@Legol: Nie mówię, że klasa taka jest niepotrzebna czy przesadna, a nawet przesadnie nazwana. Coś "super złożonego" musi nazywać sie w sposób super złożony i już, bo jednak każdy wyraz w nazwie klasy ma znacznie i jego usunięcie zmieniłoby sensowną interpretację nazwy.
Najzwyczajniej wygląda to dla mnie zabawnie, ale w żaden sposób nie neguję.
@tell_me_more: Nie do końca, bo czym to niby zastąpić? W jakikolwiek sposób nie pisałbyś danej funkcjonalności, to i tak chcąc ją ostatecznie enkapsulować w jakiejś postaci, musisz tę postać nazwać, więc gdzie tu ograniczenie?
Za długą nazwę zawsze można w jakiś sposób uprościć/zastąpić czymś nowym tak jak np. na człowieka tworzącego w drewnie mówimy "Stolarz" a nie "Pracownik Zakładu Wytwarzającego Wyroby Drewniane" w końcu pewne rzeczy upraszczają nam nazwy kosztem
@hbpitero: lepsza dobra długa nazwa, niż zła krótka nazwa - pełna zgoda. Ale jeśli trudno nadać dobrą krótką nazwę, to wyraźny znak, że kod jest słaby, albo językowi czegoś brakuje.
Części programu powinny robić jedną rzecz, i nie powinny być zbyt powiązane ze sobą. W Javie często trzeba robić klasy typu SomethingSomethingSomethingListener, albo SomethingSomethingSomethingSomethingFactory, bo nie ma wystarczających możliwości tworzenia abstrakcji i kod jest zbyt specyficzny. Dodanie funkcjonalności wymaga podziedziczenia i jakoś nazwania tego, co podziedziczyłeś.
Kiedyś się pisało klasy StringList, WidgetList, StringMap, itp żeby nie trzeba było castować co chwilę na Object i z powrotem, a od kiedy są templaty nie jest to potrzebne. Ale dalej Javie brakuje featurów i dlatego mamy TreeMap, HashMap, i LinkedHashMap, zamiast
@tell_me_more: Wg mnie te długie nazwy właśnie wywodzą się z luźnego powiązania a nie dużej specyficzności. W dużej specyficzności wystarczyła by klasa "MyApplicationClass" robiąca wszystko, a separacja niezależnych funkjonalności powoduje właśnie mnożenie się nazw.
Długie nazwy nie mają też wiele wspólnego z głębokością dziedziczenia, myślę, że wręcz odwrotnie gdyż luźno powiązana klasa czy nawet sam interfejs właśnie ze względu na niskie powiązanie/brak dziedziczenia musi swoją nazwą dobrze opisać co robi,
@hbpitero: Ten ProxyCreator jest powiązany z biblioteką AspectJ. Nikt by nie pisał oddzielnego ProxyCreatora, gdyby dało się napisać 1 uniwersalny działający z każdą biblioteką aop. To powiązanie wynika z konieczności i ogranicza użyteczność klasy. Jak chcesz użyć nowej biblioteki aop musisz napisać swojego ProxyCreatora i przeimplementować kupę niezwiązanego kodu.
Ten sam problem w C++ był ze stringami - każda biblioteka miała swoją klasę String. W mojej firmie mieliśmy w kodzie char*, std::string, QString i OString i konwersja między nimi była strasznie upierdliwa. A musieliśmy ich używać, bo różne biblioteki wymagały różnych klas.
W Javie jest używany praktycznie tylko String (na dodatek jest klasą-wartością, co jest wielkim plusem), i łączenie bibliotek nie wymaga od nas ciągłego konwertowania. Ale już z klasami typu User nie ma tak fajnie. Ile jest interfejsów User, Query czy Widget? To powoduje, że biblioteki czy frameworki korzystające z takich interfejsów muszą wybierać, albo opakowywać te interfejsy. I implementować tą samą funkcjonalność kilka razy i tworzyć klasy z nazwami na pół
te klasy Javy :D
#programowanie #java
Najzwyczajniej wygląda to dla mnie zabawnie, ale w żaden sposób nie neguję.
InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState
@Legol: @ppawel:
Za długą nazwę zawsze można w jakiś sposób uprościć/zastąpić czymś nowym tak jak np. na człowieka tworzącego w drewnie mówimy "Stolarz" a nie "Pracownik Zakładu Wytwarzającego Wyroby Drewniane" w końcu pewne rzeczy upraszczają nam nazwy kosztem
Części programu powinny robić jedną rzecz, i nie powinny być zbyt powiązane ze sobą. W Javie często trzeba robić klasy typu SomethingSomethingSomethingListener, albo SomethingSomethingSomethingSomethingFactory, bo nie ma wystarczających możliwości tworzenia abstrakcji i kod jest zbyt specyficzny. Dodanie funkcjonalności wymaga podziedziczenia i jakoś nazwania tego, co podziedziczyłeś.
Kiedyś się pisało klasy StringList, WidgetList, StringMap, itp żeby nie trzeba było castować co chwilę na Object i z powrotem, a od kiedy są templaty nie jest to potrzebne. Ale dalej Javie brakuje featurów i dlatego mamy TreeMap, HashMap, i LinkedHashMap, zamiast
Długie nazwy nie mają też wiele wspólnego z głębokością dziedziczenia, myślę, że wręcz odwrotnie gdyż luźno powiązana klasa czy nawet sam interfejs właśnie ze względu na niskie powiązanie/brak dziedziczenia musi swoją nazwą dobrze opisać co robi,
Ten sam problem w C++ był ze stringami - każda biblioteka miała swoją klasę String. W mojej firmie mieliśmy w kodzie char*, std::string, QString i OString i konwersja między nimi była strasznie upierdliwa. A musieliśmy ich używać, bo różne biblioteki wymagały różnych klas.
W Javie jest używany praktycznie tylko String (na dodatek jest klasą-wartością, co jest wielkim plusem), i łączenie bibliotek nie wymaga od nas ciągłego konwertowania. Ale już z klasami typu User nie ma tak fajnie. Ile jest interfejsów User, Query czy Widget? To powoduje, że biblioteki czy frameworki korzystające z takich interfejsów muszą wybierać, albo opakowywać te interfejsy. I implementować tą samą funkcjonalność kilka razy i tworzyć klasy z nazwami na pół