"Język inżynierii systemów SysML"

celem wyjaśnienia własnych poczynań

Dzisiaj skończyłem czytać książkę "Język inżynierii systemów SysML. Architektura i zastosowania. Profile UML 2.x w praktyce" i choć kiedyś sobie obiecałem, że na blogu nie będę umieszczać żadnych recenzji, czy też opinii na temat książek, doszedłem do wniosku, że pora na weryfikację tego poglądu:)
Jeżeli przeczytam coś, obok czego naprawdę nie powinno się przejść obojętnie - napiszę o tym..
Jeżeli przeczytam coś, czego należy unikać za wszelką cenę - również postaram się opublikować stosowny artykuł:)
Pomijam oczywiście książki, które przeczytałem do tej pory, bo albo wrzuciłem o nich wzmiankę na Google+ albo na Twitterze, a nawet jeżeli nie, to są istotniejsze tematy, na które warto pisać:P

Które metody umieścić w interfejsie?

krótki wstęp, a w nim o tym, czym jest interfejs

Do czego wykorzystuje się interfejsy? Do zapewnienia, że obiekty danej klasy będą posiadały określone metody. Po co chcemy mieć tą pewność? Ponieważ w danym miejscu ich posiadanie jest niezbędne do bezbłędnego wykonania pewnych instrukcji. Dlaczego wszystkie metody interfejsu są abstrakcyjne? Gdyż nie wymagamy określonego ich działania, wymagamy jedynie ich istnienia.

Mój kod jest świetny!

Testowanie to naprawdę świetna sprawa. Pokazuje, czy wszystko działa:)
Tylko, że niestety nie pokazuje. Jedynie dostarcza nam informacji, że nie udało nam się znaleźć błędu, a to jest naprawdę istotna różnica.

ten pieprzony init()

ten pieprzony init

Zend w wersji 1.x obfitował w klasy, które posiadały deklarację pustej metody init(), która była wywoływana w konstruktorze.

Do czego jest ona wykorzystywana? Twórcy Zenda doszli do wniosku, że jeżeli chcesz np. stworzyć odpowiednio skonfigurowany formularz (np. do dodawania produktów), to idealnym rozwiązaniem będzie rozszerzenie klasy Zend_Form i umieszczenie całej kofiguracji owego formularza w nadpisanej metodzie init(), która wykona się przy tworzeniu nowego obiektu.

Sprytne, no nie? I jeszcze w dodatku można pokusić się o stwierdzenie, że jest to implementacja wzorca template method.

Chciałbym jednak zasmucić wszystkich tych, którzy praktykują takie rozwiązanie. Ani to sprytne nie jest, a użycie wzorca jest niepoprawne i niepotrzebne.

remove useless code!

Dla każdego z Was stwierdzenie z tytułu jest zapewne czymś oczywistym, ponieważ usuwanie starego, zbędnego kodu jest, a przynajmniej powinno być, nieodłączną częścią rozwijania aplikacji, refaktoryzacji klas i ich zależności.

Jak programować obiektowo

to już koniec

Po kilku miesiącach w końcu udało mi się wczoraj opublikować ostatni wpis z tej serii:)

Jak programować obiektowo cz. 10 - final

final - what for is that?

Wielu programistów zapewne nigdy nie użyła słowa final w celu oznaczenia klasy lub metody. Dlaczego? Z prostego powodu, a raczej jego braku. "Po co?" W końcu, jeżeli ktoś będzie chciał sobie dziedziczyć bądź nadpisywać niech sobie robi to, co mu się żywnie podoba. W czym problem? Jak na ironię ten argument wcale nie jest 'przeciw' stosowaniu final, jak błędnie uważają niektórzy. Jest to najważniejszy powód, dla którego to słowo kluczowe powinno być wykorzystywane, ponieważ przemyślane jego zastosowanie może opłacić się w przyszłości.

Dublowaniu kodu mówię stanowcze TAK!

bo trzeba być oryginalnym

Często spotykam się z sytuacją, że programista za wszelką cenę stara się wyeliminować wszystkie powtórzenia w swoim kodzie. Dlaczego? Ponieważ uważa, że duplikacja kodu to czyste zło i każda linijka kodu powinna być unikalna. Tylko czy takie przeświadczenie jest słuszne? Nie.

Na Twitterze? Obecny:)

No i nadszedł ten czas, żeby zaznaczyć swoją obecność również na twitterze:)

Jak programować obiektowo cz. 9 - klasy abstrakcyjne

klasa abstrakcyjna

Czym jest klasa abstrakcyjna? Nie będę się rozpisywał na temat konstrukcji (jak zwykle:), ponieważ w internecie można znaleźć sporo definicji.
We wstępie chciałbym się natomiast skupić na podziale klas abstrakcyjnych. Co prawda, z tego co się orientuję, żadnego oficjalnego podziału nie ma, ale po jakimś czasie programowania można wyróżnić trzy powtarzające się wzorce (nie w znaczeniu wzorców projektowych) klas abstrakcyjnych: