1
1
A jakiś komentarz? Bo ten gość mówi tak monotonnie, że chyba już wolę sobie puścić miks orędzi Adriana.
2
To rozwinięcie pozycji, którą przedstawił tutaj
1
Co do pierwszego video - obejrzałem, głównie nie wiem o co gościowi chodzi. W niektóryvh miejscach (np. ostatni przykład) ewidentnie proponuje zwalczanie grypy rakiem.
Drugie video - odpadłem po 10 minutach.
Chyba mam za mało doświadczenia w programowaniu żeby pojąć o czym jest mowa.
Ewentualnie muszę spróbować po wódce (a akurat nie mam).
0
Widocznie jesteś zbyt zaczadzony OOPem. xD
0
Drugi film wyjaśnia problem z programowaniem obiektowym, ale najważniejsze wydają się bieżące zalecenia jakie daje pod koniec filmu. Też zauważyłem ten problem z hierarchią klas już na samym początku, gdy zetknąłem się z Javą. W tym filmie nie ma całkowitej negacji programowania obiektowego, lecz coś jakby nowy kierunek programowania, mimo że wyjaśnia go przy użyciu programowania proceduralnego. Wydaje się, że już powstają konstrukcje w językach wysokiego poziomu, które obejmą ten sposób programowania.
0
overcq napisał(a):
W tym filmie nie ma całkowitej negacji programowania obiektowego, lecz coś jakby nowy kierunek programowania, mimo że wyjaśnia go przy użyciu programowania proceduralnego. Wydaje się, że już powstają konstrukcje w językach wysokiego poziomu, które obejmą ten sposób programowania.
Co konkretnie nowego tutaj widzisz? Nie rzuciło mi się w oczy by proponował coś czego nie było dotąd w programowaniu.
0
- When in doubt, parameterize.
Na przykład szablony w C++. Tam gdzie nie jest wymagany parametr znany w czasie wykonywania.
- Bundle globals into structs/records/classes.
Z mojej uprzedniej rozmowy na tym forum: język Rust ma oddzielnie struktury danych dla implementacji.
- Favor pure functions. (Easier when efficiency is not a priority.)
W C++ takie funkcje mogą być zdaje się wkompilowywane w miejscu wywołania, więc to w nawiasie byłoby już nieaktualne.
- Encapsulate (loosely) at the level of namespaces/packages/modules.
To podejście nazwałbym programowaniem modułowym: dane byłyby dostępne w module dla zestawu procedur. Ale w filmie oczywiście nie powiedział tego wprost.
- Don't be afraid of long functions. (Do be afraid of needlessly shared state.)
Z tym akurat się nie całkiem zgadzam, ale to w nawiasie jest słuszne.
1
Taki miły dla oka temat, ale niestety film, a nie zwykły tekst. Do tekstu łatwiej nawiązać, wskazując jakiś konkretny cytat, a film ciężko komentować poza ogólnymi wrażeniami artystycznymi z oglądania.
Oczywista sprawa, że ten pęd ku programowaniu obiektowemu wynika z zupełnie innych przesłanek, niż rzeczywista przydatność takiej metody do tworzenia dobrze działających programów. Na przykład lektura pod tytułem "The Art of Unix Programming" - http://www.catb.org/~esr/writings/taoup/html/ - w podrozdziale "Unix and Object-Oriented Languages" przekazuje następującą opinię o OOP:
The OO design concept initially proved valuable in the design of graphics systems, graphical user interfaces, and certain kinds of simulation. To the surprise and gradual disillusionment of many, it has proven difficult to demonstrate significant benefits of OO outside those areas.
[...]
OO languages make abstraction easy — perhaps too easy. They encourage architectures with thick glue and elaborate layers. This can be good when the problem domain is truly complex and demands a lot of abstraction, but it can backfire badly if coders end up doing simple things in complex ways just because they can.
All OO languages show some tendency to suck programmers into the trap of excessive layering. Object frameworks and object browsers are not a substitute for good design or documentation, but they often get treated as one. Too many layers destroy transparency: It becomes too difficult to see down through them and mentally model what the code is actually doing. The Rules of Simplicity, Clarity, and Transparency get violated wholesale, and the result is code full of obscure bugs and continuing maintenance problems.
Czyli są dziedziny, w których wg autorów tej publikacji programowanie obiektowe się sprawdziło, ale te dziedziny nie stanowią większości zadań programistycznych, a programowanie obiektowe używane jest także poza tymi dziedzinami - generując tam więcej szkody niż pożytku.
Przy czym według mnie, winą należy obarczyć nie tylko same języki programowania nastawione na programowanie obiektowe. Winni są również autorzy książek, którzy adresują swoje książki o programowaniu obiektowym do osób początkujących, przez co idea ilustrowana jest na bezsensownych przykładach, zamiast - przykładowo - na użyciu istniejących bibliotek GUI stworzonych wg takiego modelu. Warto dodać, że autorzy propagujący programowanie obiektowe zwykle uciekają się do nieuczciwości: w przykładach jako kontrast do OOP pokazują jak najbardziej nieudolne wersje alternatywne, zamiast takich jakie w rzeczywistości zastosowałby w programowaniu proceduralnym człowiek cokolwiek doświadczony.
0
overcq napisał(a):
- When in doubt, parameterize.
Nic nowego. Sam miałem okres jakieś 7 lat temu parametryzować wszystko w kodzie. Tak mnie naszło pewnego dnia. Zastanawiałem się jak uczynić kod potencjalnie łatwiejszym do ponownego wykorzystania w środowisku gdzie będzie kilka odrębnych stanów między którymi będzie możliwe przełączanie. Doszedłem do wniosku, że to pomoże przynajmniej częściowo. Z tym, że jeśli kod nigdy by się jednak nie rozrósł to byłby to overkill. Ale takie uroki "inżynierii oprogramowania". Czasem twój emulator terminala kończy jako OS na którym stoi 3/4 internetu, a OS który był pisany do tej roli od etapu projektowania umiera śmiercią przedwczesną mimo genialności rozwiązań w nim zawartych.
- Bundle globals into structs/records/classes.
Stare i powiązane z 1.
- Favor pure functions. (Easier when efficiency is not a priority.)
Przepraszam, ale gdzie tu nowość?
- Encapsulate (loosely) at the level of namespaces/packages/modules.
To podejście nazwałbym programowaniem modułowym: dane byłyby dostępne w module dla zestawu procedur. Ale w filmie oczywiście nie powiedział tego wprost.
To też nic nowego. Większość systemów operacyjnych tym czy innym sposobem w większym lub niejszym stopniu to implementuje. Do tego niejeden projekt w C jest tak pisany.
- Don't be afraid of long functions. (Do be afraid of needlessly shared state.)
Z tym akurat się nie całkiem zgadzam, ale to w nawiasie jest słuszne.
Też nic nowego.
2
Pisałam kiedyś:
Nie rozumiem sensu programowania obiektowego