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...

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?

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.

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?

Refaktoryzować czy nie - oto jest pytanie?

o co chodzi?

Czym jest refaktoryzacja? W skrócie - jest to wprowadzenie zmian w kodzie, które nie wpływają na zmianę zachowania aplikacji, są niewidoczne dla końcowego użytkownika, ale poprawiają jakość kodu. Dzięki tym modyfikacją, w przyszłości nie ogarnie nas przerażenie, gdy będzie trzeba zajrzeć do tego kodu ponownie. No dobra, pewnie i tak ogarnie:P, ale nie będzie już ono tak wielkie.
Jeżeli to dla Was za mało, to więcej na ten temat znajdziecie tutaj.

baza danych nie istnieje

o problemi słów kilka

Zdarzyło mi się kilka (lub trochę więcej:) razy, że przy prezentowaniu projektu aplikacji programistom, padało pytanie: 'a gdzie jest baza danych?'.
No właśnie, gdzie ona jest?
Skoro prezentuje działanie aplikacji, jej logikę, to pojawiaja się przecież jakaś reprezentacja danych (modele), ale gdzie ja je trzymam, skądś muszę je odczytać, jakoś zapisać, zaktualizować. Gdzie? Kiedy? Jak? I dlaczego nie ma tego wszystkiego w projekcie?

ile testów jednostkowych warto napisać?

a na co mnie to?

Testy jednostkowe (jak i wszelkie pozostałe) przydają się. Co prawda nie są, jak sądzą niektórzy, gwarancją tego, że nasz kod nie posiada błędów i jest wolny od jakichkolwiek pomyłek. Dają nam jedynie informacje, że nie udało się danego błędu znaleźć oraz, co równie ważne, że w określonych przypadkach kod/aplikacja zachowuje się tak, jak zakładamy.

Ta druga informacja jest w stanie ułatwić nam życie w naprawdę wielkim stopniu, gdy dochodzimy do momentu, gdy kod trzeba refaktoryzować/modyfikować. Testy dają nam pewność, że w danych przypadkach, po wszystkich wprowadzonych zmianach, wszystko nadal działa w sposób prawidłowy.

Konstruktor w interfejsie i klasie abstrakcyjnej?

wstęp

Abstrahując od tego, na co pozwala nam dany język programowania (np. PHP pozwala niestety na wszystko), to czy w interfejsie jest sens posiadać deklarację konstruktora? A co w przypadku klas abstrakcyjnych? Jak sądzicie, taka funkcjonalność może się przydać, czy raczej jest to coś zbędnego, czego najprawdopodobniej nigdy byście nie wykorzystali?

Ważne, żeby był porządek:)

o czytelności kodu raz jeszcze

Było o tym, jakie stosować nazwy w kodzie, było o komentarzach, a teraz przyszła pora na kolejny wpis dotyczący czytelności kodu. I ponownie poruszam temat błahy, ale mam nadzieję, że rady w nim zawarte komuś się przydadzą:)

Dzisiaj będzie o kolejności, w jakiej atrybuty i metody powinny występować w kodzie, w zależności od ich definicji.