Groch z kapustą, czyli co daje mieszanie OOP z programowaniem strukturalnym

Nudziłem tutaj już kilka razy na temat programowania obiektowego i jego implementacji w C#.Od 2 tygodni mam okazje próbować w nowej pracy Delphi, którego już używałem ale niezbyt obiektowo w poprzedniej ;-)Jak na razie podstawową wadą Delphi jest dla mnie to, że pozwala na pisanie nieobiektowe.Nie chodzi tu o to że jestem jakimś szczególnym fanatykiem OOP, a raczej o to, że mamy tu do czynienia z klasycznym przypadkiem "mienia ciastka" i jednoczesnego "zjedzenia ciastka". Delphi dostarcza wszystkich środków niezbędnych do pisania obiektowego i większość użytkowników części z nich używa, ale pozostawia też furtkę do pisania nieobiektowego i niestety większość ludzi też z niej korzysta. W wyniku mamy spaghetti code, który obiektowy bywa, ale zwykle nie jest czytelny.A to prowadzi do sytuacji gdy poznanie prostego projektu zajmuje o wiele więcej czasu niż poznanie obiektowo napisanego bardziej skomplikowanego projektu.To może wydawać się mało ważne, w końcu niby wszyscy wiedzą, że kod należy komentować bo przyda się to na przyszłość, ale mało kto to robi ;-) to samo z obiektowością, przecież nic się nie stanie jak się ją trochę "nadłamie". Niestety, taka dualność w Delphi prowadzi do tego, że można tego języka używać przez lat wiele i nadal nie wiedzieć, że źle się pisze ;-)Ostatnio czytałem kod w Delphi, który napisał jakiś jak przypuszczam zaawansowany programista, kod ten służy do "dogadywania" się z wbudowanym w Windows NT mechanizmem mierzenia wydajności. Mechanizm niezbyt ładny, a kod go obsługujący również. Mamy w nim gdzieś z 7 plików i góra 15-20 klas i żeby go zrozumieć trzeba momentami przechodzić do 4 wymiaru ;-) a wszystko przez to, że kod jest poszatkowany. Raz jest bardzo obiektowy, do tego stopnia, że klasy implementują pewne interfejsy, utworzone specjalnie tylko dla tych klas, a innym razem ustawień pól w obiektach dokonują jakieś globalne procedury.Poprzednio pracowałem z kodem liczącym około 300 tysięcy linii, które znajdowały się w około 1,5 tysiącu klas i mimo skomplikowania można się było w nim chociaż "połapać" o co chodzi ;-) a wszystko przez to, że był obiektowy.Podobnie w jądrze Linuksa [tak Linuksa, a nie Linuxa, bo ta druga forma jak mi wiadomo jest niepoprawna ;-)], choć kod jest złożony to jednak możemy się w nim również "połapać" [wymaga to jednak większej wiedzy], bo tu kod mamy strukturalny.OOP i programowanie strukturalne to dwa całkiem odmienne paradygmaty. Można je oczywiście mieszać, ale zawsze przez to mieszanie stracimy na czytelności i otrzymamy właśnie groch z kapustą ;-)


Podobne posty^beta
Lubię enumy
Poniedziałek, czyli "w tę"
Internacjonalizacja
Patrzajcie w kod a znajdziecie ;)
Sztuczki tropiciela błędów, part 2 ;-)