Many Find Object Orientation Hard

[EditHint: Merge with ObjectOrientedDesignIsDifficult]

I find the object oriented paradigm difficult. I suspect that many programmers also do. I love programming as long as it's not object oriented. I think the idea of object oriented programming is great. Reuse is extremely important. I also can do object oriented programming. I have built my own objects, and used others. However for me it seems many times more difficult than for many other programmers.

(I have an EE degree focused on computer engineering, and have been doing programming professionally for 15 years. I started with BASIC, loved Forth, used C professionally, learned C++, now mostly use Perl, want to learn Java better, and am working on a New Media degree. I find structured, refactoring/XP, relational database, AI, and modular approaches easy -- JonGrover)

: My personal experience as a mathematician turned programmer, now managing a team of programmers, is that background experience makes a huge difference to how easily people make the transition to the Object style of thinking.
: It's also the case that some problems, simulations in particular, are naturally composed of things that interact. Others, such as electrical circuits, fall more naturally into data flow. OO is not the most natural for everything, just as FunctionalProgramming is not the most natural for everything. -- outbound1.landg.com

You are not alone. I don't "get" what the benefits of OO really are either. Note that "Reuse" is not pushed as a benefit as much any more. But, there is nothing consistent to replace it as justification. (See BenefitsOfOo). I tend to lean toward procedural plus relational, and a tad bit of functional. -top-

It is good to know that I'm not alone. It feels sometimes that I'm having this trouble all by myself.

I think that the reason why ManyFindObjectOrientationHard is that the concept is so easy, it can take a lifetime to really understand. It's a zen thing. The answer is in front of your face, and therefore hard to find.

-- JonathanArkell

I don't think so. It's not zen, it just involves a different set of goals: break things into pieces to manage complexity, plan for changes in the future, hide differences from the pieces that don't care, etc.

--DerekWoolverton

To me it sometimes (often?) seems Object Orientation is more easily applied during a phase of SoftwareRefactoring? (compared to starting with OO design from scratch). Could it be that - at least for some domains - it might be much easier to write some kind of prototype (quick and clean, but otherwise not following a certain paradigm)? Later, step by step, you apply Object Orientation to improve maintainability, reduce coupling of parts you might reuse elsewhere, etc.

At "higher levels" a few meaningful objects identified during the initial design are often so obvious that you do not have to look for (and document) them at all, but the more medium and low level objects you add (during design), the more changes will be necessary later. Finally you end up with something that really makes sense (is usable, free of bugs, maintainable, extensible, etc. and even "Object Oriented") but it looks much different from what you had designed initially. So, in effect, much of the design time and especially the time to update your design while the code evolves is wasted.

Even worse, you may blindly follow what you designed first (mainly because you had invested significant time and it costs even more time to reflect what you would like to change). The resulting software then may also be "Object Oriented" but is far from efficient, maintainable, reusable (and all the other goals that OO usually promises).

Your mileage may vary, of course, but what I think is REALLY hard is to come up with an stable "OO" design in a unknown domain. (If you design in a domain you know very well, even if you do not apply changes to some piece of code you have loaded in the editor, it's still "refactoring" somehow, because you better know what is appropriate and what not and how you did similar things in earlier projects.)

--MartinWeitzel?

See DomainDrivenDesign. A stable design, or system, or IT solution, need not be your goal. I might argue it should not be your goal, unless your customer violates the principle that the only constant is change. What most customers really want (if they did but know it) is not a solution but an ongoing process of solution evolution.

I see and can share this view (and thanks for the link, BTW). The observation I tried to share here (and for which I still would appreciate to get some comments) is bit more directed to starting up such a "solution evolution". What I found is that - for me - Object Orientation is easier to apply if I refactor a significant amount of code that already exists. And "I find Object Orientation hard" (see the title of that page) if I try to come up with "good" OO code from scratch, maybe after a longer DesignPhase. It's not that I'm not able to find a bunch classes from scratch (and I can easily double that number using DesignPatterns), but having a prototype in hand - written in whatever style - it is MUCH easier (for me) to apply Object Orientation. -- MartinWeitzel?

The way I look at it is this: except, perhaps, in the greenest of greenfield developments, there is always something that can serve as a prototype, even if it is not currently software. Are you saying that a software prototype is MUCH easier (for you) to apply Object Orientation to than any other form of prototype? To the extent that you would consider creating a non-OO prototype in software just to give you something to refactor into OO? I do have some sympathy for this view. In my own case, I would not go that far, but I am always extremely wary of modelling in any domain where the SubjectMatterExpert does not already have some form of process already in place. This seems to me to be doing the SimplestThing: implement (or prototype) first using LedgerAndQuill? and the DynamicWetwareInterface (aka TheBrain), then tackle your highest priority problem... <repeat indefinitely>.

Moved discussion on Platonic philosophy to SoftwarePlatonism