Alternative Inheritance Paradigms in Object-Oriented Design

Architecturecdesigndesign-patternsobject-oriented

My apologies if a variation of this question has been asked before, but due to its nature it is hard to search for.

I am having a discussion with a colleague about object-oriented design, and it basically comes down to a choice between two different paradigms. What I had been searching Google for was a discussion between these – as I've seen both discussed.

Paradigm A

Have a small number of classes which answer a lot of public methods, many of which are not applicable unless in certain circumstances. In these cases, they throw a runtime exception.

Example: a mathematical vector class can have any number of elements. This class answers 'Cross', but returns an error if it has anything other than 3 elements.

Paradigm B

A deeper inheritance tree, with methods only appearing where they are applicable.

Example: the mathematical vector class is specialised as a 3D-vector, with only the 3D-vector answering 'Cross'. 3D vectors are a special case as there are many functions relevant to a positional vector alone (Dot, Cross, Distance, AngleTo, etc).

I'm not actually asking for opinions on the above (although clearly the second is better!) but where can I find a good discussion on this – and similar – design issues. I can find many beginners' discussions/tutorials on the subject, but I haven't had any luck finding the more in-depth articles.

Edit:

After a prompt from @JohnDibling, I'll rephrase the question (and add another Paradigm on request):

Paradigm C

Lightweight objects with a suite of functions to interpret them, and throw errors if the provided arguments weren't valid.

Example: all vectors only respond to the most basic requests, and a series of functions like Size(vector), Cross(vector) do all of the work. Cross would throw a (runtime) error if an argument of the wrong size is given.

Could anyone give me specific reasons why A or C might be preferable to B, or point me to an article which discusses this issue in depth?

Best Answer

It depends on what you're trying to accomplish.

Generally when you use OOP or any other architectural technique you want to leverage the benefits that it's approach facilitates. One of those benefits may be more reuse. Reuse is considered good because it can reduce the overall load of code that must be reviewed,code that must be written, etc.

The OOP architectural paradigm also offers information hiding and encapsulation, important for managing and reducing complexity. Reducing complexity in code is crucial to improving code quality and increasing overall development speed.

In my opinion, one of the best ways to refine your underlying OOP architecture is to begin to build a reference implementation. Try to actually implement the high level functionality, at least conceptually or in pseudo code. Doing this forces you to continue the architectural pattern you begin with the fundamental class definitions. In this way you can get feedback from your implementation attempts about what OOP patterns are working cleanly and clearly to express your higher level functionality and which are hindering those efforts by making things more difficult by enforcing unnecessary conformance or, conversely, allowing excessive, distracting and confusing abstraction.

Known (GOF...) design pattern can help you by providing expert heuristics about which things have worked for many people over many trials.

But ultimately it is your project's requirements which will have to guide the final OOP foundation construction.

The core concept for me is whether a particular architectural approach is going to have a NET benefit or a NET loss. If it takes longer to create a whole boatload of abstraction concepts and work out all the kinks in your inheritance hierarchy, that it would to just do a more quick and dirty approach and fix a few bugs or issues. Well, it's a judgement call.

Also, it depends on what you plan to do, if these classes are intended to be the foundation of another 100,000 lines of OOP class hierarchy definitions, it may be time well spent to thoughtfully refine the abstractions as tightly as possible.

Related Solutions

C# Vector Class – Interpolation Design Decision

Maybe it is that I come from Java, but I really don't like extension methods unless there is a good reason for it.

If you want to reuse the operation code, the solution should be composition. Create an Interpolator that operates over an IEnumerable<double> (unluckily, it seems that C# lacks an equivalent to java.lang.Number, so you can't make the class generic easily). I don't think it is a bad idea that your Vector class implements it, too.

For bonus points, make the class an interface that defines the operation and inject an instance of the interface in the object, so you can change the implementation (or even use other types of interpolations, if they match the method signature) at will.

Object-oriented – Are monads a viable (maybe preferable) alternative to inheritance hierarchies

The short answer is no, monads are not an alternative to inheritance hierarchies (also known as subtype polymorphism). You seem to be describing parametric polymorphism, which monads make use of but are not the only thing to do so.

As far as I understand them, monads have essentially nothing to do with inheritance. I would say that the two things are more-or-less orthogonal: they're intended to address different problems, and so:

They can be used synergistically in at least two senses:
- check out the Typeclassopedia, which covers many of Haskell's type classes. You will notice that there are inheritance-like relationships between them. For instance, Monad is descended from Applicative which is itself descended from Functor.
- data types that are instances of Monads can participate in class hierarchies. Remember, Monad is more like an interface -- implementing it for a given type tells you some things about the data type, but not everything.
Trying to use one to do the other will be difficult and ugly.

Finally, although this is tangential to your question, you may be interested to learn that monads do have some incredibly powerful ways to compose; read up on monad transformers to find out more. However, this is still an active area of research because we (and by we, I mean people 100000x smarter than me) haven't figured out great ways to compose monads, and it seems like some monads don't compose arbitrarily.

Now to nit-pick your question (sorry, I intend for this to be helpful, and not to make you feel bad): I feel there are many questionable premises which I will attempt to cast some light on.

A monad is a set of functions that take a container type as a parameter and returns the same container type.

No, this is Monad in Haskell: a parameterized type m a with an implementation of return :: a -> m a and (>>=) :: m a -> (a -> m b) -> m b, satisfying the following laws:
```
return a >>= k  ==  k a
m >>= return  ==  m
m >>= (\x -> k x >>= h)  ==  (m >>= k) >>= h
```
There are some instances of Monad which are not containers ((->) b), and there are some containers which are not (and can not be made) instances of Monad (Set, because of the type class constraint). So the "container" intuition is a poor one. See this for more examples.
So in an OO language, a monad permits operation compositions like:
```
  Flier<Duck> m = new Flier<Duck>(duck).takeOff().flyAround().land()
```
No, not at all. That example does not require a Monad. All it requires is functions with matching input and output types. Here's another way to write it which emphasizes that it's just function application:
```
Flier<Duck> m = land(flyAround(takeOff(new Flier<Duck>(duck))));
```
I believe this is a pattern known as a "fluent interface" or "method chaining" (but I'm not sure).
Note that the monad defines and controls the semantics of those operations, rather than the contained class.

Data types that are also monads can (and nearly always do!) have operations that are unrelated to monads. Here's a Haskell example composed of three functions on [] which don't have anything to do with monads: [] "defines and controls the semantics of the operation" and the "contained class" doesn't, but that's not sufficient to make a monad:
```
\predicate -> length . filter predicate . reverse
```
You have correctly noted that there are problems with using class hierarchies to model things. However, your examples don't present any evidence that monads can:
- Do a good job at that stuff that inheritance is good at
- Do a good job at that stuff that inheritance is bad at

Best Answer

Related Solutions

C# Vector Class – Interpolation Design Decision

Object-oriented – Are monads a viable (maybe preferable) alternative to inheritance hierarchies

Related Topic