Problemy z nazewnictwem: czy nazwa „ISomething” powinna zostać zmieniona na „Coś”? [Zamknięte]

Rozdział wuja Boba na temat nazw w Czystym Kodzie zaleca unikanie kodowania nazw, głównie w odniesieniu do notacji węgierskiej. On także wyraźnie wymienia usunięcie Iprefiksu z interfejsów, ale nie pokazują przykłady.

Załóżmy, że:

• Wykorzystanie interfejsu służy głównie do testowania poprzez wstrzykiwanie zależności
• W wielu przypadkach prowadzi to do posiadania jednego interfejsu z jednym implementatorem

Na przykład, jak należy nazwać tych dwóch? Parseri ConcreteParser? Parseri ParserImplementation?

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

public class Parser : IParser {
     // Implementations
}

A może powinienem zignorować tę sugestię w przypadkach takich jak jedno wdrożenie?

Chociaż wiele osób, w tym „Wujek Bob”, odradza stosowanie Ijako prefiksów interfejsów, jest to dobrze znana tradycja w języku C #. Ogólnie należy tego unikać. Ale jeśli piszesz w C #, naprawdę powinieneś przestrzegać konwencji tego języka i używać go. Niezastosowanie się do tego spowoduje ogromne zamieszanie z kimkolwiek znającym C #, który próbuje odczytać twój kod.

Interfejs jest ważną logiczną koncepcją, dlatego interfejs powinien nosić nazwę ogólną. Wolałbym więc

interface Something
class DefaultSomething : Something
class MockSomething : Something

niż

interface ISomething
class Something : ISomething
class MockSomething : ISomething

Ten ostatni ma kilka problemów:

1. Coś jest tylko jedną implementacją ISomething, ale jest to nazwa ogólna, jakby była jakoś wyjątkowa.
2. MockSomething wydaje się pochodzić z czegoś, ale implementuje ISomething. Może powinien nosić nazwę MockISomething, ale nigdy nie widziałem tego na wolności.
3. Refaktoryzacja jest trudniejsza. Jeśli Coś jest teraz klasą, a później dowiesz się, że musisz wprowadzić interfejs, interfejs ten powinien mieć taką samą nazwę, ponieważ powinien być przezroczysty dla klientów, czy typ jest klasą konkretną, klasą abstrakcyjną czy interfejsem . Coś to psuje.

Nie chodzi tylko o konwencje nazewnictwa. C # nie obsługuje wielokrotnego dziedziczenia, więc to starsze użycie notacji węgierskiej ma niewielką, choć przydatną zaletę, gdy dziedziczysz od klasy podstawowej i implementujesz jeden lub więcej interfejsów. Więc to...

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

... jest lepszy od tego ...

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

IMO

Nie nie nie.

Konwencje nazewnictwa nie są funkcją twojego fandomu wujka Boba. Nie są one funkcją języka, języka C # ani żadnego innego.

Są funkcją twojej bazy kodu. W znacznie mniejszym stopniu twój sklep. Innymi słowy, pierwszy w bazie kodu ustanawia standard.

Tylko wtedy możesz zdecydować. Potem bądź konsekwentny. Jeśli ktoś zacznie być niekonsekwentny, zdejmij pistolet do krojenia i każ mu aktualizować dokumentację, aż się nawróci.

Czytając nową bazę kodu, jeśli nigdy nie widzę Iprzedrostka, czuję się dobrze, niezależnie od języka. Jeśli widzę jeden na każdym interfejsie, czuję się dobrze. Jeśli czasem go zobaczę, ktoś zapłaci.

Jeśli znajdziesz się w rzadkim kontekście ustawiania tego precedensu dla bazy kodu, zachęcam do rozważenia tego:

Jako klasa klienta zastrzegam sobie prawo do tego, żeby nie obchodzić mnie to, z czym rozmawiam. Potrzebuję tylko imienia i listy rzeczy, które mogę zadzwonić pod to imię. Nie mogą się one zmienić, chyba że tak powiem. Jestem właścicielem tej części. To, o czym rozmawiam, interfejs czy nie, nie jest moim działem.

Jeśli wślizgniesz się Iw to imię, klient nie będzie się tym przejmował. Jeśli nie I, klient nie dba o to. To, o czym mówi, może być konkretne. Może nie. Ponieważ nie wzywa newgo w żaden sposób, nie ma znaczenia. Jako klient nie wiem. Nie chcę wiedzieć

