fbpx

Po 33rd Degree

3 komentarze

  1. AdamB pisze:

    Podobno nie ma głupich pytań, więc co złego jest w metodach prywatnych?

  2. Myślę, że choć Autorom nie brakuje świetnych pomysłów, to jednocześnie przydałoby im się nieco pokory i szacunku (…)

    Szkoda, ze tak to odczytales. Prezentacja miala miec dosc luzny charakter, co zreszta zauwazyles, a czesc nalezalo potraktowac z przymruzeniem oka i dystansem. Kazda z wymienionych przez Ciebie postaci traktuje z duzym szacunkiem za to co zrobili, a Robert Martin to moj guru 🙂 Pozdrawiam.

  3. Metody prywatne same z siebie "nie gryzą", a mają parę niewygodnych konsekwencji:
    * trudno je przetestować, bo nie ma do nich dostępu
    * metody prywatne szybko stają się dość duże i skupia się w nich logika działania komponentu
    * bywa, że klasa ma jedną lub dwie metody publiczne oraz całą masę prywatnych, co znów nie jest ani czytelne ani testowalne.

    Metody prywatne są ok, ALE jako etap pośredni refaktoryzowania kodu. Jeśli wśród metod prywatnych zaczynamy widzieć pewną odpowiedzialność, to wygodnie jest wyodrębnić nowy obiekt.
    Zerknij tu:
    * http://msieraczkiewicz.blogspot.com/2011/02/naturalny-porzadek-refaktoryzacji-idea.html

    * http://mbartyzel.blogspot.com/2011/02/paczkowanie-kodu.html

    Podczas opinii Autorzy proponowali dogmatyczne zaprzestania używania metod prywatnych. Sądzę, że bez podania dużej ilości przykładów i rozważania różnych subtelnych kontekstów taka reguła jest trudna do przyjęcia i stosowania.

    Możesz napisać do Autorów z prośbą do szerszy komentarz. Wkrótce ukaże się książka Divine Code, współautorstwa jednego z nich – być może nam znajdziesz więcej przesłanek prowadzących do w/w wniosków.

    Inne godne polecenia lektury na ten temat to:
    * Implementation Patterns,
    * Clean Code

    pozdr,
    mb