Vấn đề đặt tên: Có nên đổi tên thành một thứ gì đó hay không? [đóng cửa]

Chương của chú Bob về các tên trong Clean Code khuyên bạn nên tránh mã hóa tên, chủ yếu liên quan đến ký hiệu Hungary. Ông cũng đặc biệt đề cập đến việc loại bỏ Itiền tố khỏi các giao diện, nhưng không hiển thị các ví dụ về điều này.

Hãy giả sử như sau:

• Sử dụng giao diện chủ yếu là để đạt được khả năng kiểm tra thông qua tiêm phụ thuộc
• Trong nhiều trường hợp, điều này dẫn đến việc có một giao diện với một người thực hiện

Vì vậy, ví dụ, hai cái này nên được đặt tên là gì? Parservà ConcreteParser? Parservà ParserImplementation?

public interface IParser {
    string Parse(string content);
    string Parse(FileInfo path);
}

public class Parser : IParser {
     // Implementations
}

Hoặc tôi nên bỏ qua đề xuất này trong các trường hợp thực hiện đơn lẻ như thế này?

Trong khi nhiều người, bao gồm cả "Chú Bob", khuyên không nên sử dụng Ilàm tiền tố cho các giao diện, thì làm như vậy là một truyền thống được thiết lập tốt với C #. Nói chung, nên tránh. Nhưng nếu bạn đang viết C #, bạn thực sự nên tuân theo các quy ước của ngôn ngữ đó và sử dụng nó. Không làm như vậy sẽ gây ra sự nhầm lẫn lớn với bất kỳ ai khác quen thuộc với C #, những người cố gắng đọc mã của bạn.

Giao diện là khái niệm logic quan trọng, do đó, giao diện phải mang tên chung. Vì vậy, tôi muốn có

interface Something
class DefaultSomething : Something
class MockSomething : Something

hơn

interface ISomething
class Something : ISomething
class MockSomething : ISomething

Cái sau có một số vấn đề:

1. Một cái gì đó chỉ là một triển khai của IS Something, nhưng nó là cái có tên chung, như thể nó đặc biệt.
2. MockS Something dường như bắt nguồn từ Something, nhưng thực hiện IS Something. Có lẽ nó nên được đặt tên là MockIS Something, nhưng tôi chưa bao giờ thấy điều đó trong tự nhiên.
3. Tái cấu trúc là khó hơn. Nếu một cái gì đó bây giờ là một lớp và bạn chỉ phát hiện ra rằng bạn phải giới thiệu một giao diện, giao diện đó nên được đặt tên giống nhau, bởi vì nó phải trong suốt cho khách hàng cho dù loại đó là một lớp cụ thể, một lớp trừu tượng hay một giao diện . Một cái gì đó phá vỡ điều đó.

Đây không chỉ là về quy ước đặt tên. C # không hỗ trợ nhiều kế thừa, do đó, việc sử dụng ký hiệu Hungary này có một lợi ích nhỏ dù bạn đang thừa hưởng từ một lớp cơ sở và thực hiện một hoặc nhiều giao diện. Vậy đây ...

class Foo : BarB, IBarA
{
    // Better...
}

... thích hơn thế này ...

class Foo : BarB, BarA
{
    // Dafuq?
}

IMO

Không không không.

Các quy ước đặt tên không phải là một chức năng của fandom chú Bob của bạn. Chúng không phải là một chức năng của ngôn ngữ, c # hoặc cách khác.

Chúng là một chức năng của cơ sở mã của bạn. Ở một mức độ thấp hơn nhiều của cửa hàng của bạn. Nói cách khác, cái đầu tiên trong cơ sở mã đặt tiêu chuẩn.

Chỉ sau đó bạn có thể quyết định. Sau đó chỉ cần nhất quán. Nếu ai đó bắt đầu không nhất quán hãy lấy đi súng nerf của họ và khiến họ cập nhật tài liệu cho đến khi họ hối cải.

