Kiedy rozpoczynaliśmy pracę nad obecnym projektem mieliśmy już trochę doświadczeń i przemyśleń odnośnie tego co czyni kod niezwykle nieczytelnym i trudnym w rozwoju. Wśród głównych przyczyn leżały ogromne klasy opakowujące kod proceduralny, długie metody czy masa zagnieżdżonych warunków - a wszystko przypieczętowane zmiennymi o słodko brzmiących nazwach temp czy zzz.
Na tym polu odnieśliśmy zauważalny sukces gdyż nasza największa klasa ma chyba 400 linii, żadna metoda nie przekracza 30 linii a 90% kodu nie ma więcej niż jednego poziomu zagnieżdżenia. Klęskę ponieśliśmy za to na innym froncie, którego istnienia kilka lat tamu nawet się nie domyślałem. Otóż kiedy tworzyliśmy nasze małe czytelne klasy zawsze musieliśmy je gdzieś umieścić. DAO szło zazwyczaj do paczki costam.dao kontrolery do paczki costam.controlers itd.
Istnieje specjalna metryka w sonarze, która bada tego typu spierdoliny :
I chociaż nie mam jeszcze w pełni intuicyjnego wyczucia tej metryki to wskazane wartości pokazują, że może być lepiej.
A co da nam to, że paczki nie będą tak poprzeplatane? Aby to zrozumieć złamiemy (ale tylko pozornie) jedną z zasad dobrego kodu obiektowego
Jak OOP tworzy Klasę Blob/Good
Klasa Money będzie dobrym przykładem bo w dzisiejszych czasach każdy potrzebuje pieniędzy. Na początek zobaczmy co się stanie kiedy przedstawimy pieniądze jako zwykłą strukturę danych:
public class Money {
private final BigDecimal amount;
private final Currency currency;
public Money(BigDecimal bigDecimal, Currency currency) {
this.amount = bigDecimal;
this.currency = currency;
}
public BigDecimal getAmount() {
return amount;
}
public Currency getCurrency() {
return currency;
}
}
Niestety powyższa forma jest zaproszeniem do tworzenia klas typu Utils czy Helper. A pod tym linkiem ----> http://nemo.sonarsource.org/ możecie zobaczyć, że klasy utils to jedne z bardziej złożonych tworów.
No to spróbujmy, żeby było bardziej obiektowo :
public class Money {
private final BigDecimal amount;
private final Currency currency;
public Money(BigDecimal bigDecimal, Currency currency) {
this.amount = bigDecimal;
this.currency = currency;
}
public Money add(Money moneyToAdd){
checkTheSameCurrency(moneyToAdd);
return new Money(moneyToAdd.amount.add(this.amount),currency);
}
public boolean isGreaterThan(Money moneyToCompare){
checkTheSameCurrency(moneyToCompare);
return this.amount.doubleValue()> moneyToCompare.amount.doubleValue();
}
private void checkTheSameCurrency(Money moneyToAdd) {
if(moneyToAdd.currency!=this.currency){
throw new RuntimeException("zle");
}
}
}
A co gdy domena się rozwija i muszę obliczyć podatek? "Tell don't ask" ?
public class Money {
private final BigDecimal amount;
private final Currency currency;
public Money(BigDecimal bigDecimal, Currency currency) {
this.amount = bigDecimal;
this.currency = currency;
}
//!!!!!!
public Tax calculateTax(double percentage){
return new Tax(amount.multiply(BigDecimal.valueOf(percentage)));
}
Jeśli mówić o smrodzie w kodzie to powyższe opcje dla mnie niezwykle śmierdzą. A co dyby tak wykorzystać modyfikator dostępu, którego nie ma?
public class Money {
private final BigDecimal amount;
private final Currency currency;
public Money(BigDecimal bigDecimal, Currency currency) {
this.amount = bigDecimal;
this.currency = currency;
}
BigDecimal getAmount() {
return amount;
}
...
}
public class TaxCalculator {
private static final double standardTaxPercentage=0.23;
public Tax calculateTax(Money money){
return new Tax(money.getAmount().multiply(BigDecimal.valueOf(standardTaxPercentage)));
}
}
Bonus - skąd się bierze fundamentalizm obiektowy
Znam pewnych ludzi, którzy kłócili by się, że powyższy przykład można rozwiązać jakimś wizytatorem czy innymi cudami. Problem polega na tym, że czasem mogą mieć rację a czasem nie ale sam fakt uznawania zasady rodem z wikipedii typu "tell don't ask" czy "DRY" za święte i nienaruszalne doprowadza mnie do szalonego płaczu. A w ogólności dobija mnie traktowanie OOP jako panaceum na wszystko - czyli zarzuty typu "ten kod jest zły bo nie obiektowy".
Jeśli ktoś ma niech zerknie sobie do rozdziału nr 6 "Czystego kodu" pod tytułem "struktury danych". Są tam dwa przykłady obliczania pól figur - jeden obiektowy a drugi proceduralny. Nie chce mi się kopiować tutaj źródeł ale wniosek postawiony przez autora jest jasny: wersja bardziej proceduralna z ifami jest lepsza jeśli dojdą nam nowe funkcje (jedno miejsce do zmiany vs wszystkie klasy figur do zmiany) - ale wersja z polimorfizmem jest lepsza jeśli spodziewamy się nowych kształtów - wniosek: obiektowy nie znaczy najlepszy.
Bo nawet czy jest sens toczyć spory odnośnie tego czy kod z ogromną klasą ale idealna enkapsulacją jest bardziej obiektowy niż kod z małymi klasami, które jednak nie starają się robić wszystkiego jednocześnie udostępniając gdzieniegdzie szczegóły implementacyjne?
A może jednak przychodzi czas aby nie ograniczać się do racjonalizacji swoich wyborów prostymi zasadami z wikipedii ale zgłębić dokładniej jakie te wybory niosą konsekwencje? Są różne modele rozwoju zdolności : Shu Ha Ri , SU HA RY , SŁU CHAJ STARY - opisujące jak to od prostych reguł należy przechodzić do zrozumienia zasad poprzez magiczną transcendencję. Na samym początku jest bagno, totalnie zjebany kod i tutaj jest miejsce na stosowanie zasad "Tell don't ask" czy "DRY" bez myślenia bo cokolwiek się nie zrobi to będzie lepiej. Ale jeśli zostanie się na tym etapie to jesteśmy na prostej ścieżce do Obiektowego Fundamentalizmu
O a teraz złamię jeszcze jedną zasadę - święte DRY
class PracownikUczelni{
private String tytuł;
}
class Film{
private String tytuł;
}
class abstract PosiadaczTytułu{
private String tytuł;
}
class PracownikUczelni extends PosiadaczTytułu{}
class Film extends PosiadaczTytułu{}
