Czy lepiej stworzyć jedną większą metodę czy dwie małe wywołać w trzeciej?

Napisałam aplikację, która po kliknięciu przycisku tworzy plik o podanej nazwie i zapisuje w nim podany tekst. Czy lepiej/estetyczniej będzie napisać wszystko w jednej metodzie, czy w dwóch różnych, a potem każdą z nich wywołać w trzeciej metodzie obsługującej zdarzenie? Piszę w JavaFX i używam SceneBuildera więc tego kodu jest naprawdę mało.

A co Ci będzie łatwiej testować? Chyba zawsze dwie małe.

Ja bym chyba wolał jedną metodę z dwiema linijkami niż dwie po jednej. Na testowanie to nie ma wpływu, bo i tak trzeba to zrobić integracyjnie... o ile to nie za mało w ogóle na test.

To zależy od rozmiaru. Jeśli ta jedna metoda będzie nadal krótka to moze być jedna, ale jeśli ta jedna dzięki temu ma 100 linijek to może lepiej podzielić...

Nie no bez przesady, jeżeli wszystko wrzucę do jednej metody to ma 15 linijek. Czyli nie ma większej różnicy jeżeli chodzi o estetykę przy tak krótkim kodzie?

Bardziej bym popatrzył czy metoda nie narusza zasady SRP.

Oprócz ważnego pytania o testowanie kodu, zastanów się jaki zapis będzie bardziej czytelny przy tworzeniu tego kodu. Jeśli większa metoda będzie realizowała jakąś sensowną logikę z punktu widzenia programu, warto by zawierała sugestywne nazwy innych metod odnoszące się do problemów rozwiązywanych przez sam program/moduł/bibliotekę. Jeśli jednak jest "niskopoziomowa" (Ty decydujesz gdzie jest "niski poziom"), zostaw 1 większą.
Ogólnie: zadawaj sobie takie pytania przy 5~7 linijkach funkcji/metody :-)

Chodzi o to, żeby metoda wykonywała tylko JEDNĄ konkretną rzecz. Np. nie powinnaś pisać metody, która robi coś i coś jeszcze. Np. pobiera dane od użytkownika i drukuje je (czy to na ekran, czy na inne urządzenie). W takim wypadku jedna metoda powinna pobrać dane, a druga je wydrukować.

Jeśli metoda robi konkretną rzecz i nie jest dłuższa niż powiedzmy 20 linijek, to jest ok. Jeśli robi się dłuższa, wtedy można się zastanowić, czy pewnych jej fragmentów nie wynieść do innych metod.

Dobrą regułą jest jeden poziom abstrakcji na funkcję - jeżeli jedna linia wykonuje jakąś operację biznesową a dwie kolejne jakieś niskopoziomowe akcje typu dostęp do pliku to lepiej to wydzielić, żeby metodę łatwiej się czytało. Jeżeli kogoś będą interesować szczegóły dostępu do pliku, to sobie zajrzy do tej metody, jak nie, to może przejść dalej.

Ja bym zrobił tak, że zamiast rozwodzić się nad jakimiś dogmatami programistycznymi, pomyślałbym praktycznie, czy sama funkcjonalność powinna być rozdzielona czy nie.

• czy może być potrzebne utworzenie pliku bez zapisywania w nim tekstu? (jeśli tak, to argument za rozdzieleniem)
• czy moze być potrzebne zapisanie tekstu do utworzonego już pliku? (jeśli tak, to kolejny argument za rozdzieleniem)
• czy moze być potrzebne wykonanie powyższych akcji, ale nie przez kliknięcie ale np. z klawiatury (jeśli tak, to argument za rozdzieleniem, ale również w ten sposób, żeby nie było to zależne od kliknięcia przycisku)
• czy dany komplet akcji (utworzenie pliku i zapisanie w nim tekstu) będzie wywołany w różnych miejscach? (jeśli tak to argument za zrobieniem 1 funkcji, która łączy wszystkie funkcjonalności i pozwala na łatwe ich odpalanie. Z tym, że niekoniecznie to przeczy rozdzieleniu - bo przecież ta jedna funkcja może wywołać 2 inne...)

która po kliknięciu przycisku tworzy plik o podanej
nazwie i zapisuje w nim podany tekst

BTW jak dla mnie tu na pierwszy rzut oka są 3 akcje (reakcja na zdarzenie przycisku, utworzenie pliku o podanej nazwie, zapisanie w nim podanego tekstu), plus 2 rodzaje danych (nazwa pliku i tekst do zapisania), które też mogą się zmienić (może trzeba będzie zapisać dane w innym pliku? Albo zapisać innego rodzaju dane?).

Czyli tak na oko jak dla mnie bardziej eleganckim rozwiązaniem byłoby rozdzielenie tego wszystkiego.

Z drugiej strony YAGNI (you ain't gonna need it), na razie pewnych rzeczy nie trzeba robić i równie dobrze można to umieścić w jednym handlerze kliknięcia myszy i nie martwić się - potem się najwyżej przerobi.

Ważniejsze jest, żeby zdawać sobie sprawę z konsekwencji danych rozwiązań i to, żeby umieć przewidywać potencjalne problemy, a nie żeby pisać od razu najlepszy kod.

Jednak zakładając, że to prosty kod, to przerobić to z jednej metody na kilka innych to moment, więc też nie widzę sensu, żeby robić niepotrzebne abstrakcje na zapas.