Teraz, gdy małpa kodowa patrzy na ten kod, nawet w Javie, może to być ważne. W końcu, jeśli muszę zmienić implementację na interfejs, mogę to zrobić bez powiadamiania klienta. Jeśli nie ma Itradycji, mogę nawet jej nie zmienić. Co może być problemem, ponieważ teraz musimy ponownie skompilować klienta, ponieważ chociaż źródło nie przejmuje się plikiem binarnym. Coś łatwego do przeoczenia, jeśli nigdy nie zmieniłeś nazwy.

Może to nie jest dla ciebie problem. Może nie. Jeśli tak, to dobry powód, aby się tym przejmować. Ale ze względu na zamiłowanie do zabawek biurkowych nie twierdzimy, że powinniśmy to robić na ślepo, ponieważ jest to sposób, w jaki robi się to w pewnym języku. Albo mają cholernie dobry powód, albo ich to nie obchodzi.

Nie chodzi o życie z nim na zawsze. Chodzi o to, żeby nie dać mi bzdury, że baza kodu nie jest zgodna z twoją konkretną mentalnością, chyba że jesteś przygotowany na rozwiązanie „problemu” wszędzie. Jeśli nie masz dobrego powodu, nie powinienem podążać drogą najmniejszego oporu wobec jednolitości, nie przychodź do mnie, głosząc zgodność. Mam lepsze rzeczy do zrobienia.

Jest jedna drobna różnica między Javą a C #, która jest tutaj istotna. W Javie domyślnie każdy członek jest wirtualny. W języku C # każdy element jest domyślnie zaplombowany - z wyjątkiem elementów interfejsu.

Założenia, które się z tym wiążą, mają wpływ na wytyczną - w Javie każdy typ publiczny powinien być uważany za niekończący, zgodnie z zasadą substytucji Liskowa [1]. Jeśli masz tylko jedną implementację, nazwiesz klasę Parser; jeśli uznasz, że potrzebujesz wielu implementacji, po prostu zmienisz klasę na interfejs o tej samej nazwie i zmienisz nazwę konkretnej implementacji na coś opisowego.

W języku C # głównym założeniem jest to, że kiedy dostajesz klasę (nazwa nie zaczyna się od I), to jest klasa, którą chcesz. Pamiętaj, że nie jest to w przybliżeniu 100% dokładne - typowym kontrprzykładem byłyby takie klasy Stream(które naprawdę powinien byłby być interfejsem lub kilkoma interfejsami), a każdy ma swoje własne wytyczne i pochodzenie z innych języków. Istnieją również inne wyjątki, takie jak dość powszechnie stosowany Baseprzyrostek oznaczający klasę abstrakcyjną - podobnie jak w przypadku interfejsu, wiesz, że typ powinien być polimorficzny.

