Więcej nie znaczy wolniej cz.2 - analiza

kiedy jest tylko pomysł...

Czym jest analiza? Analiza to rozkład na składniki/czynniki (wikipedia). Trochę lakonicznie, nieprawdaż? Próbą zdefiniowania terminu w interesującym nas kontekście zajmę się w kolejnym akapicie. Teraz skupmy się na tym kiedy jest czas na analizę?

Jest to aktywność, która powinna być przeprowadzona na samym początku, to wyniki analizy dają nam podstawy do stworzenia dobrego projektu.

Więcej nie znaczy wolniej cz.1

o tym, co sprawia, że jesteśmy lepsi

Ostatnio robiłem podsumowanie roku kierowania projektem (pisałem o tym tutaj) i statystyki, które ujrzały moje oczy, były dużo lepsze niż się spodziewałem:)
Nie jestem jednak osobą, która długo cieszy się sukcesami. Większą radość odnajduję w kolejnych wyzwaniach, więc następnego dnia, po przedstawieniu zespołowi efektów naszej wspólnej pracy, zacząłem się zastanawiać, co dalej? Wychodzę z założenia, że pozostanie w tym samym miejscu jest równoznaczne z cofaniem się do tyłu, tak więc jedynie kolejne ulepszenia wchodzą w grę:)

SOLIDny kod cz. 2 - Single responsibility principle

w czym rzecz

Jak już ostatnio pisałem, Single responsibility principle (SRP), czyli zasada jednej odpowiedzialności, mówi o tym, że klasa nie powinna mieć więcej niż jednego powodu do modyfikacji.
Często spotykam się z tym, że programiści twierdzą, że takie myślenie prowadzi jedynie do niepotrzebnego rozbijania każdej klasy na kilka bądź więcej elementów składowych. Co za tym idzie? Potrzeby zarządzania wieloma klasami. A to wszystko tylko po to, żeby zrobić coś naprawdę prostego.

Cóż, można na to spojrzeć w ten sposób. Jednak jest kilka ale...

Różnice między klasą abstrakcyjną, a interfejsem

wstęp

Zdaję sobie sprawę, że o różnicach pomiędzy interfejsem, a klasą abstrakcyjną pisałem już wielokrotnie (m. in. "klasa, czy już interfejs" oraz "abstrakcja vs interfejs"), jednak nigdy nie pisałem o tych podstawowych. Opierając się na wielu rozmowach rekrutacyjnych, które do tej pory przeprowadziłem, zauważyłem, że te różnice nie są jednak tak powszechnie znane, jak przypuszczałem i może warto byłoby je wymienić oraz wytłumaczyć skąd się biorą.

Dlatego też dzisiaj chciałbym nadrobić brak wpisu na ten temat:)

"Refaktoryzacja. Ulepszanie struktury istniejącego kodu"

co się odwlecze...

Już od dłuższego czasu przymierzałem się do przeczytania książki Martina Fowlera niestety nieustannie coś mnie od tego odciągała (zazwyczaj brak czasu lub inna literatura:). Na szczęście ostatnio udało mi się po nią sięgnąć, a dzisiaj zakończyłem jej lekturę i muszę przyznać, że... ale o tym za chwilę:)

SOLIDny kod cz. 1 - wstęp

SOLIDnie, czyli jak?

Skoro podstawy programowania obiektowego mamy już za sobą (dla tych, którzy przegapili - spis treści jest tutaj), to pora zająć się jakimiś poważniejszymi tematami związanymi z OOP :)

Na początek chciałbym rozszyfrować akronim SOLID.
Co się za nim kryje? Zbiór pięciu podstawowych zasad dotyczących programowania obiektowego:

• Single responsibility principle
• Open/closed principle
• Liskov substitution principle
• Interface segregation principle
• Dependency inversion principle

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.