Khi đọc một cơ sở mã mới nếu tôi không bao giờ thấy Itiền tố tôi ổn, bất kể ngôn ngữ. Nếu tôi thấy một cái trên mọi giao diện thì tôi ổn. Nếu tôi đôi khi nhìn thấy một, ai đó sẽ trả tiền.

Nếu bạn thấy mình trong bối cảnh hiếm hoi của việc thiết lập tiền lệ này cho cơ sở mã của bạn, tôi khuyên bạn nên xem xét điều này:

Là một lớp khách hàng, tôi có quyền không nói những gì tôi đang nói. Tất cả những gì tôi cần là một cái tên và một danh sách những thứ tôi có thể gọi với cái tên đó. Những điều đó có thể không thay đổi trừ khi tôi nói như vậy. Tôi sở hữu phần đó. Những gì tôi đang nói, giao diện hay không, không phải là bộ phận của tôi.

Nếu bạn lẻn Ivào tên đó, khách hàng không quan tâm. Nếu không có I, khách hàng không quan tâm. Những gì nó đang nói có thể là cụ thể. Nó có thể không. Vì nó không gọi newnó theo bất kỳ cách nào nó làm cho không có sự khác biệt. Là khách hàng, tôi không biết. Tôi không muốn biết.

Bây giờ là một con khỉ mã nhìn vào mã đó, ngay cả trong java, điều này có thể quan trọng. Rốt cuộc, nếu tôi phải thay đổi một triển khai thành một giao diện, tôi có thể làm điều đó mà không cần nói với khách hàng. Nếu không có Itruyền thống tôi thậm chí không thể đổi tên nó. Đó có thể là một vấn đề vì bây giờ chúng tôi phải biên dịch lại máy khách vì mặc dù nguồn không quan tâm đến nhị phân. Một cái gì đó dễ bỏ lỡ nếu bạn không bao giờ thay đổi tên.

Có lẽ đó không phải là vấn đề với bạn. Có thể không. Nếu có, đó là một lý do tốt để quan tâm. Nhưng đối với tình yêu của đồ chơi bàn không yêu cầu chúng ta chỉ nên mù quáng làm điều này bởi vì đó là cách nó được thực hiện trong một số ngôn ngữ. Hoặc có một lý do tốt chết tiệt hoặc không quan tâm.

Nó không phải là sống với nó mãi mãi. Đó là về việc không cho tôi tào lao về cơ sở mã không tuân theo tâm lý cụ thể của bạn trừ khi bạn chuẩn bị khắc phục "sự cố" ở mọi nơi. Trừ khi bạn có lý do chính đáng, tôi không nên đi theo con đường ít kháng cự nhất đối với tính đồng nhất, đừng đến với tôi để giảng về sự phù hợp. Tôi có nhiều thứ tốt hơn để làm.

Có một sự khác biệt nhỏ giữa Java và C # có liên quan ở đây. Trong Java, mọi thành viên đều là ảo theo mặc định. Trong C #, mọi thành viên đều được niêm phong theo mặc định - ngoại trừ các thành viên giao diện.

Các giả định đi kèm với điều này ảnh hưởng đến hướng dẫn - trong Java, mọi loại công khai nên được coi là không phải là cuối cùng, theo Nguyên tắc thay thế của Liskov [1]. Nếu bạn chỉ có một triển khai, bạn sẽ đặt tên cho lớp Parser; nếu bạn thấy rằng bạn cần nhiều triển khai, bạn sẽ chỉ cần thay đổi lớp thành một giao diện có cùng tên và đổi tên triển khai cụ thể thành một mô tả.

Trong C #, giả định chính là khi bạn nhận được một lớp (tên không bắt đầu bằng I), đó là lớp bạn muốn. Xin lưu ý bạn, đây không phải là chính xác gần 100% - một ví dụ điển hình sẽ là các lớp như Stream(mà thực sự phải là một giao diện, hoặc một vài giao diện), và mọi người đều có hướng dẫn và nền tảng riêng từ các ngôn ngữ khác. Ngoài ra còn có các trường hợp ngoại lệ khác như Basehậu tố được sử dụng khá rộng rãi để biểu thị một lớp trừu tượng - giống như với một giao diện, bạn biết loại được cho là đa hình.

