Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

.Ten post został edytowany przez Autora dnia 13.08.16 o godzinie 21:21

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

[Próba merytorycznego ratunku dyskusji]

Miałeś w trakcie tej dyskusji dwa posty gdzie próbowałeś napisać coś konstruktywnego - nie na zasadzie "jesteś głupi" ale "uważam, że moje rozwiazanie jest madre bo ..."

Możemy jeszcze podjać jedną próbę dykusji na temat bez obrażania siebie nawzajem.
Spróbojmy z tym samochodem skoro z grą życie nie wyszło.

Pierwsza próbka kodu :

car.getEngine().start();

Druga próbka kodu:

car.start();

Według mnie w przypadku pierwszym gdy zmieni się interfejs klasy Engine
A jaka jest twoja opinia?

Jeśłi zmiani się interface klasy Engine to wszędzie gdzie jest on używany będzie wymagana zmiana i getter nie ma nic do rzeczy; tzn. nie jest ani przyczyną problemu ani jego rozwiązaniem.

Problemem w przykłądzie opisanym przez Ciebie jest sama zmiana.

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

.Ten post został edytowany przez Autora dnia 13.08.16 o godzinie 21:21

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Jeśłi zmiani się interface klasy Engine to wszędzie gdzie jest on używany będzie wymagana zmiana i getter nie ma nic do rzeczy; tzn. nie jest ani przyczyną problemu ani jego rozwiązaniem.

Problemem w przykłądzie opisanym przez Ciebie jest sama zmiana.

Dziękuję za merytoryczną odpowiedź (bez złośliwości). Z tym interfejsem jest dokładnie tak jak piszesz i to co chciałem przekazać poprzez przykład jest ograniczenie miejsc gdzie interfejs Engine jest używany poprzez usunięcie gettera z klasy Car. Czy tutaj mniej więcej mamy zgodę?

Jeśłi coś będzie musiało użyć klasy engine w celu wywołania start() i tak będzie musiało ją sobie pobrać. Jeśli nie z Car to z czegoś innego.

Jeśli tylko Car powinno mieć prawo wywoływać metodę start() na Engine, udostępnienie gettera Engina z publiczną metodą start jest błędem projektowym a nie argumentem na "szkodliwość getterów".

<edit>
A no i chyba możemy założyć, że w pewnym skończonym czasie jakaś zmiana może tutaj nastąpić.

Dobry projekt (obiektowy) gwarantuje to, że mała zmiana funkcjonalności (z definicji) przełoży się na małą zmianę w kodzie. Jeśli ktoś zacznie, w celu np. uodpornienia się na zmiany, rezygnować z getterów i np. returnów to nie przygotuje dobrego projektu.

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Paweł Włodarski:

Cezary Kowalski:

Pierwsza próbka kodu :

car.getEngine().start();

Druga próbka kodu:

car.start();

>

car.getEngine().start();

car.engine.start();

Postaraj się reagować spokojniej i zobacz

class Car {

   private Engine engine;



   start(){

             (...)

             engine.start();

            (...)

   }

Wcale nie musisz w tym przykładzie ujawniać detali wewnętrznych klasy Car.

2) Zmiana w interfejsie (czy są gettery / settery czy ich nie ma) pociąga za sobą zmianę zawsze i wszędzie gdzie zmieniony fragment był używany.

Dokładnie jest tak jak napisałeś.

Ps. wybacz moją paranoję ale wyglądasz na profil założony na szybko na potrzeby tej dyskusji ;)

Ponownie się mylisz Młody Kolego ponieważ podświadomie zakładasz, że jak ktoś tworzy profil na GL to szuka pracy albo chce być rozpoznawalny - ale wybaczam ponieważ każdy ma prawo czynić założenia podług własnego doświadczenia.

Poprzednia moja wypowiedź była bardzo spokojna (nawet podszyta żartem). Chcesz iść tym kierunkiem to rozwinę twoje podejście (w ograniczonym zakresie tylko o postawowe komponenty z których składa się silnik ZI) i może wtedy zobaczysz, co się dzieje gdy całkowity brak dostępu do pól klasy.

