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

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.

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.

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.

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.

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.

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