Upadek programowania obiektowego

1

https://bulldogjob.pl/news/550-zegnaj-programowanie-obiektowe
Co myślicie na ten temat?
Serio obiektowe jest takie złe? W jakich przypadkach lepiej pisać obiektowo w jakich strukturalnie a w jakich funkcyjne?

9

Myslimy, ze cytowanie takich stron to robienie sobie jaj ze spolecznosci. Polecam lepiej dobierac zrodla, ktore czytujesz. Od tego zrodla poziom Twojej wiedzy nie wzrosnie :P

1

za duzo to tam nie napisal, artykul troche tak do porannej kawki i do zapomnienia

3

Liczba zero też jest przereklamowana.

2

Programowanie obiektowe ma swoje wady, ale ten artykuł ich za bardzo nie opisuje, lecz pokazuje losy programisty, który boryka się z problemem, braku testów jednostkowych i integracyjnych, złej architektury, która ma zbyt zawiłe powiązania klas ze sobą.
Prawdopodobnie w programowaniu strukturalnym by narzekał na wielki chaos, ogólnego braku powiązań itp :P

3

Kolejny klikbajtowy wpis. Gość wymyślił parę przykładów na poczekaniu i na tej podstawie wyskrobał wpis. Wybrał przykłady złego projektu.

Problem diamentowy#

Błąd w logice. Kopiarka nie jest skanerem i drukarką jednocześnie. Używa skanera, żeby zeskanować dokument i przekazuje go do drukarki.

abstract class PoweredDevice {
	abstract void start();
}

class Document {}

class Scanner extends PoweredDevice {
	void start() {}
	Document scan() {}
}

class Printer extends PoweredDevice {
	void start() {}
	void print(Document) {}
}

class Copier extends PoweredDevice {
	Scanner scanner;
	Printer printer;

	void start() {}

	void copy() {
		printer.print(scanner.scan());
	}
}

Gdyby kopiarka była drukarką i skanerem jednocześnie, mógłbym zrobić tak:
copier.scan();
copier.print();
... czy oba zadania mają pójść jednocześnie? Najczęściej tak się nie da.

Fragile base class, czyli problem delikatnej klasy bazowej

Metoda powinna robić to, na co wskazuje jej nazwa. Jeśli widzę kolejka.dodaj(Element element), to spodziewam się, że zostanie dodany element do kolejki. Jeśli autor klasy bazowej zmieni działanie metody na takie, którego nazwa nie oddaje, to jest błąd w projekcie.

1
Lubię Naleśniki z Dżemem napisał(a):

Fragile base class, czyli problem delikatnej klasy bazowej

Metoda powinna robić to, na co wskazuje jej nazwa. Jeśli widzę kolejka.dodaj(Element element), to spodziewam się, że zostanie dodany element do kolejki. Jeśli autor klasy bazowej zmieni działanie metody na takie, którego nazwa nie oddaje, to jest błąd w projekcie.

W idealnym świecie programista pisze klasy przeznaczone do dziedziczenia i myśli o tym żeby były one bezpieczne. Szkoda, że ten idealny świat tak rzadko się spotyka ;)
Nazwą metod już dawno temu przestałem wierzyć. Nie raz i nie dwa zdarzało się używać "findAll", a pod spodem SQL z "LIMIT 20". W miarę ufnym można być typom, tutaj przynajmniej można wprowadzać jakieś sensowne obostrzenia.

2
DisQ napisał(a):
Lubię Naleśniki z Dżemem napisał(a):

Fragile base class, czyli problem delikatnej klasy bazowej

Metoda powinna robić to, na co wskazuje jej nazwa. Jeśli widzę kolejka.dodaj(Element element), to spodziewam się, że zostanie dodany element do kolejki. Jeśli autor klasy bazowej zmieni działanie metody na takie, którego nazwa nie oddaje, to jest błąd w projekcie.

W idealnym świecie programista pisze klasy przeznaczone do dziedziczenia i myśli o tym żeby były one bezpieczne. Szkoda, że ten idealny świat tak rzadko się spotyka ;)
Nazwą metod już dawno temu przestałem wierzyć. Nie raz i nie dwa zdarzało się używać "findAll", a pod spodem SQL z "LIMIT 20". W miarę ufnym można być typom, tutaj przynajmniej można wprowadzać jakieś sensowne obostrzenia.

Kod piszą ludzie a nie jakaś Buka z Muminków. To, że ktoś popełnił źle zaprojektowany kod i nie poniósł za do odpowiedzialności nie znaczy, że ja od razu mam zrobić to samo. Przykładów smoków kryjących się w kodzie chyba każdy z nas może wymienić całkiem sporo ;)

1

Klasyczny argument słaby kod X vs dobry kod Y, który nie ma sensu. Słaby kod zawsze jest gorszy od dobrego kodu i nie ma tu znaczenia czy któryś z nich jest funkcyjny, imperatywny czy jeszcze jakis inny. Można napisać gówniany i nieczytelny kod funkcyjny, ale trafia się to rzadziej, bo jednak FP wymaga trochę oleju w głowie, żeby się skompilowało i zadziałało.

1

Dziedziczenie to tylko narzędzie, możliwość do wykorzystania przez programistę. I jak to z narzędziem bywa, można zastosować je dobrze i wtedy ułatwia życie, nieoptymalnie i wówczas wprowadza utrudnienia, albo wręcz źle co powoduje wymierne problemy i wypadki. Samo w sobie nie ma wartościowania, podobnie jak goto, czy zmienne globalne.

1 użytkowników online, w tym zalogowanych: 0, gości: 1