public class IntakeCamShaft{



public void check() throws BadAngleException, CamOutOfServiceException{...}



}



public class OuttakeCamShaft{



public void check() throws BadAngleException, CamOutOfServiceException{...}



}



public class MainShaft{



public void check() throws BadAngleException, SaucerOutOfServiceException{...}



}



public class SparkPlug{



public void check() throws SparkMissingException, SparkPlugOfServiceException{...}



}



public class FlowMeter{



public void check() throws ValueOutOfBandException, DiscontinuousReadingException{...}



}



public class RailInjection{



public void check() throws InjectorOutOfServiceException, NoFuelException{...}



}



public class Engine{



private IntakeCamShaft ics;

private OuttakeCamShaft ocs;

private MainShaft ms;

private SparkPlug [] sp;

private FlowMeter fl;

private RailInjection rj;



public Engine(IntakeCamShaft ics, OuttakeCamShaft ocs, MainShaft ms, SparkPlugs [] sp, FlowMeter fl, RailInjection rj){



this.ics = ics;

this.ocs = ocs;

this.ms = ms;

this.sp = sp;

this.fl = fl;

this.rj = rj;



}



public void check() throws BadAngleException, CamOutOfServiceException, SaucerOutOfServiceException, SparkMissingException, SparkPlugOfServiceException, ValueOutOfBandException, DiscontinuousReadingException, InjectorOutOfServiceException, NoFuelException {...}



}



public class Car{



private Engine e;

private boolean oilLevel = false;



public Car( Engine eng){



this.e = eng;



}



public void check() throws BadAngleException, CamOutOfServiceException, SaucerOutOfServiceException, SparkMissingException, SparkPlugOfServiceException, ValueOutOfBandException, DiscontinuousReadingException, InjectorOutOfServiceException, NoFuelException, BadOilLevel{



e.check();

if(!oilLevel) throw BadOilLevel;



}



}

I teraz patrz co się dzieje.

1) Aby utworzyć samochód jestem zmuszony za każdym razem najpierw utworzyć wszystkie jego elementy składowe. Co jest po części dobre bo wymusza porządek. ale przy braku metod dostępowych do pól składowych

2) aby przetestować jakiś komponent za każdym razem muszę przetestować cały samochód, co już nie jest dobre ponieważ za każdym razem czy chcę czy nie chcę testuję dobre komponenty a w niektórych przypadkach czas testowania może być długi.

Teraz rozumiesz czemu ostracyjne unikanie dostępu do pól klasy czy to za pomocą getterów / setterów czy bezpośrednio rodzi więcej kłopotów niż korzyści?

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Jeśłi zmiani się interface klasy Engine to wszędzie gdzie jest on używany będzie wymagana zmiana i getter nie ma nic do rzeczy; tzn. nie jest ani przyczyną problemu ani jego rozwiązaniem.

Problemem w przykłądzie opisanym przez Ciebie jest sama zmiana.

problem w tym, że zmiana interfejsu to nie koniecznie "zmiana" a także rozbudowa, i dopiero nieprzydatność "starych usług" implikuje 'zmiany", wtedy propagacja na resztę kodu będzie ograniczona lub nawet wyeliminowana, po drugie nowa funkcjonalność może wymagać refaktoringu implementacji (agregatu) np. przeniesienia wielu atrybutów pomiędzy klasami, ich podziął na klasy skąłdowe agregaktu itp. ale interfejs może pozstac niezmieniony. jeżeli np. interfejs odpowiada na pytanie "dane osoby(imię, dimie, nazwisko), to rewolucja wewnątrz agregatu tego nie zmieni, jeżeli publiczny interfejs będzie udostępniał te dane jako publiczne atrybuty lub wprost get/set to przebudowa implementacji raczej wpłynie to,

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

.Ten post został edytowany przez Autora dnia 13.08.16 o godzinie 21:23

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

