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:

Otaczanie wyjątków niskiego poziomu

O tym, że warto tworzyć własne wyjątki pisałem już tutaj. Dzisiaj pozwolę sobie na kontynuację tematu dotyczącego wyjątków, a mianowicie będzie kilka słów na temat tego czy i dlaczego warto otaczać wyjątki niskiego poziomu.

Po co te wzorce?

Od jakiegoś czasu nieodłącznym elementem wszelkich ogłoszeń o pracę dla programistów języków obiektowych pojawia się znajomość wzorców projektowych, co byłoby nawet całkiem zrozumiałe, gdyby nie jeden drobny szczegół: w wielu firmach z tego grona, rozmowa kwalifikacyjna będzie jedynym momentem, kiedy o wzorcach usłyszycie.

Jak programować obiektowo cz. 8 - interfejsy

kilka słów na początek

O interfejsach pisałem już kilka razy (np. tu i tu) i pewnie jeszcze nie raz napiszę, ponieważ są one (wraz z klasami abstrakcyjnymi) jednymi z najistotniejszych elementów projektowania obiektowego. Kiedy już je poznasz, zrozumiesz i się z nimi zaprzyjaźnisz, tak naprawdę dopiero w tym momencie odkrywasz piękno pisania obiektowego, jego elastyczność.

Nie poruszę w tym wpisie wszystkich aspektów dotyczących interfejsów, nawet nie będę się starał, chodzi mi jedynie o podstawowe (i moim zdaniem najważniejsze) cechy interfejsów.