Czy jest coś takiego jak zbyt wiele zajęć?

Question

Kiedy się rozwijasz, kiedy możesz określić, czy w swojej aplikacji masz dużo niepotrzebnych zajęć? Czy jest jakiś limit ilości klas, które powinieneś mieć?

Answer 1

Naprawdę nie ma czegoś takiego jak "zbyt wiele zajęć". To, co może być problemem, to "zbyt wiele zajęć robi to samo".

Jeśli uważasz, że masz zbyt wiele zajęć w bazie kodów, dobrym sposobem na sprawdzenie jest dodanie nowych wymagań. Wszystko, co zmusza cię do wprowadzenia pewnych zmian w kodzie. (Oczywiście w oddzielnej gałęzi kontroli źródła). Jak trudno jest dokonać tych zmian? Czy stosunkowo prosta zmiana wymaga zmodyfikowania ton i ton klas? Jeśli tak jest, to istnieje bardzo duża szansa, że ​​masz za dużo, ale problem nie dotyczy samej liczby.

W wielu przypadkach jest to kwestia osobistych preferencji. Często dochodzi do kompromisu między ponownym wykorzystaniem kodu i rozłączaniem kodu. Oddzielając wszystkie możliwe problemy i mając wiele małych klas, odrywasz wszystko od wszystkiego innego. Jednak często zdarza się, że w takich przypadkach trzeba powtórzyć kod, ponieważ wiele kodu może robić "to samo", ale z nieco innego powodu.

Z drugiej strony, jeśli upierasz się, aby nigdy nie powtórzyć niczego w kodzie, to podczas gdy dostajesz mniej klas, często kończysz z większym sprzężeniem, ponieważ jedna klasa będzie miała wiele obowiązków wobec każdego kodu, który wymaga podobnej funkcjonalności.

Najważniejsze jest w większości przypadków odporność na zmiany. Sprzężenie a ponowne wykorzystanie to coś, o co ludzie mogą się długo spierać, ale sztywność oprogramowania jest tam, gdzie argument zmienia się w rzeczywisty wysiłek (pieniądze). Sprawdź, jak trudno jest wprowadzić zmiany w kodzie. Następnie spróbuj ponownie uporządkować swoje klasy/logikę w sposób, który Twoim zdaniem byłby bardziej akceptujący zmianę i przetestuj ją ponownie. Czy nastąpiła znaczna poprawa?

Answer 2

Wszystko zależy od Twojego projektu. zależy to od twoich wymagań.
klasy musi być minimum w taki sposób, że nie ma niepożądanych klas
klasy musi być maksymalna w tym sensie, że wszystkie one mają zawierać atrybuty tam oddzielnie.

Answer 3

Ogólnie wiele zajęć oznacza, że ​​najprawdopodobniej bardzo ogólnie rozwiązałeś swoje problemy. Zwykle jest to dobre, ponieważ oznacza to, że masz nadzieję, że łatwiej będzie zmienić zachowania, gdy zajdzie taka potrzeba.

Podczas opracowywania mniejszych projektów czasami może być lepiej być bardziej szczegółowym (tj. Mniej ogólnym), aby szybciej osiągnąć cele, co może prowadzić do zmniejszenia liczby klas, ale może być trudniej zmienić w razie potrzeby.

Dopóki zajęcia są dobrze uporządkowane i mieć dobrze zdefiniowany cel to nie powinno być problemem dla wielu klas.

Co może być jak nigdy problemem jest, jeśli zajęcia są ściśle powiązane lub jeśli odpowiedzialność niektórych klasach nie są dobrze zdefiniowane. Więcej informacji na temat sprzęgania można znaleźć .

Inny problem, który może wystąpić, jest wymieniony w komentarzu poniżej. Jeśli wiele klas ma podobny kod, wystąpił problem z kopiowaniem. Zwykle prowadzi to do zmniejszonej łatwości konserwacji w systemie, ponieważ jeśli zmiana jest potrzebna w powielonym kodzie, musisz dokonać wielokrotnych zmian. Zazwyczaj jest to rozwiązywane przez dziedziczenie.

