Nie dziedzicz wcale

Oryginalny post: Inherits Nothing

Autor: Jeff Atwood

Zauważyłeś, że nowi programiści .NET mają tendencję do używaniu dziedziczenia do... hmm... wszystkiego? W pewnym stopniu jest to zrozumiałe, ponieważ dziedziczenie jest wykorzystywane w całym frameworku; wszystko w .NET dziedziczy z jednej głównej klasy. Jest jednak drobna różnica: my piszemy jakąś tam logikę biznesową, nie tworzymy języka. To co jest właściwe podczas tworzenia języka może nie być odpowiednie dla prostego kodu, który przede wszystkim musi być łatwy w utrzymaniu i łatwy do zrozumienia.

Dziedziczenie to wyspecjalizowany mechanizm i powinno być używane tylko w sytuacjach, w których rzeczywiście zachodzą relacja rodzic-potomek i wszystkie wynikające z tego właściwości. Jestem przekonany, że właśnie w tym momencie straciłem kilku czytelników będących purystami OO. Więc zanim pomyślisz sobie, że jestem szaleńcem, który całkowicie porzucił zasady OO, chciałbym zwrócić uwagę na moje doborowe towarzystwo: Dan Appleman uważa podobnie. Poniżej znajduje się krótki wycinek z jego doskonałej (i cały czas aktualnej) książki Moving to VB.NET: Strategies, Concepts and Code:

Byłem programistą C++ dłużej niż Visual Basic – i zresztą cały czas w tych dwóch językach programuję. Byłem zdecydowanym zwolennikiem programowania zorientowanego obiektowo od czasu kiedy zrozumiałem ideę klas w 1977 roku. Programowałem również we frameworkach takich jak ATL, które w bardzo dużym stopniu – i to z powodzeniem - opierają się na dziedziczeniu.

Ale jeśli chodzi o używanie dziedziczenia w moich aplikacjach lub komponentach przez te wszystkie lata, przychodzi mi do głowy może pół tuzina przypadków (co najwyżej), kiedy dziedziczenie było rzeczywiście właściwym wyborem.

Więc, tak, .NET używa dziedziczenia – ono jest wbudowane w architekturę. Tak, kod tworzony przez różnych projektantów będzie opierał się na dziedziczeniu, aby dać Ci framework na którym będziesz mógł budować swój własny kod.

Ale, jeśli rzeczywiście zrozumiałeś dziedziczenie, możesz przez cały okres swojej kariery nie stworzyć ani jednej klasy lub komponentu w oparciu o dziedziczenie.

Prowadzi to do wniosków, które również ja wypowiem: dziedziczenie jest tylko jedną z wielu możliwych dróg do ponownego wykorzystania kodu. Posiadanie prostego obiektu, bez tych wszystkich skomplikowanych (i zazwyczaj ukrytych) zasad dziedziczenia jest zazwyczaj wystarczające dla osiągnięcia najważniejszego celu: ponownego wykorzystania kodu.

Na argument, że „skoro .NET jest zbudowany na dziedziczeniu, my również powinniśmy na nim budować!”, odpowiem pytaniem: jak wielu z nas tworzy języki programowania? Jak wielu z nas tworzy jądra systemów operacyjnych? W rzeczywistości są to ekstremalne i rzadkie przypadki, i nie powinny być stosowane jako wzór w kreowaniu czegoś innego.

Dla mnie narzut dziedziczenia – podobnie jak zwiększanie stopnia skomplikowania w jakikolwiek inny sposób – z góry skazuje je na odrzucenie, przynajmniej dopóki nie zostanie uzasadniona inna decyzja. Nie używaj dziedziczenia, dopóki brakuje stuprocentowych argumentów za jego użyciem.

Data publikacji oryginału: sierpień 7 2004

Upadki i wzloty Homo Logicus

Oryginalny post: The Rise and Fall of Homo Logicus

Autor: Jeff Atwood

Pośród całej apodyktycznej dumy, którą zaobserwowałem wśród programistów, prawdopodobnie największym grzechem ze wszystkich jest to, iż uważamy siebie za typowych użytkowników. Obsesyjnie używamy komputerów, wiele wiemy o tym jak one działają, nawet udzielamy rad przyjaciołom i rodzinie. Jesteśmy ekspertami. Któż mógłby lepiej zaprojektować oprogramowanie niż my? Większość programistów nie zdaje sobie sprawy z tego, jak bardzo odstajemy od normy. Nawet w najmniejszym stopniu nie jesteśmy średniakami -- jesteśmy warunkami brzegowymi. Często mawiałem program menadżerom: jeśli pozwalasz mi projektować swoje oprogramowanie, to Twój projekt jest zagrożony.

W książce Wariaci rządzą domem wariatów, Alan Cooper określa to zjawisko mianem Homo Logicus:

Homo Logicus chce mieć kontrolę nad tym, co go interesuje, a rzeczy, które go interesują to skomplikowane, deterministyczne systemy. Ludzie są skomplikowani, ale nie zachowują się w logiczny i przewidywalny sposób, jak maszyny. Najlepsza maszyna to cyfrowa maszyna — mimo, iż może być ona najbardziej skomplikowana i wyrafinowana, to jest łatwo konfigurowalna przez programistę.

