Też trochę "potrolluję", jako że jestem kolejnym przeciwnikiem OOP.
Mnóstwo osób pisze puste hasełka o dostosowaniu narzędzi do zadania, ale nie zetknąłem się aby miłośnik OOP uznał zadanie, które wykonuje, za nie-pasujące do OOP. I nie ma się co dziwić emocjonalnemu tonowi wielu przeciwników OOP, bo jest to na prawdę irytujące, że aby nie stosować OOP to w praktyce trzeba założyć własną firmę - swoją drogą wszechobecność OOP była jednym z czynników, że sam się na taki krok zdecydowałem.
Jaka w przybliżeniu działka BTW?
Oczywiście dla wielu OOP to z definicji jest dobrze napisany program. Jeśli ktoś starał się zachowywać metodykę OOP a wyszło mu g**no, to znaczy że zastosował OOP źle. Jeśli ktoś świadomie pisał program proceduralnie, bo uważał OOP za nie-mające zastosowania w jego zadaniu i osiągnął powodzenie - działający i dający się rozwijać program - to znaczy, że nieświadomie używał OOP i tylko dzięki temu osiągnął sukces.
Otóż to. Sam ile razy w dyskusjach podawałem przykładowe rozwiązania, to zaraz kod okazywał się być "zorientowany obiektowo", bo wykorzystywał strukturę, albo wskaźnik na funkcję gdzieśtam. Ręce opadają.
Odniosę się jeszcze do tego przykładu embedded i tez, że skoro program mieści się we Flashu i procesor daje radę go wykonywać, to wszystko jest ok. Być może jest ok, a być może nie. Załóżmy, że pojawiają się nowe wymagania, które zajmą dodatkowe miejsce na Flashu i wywołają dodatkowe obciążenie procesora - taniej jest kontynuować wykorzystywanie dokładnie tego samego projektu elektronicznego, z dokładnie tymi samymi scalakami, niż robić nowy prototyp i kolejne testy elektryczne, być może kolejną certyfikację, jeśli branża wymaga - bo sprzęt się zmienił.
W ogóle nie wiem czego oni się uczepili tego embedded, przykład został podany jako anegdotyczna ilustracja kodu mnożącego poziomy abstrakcji, tam gdzie zupełnie naturalnym, wystarczającym i optymalnym jest użycie kilku funkcji na skrzyż. W sumie nie wiem, czy to kwestia jakichś problemów ze zrozumieniem czytanego tekstu, czy braku wiary w optymalność, naturalność i czytelność takiego kodu. Do tego ten nagły skok ze środowiska embedded do desktopów i podśmiechujki "kup więcej ramu/dysku. No proszę, i to my tutaj "trollujemy"? I ja i tamta osoba jasno powiedzieliśmy, że abstrakcje można mnożyć w każdym paradygmacie, ale nie, oni dalej ciągną temat i twierdzą że to jest użyte jako argument przeciw OOP, pomimo zaprzeczenia wprost z mojej strony już jakieś 3, czy 4 razy. Ale nie, oni wiedzą lepiej.
Też trochę "potrolluję", jako że jestem kolejnym przeciwnikiem OOP.
Mnóstwo osób pisze puste hasełka o dostosowaniu narzędzi do zadania, ale nie zetknąłem się aby miłośnik OOP uznał zadanie, które wykonuje, za nie-pasujące do OOP. I nie ma się co dziwić emocjonalnemu tonowi wielu przeciwników OOP, bo jest to na prawdę irytujące, że aby nie stosować OOP to w praktyce trzeba założyć własną firmę - swoją drogą wszechobecność OOP była jednym z czynników, że sam się na taki krok zdecydowałem.
Oczywiście dla wielu OOP to z definicji jest dobrze napisany program. Jeśli ktoś starał się zachowywać metodykę OOP a wyszło mu g**no, to znaczy że zastosował OOP źle. Jeśli ktoś świadomie pisał program proceduralnie, bo uważał OOP za nie-mające zastosowania w jego zadaniu i osiągnął powodzenie - działający i dający się rozwijać program - to znaczy, że nieświadomie używał OOP i tylko dzięki temu osiągnął sukces.
Odniosę się jeszcze do tego przykładu embedded i tez, że skoro program mieści się we Flashu i procesor daje radę go wykonywać, to wszystko jest ok. Być może jest ok, a być może nie. Załóżmy, że pojawiają się nowe wymagania, które zajmą dodatkowe miejsce na Flashu i wywołają dodatkowe obciążenie procesora - taniej jest kontynuować wykorzystywanie dokładnie tego samego projektu elektronicznego, z dokładnie tymi samymi scalakami, niż robić nowy prototyp i kolejne testy elektryczne, być może kolejną certyfikację, jeśli branża wymaga - bo sprzęt się zmienił.
Fajnie, że ktoś to napisał. Możecie wyśmiewać podejście programistów embedded, ale może sami kiedyś traficie na projekt gdzie nie można sobie pozwolić na rozbudowanie pamięci, bo np. system już jest gotowy i nie możemy go zmienić bo kupujemy go w całości od producenta, albo tak jak napisał przedmówca wiąże się to z kosztownymi testami EMI. Tak swoją drogą to ten projekt embedded o którym była mowa to był aplikowany w samolocie bezzałogowym. A tam nad wszystkim trzeba było panować - nad poborem prądu, masą płytki i innymi rzeczami. Przecież nie podwiesimy PC-ta pod samolotem bo dysku brakuje, bo procek nie wystarcza, prawda? Się faktycznie off-topic zrobił. EOT
Zauważ zabawną sytuację - jednym z argumentów, że przeciwnicy OOP są przeciwnikami, który jest przez OOPowców wysnuwany praktycznie za każdym razem, jest "brak doświadczenia" (oczywiście biorą ten "argument" z sufitu, bez nawet zadawania sobie trudu o zapytanie wprost o doświadczenie). A tutaj proszę - rekomendacja "dokupienia więcej ramu" oraz "co się czepiać, przecież jest jeszcze miejsce i 20% procesora". Pytanie retoryczne - o czym to świadczy z ich strony?