Beyond Object Orientation

What's beyond Object Orientation?

FunctionalProgramming
ObjectFunctional
AspectOrientedProgramming
PatternOrientedProgramming?
PureCodeGeneration?
ImplicitLogicLadders?
MergingOfRelationalAndBehavior
InstantaneousLogicForSoftware?
Components?
ProceduralProgramming
FortranLanguage
AssemblyLanguage
MachineOpcodes?

I don't have a name for this theory, but I'd argue that an experienced developer's definition of OO is far from what is taught in the mainstream. The mainstream tends to think of the animals, simple geometry examples - maybe with the GangOfFour patterns, but are a far distance from the Xp practices that are similar but non-isomorphic to mainstream OOP

Do you mean where the emphasis is on combining and delegating behaviour rather than building elaborate inheritance hierarchies?

I think so(I can't quite articulate it). I mean that OOP is taught to be done strictly one way. You *MUST* practice encapsulation, polymorphism, inheritance, etc. In practice we know that hundreds of get() and set() methods aren't helpful. We know that polymorphism can be confusing if not leveraged right. We know that inheritance can be a poor substitute for good object interaction. Basically this wiki has a much more balanced/experienced view on OOP.

I also mean that programming moved from explicit requests(procedural) to abstracted requests(OOP). OOP on this wiki seems to push past that into the more complicated disembodied aspect interaction design. It seems rooted in OOP, but it's really something different. I just can't quite put my finger on how it's different. It's light years away from the "OOP" that many seem to practice - and it's not due to just developer experience, it's something at a higher level than OOP. . . actually it makes me kind of excited to think about. . . I guess something beyond OOP would need to follow an IterativeProcess? to get there. It just seems that it's so far beyond where it started that a new name may be needed.

I think of this as looking beyond Isa and Hasa relationships to the stuff the articles at ObjectMentor [http://www.objectmentor.com/resources/articleIndex] are concerned about.

[Or the stuff smart folks would discover about OO if they weren't promoted into management first.]

"I guess something beyond OOP would need to follow an IterativeProcess? to get there."

I think it will follow more the path laid out in TheStructureOfScientificRevolutions, vis a vis KuhnParadigmShift. Iterative in one sense... people will try new techniques bit by bit. But essentially not iterative because you have to more-or-less reject the old paradigm to really get your head around the new one.

Hrm. I read the ObjectMentor stuff - I can't decide if it's clean & obvious - or void of substance. There are some articles about patterns & frameworks, but generally speaking, the site is a weak shadow of this Wiki. The shift from procedural to OO probably qualifies as a major paradigm shift, where the benefits are still being debated relative to procedural. The shift wasn't that big though, and most programmers use a mix of procedural and OO techniques, not just one.

If history repeats, the nature of the paradigm shift would have the following properties:

It will be coded by one, two, or three geeks who are fed up
It will be all over the news for two days before disappearing again
It will have an open source tool
It would be bootstrapped off the old paradigm
It will be instantly dismissed by scores of developers
It will be instantly dismissed by scores of "developers", who will write books about why it's not important
Once it was understood by a few, a slew of companies will arise claiming to have a tool that implements it
Microsoft will claim to have one ready in four months, called Visual NewParadigm?.NET
Years later some non-original tools will actually implement it.
It's benefits may be relative to the old paradigm(ala procedural vs. oop), not necessarily superior
Once it is understood, something beyond it will arise iteratively, for a while they will be called the same thing, until they become distinct.
It's not going to be programming language as we know it. Maybe some combination of architectural, evolutionary, and aspect techniques
LispWeenies will claim prior art
The Perl community will claim it's been in PerlLanguage all along, you just have to say "#(&&->$\/\//@mumble->frabitz;;" to accomplish it.
Even after it's established by many as the NextBigThing, people will have arguments as to what it is. (cf NobodyAgreesOnWhatOoIs)
It won't be where the architects/scientists were looking
XeroxParc probably threw it out as unusuable, years ago.

When doing ObjectOrientation right, it feels a lot like FunctionalProgramming.

User interfaces are generated on the fly and you don't care where the data comes from and where it goes to. Data takes care of that.

-- GuillermoSchwarz

See: FutureOfObjects, ArgumentsAgainstOop, ImprovementsToObjectOrientation

CategoryObjectOrientation