Cena jaką trzeba zapłacić za kontrolę, to zawsze więcej zachodu oraz zwiększona złożoność. Większość ludzi wolałoby podjąć umiarkowany wysiłek, ale to co odróżnia programistów od większości ludzi, to ich wola i możliwości opanowania niesamowitej złożoności. Wiedza i możliwość zarządzania systemami złożonymi z wielu oddziałujących na siebie sił, to satysfakcjonująca część pracy programisty. Latanie samolotami to archetypowe hobby programisty. Panel sterowania w kokpicie samolotu jest pełen wskaźników, pokręteł i dźwigni, ale programiści odżywają przy takim zniechęcającym stopniu skomplikowania. Homo Logicus uważa to za ciekawe i zajmujące, pomimo (z powodu!) długiej i ciężkiej nauki, jaka jest wymagana. Homo Sapiens wolałby się przelecieć jako pasażer.

Dla Homo Logicus, kontrola to cel, a złożoność to cena, którą trzeba za to zapłacić. Dla normalnego człowieka, prostota jest celem, a porzucenie kontroli jest ceną, którą zapłacą. W oprogramowaniu kontrola przekłada się na funkcjonalności. Dla przykładu, w systemie Windows 95, funkcja "Znajdź plik" daje mi wiele kontroli nad całą procedurą. Mogę określić, którą część dysku chcę przeszukać, typ pliku, który mnie interesuje, albo czy szukać po nazwie pliku, czy po jego zawartości oraz parę innych parametrów. Z punktu widzenia programisty, to bardzo fajne. Przy odrobinie początkowego zachodu otrzymuje on możliwość szybszego i wydajniejszego wyszukiwania. I na odwrót, punkt widzenia użytkownika jest mniej różowy, ponieważ musi on określić obszar poszukiwań, typ pliku, który poszukuje oraz czy szukać po nazwie, czy po zawartości. Homo Sapiens z miłą chęcią poświęci jedną ekstra minutę czasu obliczeniowego, jeśli nie będzie musiał znać tego, jak działa funkcja do wyszukiwania. Dla nich, każdy dodatkowy parametr wyszukiwania, to kolejne miejsce na wpisanie czegoś niepoprawnego. Prawdopodobieństwo popełnienia błędu i zwrócenia błędnych wyników wyszukiwania jest wyższe, nie niższe, jeśli dodamy więcej możliwości. Z chęcią poświęciliby całą niepotrzebną złożoność, kontrolę i przymus zrozumienia na rzecz tego, aby ich praca była łatwiejsza.

Homo Logicus jest napędzany przez nieustające pożądanie zrozumienia, jak wszystko działa. Dla kontrastu, Homo Sapiens ma silną potrzebę osiągania celu. O ile programiści też chcą osiągać cele, o tyle często będą akceptować porażkę jako cenę, którą trzeba zapłacić za zrozumienie. Jest taki stary żart o inżynierach, który daje pewien pogląd na temat tej potrzeby zrozumienia.

Troje ludzi zostało skazanych na egzekucję: kapłan, prawnik oraz inżynier. Kapłan jako pierwszy wchodzi na szubienicę. Kat pociąga za dźwignię, aby uruchomić zapadnię, ale nic się nie dzieje. Kapłan twierdzi, że to boska interwencja i domaga się uwolnienia. Tak też się stało. Jako następny, miejsce na szubienicy zajmuje prawnik. Kat pociąga za dźwignię i znów nic się nie dzieje. Prawnik stwierdza, iż kolejna próba byłaby powtórnym pociągnięciem do odpowiedzialności i domaga się uwolnienia. Tak też się stało. W końcu, inżynier wchodzi na szubienicę i zaczyna dokładnie przyglądać się rusztowaniu. Przed pociągnięciem dźwigni przez kata, podnosi wzrok i stwierdza, "Aha, tu jest Twój problem."

Cooper dalej wymienia parę kolejnych cech Homo Logicus:

• sprzedaje prostotę za kontrolę
• wymienia osiąganie celu za zrozumienie
• skupia się nad tym, co jest możliwe z pominięciem tego, co jest prawdopodobne
• zachowuje się jak mięśniak

Biedny ten użytkownik, Homo Sapiens, który nie jest zainteresowany komputerami i złożonością; on tylko chce wykonać swoją pracę.

Każdy może stworzyć złożoną aplikację, której nikt nie będzie w stanie opanować. To proste. Stworzenie aplikacji, która jest łatwa w użyciu.. cóż, to wymaga już pewnych umiejętności. Nie jestem pewien, czy potrzebujesz drogich projektantów interakcji, aby osiągnąć ten cel, ale musisz przestać myśleć jak Homo Logicus -- a zacząć myśleć jak Homo Sapiens.

Data publikacji oryginału: 27 września, 2004

Piękno drzemie w prostocie

Opublikowaliśmy kolejne tłumaczenie w serwsie 97rzeczy:

• Piękno drzemie w prostocie (autor: Jørn Ølmheim)
  "Odkryłem, że niezależnie od tego, jak bardzo skomplikowana jest cała aplikacja albo system, poszczególne części powinny być proste: proste obiekty z określoną odpowiedzialnością, zawierające równie proste, zwięzłe metody z samoopisującymi się nazwami."

Polecamy również artykuł pt. Prostota, którego autorem jest Joel Spolsky.

Zachęcamy do lektury,
Zespół devMedia.pl

PS. W najbliższym czasie będziemy chcieli zaprezentować Wam nową wersję devBlogów. Zgodnie z ideą prostoty - będzie to strona pozbawiona arkuszy stylów CSS. Poniżej znajduje się kilka screenów z wersji rozwojowej :)