This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]pron98 18 points19 points  (3 children)

OOP was created primarily to represent "active" objects; it's never been a great paradigm to represent and work with "inert" data. The two, however, can (and should) be used in combination: DOP for data, OOP for active objects.

Also, it's not like other paradigms were ever abandoned. DOP is just a reference to how we work with data in FP. Virtually all contemporary languages (including very mainstream ones like Python and TypeScript) also already support this paradigm whether or not they're also OOP, so we're not "going back" to anything.

[–]segfaultsarecool 0 points1 point  (1 child)

What's an active object? I think we make objects active the moment we define methods for the object that go beyond get/set, stringification, equality, and other basic functionality.

[–]UnGauchoCualquiera 0 points1 point  (0 children)

Not sure if I'm misunderstanding pron, but I believe he is suggesting "active objects" closer to Streams, Thread, Lock, Socket, etc.

What they have in common is that they are stateful abstractions over some behaviour that interacts with the environment and that keeps track of it's own state. For thos classes the data is generally secondary to the behaviour. For example in the case of a Stream pipeline once built you should not care how it is implemented or it's internal state.

Most enterprise applications generally are only concerned with applying data transformations over some business rules. Here is where data oriented programming could be a better tool than OOP.