What are the benefits of aggregating structure and functions associated with it in one object? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 1 year ago.

Improve this question

What are the benefits of aggregating a structure and functions associated with it in one object? What are the benefits of explicitly decalring a class. If i write procedural code i already know that some functions are working with specific structures. I just work with it and that's all.

For me the only benefit of OOP syntax is that it allows autocompletion tools to show me the list of methods. By the way, I noticed that I can't imagine to work without autocompletion tool like Intellisence. If I turn Intellisence off the main productivity bounty of OOP are going away and i should remember all signatures of public functions. I feel like i'm writing the same procedural code like if i'm not declared class explicitly.

Answer 1

OOP is more than dot-method syntax. How exactly OOP should be defined is up to some debate, but most definitions agree on some design benefits:

• OOP is polymorphism: by having the object contain its own methods we can have multiple objects that implement the same interface but behave differently. This allows for significant flexibility in the design of a software system, such as run-time dependency injection. There's also a fairly popular book about OOP design patterns.

• OOP is message passing: objects respond to outside messages they receive, and it is irrelevant for an outside observer how the object handles the message. This allows the object's internals to be encapsulated. Objects don't share data, they transfer data through messages. This allows a software system to be decomposed into decoupled subsystems, and is also an excellent fit for distributed computing.

These are design/architecture-level benefits, not code-level benefits.

It also happens that most OOP languages have coalesced on a syntax that has code-level benefits. This .method() syntax makes it easy to chain multiple calls, and also happens to make type-based autocomplete easier.

However, that is not inherently specific to OOP. Even in most OOP languages the same syntax is used for functions that are not methods in the OOP sense, for exampe “static methods” or non-virtual methods. Similar benefits to method chaining can be had with pipeline operators or currying in some functional languages.

Another often-touted benefit of OOP is that it allows us to encapsulate stuff in classes, e.g. with private fields. While this has some overlap with OOP this isn't quite identical either. E.g. some OOP languages offer little to no encapsulation (Python), others have no classes (JavaScript up until recently). The cause of this disparity is that C++/Java-style encapsulation is not a core part of OOP but rather of modular programming and abstract data types. Modular programming can also be done with non-OOP software systems, e.g. C's header mechanism allows for simple but usable abstract data types. Where modules are namespaces, type-based autocomplete can be useful to list the members of that namespace.

In the past, OOP has been a bit overhyped. So it's not surprising that you feel it's doing nothing for you except for having autocomplete-friendly syntax. This is entirely true for many programs. You are more likely to feel the benefits of OOP in more complex software systems, in code that needs to be easily extensible, where you need to avoid hard dependencies between components, or when you are using a static type system (with duck typing, the use of OOP techniques is often unnoticeable). Looking back over the last few decades, OOP has been most useful for GUI programming, distributed systems, and testability.

Answer 2

Compared with procedural programming, OOP allows us to build higher level abstractions by bundling code & data together.  Any time we can reduce the number of items that the consuming client has to deal with, that is positive.

In procedural programming, a simple structure can combine, say an int x and an int y.  Using a structure, a consuming client can now operate in terms of a single concept, a coordinate, instead of a pair of int's, and, this is a good thing.  This single coordinate is harder to mix up than two int's.

OOP goes a step further offering to bundle not just data members together, but also code/behavioral members.  This is a logical next step in allowing the construction of larger abstractions.  Just as bundling several data elements together reduces the client's load, so does bundling behaviors, so this is a good thing.

If I use a serializer and deserializer bundled together in one object, I'm less likely to use the wrong serializer with the wrong deserializer, whereas that is much easier to happen if as a client, I have to use separate procedures.

OOP supports multiplicity of objects, multiplicity of implementations, and, bundlings into higher levels of abstraction so consuming clients have to deal with fewer things.  It allows us to express some formal relationships that go otherwise unstated in procedural programming (e.g. that some functions are logically related to each other).

Beyond that,

• OOP also allows for a certain amount of code reuse through the mechanisms of base classes, class hierarchy, virtual methods, overrides, and virtual dispatch.  While this can be duplicated in non-OO procedural languages, it can be cumbersome, and, it is just that: duplicating OOP.

• OOP allows placing some abstractions in hierarchy, such that the hierarchy itself is a bundling of additional abstractions into one; again, bundling to reduce the number of individual and separate items the client has to deal with is a positive thing.

Yes, all that means better intellisense in the IDEs, and that's a good thing as well.  This comes by formally expressing relationships that in other languages might have gone implicitly unstated, such as functions being related by naming/prefixing rather than any formally expressed grouping/relationship.

To reiterate @Amon, OOP has also been over-hyped, and that's why we have mantras like composition over inheritance, and don't create deep class hierarchies.  I personally like: don't create a subclass when all you need is an instance.