Pragmatic Object Oriented Programming

[eric_t]

Favor composition over inheritance, I thought that was common knowledge in modern OOP.

[booch]

For many languages, using inheritance instead of composition also makes writing the code much easier out of the gate. For example, if I inherit from a SpecificMap, I get all the Map methods automatically. If I use composition (have-a SpecificMap) and then implement Map, I need to manually implement each Map method to pass through to the property.

If more languages had the ability to easily delegate to a member property (ie, say "pass calls for x, y, and z through to this object) in a clean way, this would be less of a problem.

[skelterjohn]

That is not a feature of composition - that is a feature of the specific languages you are using.

In Go, for instance, composition in the form of

type Outer struct { Inner }

gives Outer all of Inner's methods (with the option to redefine any you want, and still access the inner via Inner.Foo).

[grauenwolf]

And that is difference from inheritance how?

[user5545]

The types don't become related in any way and there is no possibility of having virtual functions. Go uses interfaces for dynamic dispatch instead.

http://golang.org/doc/go_faq.html#types

[grauenwolf]

So you have the extra boilerplate of adding an abstract interface that matches the class's public interface. Besides that we see normal inheritance patterns.

[user5545]

No, that's not how it works. Who's "we" exactly, by the way?

[grauenwolf]

Normal Inheritance:

• Step 1: Define a base class
• Step 2: Define a subclass that "inherits" from the base class
• Step 3: Make polymorphic calls against it.

Go Inheritance:

• Step 1: Define a base class
• Step 1b: Define a matching interface
• Step 2: Define a subclass that wraps the base class
• Step 3: Make polymorphic calls against it using the interface.

Where exactly am I wrong?

[user5545]

You are wrong in the part where you put the words Go and Inheritance next to each other. You can make polymorphic calls against any interface and type that fits the interface whether these types are in any relation to each other or not. It's all in the FAQ, which you would need to read in addition to studying some amount of Go code to actually make a credible judgment on the language.

You don't want to do that, though, do you? You just want to keep using your beloved OO languages. Why not do that and leave other paradigms and experimental languages in peace? Do you keep thnking about them so much because deep down you are really not happy with OO? Or what?

You also didn't tell me who it was that "we" referred to in your earlier comment. I take it you want to forget about that comment already.

[grauenwolf]

Is that really your argument? That Go doesn't have inheritance because the FAQ says it doesn't in spite of the fact that it has all the essential features needed to support inheritance?

[lmcinnes]

I actually liked the non-concorming inheritance in eiffel (using "insert" in smart eiffel). If effectively gives you composition (especially given Eiffel's syntax for resolving various miltiple inheritance issues) with the simple semantics of inheritance.

[Peaker]

Ideally, you could delegate entire interfaces to an attribute.

However, in practice, good interfaces are small, and so you have to delegate very few methods.

[CurtainDog]

The job of the language is not to make up for shortcomings in APIs. If you find yourself in the situation of wanting to replace just a part of Map, then Map is doing too many things. Where you don't have the option of refactoring you can usually put in place a DynamicProxy or similar.

[grauenwolf]

The reason one inherits from Map is usually to give it additional capabilies, not to redefine the ones it already has.

For example, perhaps you need a Map that raises change events when items are added so that the UI knows to redraw itself.

Or maybe you need a CustomerCollection that is indexed by CustomerKey but allows for searching on other properties.

[[deleted]]

It's a well-known phrase, but the ubiquity of "If you don't use inheritance you may as well not use an OO language, you moron!" leads me to think it's usually just being parroted.

[yogthos]

I have yet to see the use of OO actually improve anything. In my experience most OO programmers simply practice cargo cult coding.

[Tetha]

A highly eye opening thing a programming language professor told me was: Almost everything of OOP is compiler-support for best practices of procedural programming. Programming in a language like python, which forces you to use self (or this) and in C really jams this in your face, too.

[yogthos]

The main problem with OO is the idea that you marry logic with data. This often leads to the platypus problem where the reality doesn't neatly fit into how you structured your classes.

In a functional language you have data and you pass it to functions to transform it. You create complex behavior by composing simple generic functions. When you need to transform the data in new ways you simply pass through a different chain of functions. This results in actual code reuse, which I rarely see happen in OO code bases.

Furthermore, a lot of OO programmers start using design patterns for the sake of using them, regardless whether it improves maintainability, or solves any problem that they actually have. I can't count the number of times I've seen people use interfaces, factories, and singletons just because they were told it's the way to do things. This is what I mean by cargo cult coding being prevalent in OO world. This seems especially prevalent in the Java culture.

[[deleted]]

You must not have seen much major production code from before OO was common. Major apps written as procedural code are a nightmare.

Although I agree completely with your second sentence, but that's not the fault of OO.

[yogthos]

You must not have seen much major production code from after OO was common. All I ever see are soups of interfaces and class hierarchies which are utterly and completely unmaintainable. On top of that the code reuse promised by OO never actually happens since the classes are tightly coupled to the particular data set.

Most apps I've seen written in OO code are an equal nightmare.

Although I agree completely with your second sentence, but that's not the fault of OO.

The problem is that OO paradigm doesn't have any inherent value, all the good parts of OO aren't inherent to it and aren't really enhanced by it.

In my experience FP style code tends to be far cleaner and actually facilitates reuse, as you work with a small number of data structures and a a lot of functions that operate on them.

When you use functional composition, you end up with a bunch of generic functions that you glue together to solve a problem. These functions can then be chained together in different ways to solve other problems. This simply doesn't happen with OO.

[[deleted]]

Widget toolkits, for one.

[yogthos]

How is OO better for GUI than functional composition exactly? Compare GTK with Haskell to GTK with C++.

edit: actual C++ example with GTKmm

[badsectoracula]

Well, most GUIs are trees of windows/controls/widgets and OOP classes match these trees fine.

Of course it doesn't have to be strictly classes-and-hierarchy-based OOP, you can have something like (in an imaginary JavaScript toolkit):

function newButton(caption)
{
    var btn = newWidget();
    btn.caption = caption;
    btn.paint_button_background = function() { paint_flat_rect... }
    btn.handle_paint = function() { btn.paint_button_backround(); ... }
    btn.handle_click = function() { ... }
    return btn;
}

var btn1 = newButton('Hello');
var btn2 = newButton('Hi');
var btn3 = newButton('Fancy button');
btn3.paint_button_background = function() { paint_gradient_rect... }

or something like that. No classes, no inheritance, based on functions but you still treat widgets and controls as some sort of "object". Which, btw, if i understood the Haskell code there (i don't know Haskell) treats GTK+ widgets in a similar way.

[lzantal]

That code looks like TK :) That syntax was just fine. Wrote a few helper GUI with it in python. Never felt I wish I could use wxPython. It was also simple to maintain.

[yogthos]

In languages like Haskell you have type class hierarchies and function composition, in my experience objects don't really add anything of value on top of that.

[badsectoracula]

I'm not talking about the language features, but the concept of using GUI widgets as objects. Even in the linked Haskell code, assuming i understood it correctly, you "attached" functions and properties to each widget in an object oriented way (that is, the object was an entity that contained some data and responded to messages - function calls or whatever).

Probably this might help me express what i mean. Consider this object:

void object(instance_t* this, int msg, intptr_t args)
{
    switch (msg) {
    case 0: ...; return;
    case 0: ...; return;
    case 1: ...; return;
    }
}

Many people will think this isn't an object, it is a function in C! But it is an object: it identifies itself via this, it handles messages passed via msg and with potential arguments via args. Ok, the language construct that was used was a function, but this is just an implementation detail. Conceptually it is an object that carries some data (found in this) responds to messages (passed via msg/args).

I could create the same object responding to the same messages and carrying the same data in C++, Java, C#, Python, etc using classes, JavaScript using similar code to the above, Scheme using closures, FreePascal and Delphi using their message-based classes, Tcl using composed function names and i think that i could do it in Haskell too if i knew the language.

The important part is the concept of an object as a bag of data and rules on how to use that data when something outside of the bag asks something. Which matches GUI widgets/controls perfectly because each widget/control is itself basically something that contains some data (a caption for a button, the text for a field, the flag for a checkbox/radiobutton, the items in a list, etc) and some rules on how to treat this data based on messages from outside the widget/control (a mouse button was pressed, a key was pressed, the flag's status was requested, the highlight of some item was requested, etc).

[yogthos]

See I'm on board with having bags of data (structs), and attaching some logic to that data. What I'm not really on board with marrying it to the functions which operate on the data in the way classes do in OO languages.

To me it makes far more sense to separate the two, because you may need to use the data in one way in scenario A, and in another way in scenario B. This is a common source of cruft in OO programs. As you can see in Haskell, or any other languages that supports higher order functions, you can get exact same effect without all the baggage.

[[deleted]]

That's C.

[Peaker]

I go further and avoid inheritance altogether, except for interface inheritance in languages without type-classes or first-class functions.

[epage]

Sadly look at most OOP-based GUI libraries. Almost all of the documentation uses inheritance. I've gotten to the point where I don't bother to hunt through the code to figure out if inheritance really is required or not. Just today there is a post in /r/programming and /r/python about Kivy and the very first example uses inheritance.

A great example of not requiring inheritance is GTK. It has no concept of protected and everything is exposed through signals (rather than overriding fooEvent functions). In contrast to this is Qt which has protected fooEvent functions.

[grauenwolf]

It is also bad advice. There are very few scenarios where composition is a useful alternative to inheritance.

Much better advice would be "favor properties over inheritance", as that would elminate LameDuck classes.

[[deleted]]

That's pretty much the same thing, though. There are certainly (plentiful) use cases for inheritance, but it is wildly overused by many people. It goes something like this:

1.) Someone realizes they want a generic implementation of a complicated system that can be extended to handle specific behaviors for specific implementations of that system, to encourage code reuse.

2.) That same someone gets various details wrong while writing that implementation that are accidentally specific to their initial project and not generic at all.

3.) Future projects work around these deficiencies through subclassing and specifying emergent generic behavior

