The Great OOP Misnomer

What’s the biggest minomer with OOP?

Object-oriented programming is all about objects.

False.  Objects are instances of classes and only exist at runtime.

Object-oriented programming is all about class design.  It should have been named Class Oriented Programming (COP).

Bertrand Meyer asked this question in his classic tome on object-oriented design:

Do we design for runtime or design time?

Answer:

Object-oriented programming is about design-time constraints.  Concepts such as reuse, maintainability, encapsulation, information hiding, and inheritance are all design-time constructs.

In fact, there are multiple designs that end up with the same runtime layout (objects) but that aren’t all considered good object-oriented design (you can’t judge the class design by what the object looks like at runtime).

The lack of focus on runtime issues is, in my opinion, the greatest weakness of OOP.

This was one of the issues that the Component-Orientation crowd, such as Szyperski, capitalized on.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

10 Responses to The Great OOP Misnomer

  1. Johnny Hall says:

    OOP is all about design-time. C#/.NET is not an OO language/runtime, it’s a component-oriented language/runtime.

    COM was an elegant solution to many of the problems of that OO couldn’t solve – versioning being the biggest manifestation of those problems, which lead to DLL hell. Unfortunately, COM was implemented horribly and in order to be successful with it, you needed to be VC++ ninja. This lead to ATL, which didn’t really make things much better. Heaven forbid you were a VB developer, you were completely hamstrung.

    .NET solved those problems in an elegant way. Every “object” in .NET is actually a COM component under the covers. Unfortunately, one of the problems with .NET was that it didn’t fully recognize that the main/only artifact of reuse in COM was the interface. You can’t really reuse implementation. However, you can and should reuse interfaces. But .NET doesn’t enforce interface usage.

    So, now there are a number of problems that .NET components have. Again, these are all runtime constraints. Threading, transactions, concurrency, instance management, reliability, faulting and so on. In order to do these things with .NET requires a lot of (difficult to write) plumbing code.

    What solves this? WCF. WCF is the next version of the .NET runtime. Think of it as the equivalent of ATL was for COM. .NET will go in the next version – people just don’t realise it yet. Remember that .NET 3.0 was originally called WinFx. C# will be re-worked as a service-oriented language, rather than a component-oriented one. The services that WCF provides (forget about the web services/interoperability story, which is irrelevant to this story) for C# “classes” are paradigm shifting.

    The general .NET programming community don’t realise it yet but the sands have shifted. Give it a couple of years and sooner or later, people will realise that they aren’t OO programmers, they are service-oriented (where a WCF “class” is equivalent to a “service”) programmers.

    Of course, MS can’t tell people that directly, because it’s too scary for most people to comprehend that they’ve got another programming model to learn, yet again. So, WCF is being pitched as a solution to interoperability and web services. Interoperable with who though? No-one else supports the specs, so forget about it.

    Anyway, sorry for rambling on on your blog. I should post this stuff to my own site!

  2. Evan says:

    @Johnny Hall

    It shows that you are in the middle of Juval’s class.. ;-)

    I agree 90%. I’ll see if I can force a writeup on the other 10%.

  3. Jimmy Bogard says:

    @Johnny

    I have to agree with Udi here. WCF belongs at the _boundary_ of your application, not to define it.

    http://udidahan.weblogs.us/2007/12/29/wcf-everywhere-not-on-my-watch/

    If anything C# is being re-worked into a functional language, not service-oriented. Unless you have two different systems wanting to communicate, I can’t see why you would care about WCF.

  4. Johnny Hall says:

    Don’t get me wrong, I’m committed to DDD, NHibernate, solid OO patterns and the rest. I’m not really *that* interested in SOA (in the business sense).

    WCF isn’t ready to be used for every class but for the capabilities that it gives you, once you understand what you are getting, it’s clear that that is the direction that MS is heading.

    Read between the lines and you’ll see where .NET is heading with Oslo. I don’t think that becoming a service-oriented language would discount C# becoming a functional language as well. WCF isn’t really about communications. It’s about aspects, and those aspects are often worth paying for. Reliability, security, transactions, etc.

    The problem I have with WCF isn’t about the performance penalty of those aspects, it’s about the fact that it radically changes the programming model, specifically removing the ability to use constructors.

    I’d like to separate myself from Juval’s rather militant hardline on WCF as well ;)

    It would be useful if MS were painting an accurate picture of WCF and .NET, rather than trying to ignore the direction that they are heading in.

  5. Johnny Hall says:

    To be fair to Juval, he most definitely doesn’t think that WCF is ready to be used for every class/service. He just thinks that, if the implementation supported it, then it would be worthwhile.

    He recommends using it a layer boundaries, so, effectively, that would mean

    Client

    —-WCF boundary
    Service
    Domain

    —WCF boundary
    Repository

    At this point, I’m not ready to commit to using it at the repository boundary but I can see where it might be called for – reliability, timeout and throttling on the repositories would definitely be useful.

    I’m more or less in alignment on the performance issues. WCF is unlikely to be the bottleneck if you work on the application design with WCF in mind. Anyone who ever did anything with MTS/COM+/ES will recognize that that was the only technology which could be used to build scalable distributed apps in VB6. WCF is much the same in this regard.

  6. Jimmy Bogard says:

    @Johnny

    I guess what I’m missing is the motivation to create service boundaries between different logical layers in a single application. MS has gone many other directions before that didn’t pan out, so just because there’s a project on the horizon like Oslo doesn’t mean it’s where the world of software is going.

    With any service boundary, there will always be performance implications. It’s just the nature of the beast. I understand much of OO is messages between components, but other tools better provide things like aspects (AOP for example).

    I haven’t seen Juval’s presentation, so I’m curious to see what a full-fledged architecture like this would look like.

  7. Johnny Hall says:

    I don’t necessarily think that the world of software is heading this way, just MS. WCF was a massive investment by the company, one they wouldn’t have spent just for interoperability with platforms that don’t support the same standards anyway. Let’s face it, IBM and maybe Sun are the only ones that will even get close to supporting the full WS* stack.

    If you recall that .NET 3.0 was originally called WinFx, the you’ll grasp that they were originally intending to deprecate .NET anyway. Marketing won though. There probably won’t be a .NET 4.0. IMO.

    The particular aspects that WCF provides aren’t really provided in any other framework, and most of them are really only important in an “enterprise” environment (whatever that is). Transactions (with no code). Reliability (you have to see this to appreciate it but essentially it means that your server code will be unlikely to hang ever again). Throttling (similar advantages to reliability). Security (full message encryption, which is pretty useful if you think you might need it). Synchronisation (at no cost). And so on. The aspects that you get aren’t really provided elsewhere. And it doesn’t mean that you can’t use another AOP framework if you need to.

    So, there’s the performance issue. It is noticeable, but as soon as you do any real work, which involves any I/O – disk access, network hops, UI, then it’s orders of magnitude less important. If you were involved with COM+ then it’s a similar cost. One worth paying for in many cases.

    The architecture doesn’t look any different than any other layered architecture. You just need to use per-call at the service boundary in order to maximise scalability (something you should be doing anyway). If you’ve got course-grained classes, e.g. service layer and repository, then it fits perfectly. If you don’t, e.g. domain model, then it doesn’t and isn’t worth paying the perf penalty.

    However, the perf penalty is mostly in setting up the channel anyway (the interception pipeline) which is encapsulated in the proxy (which is used similarly to something like a Windsor container, so it’s not foreign to most of us). Cache the proxy and you don’t pay the cost on every method call.

  8. Johnny Hall says:

    Apologies for hijacking your post. Very rude of me, particularly considering that WCF is only tangential to the original topic!

  9. Evan says:

    @Johnny Hall

    Actually, it was fun reading your comments. I took Juval’s Arch course in January, so seeing your comments was cool.. :-)

    More Comments == Better

  10. Johnny Hall says:

    Cool.

    It’s funny, I was trying to remember where I’d read that Juval had said that every class should be a service. It turns out to have been your (old) blog!