poniedziałek, 29 października 2012

różne typy zwracane?

ach ten pehape...

Jedyną rzeczą, której naprawdę nie mogę przeboleć w PHP, to fakt, że nie posiada on typowania. Oczywiście można "umówić się" z innymi programistami w zespole, że "typujemy" tzn. w komentarzach określamy typ przyjmowany i zwracany i się tego trzymamy, ale jest to jedynie obejście problemu, a nie jego rozwiązanie.
Dobra, niestety świat nie jest idealny i musimy jakoś z tym żyć. W dodatku, jeżeli kod jest rzeczywiście obiektowy, to w większości przypadków typowania rzeczywiście można używać na tyle często, że zapomina się o problemie.

Jednak tylko do czasu...

sobota, 27 października 2012

interfejs + unsupported method? WTF ?!

przesada jest twoim wrogiem

Żaden z nas nie posiadł całej wiedzy, którą posiada obecnie, wraz z pierwszym kontaktem z programowaniem obiektowym. To oczywiste, że wszystkiego trzeba się nauczyć. Trwa to dłużej lub krócej, uczymy się na własnych błędach, doświadczeniu innych itp.

Czasami odkrywamy "coś", co na zawsze zmienia nasz sposób postrzegania kodu. Zdarza się, że danego rozwiązania, konstrukcji etc. używaliśmy wcześniej, ale dopiero w pewnym momencie odkrywamy wszystkie tajemnice stojące za danym zagadnieniem, ich piękno i wartości. A przynajmniej tak nam się wydaje:)

co się dzieje, gdy deklaracje są podobne...

what's the problem?

Czasami zdarza nam się zauważyć w kodzie metody, które posiadają takie same deklaracje. Jest to nieuniknione, dziesiątki, setki i więcej tysięcy linii kodu sprawia, że niekiedy "powtórzenia" tego typu się zdarzają.
Dlaczego "powtórzenia" w cudzysłowie? Ponieważ nie jest to wynik duplikacji logiki, a jedynie użycia języka w celu opisania danej funkcjonalności. Tylko czy rzeczywiście nie jest?

sobota, 20 października 2012

o fabrykach i interfejsach historia krótka

usprawiedliwienie

Na wstępie zaznaczam, że wpis nie jest przede wszystkim o wzorcu Factory (choć pojawia się on tutaj), wątkiem przewodnim nie są również interfejsy (chociaż i one się pojawią:). Najistotniejszym elementem tego wpisu jest próba przedstawienia procesu analizy, dzięki któremu usuwamy zbędne zależności pomiędzy klasami, a powiązania przestają opierać się na konkretnych implementachach.

sobota, 6 października 2012

czy wystarczy klasa, czy już czas na interfejs?

w czym problem?

Czasami są sytuacje, kiedy poważnie się zastanawiamy nad tym, czy interfejs jest nam rzeczywiście potrzebny, czy może jego stworzenie byłoby po prostu generowaniem zbędnego kodu, mającego na celu tylko i wyłącznie dodanie kolejnego elementu do, już i tak dość skomplikowanej, struktury.

Kiedy, więc klasa już nam nie wystarcza i niezbędne staje się wprowadzenie interfejsu?