[pottymouth]

Pewnie się ktoś zdziwi za użycie ostatniego tagu ( ͡° ͜ʖ ͡°)
Błakając się po internecie trafiłem na gościa, który stwierdził, że w programowaniu obiektowym w tym w javie powinno się uzywać zasady SESE (Single Entry, Single Exit). Polskich materiałów nie znalazłem na ten temat. Czy ktoś może powiedzieć czy jest w ogóle używane i dodatkowo kilka słów więcej?

double getPayAmount() {
 double result;
 if (_isDead) result = deadAmount();
 else {
 if (_isSeparated) result = separatedAmount();
 else {
 if (_isRetired) result = retiredAmount();
 else result = normalPayAmount();
 };
 }
 return result;
}; 

i z użyciem SESE

double getPayAmount() {
 if (_isDead) return deadAmount();
 if (_isSeparated) return separatedAmount();
 if (_isRetired) return retiredAmount();
 return normalPayAmount();
};

#java #programowanie #fortran #naukaprogramowania

[informatyk]

Najlepiej poczytaj sobie za i przeciw na Stacku, np.:
http://stackoverflow.com/questions/12745412/single-entry-single-exit-rule
http://stackoverflow.com/questions/17295315/when-a-statement-is-said-to-be-single-entry-single-exit-and-when-it-isnt
http://stackoverflow.com/questions/4838828/why-should-a-function-have-only-one-exit-point
http://stackoverflow.com/questions/36707/should-a-function-have-only-one-return-statement
http://softwareengineering.stackexchange.com/questions/118703/where-did-the-notion-of-one-return-only-come-from

[pottymouth]

@informatyk: super dzięki za odpowiedź ( ͡° ͜ʖ ͡°)

[L.....G]

Single Entry, Single Exit

@pottymouth: hm.. ale przecież pierwszy przykład jest z jednym exit point, a drugi przykład z wieloma

[L.....G]

@pottymouth: PS.
A problem z dupy, kwestia czytelności i może być w różnych sytuacjach różnie

w językach wysokiego poziomu już masz z definicji single entry.

co do out.. hm...nic nie wiem że powinno się używać SESE, bo bez kłopotu znajdę Ci taki przykład, że single exit, mozę wygląać mniej przejrzyście niż odwrotnie i na odwrót.

[MicMic]

@pottymouth: Według własnych preferencji. Przede wszystkim powinno być czytelne i spójne.
Osobiście używam pierwszego przykładu jeśli muszę przetransformować wynik przed zwróceniem.
Do drugiego, jeżeli masz jakąś ustaloną logikę, możesz użyć Map, gdzie T może być funkcją lub innym obiektem. Masz wtedy 2 opcje: robić na mapie bezpośrednio get(Predicate warunek), lub stream().filter(Predicate warunek).findFirst().orElse(T default);

[nachteil]

w programowaniu obiektowym w tym w javie

@pottymouth: Nie czepiam się, tylko chciałbym trochę doprecyzować - kod, który wkleiłeś, nie jest w ogóle obiektowy, a czysto proceduralny. Dobry kod obiektowy używa zasady "tell, don't ask", czyli nie sprawdza w ifach warunków, lecz raczej zleca wykonanie operacji pewnemu obiektowi, który wie, co z nią dalej zrobić. Nie twierdzę, że taki kod jest zawsze czytelniejszy, ba, w tym wypadku pewnie tworzenie struktury obiektów

[nachteil]

@pottymouth: Btw, jeśli chcesz poznać, czym jest hardkorowa obiektowość, to polecam: http://www.yegor256.com/, a na początek zwłaszcza http://www.yegor256.com/2014/11/20/seven-virtues-of-good-object.html .
Jego podejście często jest na przekór pragmatyzmowi i użyteczności, ale mi osobiście bardzo pomogło w myśleniu o obiektowości jako spójnym paradygmacie i dostrzeżeniu, gdzie ja i inni często idą na skróty, bo łatwiej jest napisać coś proceduralnie (a potem męczyć się z utrzymaniem)

[P.....3]

Jego podejście często jest na przekór pragmatyzmowi i użyteczności, ale mi osobiście bardzo pomogło w myśleniu o obiektowości jako spójnym paradygmacie i dostrzeżeniu, gdzie ja i inni często idą na skróty, bo łatwiej jest napisać coś proceduralnie (a potem męczyć się z utrzymaniem)

@nachteil: W tej dziedzinie koziołek też daje rade moim zdaniem.