Ngoài ra còn có một tính năng tiện dụng tuyệt vời khi để lại tên không có tiền tố I cho chức năng liên quan đến giao diện đó mà không phải dùng đến việc biến giao diện thành một lớp trừu tượng (sẽ bị tổn thương do thiếu tính kế thừa nhiều lớp trong C #). Điều này đã được phổ biến bởi LINQ, sử dụng IEnumerable<T>làm giao diện và Enumerablelà kho lưu trữ các phương thức áp dụng cho giao diện đó. Điều này là không cần thiết trong Java, nơi các giao diện cũng có thể chứa các triển khai phương thức.

Cuối cùng, Itiền tố được sử dụng rộng rãi trong thế giới C # và bằng cách mở rộng, thế giới .NET (vì phần lớn mã .NET được viết bằng C #, nên tuân theo hướng dẫn C # cho hầu hết các giao diện công cộng). Điều này có nghĩa là bạn gần như chắc chắn sẽ làm việc với các thư viện và mã theo ký hiệu này và việc áp dụng truyền thống để ngăn ngừa sự nhầm lẫn không cần thiết - không giống như bỏ qua tiền tố sẽ giúp mã của bạn trở nên tốt hơn :)

Tôi cho rằng lý luận của chú Bob là như thế này:

IBananalà khái niệm trừu tượng của chuối. Nếu có thể có bất kỳ lớp triển khai nào không có tên nào tốt hơn Banana, thì sự trừu tượng hóa là hoàn toàn vô nghĩa, và bạn nên bỏ giao diện và chỉ sử dụng một lớp. Nếu có một tên tốt hơn (giả sử, LongBananahoặc AppleBanana), không có lý do gì để không sử dụng Bananalàm tên của giao diện. Do đó, việc sử dụng Itiền tố biểu thị rằng bạn có một sự trừu tượng hóa vô dụng, điều này làm cho mã khó hiểu hơn mà không có lợi ích. Và vì OOP nghiêm ngặt sẽ giúp bạn luôn mã hóa các giao diện, nên nơi duy nhất bạn không thấy Itiền tố trên một loại sẽ là trên một hàm tạo - tiếng ồn khá vô nghĩa.

Nếu bạn áp dụng điều này cho IParsergiao diện mẫu của mình , bạn có thể thấy rõ rằng sự trừu tượng hoàn toàn nằm trong lãnh thổ "vô nghĩa". Hoặc là có điều gì đó cụ thể về việc thực hiện cụ thể của một phân tích cú pháp (ví dụ JsonParser, XmlParser...), hoặc bạn chỉ nên sử dụng một lớp. Không có thứ gọi là "triển khai mặc định" (mặc dù trong một số môi trường, điều này thực sự có ý nghĩa - đáng chú ý là COM), hoặc có một triển khai cụ thể hoặc bạn muốn có một lớp trừu tượng hoặc các phương thức mở rộng cho "mặc định". Tuy nhiên, trong C #, trừ khi cơ sở mã của bạn đã bỏ qua I-prefix, hãy giữ nó. Chỉ cần ghi chú tinh thần mỗi khi bạn thấy mã như thế class Something: ISomething- điều đó có nghĩa là ai đó không giỏi làm theo YAGNI và xây dựng trừu tượng hợp lý.

[1] - Về mặt kỹ thuật, điều này không được đề cập cụ thể trong bài viết của Liskov, nhưng nó là một trong những nền tảng của bài báo OOP gốc và trong bài đọc về Liskov của tôi, cô ấy đã không thách thức điều này. Theo cách hiểu ít nghiêm ngặt hơn (một ngôn ngữ được sử dụng bởi hầu hết các ngôn ngữ OOP), điều này có nghĩa là bất kỳ mã nào sử dụng loại công khai nhằm thay thế (tức là không phải là cuối cùng / niêm phong) phải hoạt động với bất kỳ triển khai tuân thủ nào của loại đó.

Vì vậy, ví dụ, hai cái này nên được đặt tên là gì? Trình phân tích cú pháp và ConcreteParser? Trình phân tích cú pháp và Trình phân tích cú pháp?

Trong một thế giới lý tưởng, bạn không nên đặt tiền tố tên của mình bằng một tay ngắn ("Tôi ...") mà chỉ để tên thể hiện một khái niệm.

Tôi đã đọc ở đâu đó (và không thể cung cấp nó) ý kiến ​​rằng quy ước IS Something này dẫn bạn xác định khái niệm "IDollar" khi bạn cần một lớp "Dollar", nhưng giải pháp chính xác sẽ là một khái niệm gọi đơn giản là "Tiền tệ".

Nói cách khác, quy ước đưa ra một cách dễ dàng cho những khó khăn trong việc đặt tên và những điều dễ hiểu là sai một cách tinh tế .

Trong thế giới thực, các khách hàng của mã của bạn (có thể là "bạn đến từ tương lai") cần có thể đọc nó sau và làm quen với nó càng nhanh (hoặc càng ít nỗ lực) càng tốt (cung cấp cho khách hàng mã của bạn những gì họ mong đợi để có được).

Công ước IS Something, giới thiệu tên cruft / bad. Điều đó nói rằng, cruft không phải là cruft thực *), trừ khi các quy ước và thực tiễn được sử dụng trong việc viết mã không còn thực tế nữa; nếu quy ước nói "sử dụng IS Something", thì tốt nhất là sử dụng nó, để phù hợp (và hoạt động tốt hơn) với các nhà phát triển khác.

