Khi truyền tên tệp cho một phương thức, tôi có nên sử dụng FileInfo hoặc tên tệp thuần túy không?

Question

Vâng, tiêu đề nói lên tất cả. Khi chuyển tên tệp cho một phương thức, tôi có nên sử dụng đối tượng FileInfo hoặc tên tệp thuần túy (chuỗi) không? Tại sao tôi thích cái này đến cái kia?

Một số đồng nghiệp của tôi muốn viết phương pháp như thế này:

• khoảng trống xuất khẩu (FileInfo fileInfo)

Là nó tốt hơn hơn:

• khoảng trống xuất khẩu (string fileName)

Cảm ơn!

Answer 1

Tôi thường chỉ sử dụng một số string - đơn giản hơn trong hầu hết các trường hợp. Nếu không, bạn có thể chỉ cần tạo một mới FileInfo từ chuỗi ở địa điểm đầu tiên.

Nếu bạn đang tạo phương pháp, bạn luôn có thể cung cấp quá tải để cho phép cả hai.

Tất nhiên, nếu bạn biết rằng bạn định gọi nó ở đâu, bạn thường là có là FileInfo, đó là một vấn đề khác.

Tôi có thể thấy quan điểm của đồng nghiệp - theo một số cách, FileInfo là cách "rõ ràng" hơn để biểu thị thông số. Tôi nghĩ rằng string là cách tiếp cận thực dụng hơn mặc dù :)

Answer 2

Tôi sẽ nói điều đó phụ thuộc :) Nhiều thao tác tệp tĩnh trên lớp Tệp cho phép một số thứ có tên tệp. Sự trừu tượng của một Tệp không phải là thường hữu ích trong .NET Framework, vì vậy tôi thiên về việc sử dụng một chuỗi ký tự và biểu thị trong tên đối số đó là gì.

Answer 3

Tôi nghĩ rằng tên tệp sẽ đủ nếu nó thực hiện tương tự.

Answer 4

Thông thường tôi sẽ chuyển chuỗi. Tuy nhiên, bạn có thể quá tải phương pháp để làm cho mọi người hạnh phúc.

Answer 5

Sự khác biệt chủ yếu là có một chút kiểm tra đang diễn ra; constructor của FileInfo thực hiện kiểm tra một tham số rỗng hoặc không hợp lệ rõ ràng. Có một vài thứ khác nữa; lấy một FileInfo về cơ bản chỉ cần đặt các onus của xử lý các trường hợp ngoại lệ từ các nhà xây dựng FileInfo trên mã gọi, như trái ngược với mã của bạn.

Dưới đây là tài liệu tham khảo MSDN cho các nhà xây dựng FileInfo cho thấy những gì các nhà xây dựng có thể ném:

http://msdn.microsoft.com/en-us/library/system.io.fileinfo.fileinfo.aspx

Answer 6

tôi sẽ làm theo quy ước của việc sử dụng hơi nước. Đây là cách tôi thấy hầu hết I/O được thực hiện. Điều đó có ý nghĩa với tôi:

void Export(string s) 
{ 
    Stream fs = new FileStream(s); //think this is correct 
    Export(fs); 
} 
void Export(Stream s) 
{ 
    s.Write (...); 
    ... 
} 

Tôi đồng ý, FileInfo chưa bao giờ hữu ích đối với tôi. gắn bó với chuỗi hoặc sử dụng luồng có thể là FileStream, MemoryStream, v.v.

Answer 7

Nếu bạn đang làm việc trên mã liên quan đến những đồng nghiệp này, tôi sẽ sử dụng FileInfo.Nó thực sự không quan trọng nhiều nhưng viết mã theo cách người khác mong đợi nó làm giảm sự bảo trì, tăng tính nhất quán, và thường làm cho mọi người hạnh phúc.

Tôi sẽ chỉ ra rằng tôi không thích ý tưởng sử dụng FileInfo vì mục đích đặt kiểm tra tính hợp lệ cho chức năng gọi, như được chỉ ra bởi McWafflestix. Nếu một cái gì đó phá vỡ giữa chức năng gọi và chức năng được gọi, nó sẽ không bị bắt. Nó sẽ không nhất thiết phải bị bắt nếu bạn sử dụng một chuỗi ... nhưng ít nhất nó làm cho nó rõ ràng nơi mà vấn đề có thể xảy ra. Và bạn sẽ muốn bắt ngoại lệ như vậy trong phương thức được gọi là anyways. Chắc chắn bạn sẽ không mở tập tin và bắt đầu đọc/ghi cho đến khi bạn đang ở trong chức năng thực tế (nếu bạn đang có, FileInfo và chuỗi có lẽ là cả hai lựa chọn sai, nhưng Stream có ý nghĩa, như TheSean gợi ý).

Answer 8

Một FileInfo sẽ thực hiện nhiều hơn để hiển thị mục đích của kiểu dữ liệu hơn là một chuỗi. Và đó gần như luôn luôn là một điều tốt. Tuy nhiên, chắc chắn có rất nhiều tiền lệ cho việc truyền một tên tệp dưới dạng một chuỗi, bao gồm hầu hết các khung công tác .NET. Tên tệp IS là một chuỗi. Có lẽ, bạn sẽ có người gọi sử dụng đối tượng FileInfo để buộc mã gọi để xác thực tên tệp (tức là xử lý ngoại lệ) thay vì gánh nặng bản thân bằng cách trả lại ngoại lệ.

Chắc chắn, trong đó có một tình trạng quá tải phương pháp sẽ loại bỏ tất cả nghi ngờ, vì vậy miễn là bạn đang xác nhận tên tập tin được thông qua tại.

Answer 9

Như thường lệ, nó phụ thuộc. Trong tất cả, nhưng cơ bản nhất của các trường hợp, tôi muốn nói bằng cách sử dụng FileInfo cung cấp cho bạn rất nhiều lợi ích với hầu như không có âm. Nghiêm ngặt OO thuyết phục sẽ nói rằng thông tin về một tập tin (đường dẫn, ngày tạo, ngày sửa đổi, vv) nên được đóng gói trong một lớp học như FileInfo. Điều này sẽ cho phép bạn linh hoạt hơn nếu xuống đường bạn cần hành vi phức tạp hơn. Nếu bạn viết mã của bạn chống lại FileInfo, nó sẽ hầu như luôn sạch hơn và ít bị lỗi hơn nếu bạn cần thay đổi.

Nếu bạn hoàn toàn không thể nghĩ ra một kịch bản mà bạn cần hành vi phức tạp hơn, và nó sẽ thực sự ném bạn đi, hãy tiếp tục và chỉ sử dụng một chuỗi.

Answer 10

1. Chuỗi không phải là PATH. Vì vậy, chuỗi không phải là cách tốt nhất để đại diện cho đường dẫn.
2. FileInfo cũng không phải là PATH, ngữ nghĩa nó đại diện cho FILE.

Vì vậy, điều này sẽ tốt hơn nếu MS cung cấp đối tượng Đường dẫn :) hoặc bạn có thể tự làm cho mình, đặc biệt nếu đây là mã nội bộ của bạn. Bằng cách này, bạn sẽ không cần phải kiểm tra các đối số PATH của bạn mỗi khi bạn làm việc với chúng. Tôi thường có nhiều cấu trúc đại diện cho các stings khác nhau, NonNullString, IdString (trường hợp không nhạy cảm), tôi tin rằng điều này làm cho mã đơn giản.