Nazewnictwo komponentow cosTamManager

0

Witam

Moje pytanie dotyczy kwestii następującej. W projekcie , którym obecnie pracuje, panuje konwencja (a raczej przyzwyczajenie) do nazywania wielu komponentów "<zwrot związany z funkcjonalnoscia>Manager".
Interesuje mnie wasza opinia na ten temat gdyż według mnie takie nazewnictwo prowadzi do tego, że do owego komponentu pasuje każda metoda która ma jakikolwiek (nawet bardzo pośredni) związek z dana funkcjonalnością.Z biegiem czasu (kolejne rozbudowy) prowadzi to do powstawania "superklasy" która ma 5000 linii. Wspomniałem o tym architektom biorącym udział w moim projekcie jakkolwiek nie są do końca przekonani. Dlatego też szukam "społecznego dowodu słuszności" :)

pozdrawiam

0

Nie do końca rozumiem twój dylemat.. Podaj może jakiś przykład takiej niefortunnej nazwy.

0

A a nie rozumiem jaki sens jest dopisywać zawsze końcówkę Menager?
Nazwa powinna być taka by maksymalnie ułatwiała zrozumienie kodu przy czym nie wskazany jest przerost formy nad treścią.

Pierwszym twoim krokiem powinno być poznanie standardów nazewnictwa w języku/środowisku/grupie w jakich pracujesz. Najważniejsze by konwencja była zrozumiała dla ciebie i innych.
Najpowszechniejszym standardem jest pola klas i zmienne zaczynają się od małych liter a typy od dużych liter. Pozostałe litery z małej za wyjątkiem tych rozpoczynających nowe słowo w nazwie. Metody pierwsza litera duża.
Pozostałe standardy nazewnictwa są charakterystyczne dla rożnych rozwiązań. Przykładowo w C++ Symbian rozróżnia się 4 podstawowe rodzaje klas nazywane od swoich prefiksów: T-klasy, R-klasy, C-klasy, M-klasy. W innych systemach nie jest konieczne takie rozróżnienie, więc tych prefiksów się nie stosuje.

0
Szczawik napisał(a)

Nie do końca rozumiem twój dylemat.. Podaj może jakiś przykład takiej niefortunnej nazwy.

Teoretycznie nie mogę zdradzać nazw komponentów jakie instnieją w tym projekcie aby nie zdradzać implementacji dlatego tez użyję fikcyjnego przykładu.

Mamy powiedzmy repozytorium( magazyn danych) w którym są przechowywane informacje o płytach muzycznych. Teraz możemy sobie stworzyć komponent który obsługuje owo repozytorium . W pierwszym przypadku możemy np. komponent nazwać "MusicDataRetriever" w drugim przypadku możemy ten sam komponent nazwać "MusicDataManager". Powiedzmy ,ze mija pół roku i idzie sobie rozbudowa o tym ze np. dostęp do pewnych płyt jest ograniczony dla pewnych userów. I teraz ktoś kto będzie owa rozbudowę robił to intuicyjnie zauważy ,że funkcjonalność dostępu nie pasuje do komponentu "MusicDataRetriever" zaś MusicDataManager i kontrola dostępu nawet tak. W pierwszym przypadku powstaną dwa komponenty, każdy będzie miał swój zakres funkcjonalności, zas w drugim robi nam się pomału klasa-gigant.

( w projekcie w którym obecnie pracuje są klasy mające po kilkanaście zakresów funkcjonalności usprawiedliwionych kategorią "manager" w nazwie komponentu, co doprowadza do tego ze utrzymanie takiej klasy jest piekielnie trudne a zmiany jednej funkcjonalności często lubią popsuć inne). W związku z tym staram się przeforsować zmianę tej konwencji w owym projekcie do czego postanowiłem posiłkować się waszą opinią.

pozdrawiam

0

Czyli do kazdej wiekszej klasy dodajecie Manager, bo tak? Ja osobiscie wole stworzyc 3 klasy wiecej niz miec jedna 1000 linijkowa, bo w tym wypadku zaczyna sie w srodku robic miszmasz. Idealne dla mnie to miec klase, ktora wykonuje ma tylko jedna funkcjonalnosc, z powiedzmy 10-20 metodami po max 15-20 linijek (plus oczywiscie wszystkie skladowe, wlasciwosci, itp). Wtedy jest milo, bo rzut okiem na nazwe metody i w razie czego cialo wszystko wyjasnia. Nawet jesli klasa robi cuda, to w przypadku wielkich cudow odwoluje sie po prostu do klas pomagajacych jej w tych sprawach i wykonujacych pomniejsze elementy.

Co do ogolnosci - dodawanie do klasy Manager to pol biedy, natomiast zgodze sie, ze w takim wypadku co druga kwestia pozornie zwiazana ze sprawa tam wleci. Zgodze sie z takim podejsciem pod warunkiem, ze ow 'Manager' dziala jako wzorzec fasady i przekierowuje żądania do odpowiednich wykonawcow. A tutaj pozostaje pytanie czy taka fasada jest uzasadniona.

0
johny_bravo napisał(a)

Czyli do kazdej wiekszej klasy dodajecie Manager, bo tak?

żeby uściślić to są to wyjątki ,jakkolwiek mają one wiele tysięcy linii i nie odrzucenie tej konwencji grozi pojawieniem się kolejnych wyjątków.

Również ,nie pełnią one roli fasady większość funkcjonalności znajduje się bezpośrednio w nich. Generalnie argumentacja tej części zespołu ,która nie widzi w tym nic złego jest taka ,że zakres funkcjonalności komponentów jest opisany w dokumentacji. Jak się okazuje niezbyt dokładnie...

