Wpis z mikrobloga

#programowanie #java #pytanie

Jakie wzorce projektowe oraz dobre praktyki uważacie za najbardziej uniwersalne/najważniejsze przy projektowaniu aplikacji: od małych konsolowych, po olbrzymie enterprise'owe? Czy przykładowo tworząc moduł/pakiet dobrą praktyką jest zacząć od stworzenia interfejsu, żeby nie być przykutym do jednej implementacji i wcielać w życie inversion of control? Jakie jeszcze żelazne zasady stosujecie na codzień?
  • 22
  • Odpowiedz
@mcprok: Właśnie o tym słyszałem, że nie warto. Mógłbyś wyjaśnić dlaczego? Jak zobaczyłem u kogoś takie podejście to strasznie mi się to spodobało z jakiegoś powodu.
  • Odpowiedz
Jakie wzorce projektowe


@baalder363: jak to mówią: jeśli potrzebujesz wzorców projektowym, to znaczy, że skopana jest architektura ( ͡° ͜ʖ ͡°) W monolitach musisz ich używać, żeby się zakopać, w mikroserwisach jest już inaczej.

dobrą praktyką
  • Odpowiedz
@baalder363: szkoda czasu, a dodatkowy kod do utrzymania, ktory niewiadomo czy bedzie uzyty kiedykolwiek. Jak w przyszlosci dostaniesz wymaganie dorobienia czegos podobnego i bedziesz chciec miec wspolne api dwoch klas to sobie wyextractujesz interfejs i tyle. Uzywajac obecnych ide to 2min roboty. Lacznie ze zrobieniem kawy
  • Odpowiedz
Właśnie o tym słyszałem, że nie warto


@baalder363: jak potrzebny to warto.

Przykład 1: serwis do DAO. Zrób interfejs bo możesz mieć dwie implementacje np. do rzeczywistej bazy danych i do bazy w pamięci (do testów lub odłączenia bazy).

Przykład 2: serwis, który robi jakąś konkretną logikę biznesową. Będziesz miał drugą implementację? Raczej nie. Chyba że interfejs tylko po to, żeby w testach zrobić mocka.
  • Odpowiedz
Jak w przyszlosci dostaniesz wymaganie dorobienia czegos podobnego i bedziesz chciec miec wspolne api dwoch klas to sobie wyextractujesz interfejs i tyle. Uzywajac obecnych ide to 2min roboty.


@mcprok: chyba że to jest oddzielny projekt z którego tylko korzystamy (np. wpinamy się przez interfejs) albo co bardziej przemawia, projekt firmy trzeciej (nie masz możliwości podmiany ich kodu, bo to oni zarządzają wersjami). Jak ci udostępnią interfejs (mimo że sami go
  • Odpowiedz
li potrzebujesz wzorców projektowym, to znaczy, że skopana jest architektura


@mk321: Bzdura, wzorców projektowych używa się w dobrze zaprojektowanych projektach.

jak używasz np. Springa, to masz z głowy Dependency Injection.


@mk321: DI nie jest tym samym, co IoC
  • Odpowiedz
@baalder363: bzdurą jest tworzenie interfejsu tylko dla sztuki. Jak nie masz od samego poczatku takiej potrzeby to nie warto.


@mcprok: miłej zabawy w unittestowaniu w srodowiskach ktore nie maja ciulowych hacków ( ͡° ͜ʖ ͡°) poza tym, jest jeszcze taka dobra zasada - "wiem, że nic nie wiem", nigdy nie zakładaj, ze "to się nie stanie", bo najczęściej potem to się dzieje ( ͡
  • Odpowiedz
@baalder363: Najbardziej uniwersalne to luźne powiązania, enkapsulacja i polimorfizm. Potem masz SOLID i parę innych skrótowców, potem wzorce. Same wzorce na początku nauki pomagają szukać rozwiązań, ale z czasem używanie staje się intuicyjne i ich rola sprowadza się do nazw stosowanych technik w celu osiągnięcia tych uniwersalnych celów - uproszczenie komunikacji na zasadzie "byłem w kinie", gdzie "kino" jest powszechnie rozumiane jako sala z dużą ilością siedzeń, ekranem, gdzie ogląda
  • Odpowiedz
  • 1
@baalder363 YAGNI oraz KISS - też czytałem że trzeba robić interfejsy ale ja to olewam jeżeli ich nie potrzebuje oraz wiem że nikt nie będzie korzystał z mojego kodu, w sumie te interfejsy to najbardziej przydają się przy jakichś utilsach, wtedy prawdopodobieństwo że ktoś będzie chciał swoje implementację robić jest bardzo duże
  • Odpowiedz
@Bruno_: KISS to taka regula z koziej dupy, ponieważ ,,proste" jest bardzo płynnym pojęciem i ludzie bardzo różnie je rozumieją, wielu bardzo mylnie - np znałem gościa dla którego KISS = jak najmniej kodu. ( ͡° ͜ʖ ͡°)
  • Odpowiedz
@alex-fortune: Z biznesowego punktu widzenia, według mnie, lepiej założyć, że coś nie będzie Ci potrzebne, a później to dorobić niż tracić czas na klepanie dodatkowo interfejsów i utrzymywanie tego kodu przez jakiś czas. Zamiast tego można szybciej przetestować hipotezę i sprawdzić czy dana rzecz działa czy nie. Po przetestowaniu biznesowym często się okazuje, że dany feature nie spełnia oczekiwań klientów i idzie do kosza. ;)

A co do unitów to
  • Odpowiedz
Z biznesowego punktu widzenia, według mnie, lepiej założyć, że coś nie będzie Ci potrzebne, a później to dorobić niż tracić czas na klepanie dodatkowo interfejsów i utrzymywanie tego kodu przez jakiś czas


@mcprok: To prawda, ale wprowadzenie interfejsów ma - dosłownie - zerowy dodatkowy overhead, chyba, że chcesz mi powiedzieć, że dodatkowe 30 sekund na wygenerowanie dodatkowego interfejsu ( i używanie jego nazwy zamiast nazwy klasy ) to jakiś wielki
  • Odpowiedz