W różnych książkach projektowych, które czytam, czasami duży nacisk kładzie się na liczbę metod, które musi mieć klasa (biorąc pod uwagę język OO, na przykład java lub C #). Często przykłady podane w tych książkach są bardzo schludne i proste, ale rzadko dotyczą „poważnego” lub złożonego przypadku.
Jednak wydaje się, że zakres wynosi od 5 do 8.
W projekcie opracowałem klasę „Notatka”, której atrybutem są właściwości: Tytuł, Opis, CreateDate itp.
Następnie kilka podstawowych metod, takich jak: getRelations (jeśli notatka jest przypisana do różnych dokumentów), getExpiryDate, ect.
Jednak w dalszym rozwoju aplikacji wymagana była większa funkcjonalność, a zatem więcej metod.
Wiem, że im mniej metod ma klasa, tym bardziej jest ona luźno powiązana. Jest to rzeczywiście dobra zaleta pod względem modułowości i możliwości ponownego użycia, a także łatwiejsza do edycji.
Nawiasem mówiąc, jeśli w naszym kontekście nie ma potrzeby (ani nawet nie ma sensu) tworzenia podklas, a wszystkie potrzebne funkcje są powiązane z tą klasą, to ile metod możemy dalej dołączyć?
Zgadzam się, że mając ponad 15 metod, być może może być konieczne trochę przeprojektowanie.
Ale nawet w takim przypadku, jeśli usunięcie niektórych metod lub dziedziczenie nie jest opcją, jaki byłby właściwy sposób?
źródło
Odpowiedzi:
Masz tyle metod, ile potrzebujesz. W miarę możliwości starałbym się ograniczyć liczbę metod publicznych do tej reguły 5-8. Szczerze mówiąc, większość ludzi ma odwrotny problem polegający na tym, że mają szalone super-metody, które należy bardziej i nie mniej. Naprawdę nie ma znaczenia, ile masz metod prywatnego pomocnika. W rzeczywistości, jeśli pozostaniesz poniżej 8 metod w Javie, możesz przekroczyć granicę z klasą, która ma tylko konstruktor, toString i getter / setter dla 3 właściwości ... co nie jest dokładną klasą. Najważniejsze jest to, nie martw się o to, ile metod jest twoja klasa. Martw się, aby twoja klasa nie zajęła się niepowiązanymi obawami i że masz rozsądny publiczny interfejs, który ma łatwe do zrozumienia metody.
źródło
Odpowiedź jest naprawdę prosta: umieść wszystko w klasie, która należy do jego obowiązków, ale bądź ostrożny przy przydzielaniu obowiązków.
Czasami duża klasa składa się z mniejszych klas o różnych obowiązkach.
Ogólnie rzecz biorąc, staram się podzielić obowiązki na mniejsze klasy, gdy klasa staje się niewygodna w użytkowaniu lub konserwacji. Rzadko mam klasy dłuższe niż 500 linii. Moje największe klasy mają około 1,5 tys. Lokalizacji.
Po prostu nie można podać ogólnej reguły, takiej jak: „klasa powinna mieć metody n im”.
źródło
Nie ma powodu (w projektowaniu OO) posiadania tak wielu metod. Nie jest również prawdą, że klasa z mniejszą liczbą metod jest lepiej oddzielona.
Spójrz na przykład na klasę java.lang.String. Wiele metod, ponieważ istnieje tak wiele rzeczy, które można zrobić za pomocą łańcucha. Niemniej jednak nie jest silnie sprzężony.
Zastanawiam się, dlaczego magiczna liczba, taka jak 15, może oddzielić dobry i zły projekt. Nie, to nie jest takie proste.
źródło
W PMD domyślnym zachowaniem reguły TooManyMethods jest identyfikacja i oflagowanie klas za pomocą 10 lub więcej metod jako potencjalnych błędów. To jednak tylko dowolna liczba. Można to łatwo zmienić w konfiguracji. Niezależnie od tego, jaka jest ta liczba, to tylko flaga dla programisty, aby spojrzeć na klasę i sprawdzić, czy jest jakiś problem, a nie to, że jest z tym problem.
Coś, co jest nieco bardziej konkretne, może być regułą 7 plus / minus 2 . Stwierdza to, że ludzki umysł może przechowywać i rozumieć od 5 do 9 „obiektów” w pamięci. Podczas czytania określonej klasy obiektami najprawdopodobniej byłyby metody i pola, które składają się na tę klasę. Jednak zajęcia często mają więcej niż 9 pól i metod, nawet jeśli nie liczyć akcesorów, mutatorów i wszelkie standardowe operacje (na przykład
toString(),hashCode()iequals()w Javie).Najbardziej odpowiednie środki to wachlowanie i wachlowanie oraz dyskusje na temat powiązań i spójności . Należy zastosować zasadę pojedynczej odpowiedzialności i rozdzielić obawy - klasa powinna zrobić lub reprezentować jedną i jedną rzecz sama. Są one znacznie lepsze niż próby przypisania liczb do maksymalnej / minimalnej liczby metod podczas oceny projektu lub implementacji.
źródło