.Ten post został edytowany przez Autora dnia 13.08.16 o godzinie 21:23

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Paweł Włodarski:

Jakub Wojt:
Jeśli tylko Car powinno mieć prawo wywoływać metodę start() na Engine, udostępnienie gettera Engina z publiczną metodą start jest błędem projektowym a nie argumentem na "szkodliwość getterów".

Dokładnie o tę sytuację cały czas chodziło, później niepotrzebnie nastąpiła fala skrótów myślowych,nieporozumień i złych emocji. Teraz wróćmy do mojego pytania, które padło jakieś 3 strony temu :D

Ponieważ jest to forum Java to interesowała mnie konkretna sytuacja z użyciem technologii JSP.
Załóżmy, że w naszym przykładzie mamy właśnie sytuację gdzie tylko Car powinno mieć prawo wywołać metodę start. Dodatkowo musimy wyświetlić w jakimś tam raporcie na stronie JSP informacje o silnikach.

Np taki zapis w JSP :

<div> ${car.engine.serialNumber} </div>

wymaga w klasie engine istnienia gettera dla Engine, który technicznie umożliwia dowolnej klasie wystartowanie silnika

To od początku - jeśli metoda jest w interfejsie implementowanym przez klasę to znaczy, że służy ona (metoda) do wywoływania przez inne klasy - i równoważność tej zasady - jeśli metoda nie ma być "publiczna i dla wszystkich" to nie powinna się znaleźć w interfejsie.

Interfejs Engine nie powinien zawierać takiej metody, może natomiast zawierać metody typu "getSerialNumber" etc ...

Jak można zrobić, żeby metoda nie była publiczna ale jednocześnie wywoływalna przez "Car" ?

Ponieważ problem dotyczy Javy - można zdefiniować klasę abstrakcyjną Engine, która implementuje interfejs z getterami a jednocześnie definiuje zabezpieczoną (protected) abstrakcyjną metodę "start".

W tej samej paczce może znajdować klasa Car i wtedy, z tego co mi wiadomo (jestem okazjonalnym prog. java więc jak coś "palnę" to proszę wybaczyć) Car może wywoływać Engine.start() ale żadna inna klasa z poza paczki robić tego nie może.

Metoda 2:
Można zdefiniować interface EngineData w którym będą tylko gettery do "numerów seryjnych" Interfejs Engine natomiat będzie dziedziczyć po tym interface i jednocześnie deklarować metody "start".
Klasa Car, zamiast zwracać obiekt typu "Engine" będzie zwracać obiekt typu EngineData.
Ale jak wiadomo to jest złe rozwiązanie, ponieważ metoda "start" nigdy nie powinna znaleźć się w interface.

Metoda 3:
Olać potencjalne konsekwencje i robić tak żeby było najszybciej. I nazywać to Scrum i TDD żeby nikt się nie przyczepił ;)

Na serio: czasem efekt nie jest warty włożonej pracy.

(Być może nawet żadna klasa w "logice" nie powinna mieć świadomości istnienia czegoś takiego jak numer rejestracyjny silnika).

Jak ma działać logika, jeśli nie ma dostępu do żadnych informacji ? :)

Ps. Jak widzisz skróty myślowe generuje niebezpieczne założenia

... czy to Twój pierwszy wątek, w którym każdy wypowiada się na inny temat ? ;)

<edit>
A no i chyba możemy założyć, że w pewnym skończonym czasie jakaś zmiana może tutaj nastąpić.

Dobry projekt (obiektowy) gwarantuje to, że mała zmiana funkcjonalności (z definicji) przełoży się na małą zmianę w kodzie.

Tak jak wyżej, dyskusja miała być o tych getterach, które są błędem projektowym i psują model obiektowy .

Nieumiejętnie zastosowane - psują. Niestosowanie getterów (returnów) - też psuje.

No kurcze; czy na prawdę w tym "Engine" sensowne jest tylko "start" ? Zwłaszcza, że inne komponenty akurat start nie potrzebują...Jakub Wojt edytował(a) ten post dnia 17.12.12 o godzinie 19:50

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Jakub Wojt:
Jak ma działać logika, jeśli nie ma dostępu do żadnych informacji ? :)

