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.

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.

Komentarze? Tylko pod wpisem, nie w kodzie:)

na początek

Na początku był kod. Kod, który się rozrastał, żył, ewoluował, a pracę nad nim wykonywało programistów wielu. I kod ten spełniał swoje zadanie. I nigdy nie dotknął go zbędny proces refaktoryzacji, co pozwoliło, że rozmiary jego były naprawdę okazałe, jego możliwości - mnogie, a czytelność - żadna.

"Na szczęście", w trakcie pracy nad kodem, wielu programistów, którzy mieli z nim do czynienia, otaczali kolejne linijki instrukcji, pokaźną ilością komentarzy, które miały na celu przekazać przyszłym pokoleniom tajemnice zawarte w kodzie i uzmysłowić jego działanie.

Nowy wygląd strony

Jak łatwo zauważyć pobawiłem się trochę wyglądem strony:) Zdecydowałem się na taki zabieg z dwóch powodów. Po pierwsze, stary wygląd już mnie zaczął nudzić:P Po drugie, chciałem dodać trochę radosnych kolorów:)

Skąd ten wpis? Bo nie jestem do końca pewien, czy wygląd jest dobry, czy nie rozprasza uwagi, czy kolory nie są zbyt jaskrawe. Niestety moje zdolności odnośnie projektowania wyglądu stron internetowych nie są powalające, dlatego też zdecydowałem się na opublikowanie tego krótkiego wpisu, z nadzieją na jakieś uwagi z Waszej strony:)

Jeżeli coś Wam się nie podoba, coś warto zmienić lub coś po drodze popsułem i nie zauważyłem tego, to będę wdzięczny za komentarze, najlepiej konstruktywne:P
Ponieważ milczenie jest oznaką zgody, to brak komentarzy uznam za podzielenie mojego pomysłu na nowy wygląd strony, więc lepiej zastanówcie się dwa razy, czy warto z komentowania zrezygnować:)

Rzeczy po imieniu nazywać

nie o formie, a o treści

Jest wiele artykułów na temat nazewnictwa i z przykrością stwierdzam, że i ja go poruszę:) Zdaję sobie sprawę, że dla niektórych Was temat jest prosty, ale uważam, że jest to na tyle istotna rzecz, że warto poświęcić jej choć jeden wpis.

Chciałem jeszcze na wstępie zaznaczyć, że nie będę zajmował się tym, czy w nazwach powinniśmy używać podkreśleń, czy też wielkich liter, czy wszystko powinno być pisane ciągiem itp. Tu już wszystko zależy od polityki firmy i konwencji (bądź jej braku) przyjętych w danym języku programowania.

"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:

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.

Jak programować obiektowo cz. 7 - const

na wstępie słów kilka

Znowu dłuższa przerwa w publikowaniu czegokolwiek. Na szczęście dobiegła końca i mam nadzieję, że w ciągu najbliższych kilku-kilkunastu tygodni uda mi się dokończyć wszystkie zaległe wpisy, na które pomysły dojrzewały, lecz z braku czasu nie mogły się doczekać realizacji:(
O czym dzisiaj? O stałych. A czym są te stałe? Kiedy ich używać, a kiedy nie? O tym dalej:)

Boski obiekt

I'm Object almighty!

Czym jest boski obiekt? Najkrótsza odpowiedź na to pytanie jest zarazem chyba najlepszą: jest wszystkim, odpowiada za wszystko. I choć może wydawać się, że stworzenie takiego bytu jest naprawdę trudne, to rzeczywistość udowodniała mi wiele razy, że aplikacje zawierają pełno tego typu tworów.

Jak programować obiektowo cz. 6 - static

wstęp

Część z Was zapewne zauważyła, że w poprzednich wpisach pominąłem kilka istotnych rzeczy dotyczących atrybutów klas, ich metod, czy też samych klas. W kolejnych wpisach postaram się nadrobić tą zaległość.

Na pierwszy ogień idzie słowo kluczowe static. Z tym, że pominę kwestię używania tego słowa jako referencji do klasy, o czym pisałem tutaj.
Co oznacza użycie statycznej metody bądź atrybutu? Jest to równoznaczne z tym, że do jej/jego używania nie potrzebujemy tworzyć instancji danej klasy.