Istnieje również przyjemna funkcja użyteczności polegająca na pozostawieniu nazwy bez prefiksu I dla funkcjonalności związanej z tym interfejsem bez konieczności uciekania się do tworzenia interfejsu jako klasy abstrakcyjnej (co zaszkodziłoby z powodu braku wielokrotnego dziedziczenia klas w języku C #). Zostało to spopularyzowane przez LINQ, który wykorzystuje IEnumerable<T>jako interfejs i Enumerablejako repozytorium metod mających zastosowanie do tego interfejsu. Nie jest to konieczne w Javie, gdzie interfejsy mogą również zawierać implementacje metod.

Ostatecznie Iprefiks jest szeroko stosowany w świecie C #, a przez to w świecie .NET (ponieważ zdecydowanie większość kodu .NET jest napisana w języku C #, warto stosować się do wytycznych C # dla większości publicznych interfejsów). Oznacza to, że prawie na pewno będziesz pracować z bibliotekami i kodem, który jest zgodny z tą notacją, i warto przyjąć tradycję, aby zapobiec niepotrzebnym nieporozumieniom - to nie tak, że pominięcie prefiksu poprawi kod :)

Zakładam, że rozumowanie wuja Boba było takie:

IBananajest abstrakcyjnym pojęciem banana. Jeśli może istnieć jakaś klasa implementująca, która nie miałaby lepszej nazwy niż Banana, abstrakcja jest całkowicie pozbawiona znaczenia i powinieneś porzucić interfejs i po prostu użyć klasy. Jeśli istnieje lepsza nazwa (powiedzmy LongBananalub AppleBanana), nie ma powodu, aby nie używać jej Bananajako nazwy interfejsu. Dlatego użycie Iprzedrostka oznacza, że ​​masz niepotrzebną abstrakcję, co sprawia, że ​​kod jest trudniejszy do zrozumienia bez żadnych korzyści. A ponieważ ścisłe OOP sprawi, że zawsze będziesz kodować przeciwko interfejsom, jedynym miejscem, gdzie nie zobaczysz Iprefiksu na typie, będzie konstruktor - dość bezsensowny hałas.

Jeśli zastosujesz to do przykładowego IParserinterfejsu, możesz wyraźnie zobaczyć, że abstrakcja znajduje się całkowicie na terytorium „bez znaczenia”. Albo jest coś specyficznego o konkretnej implementacji parsera (np JsonParser, XmlParser...), czy też po prostu użyć klasy. Nie ma czegoś takiego jak „domyślna implementacja” (chociaż w niektórych środowiskach rzeczywiście ma to sens - zwłaszcza COM), albo istnieje konkretna implementacja, albo potrzebujesz abstrakcyjnej metody klasy lub rozszerzenia dla „domyślnych”. Jednak w języku C #, chyba że twoja baza kodu już pomija Iprefiks -f, zachowaj go. Po prostu zanotuj za każdym razem, gdy zobaczysz kod podobny class Something: ISomething- oznacza to, że ktoś nie jest zbyt dobry w przestrzeganiu YAGNI i tworzeniu rozsądnych abstrakcji.

[1] - Technicznie rzecz biorąc, nie jest to specjalnie wspomniane w pracy Liskova, ale jest to jedna z podstaw oryginalnej pracy OOP i podczas mojego czytania Liskova nie zakwestionowała tego. W mniej ścisłej interpretacji (tej przyjętej przez większość języków OOP) oznacza to, że każdy kod używający typu publicznego, który jest przeznaczony do podstawienia (tj. Nie-końcowy / zapieczętowany) musi działać z dowolną zgodną implementacją tego typu.

Na przykład, jak należy nazwać tych dwóch? Parser i ConcreteParser? Parser i ParserImplementation?

W idealnym świecie nie powinieneś poprzedzać swojego imienia krótką ręką („Ja ...”), ale po prostu pozwól, aby nazwa wyrażała pojęcie.

Przeczytałem gdzieś (i nie mogę go zdobyć) opinię, że ta konwencja ISomething prowadzi do zdefiniowania koncepcji „IDollar”, gdy potrzebna jest klasa „Dollar”, ale poprawnym rozwiązaniem byłoby pojęcie zwane po prostu „Walutą”.

Innymi słowy, konwencja daje łatwość nazywania rzeczy, a łatwość jest subtelnie błędna .

W prawdziwym świecie klienci twojego kodu (który może być po prostu „ty z przyszłości”) muszą być w stanie przeczytać go później i zapoznać się z nim tak szybko (lub przy minimalnym wysiłku), jak to możliwe (daj klientom kodu, czego oczekują).

Konwencja ISomething wprowadza cruft / bad names. To powiedziawszy, cruft nie jest prawdziwym cruft *), chyba że konwencje i praktyki stosowane przy pisaniu kodu nie są już aktualne; jeśli konwencja mówi „użyj ISomething”, najlepiej użyć go, aby dostosować się (i lepiej pracować) do innych programistów.

*) Mogę uciec od powiedzenia tego, ponieważ „cruft” nie jest zresztą dokładną koncepcją :)

Jak wspomniano w innych odpowiedziach, prefiks nazwy interfejsu Ijest częścią wytycznych kodowania dla platformy .NET. Ponieważ w klasach C # i VB.NET częściej występują interakcje z konkretnymi klasami niż z ogólnymi interfejsami, są one najwyższej klasy w schematach nazewnictwa i dlatego powinny mieć najprostsze nazwy - stąd IParserdla interfejsu i Parserdomyślnej implementacji.

Ale w przypadku języków Java i podobnych, w których preferowane są interfejsy zamiast konkretnych klas, wujek Bob ma rację, że Ipowinny zostać usunięte, a interfejsy powinny mieć najprostsze nazwy - Parserna przykład dla interfejsu analizatora składni. Ale zamiast nazwy opartej na rolach ParserDefaultklasa powinna mieć nazwę opisującą sposób implementacji parsera :

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
}

Jest to, na przykład, w jaki sposób Set<T>, HashSet<T>i TreeSet<T>są nazywane.

Masz rację, ponieważ ta konwencja interfejsu I = łamie (nowe) reguły

W dawnych czasach poprzedzałbyś wszystko swoim typem intCounter boolFlag itp.

Jeśli chcesz nazywać rzeczy bez prefiksu, ale także unikaj „ConcreteParser”, możesz użyć przestrzeni nazw

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


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