Czy powinienem dodać prefiks „Abstrakcyjny” do moich klas abstrakcyjnych? [Zamknięte]

Załóżmy, że mam klasę abstrakcyjną o nazwie Task.

Czy istnieje norma lub konwencja, która sugerowałaby, żebym AbstractTaskzamiast tego nazwał ją ?

Zgodnie z efektywną Javą Blocha (pozycja 18) przedrostek Abstract jest konwencją stosowaną w szczególnym przypadku.

Możesz łączyć zalety interfejsów i klas abstrakcyjnych, zapewniając abstrakcyjną szkieletową klasę implementacji, która będzie pasować do każdego nietrywialnego interfejsu, który eksportujesz. ... Zgodnie z konwencją szkieletowe implementacje nazywają się AbstractInterface, gdzie Interfejs to nazwa interfejsu, który implementują.

Ale Bloch zwraca również uwagę, że nazwa SkeletalInterface miałaby sens, ale podsumowuje to

konwencja abstrakcyjna jest teraz mocno ugruntowana.

Jak wskazały inne odpowiedzi, generalnie nie ma powodu, aby stosować tę konwencję nazewnictwa do wszystkich klas abstrakcyjnych.

Nie ma konwencji. Chodzi o to, co pomoże Ci, jako programistom, kodować szybciej i lepiej, a także pomóc innym zrozumieć Twój kod.

Zapytaj ludzi, którzy będą widzieć i utrzymywać kod. Co woleliby zobaczyć? Co im to ułatwi? Następnie nazwij to na podstawie tego, co chcieliby.

Inna uwaga: Konwencje kodu dla języka programowania Java: 9. Konwencje nazewnictwa sugerują brak wymagań:

Nazwy klas powinny być rzeczownikami, pisane wielkimi literami, z pierwszą literą każdego wewnętrznego słowa pisanego wielkimi literami. Staraj się, aby nazwy klas były proste i opisowe. Używaj całych słów, unikając akronimów i skrótów (chyba że skrót jest o wiele szerszy niż długi formularz, taki jak URL lub HTML).

Nie. Intellisense w sposób trywialny powie mi, czy jest abstrakcyjne, więc tutaj po prostu łamiesz DRY.

Jest to w pewnym sensie kwestia preferencji (ale graniczna zła praktyka), ale większość ludzi nie lubi widzieć części kwalifikatorów w imieniu klasy.

Większość IDE i tak sprawi, że informacje te będą łatwo dostępne, więc umieszczenie ich w nazwie nie jest konieczne, a po prostu pominięcie tego będzie czystsze. Przypomina węgierską notację do nazewnictwa zmiennych, a to z pewnością uważane jest obecnie za złą formę. Polecam po prostu to nazwać Task.

W .NET często widuje się użycie „Base” jako sufiksu oznaczającego abstrakcyjną klasę podstawową. Odłożyłbym się do innych odpowiedzi, czy jest to powszechna praktyka w Javie.

Moim zdaniem nazwa jednostki nie powinna przekazywać informacji o jej strukturze typu, ale o jej semantyce. Dlatego nie ma sensu definiować swojej klasy jako „AbstractSomething”, jeśli abstrakcja nie jest częścią jej celu działania. To, że jest to podstawowa klasa abstrakcyjna, jest widoczne dla programisty i nie musi być odzwierciedlone w nazwie.

Jeśli jednak idealnie nadaje się do nazywania implementacji fabryki abstrakcyjnej nazwą AbstractFactory, ponieważ ma to związek z intencją klasy.

Ogólnie rzecz biorąc, preferuj konwencję nazewnictwa, która pomaga przekazać jak najwięcej informacji o celu twojej klasy.

Podobnie, trzymaj się z dala od SomethingImpl. Nie obchodzi nas, że jest to implementacja, a nie klasa podstawowa. Jeśli twoja hierarchia klas jest odpowiednio zaprojektowana do dziedziczenia, to ktoś może ją odziedziczyć. Z pewnością nie byłoby w nich żadnej wartości dodającej więcej sufiksów „Impl” lub innych artefaktów. Dodanie sufiksu „Interfejs” lub prefiksu „I” również nie ma żadnej wartości.

Rozważać:

IVehicle <-- IMotoredVehicle <-- AbstractCar <-- CarImpl

W przeciwieństwie do:

