Jak uniknąć podobieństwa nazw między klasami a rodzimymi? [Zamknięte]

9

Właśnie natrafiłem na „interesujący problem”, o którym chciałbym poznać Twoją opinię:

Rozwijam system i z wielu powodów (tj. Abstrakcja, niezależność technologiczna itp.) Tworzymy własne typy wymiany informacji.

Na przykład: jeśli istnieje metoda o nazwie SendEmail i wywoływana przez logikę biznesową, to ma ona parametr typu OurCompany.EMailMessage, który jest obiektem całkowicie niezależnym od technologii i zawiera tylko „istotne dla biznesu dane” (dla wystąpienie, brak informacji o kodowaniu głowy).

Wewnątrz funkcji SendEmail uzyskujemy te informacje z naszego obiektu EMailMEssage i tworzymy obiekt MailMessage (ten jest specyficzny dla technologii), aby można go było przesyłać przez sieć.

Jak widać, nasza klasa ma bardzo podobną nazwę do „rodzimej” klasy językowej. Problem w tym, że to jest dokładnie to, czym one są, wiadomości e-mail, więc trudno jest znaleźć dla nich inną znaczącą nazwę.

Czy często masz ten problem? Jak sobie z tym radzisz?

Edycja: @mgkrebbs właśnie skomentował używanie w pełni kwalifikowanych nazw. Takie jest nasze obecne podejście, ale trochę zbyt szczegółowe, IMHO. Chciałbym coś czystszego, jeśli to możliwe.

naming coding-standards variables

— JSBach
źródło

2

Zawsze stosowanie kwalifikacji wydaje się praktycznym rozwiązaniem, choć nieco gadatliwym. Użyj OurCompany.EMailMessage dla jednego typu i SendEmailClass.EMailMessage (lub cokolwiek innego) dla drugiego. Czy jest jakiś problem z przyjęciem tego podejścia?

— mgkrebbs

Tak, myślałem o tym, ale robi się pełno. Chciałbym coś „czystszego”, ale zaproponowane przez ciebie rozwiązanie jest moje obecne. Dodam to do objaśnienia

— JSBach

3

Nazwy pochodzą z kontekstu. Zwykle przestrzeń nazw lub coś takiego. Więc to nie powinien być problem.

— deadalnix

+1, podoba mi się to pytanie. Kiedyś zadałem to pytanie instruktorowi około 7 lat temu, a on pomyślał, że jestem kompletnym „....” :)

— NoChance 24.11.11

Jakiego języka używasz? Odpowiedź zależy od języka. Ogólnie odpowiedź brzmi „użyj przestrzeni nazw”. W jednej aplikacji Java dość powszechne jest używanie tej samej nazwy klasy przez pół tuzina bibliotek.

— kevin cline

3

Jest to problem dotyczący przestrzeni nazw, której zamierzasz użyć w swoim projekcie.

Zasadniczo przestrzeń nazw to zbiór słów kluczowych dostarczonych przez wszystkie Twoje klasy i / lub wszystkie klasy, których chcesz użyć w swoim projekcie (w tym standardowe klasy zwykle dostarczane z językiem / kompilatorem / IDE).

Ponieważ przestrzeń nazw jest kolekcją, stosuje się pewne podstawowe zasady, aby zapobiec tworzeniu bałaganu terminów bez powiązanego zachowania, a niektóre języki, takie jak C #, pozwalają również definiować własną przestrzeń nazw jak zwykle i używać jej również w innych klasach.

Nie myl przestrzeni nazw z podstawowym słowem kluczowym języka, oba są zbiorem słów kluczowych, ale z dużą różnicą między nimi: możesz modyfikować przestrzeń nazw, ale zwykle nie możesz modyfikować podstawowych słów kluczowych języka. Suma między obszarem nazw użytym w projekcie a podstawowymi słowami kluczowymi używanego języka daje całkowitą liczbę słów kluczowych.

Temat jest szeroko dyskutowany w Internecie, mogę zaproponować podstawowe wyszukiwanie za pomocą terminów „przestrzeń nazw [Twój język]” lub coś w tym rodzaju. Nie odpowiadam bezpośrednio na twoje pytanie tylko dlatego, że możesz mieć inne podejście do różnych języków.

— Micro
źródło

3

Mój stary zespół programistów używa do dodawania akronimu aplikacji w każdej spersonalizowanej klasie. Mieliśmy na przykład klasę ABCEmail .

Myślę, że jest to prostsze niż poleganie na przestrzeni nazw, ale może być również uzupełniającym rozwiązaniem do korzystania z przestrzeni nazw.

Wreszcie, ponieważ tworzysz nowy obiekt, oznacza to, że obiekt macierzysty nie odpowiada Twoim potrzebom, więc nazwa Twojego pliku e-mail może być CustomizedEmail , AdvancedEmail ... itd.

— Amina
źródło

1

Zgodziłeś się na ostatni punkt, ale dlaczego miałby OAEmailbyć lepszy niż OurApplication.Email? OAEMailma wpływ na każdą część oprogramowania, podczas gdy notacja przestrzeni nazw ma wpływ tylko tam, gdzie następuje konwersja i obie klasy są używane w tym samym pliku źródłowym.

— Steven Jeuris

1

Myślę, że prefiks jest dobrym pomysłem, gdy twój język nie obsługuje przestrzeni nazw. Ale jeśli język obsługuje jakąś formę w przestrzeni nazw, to użyj go (to jest problem, którego nazwy zostały zaprojektowane, aby rozwiązać!). '

— Martin York

