2

I'm getting the sense that reputable OO design and patterns come down to reducing conditional statements (if statements) via polymorphism. This would be very general statement, and wondering if it's true. If it's not true, can you provide an example.

To be clear - My question is purely academic. It is not concerned with the realities and practicalities of crafting software. For example, the question is ignoring tradeoffs like understandability vs complexity.

abc123
  • 8,043
  • 7
  • 49
  • 80
  • 4
    No, all OO is concerned with separation of concerns. "Reducing conditionals" is a perk of polymorphism, but not the reason for OO. – Amadan Feb 01 '16 at 02:06
  • @user2864740 Thanks, edited to be more clear. When I say "reputable OO design", I'm referring to generally accepted design practices. – abc123 Feb 01 '16 at 02:09
  • @Amadan I wasn't even thinking about that when I wrote this. I guess that feels like a given. – abc123 Feb 01 '16 at 02:11
  • FWIW: I write lots of 'OO' code, but have very little polymorphism applied in this manner. I'm of the camp that type-based subtyping is 'bad'; as such polymorphism in my code is related mostly to DI, which really doesn't feel related to "reducing conditionals"; of course this depends on the exact problem being solved. – user2864740 Feb 01 '16 at 02:17

3 Answers3

3

I guess reducing conditional statements is a side effect of OOP because of polymorphism. IMHO, the major benefits of OOP are

  • it makes code make sense;

With inheritance, you can easily define "relationships" between classes. e.g. Dog IS A KIND OF Animal, so Dog inherits Animal and Dog has all the methods/functions and fields/variables that Animal has. In most OO languages, if not all, there is this thing called interface or protocol. This defines another kind of relationship. A CAN BE USED AS relationship. With all these relationships, your code would probably make sense.

  • it makes code abstract;

I think abstraction is the most important aspect of OOP. With classes and objects, you can write:

SuperMarket market = new SuperMarket();
goToTheSuperMarket(market);

Instead of

for (int i = 0 ; i < 1000 ; i++) {
    walk();
}
turnLeft();
for (int i = 0 ; i < 1000 ; i++) {
    walk();
}
...

Which is very functional.

  • it encapsulate stuff in the code that external users don't need to know.

Encapsulation is in OOP is also very important too. I really like this feature. It allows you to hide some functionality of your class.

You see, there are so many other benefits to OOP. OOP not only reduces the number of conditionals.

Sweeper
  • 213,210
  • 22
  • 193
  • 313
  • Your OO vs functionnal example is very wrong, as even your OO example is functionnal. Also, most functionnal languages have support for complex data structures so you could write the exact same code as the OO sample minus the `new` keyword. – plalx Feb 01 '16 at 14:12
  • 1
    @plalx, I don't see any functional code here. The first example may be OO, but is really too short to say. The second example is [procedural](https://en.wikipedia.org/wiki/Procedural_programming) (imperative) which is the opposite of functional (declarative). – jaco0646 Feb 02 '16 at 03:16
  • "In most OO languages, if not all, there is this thing called interface or protocol". Not nearly in all: most of the dynamic OO languages don't, because they can just use duck typing: Ruby, Python, JavaScript, Smalltalk, CommonLisp - none of them have interfaces. – Amadan Feb 02 '16 at 06:45
  • 1
    @jaco0646 OO is data structures with behaviors. `goToTheSuperMarket(market)` is functionnal in nature because behavior is segregated from data structures. If you had something like `person.goTo(market)` then it would be a valid OO example. I agree that the second example is not functionnal either...there is probably not even for loops in pure functionnal languages as they have `foldLeft`, `map`, `reduce`, etc. – plalx Feb 02 '16 at 14:15
1

Reducing the number of conditionals is indeed one benefit you get from abstraction. However, this is not the ultimate goal of OO and other forms of abstraction than object polymorphism exist in other paradigms that provide similar effects.

I would say that the big historical goal of OO, especially visible in its original implementation in Smalltalk is instead encapsulation - the idea that each object is a small computer of its own. Or, as Alan Kay put it,

a single kind of behavioral building block that hides its combination of state and process inside itself and can be dealt with only through the exchange of messages

...a concept that seems to have been lost in a sea of getters, setters and shared mutable state in later OO avatars.

guillaume31
  • 13,738
  • 1
  • 32
  • 51
0

As the other answers state, reducing conditionals is not the main objective of OO design, but rather a benefit from function polymorphism. Other paradigms such as functional programming can also have that effect.

OO design is more about producing a Low Representational Gap (LRG) -- the distance between a model of the problem and a model of the solution. It's what another answer refers to as "code making sense."

The following is reused from https://softwareengineering.stackexchange.com/a/308922/51948

A solution to a real-world problem needs to have a representation that closely resembles the model of the problem. It's why a dice game has a class called Die with a method called roll(), and not a block of code with 011100110000001110101000100001010101000100 (assuming those binary digit abstractions made sense on some platform). This has been called the representational gap by Larman. Abstractions allow keeping this gap smaller -- a strategy known as Low Representaitonal Gap (LRG). It makes code easier to trace to requirements and to understand. The Domain-Driven Design (DDD) approach is similar.

Rolling the dice by jcoterhals, on Flickr
"Rolling the dice" (CC BY-NC-ND 2.0) by jcoterhals

UML class diagram of DiceGame

Community
  • 1
  • 1
Fuhrmanator
  • 11,459
  • 6
  • 62
  • 111