tak jak ja: działam, można mnie wywołać, a nie udostępniam szczegółów warsztatu pracy :) - ma zdefiniowany interfejs: moją ofertę.

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

.Ten post został edytowany przez Autora dnia 13.08.16 o godzinie 21:23

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Czytania głupot pisanych przez ludzi,

Oj Jakub Jakub to, że czegoś nie rozumiesz nie znaczy, że to jest głupota. Być możę po prostu tego nie rozumiesz.
To że kogoś nie rozumiesz nie znaczy, ze jest "matołkiem", być może po prostu nie rozumiesz co chce ci przekazać.

No dobrze... W "moim świecie" tacy ludzie (i ich zalecenia) zamiast pomagać w rozwiązywaniu problemów - tworzą je.

Przykład: jeśli ktoś nie przemyśli czegoś przy tworzeniu interface - ja taką sytuację nazywam "złym interface"; "oni" nazywają to "użycie gettera jest złą praktyka". Być może "oni" mają rację, ale jakoś w "moim świecie" - nigdy.

No i zobacz - do mnie możesz być nastawiony negatywnie

? :) nie jestem do Ciebie negatywnie nastawiony :)

ale zerknij na link, który wkleił kilka postów temu Jarek

http://sprawnainzynieriaoprogramowania.blogspot.com/20...

To jest głupie.

Na podstawie wcześniejszych dyskusji wydaje mi się, że ma on u ciebie pewien autorytet także możesz wrócić do jego wypowiedzi odnośnie ćwiczeń i uwagi o nabieraniu pokory.

Jarek wkleił tylko "opinię programisty".
A z pokorą - bardzo chętnie - nabiorę ale tylko pod warunkiem, że osoby które powinny jej mieć 10x mniej niż mają, też tak postąpią ... i to dotyczy tak samo autorów jak i "opiniujących". Żeby nie było, że "nie można krytykować, ale można chwalić".

PS. No i oczywiście dalej w swojej wypowiedzi zacząłeś już jakieś dziwne personalne wycieczki w moją stronę ale tego nawet nie bedę komentował.

To nie była personalna wycieczka a jedynie sugestia, że posiadanie dużej wiedzy z zakresu "współczesnego IT", jest kompletnie nie przydatne w rozwiązywaniu konkretnych problemów.
Nie wiem, co czytałeś i w jakich szkoleniach uczestniczyłeś - miałeś konkretny problem i chciałeś go rozwiązać w zły (sugerowany przez 'ludzi z wiedzą') sposób.Jakub Wojt edytował(a) ten post dnia 18.12.12 o godzinie 21:24

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Jakub Wojt:

Nie chce bezpośrednio cytować tekstu bo jak wspomniałem narosło wiele nieporozumień.
Tak jak pisaliśmy w ostatnich postach : geter może (nie musi) być błędem projektowym. I teraz odchodząc trochę od dyskusji o projektowanie w stronę edukacji powstaje pytanie jak najlepiej nauczyć się rozpoznawać sytuację kiedy dane rozwiązanie jest błędem a kiedy nie. Jednym z pomysłów jest aby wziąć jakiś mały problem i spróbować go zaimplementować jednocześnie sprawdzając jak na rozwiązanie wpłynie badane ograniczenie.

Ja np ucząc się programowania funkcyjnego robię sobie ograniczenie, że np. użyję "domknięć" w ten a nie inny sposób i po takiej 45 minutowej sesji patrzę gdzie to pomogło a gdzie przeszkodziło. I nie chodzi tutaj aby tak robić zawsze ale o zrozumienie konsekwencji (i złych i dobrych) danego założenia.
To chciałem objaśnić bo pamiętam, że dużo emocji powstało wokół tego ćwiczenia jako takiego.