@Steven Jeuris: Nazwę klasy należy wybrać po jej utworzeniu. Później uważam to za złą praktykę, aby to zmienić ... z powodu wszystkich niepotrzebnych skutków.

— Amine,

@Loki Astari: Nie wiem, którego IDE używasz, ale uważam, że łatwiej jest obsługiwać inną nazwę klasy podczas wyszukiwania lub otwierania danej klasy. Widziałem projekty z dostosowaną wersją „e-maila” i za każdym razem, gdy chciałem otworzyć plik, musiałem przeglądać kilka przestrzeni nazw. Twój punkt jest nadal aktualny. Wydaje mi się, że zależnie od organizacji pakietu, ile niestandardowych klas zostanie utworzonych.

— Amine

1

@ Amine: Nie zdawałem sobie sprawy, że tak naprawdę dyskutujesz przeciwko przestrzeniom nazw. Sugeruję, abyś poczytał trochę więcej o przestrzeniach nazw, aby zobaczyć wszystkie zalety korzystania z nich: enkapsulację, eliminację dwuznaczności, mniej nadmiarowości, ... Ps: Większość współczesnych IDE ma funkcje wyszukiwania, które pozwalają szybko znaleźć plik źródłowy bez konieczności przeglądania hierarchia. Co do twojego komentarza: ciągłe refaktoryzacja jest częścią rozwoju oprogramowania. Kiedy możesz wymyślić bardziej odpowiednią nazwę, duży wpływ lub nie, powinieneś rozważyć zmianę nazwy. Najlepiej jednak najpierw omówić to z kolegami.

— Steven Jeuris,

3

Jakiego języka używasz? Odpowiedź zależy od języka. Ogólnie odpowiedź brzmi „użyj przestrzeni nazw”. Prawie nigdy nie zmieniłbym nazwy typu, aby uniknąć konfliktu z zewnętrzną przestrzenią nazw.

W pojedynczej aplikacji Java dość często zdarza się, że ta sama nazwa klasy (np. „Data”) jest zdefiniowana w pół tuzinie przestrzeni nazw. Jeśli jedna klasa musi używać dwóch oddzielnych klas Date, wówczas jedna z klas Date musi być w pełni kwalifikowana wszędzie tam, gdzie się pojawi, ponieważ Java nie obsługuje aliasów typów. W C ++ życie jest łatwiejsze; możesz po prostu zmienić nazwę jednego z nich za pomocą typedef.

— Kevin Cline
źródło

Już miałem opublikować podobną odpowiedź, ale zamiast aliasu C ++ przykład chciałem wspomnieć o używaniu dyrektywy C # w aliasie .

— Steven Jeuris,

@Steven: Chciałem wspomnieć o C # zamiast C ++, ale minęło kilka lat, odkąd programowałem w C # i nie byłem pewien.

— kevin cline

2

Czy często masz ten problem? Jak sobie z tym radzisz?

To zależy od używanego języka. W c ++ i java ten problem rozwiązuje się za pomocą przestrzeni nazw. Używam c ++ i zdarza się, że mam różne klasy o tej samej nazwie. To nie jest problem, ponieważ są w różnych przestrzeniach nazw.

W innych językach nie ma innej drogi, jak tylko podanie różnych nazw.

— BЈовић
źródło

Dla komputera nie stanowi to problemu, ale dla programisty może być, ponieważ na przykład masz EmailMessage i MailMessage.

— JSBach

@Oscar Oczywiście. W przypadku komputera może być xyz123i nadal działa tak samo. Nie widzę innego sposobu niż gadanie (powiedziałeś w komentarzach, że próbujesz tego uniknąć).

— BЈовић

2

Twoje pytanie jest bardzo dobre. Co powiesz na to, jeśli przedrostek twojej metody ma prefiks taki jak U (lub u) lub cls (skrót od klasy)? Dla przykładów:

clsEMailMEssage lub uEMailMEssage

Nie wymaga to dużo pisania i od razu można stwierdzić, że typ jest „twój”.

Edytuj - w odpowiedzi na pierwsze 2 komentarze:

Chciałbym zwrócić uwagę czytelnika na fakt, że: Nie wszystkie węgierskie notacje są sobie równe. Trzeba odróżnić systemie węgierskim i Aplikacji węgierskim zakładam, że powyższa sugestia następujący typ Aplikacje węgierski, który nie jest szkodliwy.

Szkoda związana z notacją węgierską systemową, taka jak nazywanie identyfikatora intID, nie występuje w powyższej sugestii.

Aby uzyskać więcej informacji na ten temat, zobacz: Poprawianie błędnego kodu - Niepoprawne oprogramowanie

— Bez szans
źródło

3

Za każdym razem, gdy ktoś poleca węgierski zapis, Bóg zabija kociaka.

— Konamiman

2

BIgHUmpCAmelCAsing też nie pomaga.

— Steven Jeuris

Komentarze powyżej są mile widziane. Pls widzę moje zmiany, chociaż wiem, że niektórzy z nas nie zmienią zdania, w końcu kto chce zabić kota? :)

— NoChance 25.11.11

Usunąłem głosowanie w dół, gdy dodaliście jakieś uzasadnienie. Nie zgadzam się jednak, że w tym scenariuszu aplikacje węgierskie są bardziej odpowiednie niż nazwy. Gdy język obsługuje aliasy, jest to o wiele bardziej odpowiednie rozwiązanie. Zobacz odpowiedź Kevina Cline'a .

— Steven Jeuris,

@Steven Jeuris, dzięki za komentarz. Przestrzenie nazw są idealne, z wyjątkiem tego, że pisanie ich jest długie, sprawdzę podany link.

— NoChance,