dzięki za opinię
pozdrawiam

0

No to moim zdaniem to, mowiac dosadnie, bzdura. Dokumentacja to jedno a klasa po 5000 linii to drugie. Dokumentacja to nie wszystko i czasem trzeba do kodu zajrzec a wtedy krzyz na droge. Co wiecej, zajrzec to pol biedy, ale rozbudowanie takiego kodu zajmuje zdecydowanie wiecej czasu niz rozlozenie klasy na 10 czesci i zmiana tylko jednej funkcjonalnej 'podklasy'. A co do powodow wiekszej ilosci czasu to wymienie chocby kilka:

  • czas potrzebny na odnalezienie sie w kodzie, ktorego sie nie widzialo pare miesiecy, badz nigdy wzrasta wrecz wykladniczo w stosunku do objetosci kodu, ktory trzeba objac na raz
  • to samo dzieje sie z czasem potrzebnym na napisanie testow danej klasy - no chyba, ze tutaj ich nie piszecie
  • skoro napisanie testu jest trudne badz go w ogole nie ma to istnieje duza szansa, ze po zmianie nastapi propagacja bledu na wszystkie klasy korzystajace z szerokiej funkcjonalnosci klasy. A skoro funkcjonalnosc jest szeroka to i klas korzystajacych wiele. Stad moze wynikac duza strata czasu na dostosowanie klas do zmiany. Generalnie im mniej klas korzysta z 'Managera' tym lepiej.
  • No i pozostaje kwestia korzystania z takiej klasy, gdzie tak naprawde nie wiadomo jaka jest jej funkcjonalnosc, bo jest zbyt szeroko sprecyzowana. Wracajac do przykladu z muzycznym repozytorium trudno po nazwie MusicDataManager dociekac czy ow manager rowniez zapisuje i odczytuje pliki, czy robi to zewnetrzna baza, czy przy okazji rowniez je odtwarza, itp. Jak dla mnie to zbyt szeroka definicja by bylo to uzyteczne.
0

Polecam książkę Head First Object-Oriented Analysis and Design.

Książka w sposób bardzo przystępny, wręcz łopatologiczny wyjaśnia jak projektować aplikację aby była maksymalnie elastyczna i co zrobić aby wprowadzanie do niej poprawek nie wymagało przeprojektowania dużej części kodu. Praktyczne rady jak pisać swoje klasy oraz przeprowadzenie "za rękę" przez cały proces projektowania i tworzenia aplikacji czynią z tej książki pozycją obowiązkową dla każdego kto chciałby pisać dobry kod obiektowy.

0
johny_bravo napisał(a)

Wracajac do przykladu z muzycznym repozytorium trudno po nazwie MusicDataManager dociekac czy ow manager rowniez zapisuje i odczytuje pliki, czy robi to zewnetrzna baza, czy przy okazji rowniez je odtwarza, itp. Jak dla mnie to zbyt szeroka definicja by bylo to uzyteczne.

I to jest właśnie teza z którą wyszedłem i szukałem tutaj jej potwierdzenia.
pozdrawiam

0

Dodam jeszcze jedna ciekawa analogie, ktora przyszla mi na mysl. W zwiazku z faktem, ze paradygmat obiektowy ma na celu przeniesienie problemu na wyzszy poziom abstrakcji czesto wzorowany na prawdziwym zyciu mozna zauwazyc tez taka kwestie. W normalnej firmie jest stanowisko 'manager', nazwijmy go szefem dzialu, zeby bylo po polsku. Taki szef dzialu nie wykonuje wszystkiego sam, bo nawet na maly dzial muzyczny (trzymajac sie przykladu) sklada sie zwykle wiele kwestii. Stad szef ma do dyspozycji asystentow, sekretarke pracownikow zaufanych i szeregowych pracownikow. Jego rola jest pilnowanie by to wszystko dzialalo jak trzeba i odpowiedzialnosc przed jego szefami. Tyle. Stad wczesniejsze skojarzenie z fasada. Co wiecej na 'funkcjonalnosc' szefa i calego dzialu skladaja sie 'funkcjonalnosci' pracownikow i umiejetnosci kierownicze szefa.

Tyle z przemyslen :)

0

Późno, ale dla mnie to nawet to 'manager' jest do bani dobrane, bo właśnie sugeruje to, o czym johny mówi: manager, controller itp z reguły są 'przekierowaczami' - zarządzają obiektami podrzędnymi, same nie implementują funkcjonalności. A jak pojedyncza klasa ma ponad 20 metod zaimplementowanych, to jest niedobrze...

w bibliotekach dla c++ używających - że tak ujmę - modern design, podział jest bardzo mocny. Nawet to, co by kusiło, często nie ma miejsca, że podam przykład z głupim stringiem: niby można do typu tekstowego wsadzić wszystkie trim, find i inne explode. A jednak, robione to jest tak, że string zajmuje się wewnętrznym przechowywaniem tekstu, a już operacjami wyższego rzędu się zajmuje klasa dziedzicząca, adapter, a nawet zewnętrzne funktory.

małe klasy mają głównie zalety: już pomijając kwestię ogarnięcia kodu, to jest mniej do rekompilacji podczas zmian, można się łatwiej podzielić modułami z zespole, prostszy refactoring, dokładniejsze i godniejsze zaufania zestawy testowe.

dopisane:
ty ghostek rację masz, ten "manager" to z niczym się nie kojarzy, po prostu tor dyskusji mnie zasugerował ;)

1 użytkowników online, w tym zalogowanych: 0, gości: 1