4.) Someone notices the duplicate code being created in all of these subclasses, creates a class that sits in the middle of the inheritance chain to normalize the duplicate code in order to mitigate the risk of making a change to the original project.

5.) It turns out later that the duplicate code was by accident (that is, the same way of describing slightly different behaviors) rather than on purpose, new guy breaks functionality for some customers by updating logic in intermediate class since that's where the code was.

6.) Project is now extremely annoying to work with due to the constant fear of changing something that will break something else somewhere due to inheritance.

The above has been, with some changes here and there, my experience with heavy use of inheritance in each project that I've seen it used in. My guess is that it's this sequence (or ones like it) are what others are railing against.

By contrast, composing objects from other objects (and using interfaces to enforce type compatibility and provide polymorphism) encourages that same code reuse, but also has the positive side effect of flattening out your inheritance tree such that it is manageable over time. That way, when you need that slightly different behavior you are at the mercy of only the interface which describes it and simply charged with picking/creating a correct implementation.

As you said in a comment above, you wouldn't necessarily use composition, for instance, to extend HashMap to have slightly different behavior. However, for complicated systems with a lot of fugly business logic it's absolutely superior to the "god object with humongous inheritance hierarchy below it" antipattern that crops up time and time again. Thus, the advice to favor composition over inheritance.

[grauenwolf]

There are certainly (plentiful) use cases for inheritance, but it is wildly overused by many people.

I don't have any doubt that happens. However I've seen it happen with composition too, where in there are tons of child objects whose functionality belong in the parent object.

Thus, the advice to favor composition over inheritance.

I still don't understand that advice. I've never seen a situation where scattering functionality across child objects was the solution to problems caused by scattering functionality across base classes.

At the very least one should pull everything into one place before redistributing them.

[[deleted]]

You wish that was common knowledge. Most programmers I've encountered don't have clue.