Answer 4

Aplikacja może być wszystko w jednym pliku kodu lub każda funkcja może być rozpylany w oddzielnym pliku, jedyną rzeczą, dotknięte jest maintainabiliy. Utrzymanie może oznaczać twoją zdolność do poruszania się po kodzie, lub może oznaczać, jak inni rozumieją kod, lub jeśli możliwe jest budowanie nowych wydań.

Nie wydaje mi się, aby istniały ogólne wytyczne w tym zakresie, które zawsze mają zastosowanie, zależy to od tak wielu rzeczy. Np. Podczas kodowania w JavaScript zazwyczaj używa się mniej (i większych) plików, które zawierają więcej niespokrewnionych funkcji niż w przypadku kodowania w języku C# lub C++.

Jeśli używasz programu Visual Studio 2012, to http://msdn.microsoft.com/en-us/library/bb385910.aspx i http://msdn.microsoft.com/en-us/library/dd264939.aspx zawiera informacje o tym, jak działa kodowanie danych i analiza kodu.

To jest przykład raportu z Code Metrics w Visual Studio 2012 na podstawie mojej własnej aplikacji, wartości są wyjaśnione na http://msdn.microsoft.com/en-us/library/bb385914.aspx.

Project: <<Projectname>> 
Configuration: Debug 
Scope: Project 
Assembly: <<Path>> 
Maintainability Index: 84 
Cyclomatic Complexity: 479 
Depth of Inheritance: 8 
Class Coupling: 189 
Lines of Code: 903 

Answer 5

Myślę, że to zależy, który obszar ma dużą liczbę klas. Jeśli istnieje wiele klas statycznych zawierających typową logikę biznesową, zostanie to uznane za złe, ponieważ klasy statyczne powinny być używane tylko dla typowych metod pomocniczych. Klasy statyczne nigdy nie powinny zawierać wspólnej logiki biznesowej.

Jeśli istnieją różne klasy dla różnych warstw dla przechowywania zasadniczo tych samych danych. Zostanie to uznane za złe, ponieważ klasy DTO nie powinny być duplikowane między warstwami.

Jednak jeśli zajęcia zostały stworzone po odpowiednim rozkładzie wymagań, to myślę, że to jest rzeczywiście dobry, aby mieć dużą liczbę klas.

Answer 6

Jak wielu innych zasugerował: „to zależy ...”

Zazwyczaj zależy to od kombinacji swoich metod, celów i preferencji i umiejętności członków zespołu. Jeśli jesteś bardzo surowy w testach jednostkowych, prawdopodobnie skończysz z wieloma małymi, ogólnymi lekcjami i zastrzykiem zależności. Oznacza to również, że poszczególnym członkom zespołu trudno jest dostrzec konkretną całość, którą budujecie ze wszystkich części, które są bardzo, bardzo ogólne.

Osobiście wolę myśleć w kategoriach API zbudowanego na dwóch poziomach: niższego poziomu generycznego, niezależnego i wysokiego poziomu, gdzie używam kilku fasad, reżyserów itp., Aby zaprezentować coś konkretnego i użytecznego inni koderowie. Jest to podobne do projektowania bibliotek IOS IMHO.

Answer 7

W projekcie, nad którym obecnie pracuję, zdecydowanie uważam, że używamy zbyt wielu klas - a przynajmniej zbyt wielu obiektów/instancji.

Zbudowaliśmy CMS oparty na PHP/MySQL, gdzie każdy rekord i pole w bazie danych jest reprezentowane jako obiekt w PHP. Może to skutkować dziesiątkami tysięcy wystąpień w tym samym czasie i ciągle mamy problemy z wydajnością/skończy się pamięć itp.

To oczywiście nie może być problemem w innych językach programowania lub z innymi wymaganiami , ale wydajność jest moim zdaniem również kwestią do rozważenia.

Answer 8

Kent Beck odpowiada na twoje pytanie. Jeff Langr w książce "Clean Code A Handbook of Agile Software Craftsmanship" omawia cztery zasady projektowania określone przez Kent Beck.

