W poprzednich częściach przeszliśmy przez zasady SOLID.
S – Single Responsibility Principle (oraz cz. 2)
O – Open Close Principle (oraz cz. 2)
L – Liskov Substitution Principle
I – Interface Segregation Principle
D – Dependency Inversion Principle
Słowo SOLID bardzo dobrze odzwierciedla to, do czego te zasady prowadzą czyli do budowania solidnego kodu. Przez solidny kod rozumiem taki, który jest łatwy w modyfikacji i który szybko można dostosować do zmieniających się wymagań. Nie są to jednak wszystkie zasady programowania obiektowego, które warto znać i stosować.
Na tapetę bierzemy zatem Reuse Release Equivalence Principle czyli zasadę, która mówi, że kod, który chcemy ponownie wykorzystać, powinien być w paczce, czarnej skrzynce, która jest dostarczalnym modułem czyli po ludzku biblioteką czy też assembly (w .necie).
A jeszcze bardziej po ludzku, zasada ta mówi po prostu, że ponownie użycie kodu to nie jest skopiowanie klasy z jednego projektu do drugiego. Jeżeli chcemy użyć ponownie raz napisany kod to należy go wydzielić do biblioteki czy modułu, który później możemy użyć ponownie.
Takie podejście powoduje, że gdy autor oryginalnego kodu wprowadzi zmianę – w szczególności poprawi jakiś błąd – wówczas możemy łatwo korzystać z dobrodziejstw takich zmian pobierając nową wersję biblioteki. W zespołach korzystających z automatyzacji (Continious Integration/Delivery) nawet nic nie trzeba robić – build server zrobi za nas wszystko.
To co powyżej napisałem może wydawać się oczywistą oczywistością jednak niestety nie jest. Jest wielu programistów (serio!), którzy “ponowne użycie kodu” rozumieją jako kopiowanie z jednego pliku do innego pliku. Dzięki czemu odcinają się od jakiejkolwiek możliwości rozsądnej aktualizacji kodu poza spisaniem na kartce wszystkich takich kopii i regularnie przeglądanie repozytorium w poszukiwaniu zmian – POWODZENIA
Zasada ta ma szczególne znaczenie w grupach, gdzie pracuje więcej niż jedna osoba lub gdy jedna osoba pracuje nad więcej niż jednym projektem – czyli praktycznie zawsze.
Jedyne ewentualne odstępstwo od tej zasady jakie widzę, to kopiowanie kodu, który jest podobny jednak logicznie posiadający inny kontekst.
Aby korzystać z dobrodziejstw zasady Reuse Release Equivalence Principle dobrze stosować się do wcześniejszych – tych z SOLID-a bo wyobraź sobie, że w metodzie CalculateInvoiceValue nagle ktoś zmieni obliczanie faktury na obliczanie różnicy pomiędzy dwiema datami.
