Chociaż niektóre obiekty, które tworzę, modelują obiekty świata rzeczywistego, czy kod przed OOP nie zrobiłby tego samego?
Największa różnica między kodem OOP a kodem sprzed OOP polega na tym, że ten pierwszy modeluje sytuację w świecie rzeczywistym jako grupa odrębnych jednostek oddziałujących ze sobą, każda z ograniczoną „mocą” w zakresie tego, co może zrobić, a także zdolna do „reagowania” na zdarzenia zewnętrzne z własnymi działaniami. Ten ostatni modeluje wszystko jako duży fragment danych, który sam nic nie robi, podczas gdy obliczenia reprezentują „rzeczy, które się zdarzają” i mogą wpływać na niektóre lub wszystkie z nich.
To, czy lepiej modeluje rzeczywisty świat, czy nie, to naprawdę zależy od tego, które aspekty świata modelujesz. Na przykład symulacja fizyki, w której chcesz opisać skutki, które, powiedzmy, zapalony ogień miałby w otaczających obiektach, lepiej reprezentowałaby „tradycyjna” metoda, ponieważ zarówno światło, jak i ciepło są dobrze… zdefiniowane procesy, które wpływają zarówno na stan zewnętrzny, jak i wewnętrzny innych obiektów i nie różnią się w zależności od zachowania poszczególnych obiektów, na które wpływ mają tylko ich właściwości.
Z drugiej strony, jeśli modelujesz różne komponenty, które oddziałują na siebie, aby uzyskać pożądane zachowanie, traktowanie ich jako agentów zamiast rzeczy pasywnych może ułatwić wykonanie tego poprawnie bez niczego. Jeśli chcę włączyć telewizor, wystarczy nacisnąć przycisk, jeśli przewód zasilający jest odłączony TV.turnOn, sprawdzi to dla mnie. Tak więc nie ma ryzyka, że zmienisz trybik i zapomnisz obrócić tego, który go dotyka, ponieważ sam tryb (jeśli jest odpowiednio zaprogramowany) zajmie się drugorzędnymi interakcjami wynikającymi z pierwotnego.
Ale OO naprawdę polega na modelowaniu rzeczy, a ta metoda modelowania nie wydaje mi się inspirowana prawdziwym światem.
Uważam, że ma to więcej wspólnego ze sposobem, w jaki postrzegamy świat, niż z tym, jak on naprawdę jest. Można argumentować, że wszystko to tylko wiązka atomów (lub energii lub fal, cokolwiek innego), ale to nie pomaga nam poradzić sobie z zadaniem radzenia sobie z problemami, przed którymi stoimy, ze zrozumieniem otaczającego nas środowiska i przewidywaniem przyszłych wydarzeń ( lub opisując poprzednie). Tworzymy więc „modele mentalne” świata i często te modele mentalne znajdują lepszą zgodność z OO niż model danych + procesów - co prawdopodobnie modeluje „lepiej” rzeczywisty świat.
Warto również zauważyć, że większość ludzi uważa OOP za synonim „klasycznego OOP”, w którym taksonomicznie tworzymy zbiory i podzbiory rzeczy, i jednoznacznie umieszczamy obiekty w bardzo specyficznym zestawie. Jest to bardzo przydatne do tworzenia nowych typów wielokrotnego użytku , ale nie tak świetne, gdy modelowany element jest dość samowystarczalny i chociaż inicjuje interakcje z innymi obiektami, rzadko, jeśli w ogóle, jest celem interakcji. Lub gorzej, gdy istnieje kilka (może tylko jeden) przypadek tego podmiotu lub przypadki różnią się znacznie pod względem składu, zachowania lub obu.
Istnieje jednak również „prototypowy OOP”, w którym obiekt jest opisywany przez wybranie podobnego i wyliczenie aspektów, w których się różnią. Proponuję ten esej, aby uzyskać dobre i niezbyt techniczne wyjaśnienie procesu myślowego (cały post jest zbyt duży, nawet jak na standardy Steve'a Yegge, więc wskazuję odpowiednią sekcję: P). Ponownie, jest to dobre dopasowanie do naszych modeli mentalnych, gdy wyobrażamy sobie nieznane przypadki w porównaniu do znanego, ale niekoniecznie ze względu na to, jak działa prawdziwy świat ... (dwie krowy są w rzeczywistości całkowicie odrębnymi bytami, nawet jeśli je postrzegamy pod wieloma względami „podobne”)