(w kolejności ważności)

1. Uruchamia wszystkie testy
2. zawiera nie powielania
3. wyraża intencję programisty
4. minimalizuje liczbę klas i metod

Kent sugeruje przyjęcie podejścia pragmatycznego do k eep niski poziom klasy i metody. Podaje przykład przestrzegania dogmatycznych reguł, tak jak wszystkie klasy powinny mieć interfejsy. Zwykle tak, ale czasami zdarzają się sytuacje, w których może to nie być konieczne. Ta zasada jest jednak najniższym priorytetem czterech zasad prostego projektu.

(uwaga, to jest Kent Beck opinia, nie tyle moje!)

Answer 9

filozoficzna:

Istnieje coś takiego, jak zbyt dużo niczego. Możesz mieć za dużo i za mało zajęć. Niektórzy lubią udawać, że więcej jest za darmo, ponieważ mogą używać narzędzi takich jak wyszukiwanie jako pretekst do tworzenia nadmiernie niechlujnych, trudnych w nawigacji i dużych przestrzeni wyszukiwania. Na dłuższą metę zawsze znajdziesz wymierny deficyt.

Nie jestem pewien, czy istnieje górny limit liczby klas, jakie możesz mieć. Możesz znaleźć sposoby na teleskopowanie rzeczy dodając klasy w nieskończoność, technicznie rzecz biorąc, w nieskończoność. Jeśli nie możesz mieć zbyt wielu zajęć, ale możesz dodać je w nieskończoność, to nigdy nie ukończysz programu ze względu na liczbę klas, które chcesz mieć, dlatego możesz mieć za dużo zajęć.

Liczba IDE sprawia, że ​​bardzo łatwo można tworzyć wiele klas i łączyć je z takimi elementami, jak generowanie tablicy, automatyczne uzupełnianie i zawsze jest copypasta. Wiele narzędzi zmniejsza koszt tworzenia tego, co jest w zasadzie często bezużytecznym kodem, ale nie zmniejsza tak bardzo kosztów nadęcia. Nawet przy pomocy pomocników, kod nieogrodzony będzie zawsze działał taniej niż nadęty (można tylko zmniejszyć podatek, a nie go wyeliminować). Jeśli nie przejmujesz się tym, w końcu stanie się problemem. Nawet jeśli masz takie rzeczy jak skanowanie kodów, grzywna i zamiana w pliku, to dziesięć razy więcej jest dziesięć razy więcej. Oznacza to dziesięć razy więcej do zmiany, dziesięć razy więcej, aby pójść źle i jedną dziesiątą ilości wysiłku zużywanego na linię.

Wiele osób wpada w pułapkę myślenia, że ​​zmniejsza złożoność, dodając więcej zajęć. W rzeczywistości mają tendencję do po prostu przełamywania złożoności, odsuwania rzeczy od rzeczy, z którymi są powiązane i dodawania warstw złożoności w formie pośredniej. Kod liniowy staje się niepotrzebnie nieliniowy (jest to przykład zbyt wielu akapitów, choćby słusznie, lepszym przykładem może być jeden akapit na zdanie lub słowo jako zbyt wiele, gdy akapity stają się zdania, to nie t naprawdę mają już dwie oddzielne rzeczy, to prawdopodobnie dowód na dwa paragrafy, kiedy zdania przestają być czymś innym niż akapitami).

detekcji:

Prosty sposób, aby spojrzeć na to, czy masz PATH (single node/jedna funkcja/klasy/etc), ale złamać go na A-> B rzeczywistości nie zyskać byle co. Po prostu wziąłeś jedną kartkę papieru, rozerwałeś ją na dwie części, położyłeś na dwóch kopertach i wysłałeś do miejsca przeznaczenia. Jeśli okaże się, że rzeczywiście potrzebujesz węzła z więcej niż jedną krawędzią, to coś zyskasz. To byłby na przykład A-> B, A-> C.Za pomocą analizy wykresów można wyłowić zbyt wiele obiektów. Jeśli masz duże, długie, połączone listy lub wiele małych powiązanych list (lub może nawet kilka), prawdopodobnie możesz powiedzieć, że masz za dużo zajęć. Nie wszystkie formy nadmiaru obiektów są tak łatwo wykrywane. Przy zbyt wielu klasach konserwacja staje się nadmiernie złożona, ponieważ kończysz na wspieraniu poziomu elastyczności i modelu, z którego tylko część wykorzystujesz. Oznacza to, że wiele kodu nie odpowiada faktycznie temu, co należy zrobić. Już samo to czyni trudnym do utrzymania, ponieważ cel tego kodu jest subiektywny, a nie obiektywny, może równie dobrze być arbitralny.