*) Tôi có thể thoát khỏi việc nói rằng "cruft" này không phải là một khái niệm chính xác nào :)

Như các câu trả lời khác đề cập, tiền tố tên giao diện của bạn Ilà một phần của hướng dẫn mã hóa cho khung .NET. Vì các lớp cụ thể thường được tương tác nhiều hơn so với các giao diện chung trong C # và VB.NET, nên chúng là lớp đầu tiên trong các sơ đồ đặt tên và do đó nên có các tên đơn giản nhất - do đó, IParsercho giao diện và Parsercho việc triển khai mặc định.

Nhưng trong trường hợp Java và các ngôn ngữ tương tự, nơi các giao diện được ưa thích thay vì các lớp cụ thể, chú Bob đã đúng ở chỗ Icần loại bỏ và các giao diện nên có tên đơn giản nhất - Parserví dụ như giao diện trình phân tích cú pháp của bạn. Nhưng thay vì một tên dựa trên vai trò như thế ParserDefault, lớp nên có một tên mô tả cách trình phân tích cú pháp được triển khai :

public interface Parser{
}

public class RegexParser implements Parser {
    // parses using regular expressions
}

public class RecursiveParser implements Parser {
    // parses using a recursive call structure
}

public class MockParser implements Parser {
    // BSes the parsing methods so you can get your tests working
}

Đây là, ví dụ, làm thế nào Set<T>, HashSet<T>và TreeSet<T>được đặt tên.

Bạn đúng ở chỗ quy ước I = giao diện này phá vỡ quy tắc (mới)

Ngày xưa, bạn sẽ thêm tiền tố vào mọi thứ với kiểu intCount boolFlag, v.v.

Nếu bạn muốn đặt tên cho những thứ không có tiền tố, nhưng cũng nên tránh 'ConcreteParser', bạn có thể sử dụng các không gian tên

namespace myapp.Interfaces
{
    public interface Parser {...
}


namespace myapp.Parsers
{
    public class Parser : myapp.Interfaces.Parser {...
}