Inna naukę jaką wyciągnąłem z tego wątku to to, że przy takim szerokim spektrum osób z różnym doświadczeniem na forum trzeba robić odpowiednie podkłady pod twierdzenia. A podkładem pod uproszczone twierdzenie "gettery to zła praktyka" jest to, że niektóre technologie jak JSP (i kiedyś Hibernate) wymuszają stosowania geterów tam gdzie model ich nie uzasadnia. W efekcie tego dowolna klasa może sobie grzebać w bebechach innych klas i o takich kwestiach jak "information hiding" w dużym stopniu można zapomnieć. Rozwiązań tego problemu przewinęło się w tym wątku kilka - każde ma swoje wady i zalety - idealnego niestety nie znam .
Mam nadzieję, że tym razem "podkład" był wystarczający ;)

<edit>
A no i żeby było jasne to co napisałem powyżej nie oznacza, że gdzieś tam nie istnieje getter, który ma w modelu sens.Paweł Włodarski edytował(a) ten post dnia 18.12.12 o godzinie 23:56

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Paweł Włodarski:
A no i żeby było jasne to co napisałem powyżej nie oznacza, że gdzieś tam nie istnieje getter, który ma w modelu sens.

z mojego doświadczenia wynika, że co do zasady łatwo obronić tezę o własności prywatnej: jak ktoś potrzebuje coś mojego to musi mnie o to poprosić, nierozsądne jest rozdawanie z lenistwa kluczy od własnego mieszkania każdemu kto czasem coś ode mnie potrzebuje, bo po pierwsze w końcu przestana panować nad tym kto ma klucze do mojego mieszkania, każdego muszę poinformować o rozkładzie przedmiotów w moim domu, nie mam gwarancji że niczego nie napsują, każdy remont mojego mieszkania wymaga powtórnego poinformowani o zmianach a mogę o kimś zapomnieć, po trzecie ludzie maja głupi zwyczaj dorabiania kluczy i przekazywania "zaufanym kolegom", w efekcie po jakimś czasie przestaję panować nad sobą i mieszkaniem.

Sytuacja najzdrowsza to taka, w której łatwo znaleźć mój adres o poznać moje kompetencje, nie wpuszczam obcych osób do domu nigdy i muszę mieć na prawdę dobry argument by te zasady złamać. Co prawda wymaga to ode mnie konsekwencji i nie raz jednorazowej dodatkowej pracy ale jednorazowej...

Nie znam przypadku, gdy łamanie powyższego kiedykolwiek by mi pomogło... biorąc pod uwagę dość duże ryzyko nadmiernej "otwartości". Dlatego jak chyba tu już napisałem, każdy projekt zaczynam od tworzenia interfejsów, za atrybuty biorę dopiero wtedy jak "maszyna działa". nie ma atrybutów nie ma get/set i da się i bardzo pomaga.Jarek Żeliński edytował(a) ten post dnia 19.12.12 o godzinie 08:18

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Jarek Żeliński:

z mojego doświadczenia wynika, że co do zasady łatwo obronić tezę o własności prywatnej: jak ktoś potrzebuje coś mojego to musi mnie o to poprosić, nierozsądne jest rozdawanie z lenistwa kluczy od własnego mieszkania każdemu kto czasem coś ode mnie potrzebuje

No tak Jarku, przykład jest bardzo zgrabny. Ale w takim razie - co robisz kiedy potrzebujesz skorzystać z usług, którym musisz dostarczyć coś z Twojego domu? Na przykład z tapicera, któremu chciałbyś zlecić naprawę kanapy? Czy zgodzisz się, że to jest uzasadniony przypadek użycia gettera:

tapicer.napraw(dom.getKanapa()) 

czy masz na to inny sposób?

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Tomasz Szymański:
czy masz na to inny sposób?

Pytanie co prawda do Jarka ale można też tak:

dom.pozwolWejsc(tapicer) 

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Tomasz Szymański:

Jarek Żeliński:

z mojego doświadczenia wynika, że co do zasady łatwo obronić tezę o własności prywatnej: jak ktoś potrzebuje coś mojego to musi mnie o to poprosić, nierozsądne jest rozdawanie z lenistwa kluczy od własnego mieszkania każdemu kto czasem coś ode mnie potrzebuje

