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.