Vehicle <-- MotoredVehicle <-- Car <-- DefaultCar
                                   <-- Ferrari
                                   <-- Trabi

Zdecydowanie wolę ten drugi.

To w pewnym sensie podobny do rażącym nadużyciem z notacja węgierska ten ostatni dał mu swoją złą reputację , jak ludzie zaczęli błędnie interpretują go jako wymagające deweloperom poprzedzić ich zmienne ze wskaźnikiem typu zmiennej. Chociaż może to czasem mieć swoje zastosowania (głównie, jeśli jesteś leniwy, aby sprawdzić definicję typu), jest to w większości bezużyteczne. Oryginalnym pomysłem Simonyi z notacją węgierską było użycie go jako mnemonika, aby przypomnieć twórcy o możliwościach jednostki, a nie jej rodzaju.

Dobrą zasadą jest, aby nie włączać właściwości do nazwy, które są oczywiste ze składni. Ponieważ w Javie musisz oznaczyć klasę abstrakcyjną trafnie nazwanym abstractsłowem kluczowym, nie zawarłbym jej w nazwie. Na przykład w C ++ sprawa nie jest tak jednoznaczna, ale przynajmniej kompilator powie ci, kiedy niepoprawnie użyłeś klasy abstrakcyjnej. W czymś takim jak Python, wyraźne nazywanie klasy abstrakcyjnej jako takiej nie jest złym pomysłem.

Zwykle wyjątkiem od reguły jest niejednoznaczność nazwy. Jeśli z jakiegoś powodu istnieje konkretna podklasa Task(w innych przykładach może to być bardziej sensowne, ale niezależnie od tego), to na pewno użyj AbstractTask.

protected abstract SomeClass { }

To mówi mi, że to klasa abstrakcyjna. Dodanie przedrostka jest tautologią i anty-wzorcem i w większości przypadków nie jest właściwe, zobacz link, na którym mówi package localna przykład o byciu wyjątkiem.

W większości przypadków Abstractklasy nie powinny być częścią publicznie dostępnego interfejsu API, jeśli tak naprawdę powinien istnieć dobry powód, a dobry powód powinien zawierać oczywiście dobrą nazwę inną niż AbstractSomeClass.

W większości przypadków, jeśli nie możesz wymyślić bardziej opisowej nazwy, prawdopodobnie musisz trochę przeprojektować.

Moje pięć centów, prawdopodobnie będziesz miał implementacje tej abstrakcyjnej klasy i będą one nazywać się „SomeSpecificTask”, „TaskWithBubbles”, „StrangeTask” itd. Więc nie będzie konfliktu nazw między twoim abstrakcyjnym „Zadaniem” a nimi.

Ponadto słowo „abstrakcyjne” dotyczy składni języka, a nie jednostek domeny biznesowej, więc wolałbym nie używać go jako części nazwy.

Z drugiej strony, w jednej odpowiedzi tutaj widziałem fragment J.Bloch Effective Java, który mówi, że używanie „abstrakcji” jako części nazwy jest ugruntowaną praktyką. Może tak być. Ale tak czy inaczej, w oficjalnych konwencjach kodu Java nie ma nic na ten temat.

Jeśli pracujesz w zespole, cały zespół musi zdecydować, czy powinieneś poprzedzać klasy abstrakcyjne „Streszczenie”.

Jeśli pracujesz na własną rękę, to zależy wyłącznie od Ciebie, a nie ode mnie lub kogokolwiek innego na tej stronie.

Nie jestem programistą Java (INAJD?) I nie znam standardowej nomenklatury dla takich rzeczy, ale wydaje mi się, że Taskbrzmi to wystarczająco abstrakcyjnie, że może być samodzielne w obecnej postaci.

Co jeśli chcesz napisać abstrakcyjną AbstractSyntaxTreeklasę? A może po prostu streszczenie SyntaxTree?

To nie jest konwencjonalne i może łatwo pomylić ludzi.

Ja to zrobiłem. Dodałem „Streszczenie” jako przedrostek do mojej klasy abstrakcyjnej o nazwie AbstractOperation. Powodem, dla którego to zrobiłem, był inny pakiet, który miał nieabstrakcyjną klasę o nazwie Operacja, i pomógł mojemu zespołowi i programistom, którzy później przejęli kontrolę, unikając pomyłki między nimi.