Is OO design's strength in semantics or encapsulation?

Question

Object-oriented design (OOD) combines data and its methods. This, as far as I can see, achieves two great things: it provides encapsulation (so I don\'t care what data there is,

Answer 1

As a Lisp programmer, whose object system arguably provides neither of these, I say: none of the above.

jwz: "the pseudo-Smalltalk object model loses and that generic functions (suitably constrained by the no-external-overrides rule) win".

I think the desirable attributes which you and others list here (encapsulation, modularity, etc.) are not as inherent in OO as you think. They're often provided alongside Java-style OO, but not purely the consequence of it.

Answer 2

Let's take a step back and look at this from a higher level. The advantages of any language feature lie in the ability to succinctly express the problem/solution in a more natural way with respect to the problem domain.

The mechanics of OOP are easily implemented in plain C with structs and function pointers. You can even get a bit of OOP feel doing it that way. However, OOP idioms are not nearly as forthcoming in such an environment. When there's actual language support for OOP then the expressiveness of the paradigm comes out, and the way a language implements an idea has a very real impact on what is "said" and how. For example, see differences in code using closures/lambdas in lisp, python, ruby, etc.

So in the end it's not about the components and underlying concepts, but rather how they're put together and used that make OO in C++ what it is.

Answer 3

Your question reads like You want to derive the benefits of a house by analyzing a brick.

Having the ability to provide semantic context and encapsulation are just the basic capabilities of a class in OO. (Like a brick can withstand a certain force and claim a certain space.)

To continue the analogy: To get the maximum out of bricks, just put them together. The very same applies to classes and objects.

There are a lot of design patterns that can be used for OO programming. Most of them rely on the abilities "encapsulation" and "semantic", that You mentioned.

Some of those patterns are even an answer to the third paragraph of Your question:

• If You want to extend the behaviour of an existing class, You can create a derived class.
• If You want to extend or change the behaviour of an existing object, You might consider the decorator pattern.

Answer 4

Some form of modularity is the key to any scalable design. The limitations of human beings prevents people from "grokking" too much information at once, so we have to subdivide problems into manageable, cohesive chunks, both to provide a basis for understanding a large project, as well as a way to subdivide the work assignments of a large project among many people.

How to choose the most effective "division"/"partitioning" of a large project to meet the goals above? Experience has shown that OO is the big winner here, and I think many people would agree that two key attributes of OO that make it good at this are:

• Encapsulated: each class encapsulates a "secret" - a set of implementation-specific assumptions-that-are-likely-to-have-to-change-over-time about its implementation - and exposes an interface that is agnostic to these assumptions; layering such encapsulated abstractions makes it possible to architect a robust design where components/implementations can easily be swapped in the face of anticipated changes.
• Noun-centric: in most domains, humans seem better at first decomposing a domain model by thinking about the nouns/data of a domain, followed by identifying the supportive verbs that are associated with each noun.

Regarding functional programming (FP) versus OO, I have blogged about this, but briefly I think that FP is more about implementation techniques whereas OO is more about program structure and design, and thus the two are complementary, with OO being more dominant on the 'large' end of the scale and FP being more dominant on the 'small' end. That is, on a large project, the high-level structure is best described by the OO class design, but many of the module-level details (implementations, and details of the shapes of the interfaces of the modules) are best shaped by FP influences.

Answer 5

Encapsulation in conjunction with Polymorphism. The ability of classes in most OOP languages to implement one or more interfaces has had the biggest impact on the development of my software. This feature allows me to precisely define the interaction between two object.

Not only define the interactions but document it so that years later I can return to that section of code and see what is happening clearly.

This feature is the main reason why I prefer using OOP languages over functional languages. While very powerful I have found software written in functional languages to be a pain to maintain when the maintenance cycle is measured in decades. (AutoLisp software found in AutoCAD)