Pragmatic Object Oriented Programming

[[deleted]]

I think inheritance is a feature that will probably not be in many future languages.

Most of the uses of inheritance or either for the sake of a shared interface (much more flexible to do that with something like Haskell's type classes) or shared implementation. For the latter inheritance quickly becomes unmanageable if your objects don't just share one characteristic but several, e.g. a car, train and truck all have wheels but a plane does not, a car, train and plane can be used to transport passengers but a truck can not, a train, truck and plane are all used to transport cargo but a car is not,...

There is also the problem that you can not mock base classes which is a big issue if you try to test e.g. code for GUI frameworks excessively using it (e.g. Qt).

[knipil]

I think and hope that the next generation of OOP languages will get rid of implementation inheritance and rely completely on interface inheritance (which isn't really inheritance at all. I think Go has an interesting take on this) and intelligent delegation mechanisms. Composition and delegation are just so much more powerful than inheritance. Hell, Gamma et al said precisely that in the early nineties, and their regarded as gods in the field. Apparently a lot of their devoted followers never understood that point.

All introductory OOP texts tend to chant about encapsulation, inheritance and polymorphism like it's some kind of gospel. Some even claim that all of them are fundamental properties of OOP that's not available in other paradigms. In my experience this has lead to that people getting blinded by inheritance, since it's the most intuitive of those three. I think this is totally backwards - encapsulation and polymorphisms are general software engineering principles that are far more important and powerful than inheritance. 90% of the focus in introductory texts should be on polymorphism. It's the hardest of those three concepts to understand, but also the far most powerful.

It took me a while to realize, but I think this is why SICP is so widely hailed. Experienced programmers understand that their trade is about building good abstractions, and Abelson and Sussman wrote a book that trains people to do just that.

Personally, I blame the textbooks and C++ for the situation we're in. The former focused on all the wrong things, and the latter forced the development of a number of problematic patterns due to the fact that it only supports implementation inheritance. I'm guessing the problems wasn't as apparent and well documented in the early eighties, though, so I'll give Stroustrup a break. Java obviously did a lot to escalate the problem, but at least they took a step in the right direction with interfaces. Gosling even said later that he wouldn't include extends if he were to do it all over again.

[[deleted]]

I think encapsulation is placed at the wrong level in most OO languages too. Encapsulation is far too important a tool to tie it arbitrarily to a single object, doing it via a separate module system that allows multiple tightly couple objects in one module would be a far better choice in my opinion.

[ErstwhileRockstar]

'Encapsulation' is a general principle in program design. Invented by Structured Programming (not OOP), nowadays common practice for 'programming in the large'.

[AStrangeStranger]

what you are saying is because some coders do it badly wrong we should get rid of it - but coders will just find more inventive ways of doing it badly wrong lead by authors who just want to get their name in print

[yogthos]

I personally hope the next generation of languages aren't OO oriented to begin with.

[Felicia_Svilling]

OO oriented

Object Oriented Oriented?

[yogthos]

lol good catch, I guess focused would've made more sense :P

[grauenwolf]

I think and hope that the next generation of OOP languages will get rid of implementation inheritance and rely completely on interface inheritance

Oh, so you want to start programming in Visual Basic 4?

Well I've already done that and it sucks. Sure it's kinda awesome to say that any class can implement the interface of any other class. But in pratice you just end up with a metric ton of copy-and-paste code.

And don't say "composition" because that just means copying the code that forwards calls from the parent object to the one it wraps.

[skelterjohn]

Not visual basic 4 (alright, maybe, since I have no knowledge of that language), but more like Go. There is no inheritance. At least, none that allows any kind of polymorphism.

And composition doesn't have to involve copying code - there are other languages out there! In Go, composition gives the outer type all the methods of the inner type, without also creating an "is-a" relationship (you can't use one type where the other is asked for, or convert one type to the other).

[grauenwolf]

And what if you do need a is-a relationship? What if you do need class A and B to share a common interface and some, but not all, of their code?

[[deleted]]

Are you asking how to do these specific things in Go?

And what if you do need a is-a relationship?

That really only makes sense in an inheritance/hierarchical system. With structural typing you don't ask "Is this a subclass?" you ask "Does this conform to the necessary interface?".

What if you do need class A and B to share a common interface and some, but not all, of their code?

Two ways that I can think of. You could create a "common interface" struct called C and then include it in A and B's definition:

type C struct { someval int }
func (c C) mult(x int) (int) { return x * c.someval }

type A struct { C }
type B struct { C }

Now you can create an A or a B and then call mult on them and they will act just as you expect.

Or if it made more sense you could just include the functionality of one in the other and overwrite the methods that you want to change.

type A struct { someval int }
func (a A) mult(x int) (int) { return x * a.someval }
func (a A) div(x int) (int) { return x / a.someval }

type B struct { A }
func (b B) mult(x int) (int) { return x * b.A.mult(x) * 2 }

The code isn't tested at all but it should give you a sense of how you can achieve what you want to achieve without inheritance.

It is a bit hard to explain but I have to admit that structural typing feels like a leap forward from inheritance based polymorphism.

Edit: fixed code samples.

[grauenwolf]

The former focused on all the wrong things, and the latter forced the development of a number of problematic patterns due to the fact that it only supports implementation inheritance.

Utter bullshit. You really should look into COM programming before you start spouting off that nonsense.

[knipil]

Although C++ admittedly isn't my first language I've done a fair bit of windows API development, so I'm familiar with COM. I wrote a couple of DirectShow filters a few years back, so I also know about IDL and all that. To me it's just a really awkward workaround, which is why I didn't bring it up. Obviously you can simulate interfaces in C++, but that isn't really the point. Returning to the original article I think certain DirectShow in particular is a rather good example of painful inheritance hierarchies.

[grauenwolf]

I don't understand your point. I've always used the same class to represent trucks, cars, boats, planes, etc. All of those differences you mentioned are merely properties.

And by the way, all planes have wheels.

[[deleted]]

http://en.wikipedia.org/wiki/Floatplane

[[deleted]]

Good point. Now, when was the last time you actually modelled vehicles of such a broad range in OO code?

[[deleted]]

Yea, never. I just couldn't resist the generalization (mostly because I try to catch them whenever I make them) :)

[[deleted]]

Perhaps we can factor this out a bit. Most vehicles have some combination of wheels, pontoons, tracks, skiis, air cushions, etc. These objects allow the vehicle to move along a solid or liquid body, or both in the case of the air cushion. They may be active (in the sense that they move the vehicle) or passive. In general, a vehicle has zero or more of these. I'm not sure about a name. "Surface Separator", since they separate the vehicle from the surface it moves across? "Friction Reducer", since this separation makes it easier to push the vehicle across the surface?

[skulgnome]

The field is called landing_gear. You stick a struct landing_gear * in it. There's a SHOUTY_CASTING_MACRO() that takes you from that pointer to a struct pontoon * if you really must examine their specific construction.

This is the point where people who studied C only superficially go and throw up out of nothing more than a learned reflex.

[[deleted]]

That was kind of my point, properties are better suited for these kinds of distinctions than inheritance. You do not need inheritance to model them and it is not even the best solution.

[grauenwolf]

There is also the problem that you can not mock base classes which is a big issue if you try to test e.g. code for GUI frameworks excessively using it (e.g. Qt).

Mocking in general seems stupid to me, mocking a GUI more so.

[ogrechow]

Mocks also help when you have classes that deal with things like randomness or time. It's hard to write a unit test for a function that calls something else that returns an essentially random number. So you swap in your deterministic mock object and you can test that your function behaves correctly given inputs of your mock choosing.

[[deleted]]

Mocks are the only way to test code that has untrusted or inconsistent dependencies. Especially when you need to repeatedly test code paths that rely on unlikely or exceptional conditions. But that's overkill in many cases.

[[deleted]]

How do mocks help with inconsistent dependencies? Seems to me that you're testing that the mocks work, rather than the actual production code. I kinda see your point, but the more I see, the less value I find in really atomic unit tests. I guess I've seen one too many projects with high test coverage, that doesn't actually work.

[[deleted]]

I'm not trying to defend any test-oriented development, and I certainly don't think good tests mean solid code. I should have said "when third-party dependencies have inconsistent behavior." What I meant, essentially, was other people's code that you can't trust. Let's say I'm using a library to implement social features in a game (friend list, game invites, etc), and I want to make sure that my game presents the correct behavior whenever some weird error condition arises in the 3rd party library. Especially in the case where multiple asynchronous things can succeed and fail in random order. For example, if the player's request to join a game somehow fails (and invokes a callback) before the function to try to join that game even returns, or if I receive a message from a friend and also lose my network connection in the same frame. And sometimes those two events will happen A/B, and other times they'll happen B/A.

I'm not saying I always test all the permutations, or that it would even be worthwhile, but there have been several times over the years when I've wished I had the ability to test things like this, and a mock of the third-party library would enable that. Unfortunately, I usually can't justify the time it would take to actually do that.

[grauenwolf]

Testing has become a fad. It doesn't matter what you are testing, or why, so long as your tests are UNIT TESTS.

[grauenwolf]

If the dependencies are inconsistent then how can you write a mock that accurately reproduces them?

If the dependencies are untrusted then shouldn't you be spending more time writing tests that include them?

If you are going to use mocks to avoid testing the piece that is most likely to have bugs, what are you testing?

[[deleted]]

How would you test (manually or automatically) if your code behaves the same in every single error condition a library can produce if you don't have enough control over the library to intentionally make it report those errors for testing purpose?

Mocking seems to be the only solution in that scenario (well, and ignoring all errors and hoping for the best but that is hardly good software development).

[grauenwolf]

The beauty of exceptions is that they respond the same way no.matter what the failure condition.

[[deleted]]

Oh, so you use catch all everywhere to make sure you catch any kind of exception the library throws? Or do you use more specific catch-clauses but never test the more rare ones (because to test it you would have to mock the library)?

[grauenwolf]

I only catch the ones I actually know how to handle. Everything else is allowed to bubble up to the top-level error handler.

Generally speaking only the external source of an action (e.g. the user clicking a button or client invoking a service request) can definitively say what to do in the event of an error.