OOP is bad

0

Co wy na to:

2

hah.png

0

Pan Seliga mówił, że AOP jest właściwym podejściem, a OOP to 'generalnie bulszit'.

9

Moim zdaniem główny problem tego video jest taki że gość opowiada czemu "pisanie dobrego proceduralnego kodu jest lepsze od pisania słabego obiektowego kodu", a generalizuje to na pisanie obiektowego kodu w ogóle ;] On sobie wymyślił jakiś biedny wyimaginowany sposób pisania obiektowego kodu (pewnie po prostu sam taką biedę robił) i sie nad nim pastwi ;]

A potem? Potem to juz meksyk bo chłop opowiada jak należy pisać ten jego wymarzony kod proceduralny i opisuje... dokładnie jak należy pisać kod obiektowy i jak sie to w praktyce robi - z bezstanowymi serwisami pracującymi na niemutowanych obiektach. Z tą różnicą tylko że on sugeruje zamykać to w jakieś wyimaginowane moduły, co w zasadzie w praktyce niczym nie różni sie od idei bezstanowego serwisu.

Dodatkowo widać z jego wypowiedzi że jest fanem pisania funkcji na 1000 linii żeby zawierały "wszystko dotyczące danego zagadnienia". Widać że ten gość chyba nigdy nie napisał też jednego testu a nie nie pracował przy jakimś bardziej złożonym projekcie tropiąc buga w takim tasiemcowym kodzie. To by go szybko oduczyło takiego myślenia. Z tym wstawianiem komentarzy zamiast ekstrakcji metod to aż szkoda komentować...

0

Kolego Stanisławie, prawdę rzeczesz, ale czy sam nie popełniłeś nigdy tasiemca? Ja się przyznaję i pierwszy kamieniem nie rzucę.
Co sądzicie o przewadze programowania aspektowego nad obiektówką? Bo wiadomo, że to co ten gość na filmie głosi to bajkopisarstwo.

4

W produkcyjnym kodzie? Nie, bo nie przeszedł by code-review. Ale miałem za to okazję refaktorować takie tasiemce / łatać bogi w takim kodzie i wiem jaki to jest ból i ile z tym kłopotu. Ktoś kto twierdzi ze to jest dobry pomysł po prostu nigdy nie pracował z takim kodem i opiera sie na tym co "mu sie wydaje".
Nie do końca rozumiem problem z AOP. Przecież AOP może działa bez problemu razem z innymi stylami programowania. Java już od dawna wspiera używanie AOP choćby przez takie rzeczy jak deklaratywne anotacje typu @Transactional.

1

Słaba ta prezentacja, tak samo zresztą jak pisanie strukturalne w Javie (pattern "utils").

Jak się czegoś nie rozumie to są dwie opcje:

  • nauczyć się tego
  • zacząć publicznie negować zalety danej techniki / technologii

Autor filmu wybrał tę drugą drogę i może by nawet coś tam z tego można było wykrzesać gdyby nie to o czym tu już wspomniano.

  1. Komentowanie kodu już jakiś czas temu określono jako "smrodek" oznaczający że kod nie jest wystarczająco dobry żeby być czytelny bez komentarza. Autor filmu twierdzi coś zupełnie przeciwnego.

  2. Funkcje z sekcyjkami. To pomysł wprost ściągnięty z COBOL-a. Zarówno brak enkapsulacji (bo sekcja żeby otrzymać dane musi je dostać nie-wprost - czyli z globala), jak i prezentacji przepływu (czyli autor przegapił rewolucją bąbelkową z lat 70-tych - DFD).

  3. Programowanie aspektowe. Wg mnie tak naprawdę nie ma czegoś takiego. Są techniki aspektowego programowania (dostępne m.in. w Javie, JavaScript i Pythonie, nawet w C - makra), są obszary w których tradycyjnie się to stosuje (np. transakcje, konfiguracja czy prawa dostępu) ale nie słyszałem żeby ktoś twierdził że pracował z "aspektowo-zorientowanym systemem". Samo hasło AOP występuje często jako marketingowy chwyt żeby sprzedać parę kopii oprogramowania więcej.

Więcej się nie wsłuchiwałem, bo szkoda życia na takie wywody. Lepiej już z nudów pouczyć się jakiegoś egzotycznego assemblera.

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