No tak Jarku, przykład jest bardzo zgrabny. Ale w takim razie - co robisz kiedy potrzebujesz skorzystać z usług, którym musisz dostarczyć coś z Twojego domu? Na przykład z tapicera, któremu chciałbyś zlecić naprawę kanapy? Czy zgodzisz się, że to jest uzasadniony przypadek użycia gettera:

tapicer.napraw(dom.getKanapa()) 

czy masz na to inny sposób?

kontekst jest taki, że trzeba naprawić kanapę, pierwszy, który wie, że kanapa jest zepsuta to jej użytkownik (a nie tapicer):
- szukamy kompetencji (o ile nie wiemy już gdzie są)
- zlecamy naprawę kanapy
czyli:
mieszkaniec domu woła operację klient -> tapicer.napraw(kanapa)

to klient przekazuje właściwą (uszkodzoną) kanapę do naprawy a nie tapicer żąda konkretnej kanapy, nie wpuszczam tapicera do domu ani nie zdradzam mu wiedzy o wyposażeniu domu (hermetyzacja)

wariant moim zdaniem dużo gorszy:
tapicer pyta właściciela domu o listę uszkodzonych mebli (bo skąd posiada wiedzę, że tam jest kanapa do naprawy?)
właściciel pokazuje listę mebli
tapicer prosi o konkretną kanapę, (czyli twój pomysł)

podejście jakie proponujesz przywodzi mi (może się mylę) podejście typu lista funkcji na zbiorze danychJarek Żeliński edytował(a) ten post dnia 19.12.12 o godzinie 14:49

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Obserwuję ten temat od jakiegoś czasu, dotyka on niebanalnych tematów, z którymi zderza się każdy. (pomijając to, że jest jednym wielkim off-topem:]) Szczególne uznanie dla Jarka, głównie za to, że nie tylko posiada wiedzę, ale też potrafi przekazać ją w wersji strawnej dla innych.

Odnośnie samej sprawy - gettery to standardowy sposób dostępu do pól klasy i myślę, że tak należy o tym myśleć. Dlatego też:
1.jeśli wyciągamy dane obiektu w celu wykonania operacji biznesowej, to po prostu wpadamy w anemiczną logikę, popełniamy poważny błąd obiektowy i powinno to być karane ucinaniem palców
2.jeśli wyciągamy dane obiektu w celu wyświetlenia strony .jsp, czy silnik zapisujący w bazie danych wymaga getterów, to robimy to co konieczne

Jarek pokazał świetny sposób na wyciąganie danych dla celów widoku (stworzenie dodatkowego obiektu danych), dzięki temu gettery przestają być potrzebne. Mam jedynie wątpliwości co do pola ID obiektów będących agregatami. Czy zapytanie się obiektu o jego identyfikator łamię zasadę enkapsulacji ? Nie chodzi mi tutaj o id w znaczeniu bazodanowym, tylko o identyfikator agregatu w metodyce DDD.

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Marcin Mroczkowski:
Mam jedynie wątpliwości co do pola ID obiektów będących agregatami. Czy zapytanie się obiektu o jego identyfikator łamię zasadę enkapsulacji ? Nie chodzi mi tutaj o id w znaczeniu bazodanowym, tylko o identyfikator agregatu w metodyce DDD.

Hm... a w jakim kontekście potrzebujemy tego ID?

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Jarek Żeliński:
Hm... a w jakim kontekście potrzebujemy tego ID?

Dla przykładu w serwisie domenowym, kiedy jesteśmy zmuszeni do wykonania złożonej operacji na więcej niż jednym agregacie (wiem że to nie powinno się tak robić, ale czasami inaczej się nie da). Osobiście trafiłem na przypadek, w którym musiałem w serwisie stworzyć instancję nowego agregatu typu Y, który potrzebował referencji do agregatu typu X (asocjacja agregatów po ID). W tym wypadku musiałem zapytać się X o ID.