Możesz wziąć bazę kodów i zmniejszyć liczbę klas, dopóki nie masz tylko tych, które rzeczywiście są potrzebne. Oznacza to tylko te, które są potrzebne do przenoszenia (przekazywanie danych dookoła), różnice w sposobie zachowywania się (przekazywanie metod w pobliżu) i jak to jest potrzebne dla rozsądnej separacji (radzenie sobie z głównymi pojęciami niezależnie od trwałości, prezentacji itp.) I jak to jest potrzebne do deduplikacji. Kiedy nie będzie w stanie pracować na dobrym projekcie, wielu programistów zrobi to w odwrotnym kierunku, pisząc kod i dzieląc go tylko tam, gdzie jest to potrzebne, by służyć konkretnemu celowi na żądanie.

Chociaż jest to mierzalne, nie ma dokładnej miary zbyt wielu klas ani idealnego znaku. Są tylko wskazówki. Duży wskaźnik między minimalną liczbą wymaganych klas a maksymalną na przykład jest podpowiedź. Co jest duże? Powiedziałbym, że 100 razy jest zdecydowanie podejrzany, 10 razy dość podejrzany, 5 razy nieco podejrzany. Może się to zmienić w zależności od wielu parametrów.

Dziwnym środkiem jest skompresowanie kodu. Im lepszy współczynnik kompresji, tym większa szansa na wzdęcie. Nie jest to jednak doskonała miara, ponieważ wymaga punktów odniesienia. Pewne sposoby na zmniejszenie stopnia kompresji mogą być bezproduktywne, kodowanie do określonej liczby naiwnie nigdy nie zadziała.

Możesz dowiedzieć się, czy masz do wielu zajęć (lub interfejsów), jeśli robią ci pracę, która nie pomaga naprawdę w osiągnięciu ostatecznego celu lub jeśli spowalniają cię bardziej niż przyspieszają w górę. Może to być jednak subiektywne. Jeśli ktoś zrobił zbyt wiele zajęć, oznacza to, że będą musieli zmienić swoje przyzwyczajenia, co oznacza, że ​​zazwyczaj istnieje opłata za wejście na lepsze podejście do kodowania. Na początku projektu jest to trudne do wykrycia, ponieważ dodawanie kodu jest zwykle bardzo tanie. Nic tak bardzo nie zależy od tego, warstwy są płytkie itd. To nie jest aż do wielu miesięcy, a nawet roku do projektu, który rozlewa się, kiepska organizacja itp., Że koszty stają się oczywiste. Dopiero kiedy projekt staje się praktycznie martwy, ludzie zwracają uwagę. Wiele osób nie wie, czy coś, co zajmuje rok, powinno zająć rok czy sześć miesięcy. Rzadko istnieje punkt odniesienia.

Jeśli spojrzysz na swoje zajęcia, możesz wybrać kilka rzeczy. Ile kodu jest OO i ile wynosi FO (zorientowanie obiektowe a zorientowane na funkcjonalność)?

Funkcjonalność Oriented oznacza kod, który faktycznie coś robi i bezpośrednio przyczynia się do końcowego efektu. Obejmuje to twój niezbędny kod. Najprawdopodobniej będą to operatorzy, którzy nie będą mieli przypisanych ani nie będą rzucać. Zwykle instrukcje warunkowe, rozgałęzienia, odczyt danych, wybór sposobu działania i podejmowanie odpowiednich działań, takich jak generowanie danych, mutacja lub pobieranie/przechowywanie przeciwko IO.

