Dlaczego samochody są złe, czyli po jakiego grzyba tutoriale robią nam wodę z mózgu?
W końcu się zmotywowałem, a poniżej efekt
Jeśli ktoś z Was uczył się jakiegoś obiektowego języka programowania to mógł się przed chwilą uśmiechnąć pod nosem. Samochody. Wszędzie te samochody. Oczywiście, samochody posiadają markę, kolor, silnik. To już musi brzmieć znajomo. Ale od początku.
Obiekt. Podstawowa jednostka czasu i przestrzeni w obiektowych językach programowania. A może to jednak klasa jest tą jednostką? Prawda jest taka że w przypadku obiektów i klas nie ma dylematu kury i jajka - tu wszystko jest jasne. Klasa jest "projektem" obiektu, a obiekt instancją klasy. I choć w Javie wszystko dziedziczy po klasie Object, to jednak nie ma obiektu bez klasy.
Część z Was już wie, a część z Was zaraz się dowie, że klasa będąc "projektem" obiektu, jego definicją, w swoim najprostszym ujęciu może posiadać pola oraz metody. Pola służą do przechowywania danych, z kolei metody, w dużym uproszczeniu, coś z tymi danymi przechowywanymi w polach robią.
No ale dziki! Co z tymi samochodami, bo się niecierpliwimy!
Już odpowiadam. Jeśli ktoś miał okazję robić jakiś tutorial z Javy albo uczestniczył w bootcampie to prawie na sto procent widział public class Samochod. Taki Samochod miał pola: private String kolor, private String marka i obowiązkowo private Silnik silnik. Posiada też metody. I tu się zaczyna cały problem jaki widzę. Bo czy logicznym z punktu widzenia początkującego programisty jest to że Samochod posiada metody uruchom() czy zahamuj()? Ano tak. A czy z perspektywy programowania obiektowego ma to sens? Ano nie. Paradoksalnie, często w tutorialu samochód jest jeszcze dalej eksploatowany, i w pewnym momencie służy do wytłumaczenia czym jest odwrócenie zależności, i wtedy (najczęściej) jest to zrobione poprawnie. Ale o tym kiedy indziej.
To co z tym samochodem jest nie tak że jest on złym przykładem? Bo samochód sam w sobie jest tworem zbyt skomplikowanym żeby móc go opisać za pomocą jednej klasy która będzie zawierała absolutnie wszystkie jego elementy składowe, metody, enumeracje, i co tylko sobie można jeszcze tam wyobrazić.
Dlaczego nikt nie używa jako przykładu czegoś prostszego? Weźmy takiego buta. But ma kolor, but ma markę, składa się z kilku różnych materiałów które zostały użyte do jego produkcji, ma sznurówki, rzepy czy zamek. No but. Chyba każdy z Was widział kiedyś buta.
Jedyne metody jakie może mieć nasz but to tak zwane gettery i settery - metody które służą do ustawiania wartości pól. Przykładowo - but ma kolor, więc setterem do ustawienia koloru będzie setColor() a getterem do pobrania wartości koloru będzie getColor(). Bez żadnych skomplikowanych powiązań między wewnętrznymi elementami buta. Jest on też doskonałym przykładem do tego by pokazać kilka rodzajów pól jakie może mieć klasa. Kolor - ciąg znaków, rozmiar - wartość liczbowa, sposób wiązania - enumeracja (sznurówki, rzepy, zamek), a rodzaj materiału może być osobnym obiektem o nazwie Material, który będzie miał w środku przykładowo rodzaj materiału i wartość prawda/fałsz odnosząca się do jego nieprzemakalności. Proste? Proste.
But nie będzie miał metod takich jak załóż() czy zawiąż() - bo każdy chyba się zgodzi że but się sam nie zakłada ani sam się nie zawiązuje (no dobra, wiem że istnieją Nike Adapt :P) - wiadomym jest że za zakładanie buta odpowiedzialny jest inny obiekt - Człowiek.
Odpowiedzialność to też ważne słowo w programowaniu obiektowym. Dziś rozpisywać się o tym nie będę, ale chciałem napomknąć jedynie że w programowaniu obiektowym mamy wprowadzony zestaw założeń opisywany skrótem SOLID - gdzie rozwinięciem pierwszej literki jest "Single responsibility principle" mówiąca o tym że klasa powinna mieć tylko jedną odpowiedzialność. W przypadku klas służących do przechowywania danych - tą odpowiedzialnością jest... przechowywanie danych. Ot, niespodzianka. Umieszczanie metody uruchom() w klasie Samochód łamie tę zasadę. "Czepiasz się, dziki" - ano czepiam się, bo osobiście uważam że złym pomysłem jest rozpoczynanie uczenia innych ludzi programowania od zrobienia tego na złym przykładzie.
Uff. Przebrnąłem. Jeśli doczytaliście aż do tego miejsca to dajcie znać jak bardzo powinienem przestać pisać o programowaniu
