ProceduryToJestTo napisał(a):
Okej, skoro piszę modularny kod, o takich cechach, to jestem programistą obiektowym, a więc zarzuty, że nie rozumiem OOPu są wzięte z sufitu i nieprawdziwe. Więc proszę się odstosunkować od pisanie orzeze mnie wszystkiego w C lub Go. Okej a zatem, na mocy bycia programistą obiektowym stwierdzam - OOP ssie, kiedy są w nim klasy, nie ssie kiedy w nim klas nie ma. Wszyscy zadowoleni?
Go - O jak obiekt?
Ce - e jak enkapsulacje?
Przypadek? Nie sądzę.
A skąd Ci się teraz wzięły klasy?
Gdzie w definicji OOP są klasy?!
W filozofii też są objekty!
https://en.wikipedia.org/wiki/Object_(philosophy)
An object is a technical term in modern philosophy often used in contrast to the term subject. A subject is an observer and an object is a thing observed. For modern philosophers like Descartes, consciousness is a state of cognition that includes the subject—which can never be doubted as only it can be the one who doubts—and some object(s) that may be considered as not having real or full existence or value independent of the subject who observes it. Metaphysical frameworks also differ in whether they consider objects exist independently of their properties and, if so, in what way.[citation needed]
@Krolik, dobra pośmieszkowaliśmy o obiektowości i funkcyjności, to teraz zejdźmy na ziemię.
https://en.wikipedia.org/wiki/Object_(computer_science)
In computer science, an object can be a variable, a data structure, a function, or a method, and as such, is a location in memory having a value and referenced by an identifier.
https://en.wikipedia.org/wiki/Object_(computer_science)
In the class-based object-oriented programming paradigm, "object" refers to a particular instance of a class where the object can be a combination of variables, functions, and data structures.
https://en.wikipedia.org/wiki/Object_file
An object file is a file containing object code, meaning relocatable format machine code that is usually not directly executable. There are various formats for object files, and the same object code can be packaged in different object files. An object file may also work like a shared library.
Jak to się ma do plików obiektowych c?
https://en.wikipedia.org/wiki/Object_code
In addition to the object code itself, object files may contain metadata used for linking or debugging, including: information to resolve symbolic cross-references between different modules, relocation information, stack unwinding information, comments, program symbols, debugging or profiling information.
In computing object code, or sometimes an object module, is what a compiler produces.[1] In a general sense object code is a sequence of statements or instructions in a computer language,[2] usually a machine code language (i.e., binary) or an intermediate language such as register transfer language (RTL).
Czyli podsumowując jakiej odmiany OOPu programistami jestem ja i @Troll anty OOP skoro nie programujemy za pomocą klas? Classless Object Oriented Programming, w skrócie COOP?
A co Ty mi jakąś wikipedię cytujesz. Cytuj źródło.
OOP (...) means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things. It
can be done in Smalltalk and in LISP. There are possibly other
systems in which this is possible, but I'm not aware of them.
-- Alan Kay, twórca OOP
Krolik napisał(a):
A co Ty mi jakąś wikipedię cytujesz. Cytuj źródło.
OOP (...) means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things. It
can be done in Smalltalk and in LISP. There are possibly other
systems in which this is possible, but I'm not aware of them.-- Alan Kay, twórca OOP
Czyli UNIX jest zorientowany obiektowo! Bo ma procesy i mechanizmy IPC!
OOP to siła!
OOP to życie!
OOP to istnienie!
Nie ma Boga prócz OOPu, a programowanie proceduralne jest jego prorokiem!
Hare OOP! Hare! Hare! Hare Smalltalk! Hare! Hare!
No i? Programowanie to proces, który wymaga myślenia. Żaden kompilator nie zastąpi mózgu.
Oczywiście, że kompilator nie zastąpi mózgu, ale język z kompilatorem mogą zrobić za nas rzeczy następujące:
Te rzeczy nie wymagają OOPa, ale kodzenie bez nich jest mocno błędogenne. Dlatego do C i C++ powstało wiele narzędzi do statycznej bądź dynamicznej analizy kodu, które uzupełniają te braki, np valgrind czy lintery. Po co jednak stosować nieudolne protezy typu valgrind i linter skoro można mieć poprawność zapewnioną przez język i kompilator jak w Ruście?
C i C++ są równie słabe pod względem błędogenności. To języki znane z off-by-one-error które manifestowane są trudnymi do wykrycia błędami (zamiast natychmiastowego wyjątku jak w cywilizowanym języku), segfaulty spowodowane błędną arytmetyką wskaźników, use-after-free, buffer overflow, itp itd Te błędy to wynik głównie prymitywności języka, bo ludzką rzeczą jest popełnianie błędów i ludzką rzeczą jest automatyzowanie mozolnej i odmóżdżającej pracy.
ProceduryToJestTo napisał(a):
OOP to siła!
OOP to życie!
OOP to istnienie!
Nie ma Boga prócz OOPu, a programowanie proceduralne jest jego prorokiem!
Hare OOP! Hare! Hare! Hare Smalltalk! Hare! Hare!
Nie doczekałem się od pierwszego/drugiego (?) uczestnika dyskusji odpowedzi, więc ponawiam pytanie:
Jak w praktyce nie-OOP projektuje się rozwiązanie dotyczące jakiejś nietrywialnej domeny? W przypadku OOP jest ot po prostu przejście od OOA. Jak to wygląda w przypadku tej prostszej praktyki proceduralnej?
Że się wkleję (popcornu mi zabrakło na ten wątek)... krytyka OOP i promowanie C to jak krytykokanie diesla i proponowanie starego dwusuwa jako alternatywy.
yarel napisał(a):
ProceduryToJestTo napisał(a):
OOP to siła!
OOP to życie!
OOP to istnienie!
Nie ma Boga prócz OOPu, a programowanie proceduralne jest jego prorokiem!
Hare OOP! Hare! Hare! Hare Smalltalk! Hare! Hare!Nie doczekałem się od pierwszego/drugiego (?) uczestnika dyskusji odpowedzi, więc ponawiam pytanie:
Jak w praktyce nie-OOP projektuje się rozwiązanie dotyczące jakiejś nietrywialnej domeny? W przypadku OOP jest ot po prostu przejście od OOA. Jak to wygląda w przypadku tej prostszej praktyki proceduralnej?
Ale przecież nietrywialne domeny (Linux, git, Apache etc.) są programowane obiektowo jak sifu @Krolik sensei wyjaśnił. Więc czemu miałoby to się odbywac inaczej?
jarekr000000 napisał(a):
Że się wkleję (popcornu mi zabrakło na ten wątek)... krytyka OOP i promowanie C to jak krytykokanie diesla i proponowanie starego dwusuwa jako alternatywy.
Może mi ktoś wreszcie wyjaśnić, kto tu promuje C? Bo czytam wątek od początku i widzę jedynie zarzuty promowania C i zero samej promocji.
Podsumowując OOP to Chrześcijaństwo, a proceduralkne to Judaizm. Co prawda w Judaiźmie nie ma Jezusa, ale jest Mesjasz, więc każdy kto odwołuje się do pojęcia Mesjasza jest Chrześcijaninem. Spoko........ ...wait what?
Wibowit napisał(a):
Dorzucę jeszcze historię o Gicie, bo dla niektórych git jest objawieniem geniuszu Linusa Torvaldsa. Okazuje się, że git jest mocno wzorowany na BitKeeperze. Ponadto mało brakowało, a zamiast gita Linus używałby Mercuriala, także pisanego po tym jak BitMover odebrał licencję na BitKeepera dla Linuksa (z powodu inżynierii wstecznej).
https://softwareengineering.stackexchange.com/a/96992 :
I see a lot of answers to this that rely on the feelings the author had when hearing about one or the other SCM. Others say it all was sheer luck. I believe luck can be traced back in history.
I will talk about history.
Git and Mercurial were created simultaneously in order to solve the same issue. Back in those days, the Linux kernel was forced out of a period during which it had been using BitKeeper, a proprietary distributed SCM which had served them well for many years.
Indeed, Larry McVoy, CEO of BitMover, the company behind BitKeeper, stopped giving his software away for free to Linux developers, because someone inside the Linux community had reverse-engineered it.
Linus Torvalds, dissatisfied with what already existed, subsequently started to work on a brand-new SCM that he would soon call Git. Quickly thereafter, Matt Mackall started the Mercurial project for similar reasons.
After some time developing these projects separately, Matt Mackall presented an advanced version of his SCM and benchmarked it a certain way, comparing it to Git (which was itself only a couple weeks old). Linus considered using it instead of Git for Kernel development, but dropped the idea when he realized that Mercurial was using Changesets to log revision modifications. He feared that was too close to the way BitKeeper worked, and he certainly didn't want anything that could make someone say, "They built a BitKeeper clone".
Git was therefore used for Kernel development instead of Mercurial, but both were technically relevant. The end-result is, Git started out by being actually used where it was designed to be used, while Mercurial was not as fast to find its first big FOSS use. Because it was endowed with a very good design, and thanks to Matt Mackall's perseverance, it eventually became famous and got used for big, real-world projects.
Today, they are both famous. Which one is most famous is impossible to say. Google Code only integrated Git recently, while it had Mercurial for a long time. Many really big and famous projects use either.
I guess what I mean is, when the very reason why you have started a project vanishes, it is harder to gain popularity, but still feasible.
Bazaar is another SCM which is very famous in the GNU world, but not so much outside that, because it was built with the intent of satisfying the GNU community. Software often go where their creators want to go, and no further.
On the other hand, distributed SCMs are clear winners. I don't see many widely-used non-distributed SCMs out there.
(nie wiem czy takie długie cytowanie mieści się w ramach fair use, ale w taki sposób jest lepsza widoczność)
No widzisz, jak dowiódł @Krolik git jest zorientowany obiektowo. Więc atakując gita atakujesz projekt zorientowany obiektowo. Podobnie atakując kod Linuksa atakujesz kod zorientowany obiektowo. Powstrzmaj swe heretyckie zapedy i zaniechaj natychmiast tej krytyki OOPu.
ProceduryToJestTo napisał(a):
Podsumowując OOP to Chrześcijaństwo, a proceduralkne to Judaizm. Co prawda w Judaiźmie nie ma Jezusa, ale jest Mesjasz, więc każdy kto odwołuje się do pojęcia Mesjasza jest Chrześcijaninem. Spoko........ ...wait what?
Schizofrenia.
No widzisz, jak dowiódł @Krolik git jest zorientowany obiektowo. Więc atakując gita atakujesz projekt zorientowany obiektowo. Podobnie atakując kod Linuksa atakujesz kod zorientowany obiektowo. Powstrzmaj swe heretyckie zapedy i zaniechaj natychmiast tej krytyki OOPu.
Napisałem, że git nie jest objawem geniuszu, bo to w zasadzie klon BitKeepera, ale zmieniony na tyle, by Torvalds się dobrze z tym czuł, tzn nie obawiał się, że ktoś rzeczywiście krzyknie że git to klon BitKeepera. Nie atakuję gita tylko stwierdzenie, że Torvalds jest wspaniały, bo stworzył gita.
Torvalds oddał gita w obce ręce dwa miesiące po zaklepaniu początkowej wersji. Za Wiki:
Junio C Hamano (濱野 純 Hamano Jun[1]) is a Japanese software engineer living in California[2] and working for Google.[3] Best known for being the maintainer of Git since 26 July 2005, two months after its first release.[4][5] Linus Torvalds said in 2012 that one of his own biggest successes was recognizing how good a developer Hamano was on Git, and trusting him to maintain it.[6]
Podsumowując: nie lubisz OOPa i w kółko o tym piszesz, ale bez sensownych argumentów. Co mamy z tym zrobić?
Ja proponuję przeciwnikom OOP (jak i zwolennikom) zrobienie eksperymentu i nie używanie tego słowa (ani synonimów, czyli "obiektówka" i podobne. Nawet słowa obiekt można nie używać).
Mam wrażenie, że niektórzy po prostu uczepili się tych 3 literek i szukają pretekstu do kłótni na siłę. Czyli słowem: trollują.
Rozmawiajmy o realnych problemach.
W jaki sposób poradzimy sobie ze zmianami stanu w programie? Czy zrobimy globalne zmienne i hopsasa? Czy może będziemy starali się odizolować gdzieś "ruchome części"? A może w ogóle pójdziemy w niemutowalność?
W jaki sposób poradzimy sobie, że zmianami w części aplikacji, tak żeby odizolować te zmiany od reszty? Jeśli ruszymy X, to czy się nie rozwali Y?
W jaki sposób zabezpieczymy możliwość łatwego rozszerzania aplikacji? Architektura oparta o pluginy? Czy coś innego?
W jaki sposób poszczególne moduły* będą się komunikować ze sobą?
To są realne pytania (jedne z wielu zresztą), a nie to, czy ktoś pisze OOP czy nie.
Na pewnym poziomie większość paradygmatów dochodzi do tego samego (np. do tego, że "shared mutable state is the root of all evil" czy do tego, że w kodzie powinien być decoupling). Programowania nie można poznać do końca, ale pewne zasady są "obiektywne" o tyle, że wydają się być odkrywane i stosowane, niezależnie od paradygmatu. Jeśli coś jest skuteczne (albo jeśli coś jest szkodliwe), to wcześniej czy później ktoś na to wpadnie (a jeśli nawet sam nie wpadnie to podpatrzy u kogoś - to dlatego programiści OOP masowo idą w stronę funkcyjności, bo funkcyjność rozwiązuje parę problemów, np. problem z globalnym mutowalnym stanem, czyli w zasadzie uzupełnia obiektówkę, która rozwiązuje dokładnie ten sam problem ale od drugiej strony (@Krolik już o tym wspomniał w tym wątku zresztą Świetna dyskusja dlaczego OOP ssie. ).
To nie jest jakaś zabawa, który paradygmat jest bardziej cool, tylko to jest tworzenie oprogramowania i rozwiązywanie problemów, które się pojawiają. Jak dla mnie programiści powinni być bardziej jak naukowcy albo inżynierowie, a póki co w tym wątku niektórym wydaje się, że programowanie jest jak arena gry politycznej i kto będzie miał więcej głosów i przekona kogoś, że partia OOP/proceduralna jest dobra/zła.
** przez moduł podstawcie sobie np. moduł (jeśli w języku są moduły), klasę, obiekt, funkcję, procedurę, lambdę, cokolwiek, co jest modulaste, co da sie łatwo wydzielić. Żeby potem nie było kłótni, czy coś jest czy nie jest obiektem. *
Wbiłem na kanał #programming na freenode i porozmaialiśmy tam sobie o tym,
Wnioski, do których doszliśmy:
Zatem OOP ssie, bo nie wiesz co to jest OOP.
Tu jest ciekawa dyskusja o tym czy Rust jest OOP czy nie: https://doc.rust-lang.org/book/second-edition/ch17-00-oop.html
Przytaczają taki argument, niepoparty przykładami:
Inheritance has recently fallen out of favor as a programming design solution in many programming languages because it’s often at risk of sharing more code than needs be. Subclasses shouldn’t always share all characteristics of their parent class, but will do so with inheritance. This can make a program’s design less flexible, and introduces the possibility of calling methods on subclasses that don’t make sense or that cause errors because the methods don’t actually apply to the subclass. Some languages will also only allow a subclass to inherit from one class, further restricting the flexibility of a program’s design.
For these reasons, Rust chose to take a different approach, using trait objects instead of inheritance.
Argument jest lewy ponieważ w samym Ruście metody w traitach mogą mieć domyślne implementacje i też można napykać wiele metod, które nie mają sensu w każdej implementacji traita.
Java pozwala na implementowanie wielu interfejsów, a interfejsy od Javy 8 mogą mieć domyślne implementacje metod. Z tego wynika, że gdyby w Javie unikać rozszerzania klas przez inne klasy to dostalibyśmy język który używa się podobnie jak Rusta. Aktualnie jest jednak tak, że w Javie mam wybór: mogę dziedziczyć po klasach i/ lub komponować klasy. W Ruście nie ma dziedziczenia, zostaje tylko kompozycja.
Wydaje mi się, że można by przyhaczyć i zrobić takiego Rusta++, który oferowałby dziedziczenie i który byłby mechanicznie tłumaczony na czystego Rusta. Nie widzę technicznych przeszkód przed wprowadzeniem dziedziczenia do Rusta w takiej czy innej formie. Prawdopodobnie jednak unikanie dziedziczenia jest po to, by zachęcić do Rusta zarówno zwolenników jak i przeciwników OOPa promując Rusta jako coś co jest niby równie fajne jak OOP ale nie jest OOPem.
No dobra, to skoro minęła przerwa w tym meczu bokserskim, i obie drużyny zmyły już z ringu swą krew, przejdźmy do następnej rundy.
Musimy sobie teraz postawić bardzo istotne pytanie natury egzystencjalnej:
***Czym jest obiekt w paradygmacie obiektowym? ***
Czy jest on uzależniony od zaimplementowania jakichś określonych konstruktów programistycznych?
W zasadzie wiekszość jest zgodna, że jeśli jest on opart o vtable i klasy to mamy do czynienia z OOPowym obiektem.
No właśnie - większość oznacza istnienie opozycji o innym zdaniu na ten temat.
Do tego dochodzi problem istnienia lub nie obiektu bez implementowania klas na poziomie języka lub samodzielnego implementowania vtable w kodzie w języku "domyślnie nie obiektowym"! Tutaj pojawiają się rozbieżności przy wyznaczaniu granic, tego co jest obielktem w sensie OOP, a co nie. Czasem różnią się one ledwie detalami, ale te detale prowadzą do zaliczenia różnych modeli programistycznych w jednym wariancie definicji obiektu, a oraz odrzucenia w innej definicji. W ekstremalnych przypadkach z jakimi się spotkałem praktycznie każdy kod zaliczano do obiektowego na podstawie definicji - wszak samodzielny program to samodzielny obiekt. Dlaczego istnieją różne definicje obiektów? Czyżby ten termin był zbyt emfemeryczny by dał się ująć w karby jednoznacznej definicji?
W zasadzie wiekszość jest zgodna, że jeśli jest on opart o vtable i klasy to mamy do czynienia z OOPowym obiektem.
W C++ można tworzyć hierarchie klas bez metod wirtualnych - vtable więc niepotrzebne.
W Pythonie natomiast obiekt jest faktycznie bardzo wydajną hashmapą, więc też vtable nie ma.
OOP to raczej sposób organizacji kodu i danych, a nie konkretne konstrukcje składniowe (czy szczegóły implementacyjne) aczkolwiek przystosowana składnia jest potrzebna by ułatwiać (i tym samym zachęcać do poprawnego używania) podejście obiektowe. Jak dla mnie sztandarowym zestawem zasad związanych z OOPem jest enkapsulacja oraz SOLID - jeśli twój kod spełnia te wymagania to w zasadzie piszesz obiektowo. Pisanie obiektowo w języku nieprzystosowanym do OOPa to prawdopodobnie hipokryzja.
Czym jest obiekt w paradygmacie obiektowym?
Czy jest on uzależniony od zaimplementowania jakichś określonych konstruktów programistycznych?
Obiekt nie istnieje w kodzie, to tylko w umyśle. Na poziomie fizycznym istnieje tylko to, co procesor jest w stanie zrozumieć, czyli kod maszynowy, a wszystko ponad to, to nasze rojenia i iluzje. Obiekty nie istnieją w sposób namacalny, podobnie jak nie istnieją wzorce bandy czworga. Ten "obiekt" to po prostu pewien wzorzec projektowy albo koncepcja teoretyczna.
"Obiekty" to masz jak weźmiesz kartkę papieru i narysujesz kwadraciki z nazwami klasy w środku. Albo jak pomyślisz o czymś w kategoriach obiektów.
Inna sprawa, że ten wzorzec często jest zaimplementowany już na poziomie języka, dlatego ludziom się wydaje, że OOP jest czymś immanentnym do kodu, że siedzi w kodzie. Ale prawda jest taka, że to człowiek może wybrać, że coś postrzega albo nie w sposób obiektowy, niezależnie od języka.
Np. jak widzę kod w stylu "god object", czyli jeden duży obiekt, który ma za dużo odpowiedzialności i zajmuje się wszystkim, począwszy od łączenia się z bazą, obługą GUI aż po robienie prania - to ja takiego kodu nie postrzegam jako obiektowy. Dla mnie wtedy jest to wypaczenie OOP i choćby ktoś uważał, że napisał OOP dla mnie nie będzie to miało wiele wspólnego z tym paradygmatem.
Nie dlatego, że obiektywnie OOP jest takie czy inne, tylko, że dla mnie (i dla wielu innych, sam tego nie wymyśliłem) obiekt powinien mieć określoną odpowiedzialność, jeśli obiekt robi za dużo rzeczy naraz, to przestaje być obiektem a zaczyna być nie wiadomo czym.
Podobnie można podać wiele innych argumentów, dla których dany sposób kodowania można uznać za obiektowy bądź nie. Ale to dalej będzie subiektywne.
Skoro da się religijnie patrzeć na OOP, to czemu nie filozoficznie? Obiekt = desygnat bytu. Trzeba sobie jednak zadać pytanie co to jest byt, jakie są kategorie bytu, czym się różnią (struktura, zachowanie) i stąd już blisko do naturalnego przejścia do OOP ;-)
Tak naprawdę dla kogoś kto pisał kiedykolwiek jakąś bibliotekę, różnica między OOP a programowaniem proceduralnym nie ma nic z emocji czy flejmu.
A już to vtable to jakiś totalny trolling z nudów chyba.
OOP:
Programowanie proceduralne:
Czym jest obiekt? Strukturą z dołączonymi ściśle powiązanymi zachowaniami (na sposób udostępniany przez język lub umowny).
Klasa z samymi zachowaniami to programowanie proceduralne (np. klasa *Utils).
Klasa bez zachowań to struktura danych.
W COBOLu można pisać proceduralnie - jeśli się chce.
W C można pisać obiektowo - jak wyżej.
Ogłoszenie parafialne:
Użytkownik @ProceduralMasterRace omija bana zakładając kolejne konta. Będą one banowane, a kolejne posty jego autorstwa będą usuwane. Sugeruję nie wdawać się w dyskusję.
LukeJL napisał(a):
Czym jest obiekt w paradygmacie obiektowym?
Czy jest on uzależniony od zaimplementowania jakichś określonych konstruktów programistycznych?
Obiekt nie istnieje w kodzie, to tylko w umyśle. Na poziomie fizycznym istnieje tylko to, co procesor jest w stanie zrozumieć, czyli kod maszynowy, a wszystko ponad to, to nasze rojenia i iluzje. Obiekty nie istnieją w sposób namacalny, podobnie jak nie istnieją wzorce bandy czworga. Ten "obiekt" to po prostu pewien wzorzec projektowy albo koncepcja teoretyczna.
"Obiekty" to masz jak weźmiesz kartkę papieru i narysujesz kwadraciki z nazwami klasy w środku. Albo jak pomyślisz o czymś w kategoriach obiektów.
Inna sprawa, że ten wzorzec często jest zaimplementowany już na poziomie języka, dlatego ludziom się wydaje, że OOP jest czymś immanentnym do kodu, że siedzi w kodzie. Ale prawda jest taka, że to człowiek może wybrać, że coś postrzega albo nie w sposób obiektowy, niezależnie od języka.
Np. jak widzę kod w stylu "god object", czyli jeden duży obiekt, który ma za dużo odpowiedzialności i zajmuje się wszystkim, począwszy od łączenia się z bazą, obługą GUI aż po robienie prania - to ja takiego kodu nie postrzegam jako obiektowy. Dla mnie wtedy jest to wypaczenie OOP i choćby ktoś uważał, że napisał OOP dla mnie nie będzie to miało wiele wspólnego z tym paradygmatem.
Nie dlatego, że obiektywnie OOP jest takie czy inne, tylko, że dla mnie (i dla wielu innych, sam tego nie wymyśliłem) obiekt powinien mieć określoną odpowiedzialność, jeśli obiekt robi za dużo rzeczy naraz, to przestaje być obiektem a zaczyna być nie wiadomo czym.
Podobnie można podać wiele innych argumentów, dla których dany sposób kodowania można uznać za obiektowy bądź nie. Ale to dalej będzie subiektywne.
Wszystko jest zatem kodem w paradygmacie obiektowym. Piękna zachłanna definicja. W ten sposób można do OOPu przypisać wszystkie zasługi dowolnego podejścia programistycznego, a porażki zrzucić na karb niewłaściwego zastosowania paradygmatu obiektowego. To takie "jak co złego, to nie OOP". To jakaś forma programistycznego panteizmu. Po co więc powstał termin "programowanie zorientowane obiektowo"? Jego istnienie jest w świetle takiej definicji zbytkiem, wręcz wymysłem szaleńca. Po co nadawać imię czemuś, co się od lat nazywa po prostu "programowaniem"?
4lph4NULL napisał(a):
Wszystko jest zatem kodem w paradygmacie obiektowym. Piękna zachłanna definicja. W ten sposób można do OOPu przypisać wszystkie zasługi dowolnego podejścia programistycznego, a porażki zrzucić na karb niewłaściwego zastosowania paradygmatu obiektowego. To takie "jak co złego, to nie OOP". To jakaś forma programistycznego panteizmu. Po co więc powstał termin "programowanie zorientowane obiektowo"? Jego istnienie jest w świetle takiej definicji zbytkiem, wręcz wymysłem szaleńca. Po co nadawać imię czemuś, co się od lat nazywa po prostu "programowaniem"?
No chyba że program był zrobiony przez człowieka niedoświadczonego tak, że od razu widać, że autorem jest ktoś niezaawansowany i akurat mu się program nie udał (bo wiadomo, że nawet początkujący może mieć szczęście i zrobić w miarę dobrze) - wtedy nie był to OOP i brak zastosowania OOP był przyczyną niepowodzenia.
Albo druga opcja, że ten niezaawansowany człowiek dokładał starań by program był jak najbardziej zgodny z OOP - wtedy jest to po prostu niepoprawnie wykonane OOP.
Jego istnienie jest w świetle takiej definicji zbytkiem, wręcz wymysłem szaleńca.
Po co nadawać imię czemuś, co się od lat nazywa po prostu "programowaniem"?
Chodzi o sposób myślenia o programowaniu. Programowanie można postrzegać w formie "nieskończenie długiej taśmy podzielonej na pola w których zapisuje się dane. "
https://pl.wikipedia.org/wiki/Maszyna_Turinga
Niby wszyscy mówią, jaki to Turing był mądry, ale mało kto w ten sposób programuje.
Programowanie można postrzegać jako funkcje matematyczne i wprowadzać różnego rodzaju formalizmy (rachunek lambda itp.)
Można postrzegać jako zbiór instrukcji kodu maszynowego.
Albo jako maszynę stanów skończonych.
Można postrzegać jako zestaw podprogramów/procedur.
A można postrzegać wreszcie jako** komunikujące się ze sobą obiekty.** (wtedy masz OOP)
Albo jak sieć neuronową. To też pewien paradygmat.
Co wybierzesz, to będziesz programowanie postrzegał w ten sposób. "If all you have is a hammer, everything looks like a nail".
W każdym razie to oczywiste, że paradygmat narzuca sposób myślenia (dlatego jest zwany paradygmatem).
Swoją drogą i tak można się kłócić o paradygmat, ale prawda jest taka, że to nic nie da skoro jakiś PM / PO może postrzegać programowanie jako "zbiór historyjek" czy "list tasków do zrobienia" i dla niego całe programowanie będzie się dało podzielić na historyjki. Czyli cokolwiek zaprogramujesz i tak będziesz musiał o tym myśleć w kategorii tasku, a nie żadnych obiektów. Task Oriented Programming.
LukeJL napisał(a):
Jego istnienie jest w świetle takiej definicji zbytkiem, wręcz wymysłem szaleńca.
Po co nadawać imię czemuś, co się od lat nazywa po prostu "programowaniem"?Chodzi o sposób myślenia o programowaniu. Programowanie można postrzegać w formie "nieskończenie długiej taśmy podzielonej na pola w których zapisuje się dane. "
https://pl.wikipedia.org/wiki/Maszyna_Turinga
Oho, jaki popis elokwencji.
Niby wszyscy mówią, jaki to Turing był mądry, ale mało kto w ten sposób programuje.
Niestety nie dysonujemy też nieskończoną taśmą. ;)
Programowanie można postrzegać jako funkcje matematyczne i wprowadzać różnego rodzaju formalizmy (rachunek lambda itp.)
No i dalej każdy samodzielny lub będący modułem kod pisany funkcyjnie jest według twej zachłannej teorii kodem zorientowanym obiektowo.
Można postrzegać jako zbiór instrukcji kodu maszynowego.
No i dalej każdy samodzielny lub będący modułem kod pmaszynowy jest według twej zachłannej teorii kodem zorientowanym obiektowo.
Albo jako maszynę stanów skończonych.
I znów będzie to kod zorientowany obiektowo.
Można postrzegać jako zestaw podprogramów/procedur.
I znów będzie to kod zorientowany obiektowo.
A można postrzegać wreszcie jako** komunikujące się ze sobą obiekty.** (wtedy masz OOP)
OOP masz wtedy kiedy ty chcesz. Po prostu dobierasz sobie defincję pod teorię. Nawet teoria mnogości ze swym
pojęciem pierwotnym zbioru jest lepiej zbudowana. Znajdź mi w ogóle artykuł naukowy stosujący twoją definicję,
bo trochę ich już na temat OOP napisano, a żaden mi znany nie stosuje tak zachłannej.
Albo jak sieć neuronową. To też pewien paradygmat.
Co wybierzesz, to będziesz programowanie postrzegał w ten sposób. "If all you have is a hammer, everything looks like a nail".
Problem z tym, że wyglądać jak coś a być tym czymś to dwie odrębne sprawy.
W każdym razie to oczywiste, że paradygmat narzuca sposób myślenia (dlatego jest zwany paradygmatem).
WIęc zdefiniuj ten sposób myślenia, bo rzucasz ogólnikami. Poza tym, twierdzisz, że programować obiektowo można o tym nie wiedząc, więc gdzie tu jakieś "narzucanie"?
Jeśli nie umiesz sprecyzować swego stanowiska co jest obiektem, to powiedz namy kiedy kod nie jest zorientowany obiektowo? Bo na razie nie widzę, by w ramach twojej definicji istniał kod, który by nie był zorientoawny obiektowo. Co jest lekkim nonsensem również dla zwolenników OOP w dyskusji pod postem, czy ogólnie w internetowych debatach na ten temat nikogo nie przekonuje.
Czy OOP jest supersetem proceduralnego?
Jeśli tak, to proceduralne też ssie.
Jeśli podzbiorem, to ssie tak samo jako proceduralne.
Jeśli ma część wspólną, to proceduralne też ssie.
Ergo, proceduralne ssie ;-)
Czy jest jakiś paradygmat, który nie ssie? ;-)