Object Thinking
maj 7, 2008Będąc w Galway wysłuchałem prezentacji ‘Object Thinking’ Alan’a Deana. Początek prezentacji, trzeba to powiedzieć, był zniechęcający, pojawiło się sporo akademickich formalizmów, mających nikłe odzwierciedlenie w codziennym życiu. Przykładowo przydługawe, dywagacje o tym który z terminów jest właściwy: software developer czy software engineer? Dość mistrzu, nie po to tu przyszedłem, nawijaj o obiektach.
Jednak gdy doszliśmy do meritum prezentacji, przestałem ziewać i zacząłem słuchać . Otóż padła propozycja aby odrzucić dotychczasowy sposób myślenia o klasach jako o zbiorze pól i właściwości, no i metod ale o nich za chwilę, i zastąpić je koncepcją samo-opisywalności. Zgodnie z propozycją, najprostsza, definicja klasy wyglądała by następująco:
public class Customer : Dictionary<Uri, Object> {}
Ciekawe prawda, ot taki pojemnik na wszystko. Metody, rzecz jasna, pozostają a ich celem jest opisywanie intencji klasy.
Uzasadnieniem takiego podejścia do klas, jest twierdzenie, że zdecydowana większość modyfikacji jakie, jesteśmy zmuszeni wprowadzać, dotyczy właśnie sposobu reprezentacji danych. Oczywiście tego typu zmiany zwykle, powodują reakcję łańcuchową i pociąga modyfikacje w innych klasach. Więc po co się z tym męczyć? Umożliwmy przechowywanie dowolnych danych i wszyscy będą szczęśliwi.
No chyba niezupełnie. Nie twierdzę, że idea jest pozbawiona sensu, bo widzę logikę tego rozumowania, jednak dostrzegam również kilka potencjalnych problemów.
Przede wszystkim porzucamy strong typing, wszystko może być obiektem więc konieczna jest walidacja elementów przechowywanych w naszym pojemniku. Oczywiście bez jawnego określenia typów, intellisense Visual Studio, przestanie nas ostrzegać o potencjalnych problemach. Dalej z punktu widzenia bazy danych, tabele też miały by zostać tylko pojemnikami na dane? Żadnych kluczy, indeksów etc. ? Już widzę jak przystają na to administratorzy baz danych.
Kolejnym problemem może być czynnik ludzki i nie chodzi mi tu o mentalne reperkusje przestawienia się na nowy sposób myślenia, a czysto pragmatyczne podejście. Nie oszukujmy się większość ludzi jest leniwa, a programiści to już w szczególności 
. Wcale nie jest takie nieprawdopodobne, że niektóre wartości mogą być przechowywane w klasie po kilka razy (szczególnie jeśli pracujemy w zespole). Co może prowadzić do wszelakiej maści problemów.
Jak na razie nie oceniam, czekam, aż tęższe głowy od mojej wypowiedzą się w tej sprawie. Może za jakiś czas pojawią się jakieś study case, projektów wykorzystujących to podejście. Poczekamy zobaczymy. Tymczasem dla zainteresowanych slajdy i przykłady z prezentacji są dostępne tutaj.