Obiekt zorientowany oznacza po prostu reprezentowanie pojęć przy użyciu klas. Ten kod prawie zamienia kod proceduralny na język deklaratywny. Jeśli większość twoich klas jest po prostu pomocą przy sprawdzaniu ciężkich typów, reprezentacji itp., Możesz mieć za dużo. Oznaki tego są klasami i metodami z częściami ich nazw, które mogą być zmiennymi pozwalającymi zmniejszyć te klasy. Bardzo silną oznaką tego jest to, że większość tego, co robią te klasy, to boksowanie. Po prostu przypisywanie zmiennych, ale nie robi dużo więcej. Jest to naprawdę przypadek posiadania nadmiernej struktury i zwykle braku deduplikacji, dynamicznego kodowania lub abstrakcji.

W oczywistym przypadku, jeśli klasa nigdy nie jest używana, jest to klasa zbyt duża (jeśli jest to martwy kod). Rzeczy takie jak klasy, które są identyczne, ale mają różne nazwy, są również dobrym znakiem.

Przyczyny:

To może być napędzany przez szereg rzeczy asides z mechanizmów, które sprawiają, że bardzo łatwo tworzyć i łączyć rzeczy razem (które mają tendencję do zerwania podczas abstrakcyjne i robić rzeczy dynamicznie zachęcanie unikanie dobrych nawyków który zastępuje, ale łamie IDE). Często wpadałem w pułapkę, próbując reprezentować wszystko absolutnie doskonale, jednak OO nie jest wystarczająco elastyczny, aby to zrobić i często okazuje się być YAGNI. Powszechnym problemem jest po prostu brak abstrakcji, w której zazwyczaj występuje zmienna rozwijająca się w konstrukcje językowe najwyższego poziomu, jak wspomniano wcześniej (która również łączy się z projektem, aby bezpośrednio ujawnić wszystko bezpośrednio IDE). Może to nie tylko zdradzić brak dynamicznego kodowania, ale także użycie preprocesora lub podobnego. To, jak to będzie wyglądało, jest w zasadzie drzewem ze wszystkimi zdefiniowanymi liśćmi. O ile to możliwe, z klasami, które chcesz uniknąć, musisz zdefiniować klasę dla każdego możliwego liścia. Znakiem ekspansji drzewa może być ekstremalne miejsce, w którym masz klasę dla każdego możliwego użycia prymitywu. Może to być również oznaką czegoś bardziej ekstremalnego. Rozwinięty Kartezjański Produkt wszystkich klas. W tym przypadku nie łatwo uzyskać klasę dla Nogi, ale klasę dla CatLeg, DogLeg itp., Gdy zwykle nie ma faktycznej rozbieżności między tymi dwoma. Niektórzy ludzie mogą to zrobić z powodu ekstremizmu sprawdzania typu, aby powstrzymać kogoś przed umieszczeniem DogLeg na CatLeg. To paskudny i powszechny anty-wzór.

Jednym z największych czynników prowadzących zbyt wiele zajęć jest próba przestrzegania standardów pochodzących z chmury, które tak naprawdę nie mają zastosowania w danej sytuacji. W tym przypadku nie programujesz w odpowiedzi na swój problem. Programujesz w odpowiedzi na problemy innych ludzi.

Jest to bardzo częste w przypadku rzeczy takich jak SOLID. Bardzo ważne jest, aby znać i rozumieć zasady takie jak SOLID, móc je stosować, ale ważne jest również wiedzieć, kiedy ich nie stosować.

Ta zasada jest szeroko stosowana, gdy nauczane są języki OOP z dużymi bibliotekami. Jeśli tworzysz bibliotekę OOP, którą chcesz dystrybuować do świata, potencjalnie miliony ludzi z każdym możliwym przypadkiem użycia, wtedy chcesz przestrzegać zasad OOP, które prowadzą do wielu problemów, tworząc interfejsy i klasy, aby może być używany na różne sposoby, a więc jedna funkcja nie ma dużej szansy na wciągnięcie innej, która może nie być potrzebna. Musisz wziąć pod uwagę, że na tym świecie nie chcesz tworzyć bibliotek, które ludzie będą musieli rozwidlić. Ludzie nie chcą tego robić, ponieważ stają się opiekunami kodu, którego używają ponownie, w przeciwnym razie stracili całkowity koszt posiadania.

Te zasady dodają też sporo narzutów, a jeśli baza ma ograniczony zakres użytkownika, jest w pełni pod kontrolą, itp., To prawdopodobnie masz za dużo kodu, jeśli robisz to "sposób, w jaki powinno "dla kodu rozproszonego. Nawet jeśli masz kod, który jest rozpowszechniany, czasami może on być zbyt ekstremalny, aby wcześniej przygotować wszystkie przypadki użycia, czasami musisz ustalić, co najprawdopodobniej będzie potrzebne, a następnie wszystko inne zostanie zmienione na żądanie. W małej bibliotece możesz pozwolić sobie na dużo dodatkowej pracy. W przypadku dużej bazy kodu trzeba ćwiczyć, gdzie koszty ogólne najprawdopodobniej pokryją się same.

Counter przykład:

W idealnym świecie, kodować Minimalistycznie i wyłącznie według własnych doraźnych potrzeb. Istnieje tendencyjność, w której ta metoda jest lepsza ze względu na ekscesy, które nie są odkrywcze. Braki są. Jeśli masz za mało, bezpośrednio się przedstawisz. Jest to bardzo częste zjawisko w DRY. Po dodaniu jednej funkcji dodajesz kolejne.Najpierw kopiujesz i wklejasz, a następnie zmieniasz dolną połowę. Wspólne górne połówki dwóch funkcji są zduplikowanymi kodami, natychmiast ujawnia się, że należy je deduplikować. Robisz to, tworząc trzecią funkcję. Wiesz, że nie jest to jedna funkcja zbyt duża, ponieważ masz obiektywny, udowodniony powód, by ją stworzyć. Takie podejście staje się trudniejsze, gdy piszemy kod do użytku przez innych. Przez innych niekoniecznie mam na myśli kogoś. Mam na myśli osoby bez bezpośredniego dostępu do bazy kodów, zwykle nieznajome. Zasadniczo ludzie, którzy nie mogą łatwo/szybko/tanio zepsuć kodu, gdy jest to konieczne. Jeśli nie obsługujesz takich odbiorców, nie musisz się martwić, że przedwcześnie zepsujesz swój kod.

Niedawno użyłem biblioteki online z za małą liczbą klas. Zawierał jedną klasę z wieloma obowiązkami. Wymagałoby to zapisu pliku (jako typu pierwotnego) do zapisu, aby następnie automatycznie wyprowadzać nagłówki HTTP odpowiednie do strumienia, który generował w oparciu o wywołane metody (takie jak addImage, addText, itp.).

W idealnym świecie ta klasa nie powinna przyjmować założeń dotyczących wydajności. Zastosowania mogą chcieć wyprowadzać dane do systemu plików, pamięci, strumienia TCP itp. Musi on oferować interfejs z prostą metodą zapisu lub korzystać ze standardowej biblioteki. W moim przypadku musiałem tylko mieć to wyjście przez łączenie ciągów, ale aby to osiągnąć, musiałem otworzyć mapowanie pseudo-pliku w pamięci (co normalnie nie byłoby możliwe, ale język pozwala na to jako hack).

Miałem ten problem wiele razy przy użyciu losowych bibliotek ze wszystkich źródeł. W niektórych przypadkach będzie oczywiste, gdzie należy stosować separację, a czasami nie. Jeśli masz wątpliwości, zbyt mało wciąż bije zbyt wiele, ponieważ w końcu masz gwarancję, że się o tym dowiesz. Zauważam, że jeśli dodasz coś, czego nie jesteś pewien, skończysz na znacznym terytorium. Jeśli zrobisz to raz, prawdopodobnie zrobisz to dwa razy i wtedy stanie się to nawykiem.