Slashdot Mirror
The Post-OOP Paradigm
Kallahar writes "American Scientist has an article up about Computing Science: The Post-OOP Paradigm. The article has a great overview of how OOP works, and then goes on to a brief outline of the possible successors to OOP such as Aspect, Pattern, and Extreme Programming. Also a pretty picture of OOP Spaghetti."
How could Aspect, Pattern, and Extreme Programming replace OOP? That's ludicrous.
;-)
Aspect programming doesn't have inheritance (that I am aware of) so it is a weaker model than OO. Although we should "...favor composition over inheritance", it doesn't mean we should do away with it! Also, where the polymorphic method behavior of Aspect?
Pattern design's foundation rests on OO. Take away OO and Pattern can't exist.
Extreme Programming has nothing to do with any of the above. It's not even an architecture. It lives under the misguided notion that since team-analysis works well, team-programming must work well too.
However most OOP programmers try to over-OO everything. This is a problem from day one - their instructors show them how to make an object and how cool it is to have the object do something on its own. Thereafter, the students objectize everything. This leads to situations where you've got horribly bloated code that runs slow as hell.
It's this kind of instruction that leads to programmers writing whole object-oriented interfaces to things that can be very easily manipulated without all the overhead. For example I had a consultant working (briefly) with me who wrote several thousand lines of code that would edit colon delimited files (like /etc/passwd, for example) when a simple strtok in C or split() in perl would have done the trick in a few lines, without all that code to debug.
People need to always take a step back and see if the language contstructs they plan to use are appropriate for the task at hand. More often than not, they'll find that they higher level languages are too much. Don't write a C program when you can write it in shell. Don't write daemonizing code in your app if it can run from /etc/inittab. Don't write a scheduler when you can do it in cron. And never write OO when procedural programming can do the same trick in less space.
It does not make sense to say that these other ideas are succeeding/ replacing OOP. I don't think that people practicing for example Extreme Programing have stopped using objects, or that they promote the use of global variables.
Rather, there are refinements and additions to OOP, and they cover subjects that have not been addressed before. It is not that they address the same issues with a new set of solutions.
Tor
not to be confused with this flavor of spaghetti.
"And this is my boy, Sherman. Speak, Sherman." "Hello." "Good boy."
I dont understand why people think Pure Object Oriented Databases will replace Relational Databases or ORDB. All type Pure OODB, ORDB, RDBMS all will have there place.
Same thing with OOP, there are tasks which lends themselves better to OOP vs functional programming, and vice versa.
Every technique will have its place.
We have the same mix-conception about XML replacing everything else. e.g.
<actor name="Martin" show="Simpsons">
<sprach volume="high">ha ha!</sprach>
</actor>
Consensus is good, but informed dictatorship is better
...doing your design on the fly? Which is what everyone does anyway? Why is this something new? If you read any coding manual, they try to impress on you that you should plan your design from the start, then code it. Reason being that in the long run, less time is used. Well they'd only mention this if the "wrong" way was to just hash it out as you code. So if planning your design is the opposite of just figuring it out as you go along, then isn't "Extreme" programming the opposite of planning it beforehand? Which is what everyone does anyway? And this guy thinks he came up with something new?
When I hear about "extreme" programming, I envision some guy coding while skiing down a steep mountain (which has no snow, BTW).
A real shape library would have methods like isConvex() and numberOfSides() instead of implementing the number of sides as an infinite number of subclasses (triangle, quadrilateral, etc.)
Perhaps these guys should have read Antipatterns or Pitfalls of Object Oriented Development instead of wasting their time with this article.
The example that is brought up with all the shapes turns out to have a fault. Inheritence might not be a good way to model those relationships.
So, all this article has done is show that the P-OOP thing is better than a octopus inheritance tree. Of course it is. Inheritence tends to get used way too much anyway.
Consider the famous example that we have all seen: an employee class is derived from a person class. That example appears in countless books, and probably countless systems in actual production today. But is it correct? The challenge of designing a system is to make it flexible enough to stand in the future.
Suppose we have a person who is an employee and a student at the same time. Should we use multiple inheritence? That would be screwy, and also not natural to implement in a language like Java. It turns out that breaking the problem apart into an inheritence type arrangement isn't the best or most flexible way to approach the problem.
In short, the article has made a good case why inheritence is sometimes not the right tool to use. But remember that OOP is three things: 1) inheritence 2) encapsulation and 3) polymorphism. And a language like C++ (and Java soon) has the notion of *generic programming* which the article didn't talk about.
If tits were wings it'd be flying around.
Of the 3 'paradigms' mentioned as alternatives to OOP, only aspect oriented programming is even on the same order as OOP. Patterns are a design methodology and XP is a workflow.
Aspect is best used in conjunction with OOP. In fact I would say that anyone that uses Objective-C's categories has been doing aspect all along.
I would even argue that you don't really need inheritance. In theory it's good, but as with over-OO'ing everything it quickly becomes complicated. And the more complicated it is the more spaghetti-like it feels and the less likely a programmer will reuse the code.
I've seen some very complex software written in functional languages that was very easy to follow even though the had no real OO concepts (usually some sort of module system and the equivalent of C's structs).
Sometimes the most straightforward approach is the clearest and OO is anything but straightforward when you think about all the layers that go into it. Now, I'm not saying OO is all bad, it has good features. I feel a powerful programming language should strike a balance between the different programming methodologies.
In the past I have made some comments on what I think plain old C could become if it incorporated some modulization features.
The ratio of people to cake is too big
I told my manager in a design meeting that we should do all new development using POOP techniques and POOP tools and POOP constructs. Now I'm unemployed like the rest of you.
I don't need no instructions to know how to rock!!!!
There is some truth to that, I'm sure, but I'm not aware that programmers schooled in any other methodology are perfect programmers straight out of school. It's a tough craft, and it takes a few years of being an idiot until you start producing really good code, regardless of methodology.
Where I disagree is on the relative proportions of these two things. I firmly believe that we're still at the point where well over half of what a programmer does fight with tools, rather than solve new problems. I'd go so far as to say I think it's about 90% accidental complexity, which implies that the ideal programming language could allow a given development team to produce systems that are ten times more elaborate/powerful/complex/etc than today's.
So I think the language designers still have a lot of work ahead of them.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Everywhere I turn right now someone is yapping about "Patterns": No longer is it simply standard best practices, but rather now it's the new age "Patterns". No longer do you do code maintenance: Now you "Refactor". No longer do you wing it, now you do "Agile Development". It almost makes the speaker sound ridiculously naive hanging onto whatever terminology they hear, as if it's something new when it's merely renaming existing techniques and standards.
I need to get back to working on my dinner heating patterns.
First: yeah, right because XP (et al) re-writes OO: pair programming, early delivery, RAD, iterative development etc are different ways of running a life cycle, not different ways of structuring your model of a domain.
Second: this reminds of when the K boys did a big rant about "I prove OO is flawed because if you have a class Person and derive from it Customer and Staff classes then you break stuff when a staff member quits his job and walks into the shop and buys stuff as you need to get the object to mutate classes". They claimed to instead invent "OO++" (they called it that). The correct OO answer is that you've got a poor design, you need to revisit it (and aspects or attributes or roles as concepts may help you think about this), but that doesn't break or replace OO (ie straw man argument).
Now meta-programming, such as the (now rather old but still a head-fuck for those who program in one language only) Meta Object Protocol is the direction that I see code structure moving: more Lisp-like structures and flexibility to change your object protocol on the fly, losing strong typing as a fundamental mechanism for OO, these are ways to let you manipulate the larger level structure of your code whilst keeping the lowest level of syntax constant . You let people write their OO code as they like, but as an over-coordinator you can suddenly change the way inheritance works, or the way method-dispatch works to get different effects. It's what I like about Perl (which is making me realise what all those Lisp hackers were raving about for so long, but I prefer the pragmatic approach of perl over the rather purist lisp).
--
T
I spent a lot of money on booze, birds and fast cars. The rest I just squandered. - George Best
There are so many obvious glaring problems with this article I'm surprised it got published. XP as a "replacement" for OOP? Goodness, one is a methodology for building software, the other is a programming mechanism. Patterns? They are applicable in areas other than OOP. Like... architecture for instance . AOP? That's just a fancy way of inserting code into a class. Same principle as using #define in C or C++, though certainly more powerful.
Most of the 'problems' of OOP are the same as the 'problems' with older languages and practices. Simply put, once you weed out the people who aren't very good at design or programming, the lazy, the stress-cases under schedule pressure, etc. etc., you have a small group of people left who are building "good" software. (Measured by the quality of the code itself, not the success of the product.)
One of the biggest impediments to good software IMO is that the current crop of languages and tools don't punish laziness up-front. Using a magic number (or string) in a dozen places? No compiler will complain. Got a method that is calling myFoo.getList().calculateMarbleSize().insertInto( table )? No problem! Got a class that's importing classes from two dozen packages? Hey, it compiles, it must be good.
All of these examples are well-understood problems which can be avoided or fixed with very little effort. But until we have languages and tools that actively encourage good practices, we'll keep writing crap.
(Insert a rant about methodologies here -- I'm not going to go on anymore.)
-Thomas
What you're saying is that "Bad OOP (pOOP) is not the answer" which I agree with.
However, the idea behind object oriented programming is to break repeated tasks down to a general algorythm that can be reused at 1000 different places in the code without having to write 1000 different, but similar, pieces of code. This is always a good idea.
Bad OOP is when some jackass writes a 600 line "Swiss-Army Object" and insists on including it everywhere instead of doing any new coding.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
And never write OO when procedural programming can do the same trick in less space.
Half the point of OO programming is so that later on you can change functionality easily, or expand the use in certain directions. One should always program in an object-oriented way (within anything other than a tiny application) for a few reasons.
Firstly it can save an awful lot of time later on - I make an effort to have a sensible OO design to all programs I write, and although this may increase the time it takes to write the functionality the first time around, the amount of time I frequently save down the track when I need to expand the application more than makes up for it.
Secondly, it is just good programming practice. If you are writing an OO program, you shouldn't leave chunks of procedural code lying around, because it is neither neat, nor consistant. If you are speaking in French, you don't throw in German verbs because they are faster to say...
Now obviously there are always exceptions to the rule - although the only two I can think of is when speed is crucial (although with modern compilers the overhead of OOP seems to be extremely small), or when it is an extremely tiny application (but that goes without saying).
well, I heard this 20 years ago (about Prolog, Haskell, Smalltalk, LISP, etc). I really don't think in the commercial world any well designed language is going to be popular. Sorry (and I truly am). The future will continue to be half baked, bug generating, hard to maintain semi-OO languages such as C++ and Java and Microsoft's VB
Some people using OO incorrectly does not mean that the entire concept is in error (insert baby_bathwater.comment).
The statment "... OO is anything but straightforward when you think about all the layers that go into it." is a hint at the underlying problem, I think. If you have to think about the layers, your model has some problems.
The functional system you describe with the module system sounds like it is building some very nice layers. I'm not saying it can't be done without OO.
What I am saying is that OO (and OO languages like Java) encourage you to do it "the right way". You can write spaghetti code in Java, but it takes some doing. You have to sprinkle a lot of static keywords around, and make a lot of classes that don't make sense.
Coversely, to write clean, modularized code in most fuctional languages, you have to be more "disciplined" and stay out of things that you shouldn't be in.
I suppose, in conclusion, I would say that OO leads to very clean, straightforward code when the concepts are well understood and applied. Understanding and applying these concepts is not a simple task, however, and I'll admit that in the time I've been doing it (~7 years) I don't have it cold.
Just my $.02
-Zipwow
I don't know which is more depressing, that 2/3 didn't care enough to vote, or that 1/2 of those that did are crazy.
#1. Observe that there's no benefit in Convex and Simple inheriting from Polygon. They are abstract classes of polygons classes for which instances cannot reasonably be constructed (because polygons need a number of sides) and, presumably, cannot implement many of the base operations of Polygon that they're inheriting. Thus, the hierarchy can be simplified by making Convex and Simple interfaces.
#2. Another solution to the above observation is to make Convex and Simple mix-ins (if your OOP language supports them).
#3. Don't try to account for two separate properties in a single taxonomy. Make either the number of sides or the type of polygon an instance attribute, rather than part of its type. For instance, we might decide that all polygons, regardless of number of sides, have the same basic set of operations, and so only work with Convex and Simple classes.
Another distinct problem with the diagram is that it mixes what we assume to be instances (a star) with what we assume are classes (Pentagon). From what I've seen, the article deals with class-based OOP, so this is an odd confusion. In fact, the problem it illustrates is perhaps mitigated, if not eliminated, in moving to a prototype-based system.
If a corporation is a personhood, is owning stock slavery?
XP is heavily influenced by TDD -- Test Driven Development. The idea is that you only write code when you have a failing test. You write the test, it fails, you write the code to make the test pass. Then you go back to the requirements, write another test specified by the requirements, run it, it fails, so you write the code to fix it. Repeat until all tests (unit and functional) pass. When all your functional tests pass, you've met the requirements for the app (because the functional tests represent the use cases) and you're done.
Coding in this fashion does two things. It ensures that you've got a safety net at all times, and it forces your code to be loosely coupled and modular. Because you have 100% coverage, you're not afraid to change the code, because if you break something, you'll get a failing test. If you make a change and all your tests pass, you have the confidence that you didn't inadvertently break something in your code.
Additionally, your code needs to be modular and loosely coupled because it's tough to test if it isn't. If you have a God Class with lots of dependencies, you won't be able to unit test it because of all the dependencies. That's to say, you won't be able to test it as a unit. If you have a method that's doing lots of things, you'll have to write lots of tests to verify every path of execution. So instead, you're strongly encouraged to write simple methods that do one thing well for ease of testing.
A real OO guru knows all sorts of things about coupling and cohesion and patterns and when to use composition and when to use inheritance. They always obey the Law of Demeter and consistently separate the implementation from the interface. And to be able to do this, they've got a dog's life of OO experience under their belt. Here's the kicker. The XP evangelists say that using XP and TDD, in particular, gives you the benefits of all this experience as an emergent property of the methodology.
You obey the Law of Demeter because testing a class that breaks it isn't a unit test -- it's a subsystem test. You use interfaces because it allows you to substitute mock objects for the objects that your object under test interacts with. You use composition and inheritance appropriately because your tests will fail if you don't. Oh, and by the way, if you start with inheritance and move to composition, it's not a problem because all your tests will insure you don't leave something broken.
The point is that a programmer really only needs to learn how to write good tests in order to be a good programmer. TDD gives you all the stuff that you would normally have to have gained through experience.
So, that's why I think it's similar to AOP. They both produce higher quality and more maintainable software. However, TDD is a social solution, while AOP is a technical one. And, as long as I'm on my soapbox, I'll just mention that many patterns are compensations for things that more powerful languages do easily. For example, lisp's map procedure is an example of Visitor. Generally, languages that support higher order functions, or that treat functions as first class types, don't require as much pattern silly-walking. Also, AOP is old. Lisp has had it for a long time. In fact, the main architect of AspectJ, Gregor Kiczales, worked on the Common Lisp Object System (CLOS) with Richard Gabriel. Plus ca change, plus ca meme chose, innit. Here's a link to some thoughtful writings on the subject.
One other point -- for those inclined towards genetic programming. I think that the XP TDD way of programming suffers from the same problems as the hill climbing algorithm. It tends to produce quality, but I think it's easy to get stuck at a local minimum.
Until management and HR get it through their head that programming is about hiring the "right people", building software will still be spaghetti. Crappy programmers who can't think beyond the line they are currently typing is the main cause of a lot of problems. In the worse cases, it's programmers who refuse to listen and understand the functional requirements before they code. Not enough programmers take a humble approach and take time to listen closely and think ahead.
Not everyone can and even the best programmers can't think of everything. It's all about finding the right balance to build a team that compliments each other.
Let's remember that, once you compile a program, you are left with the same thing no matter what language you used: instructions and data. Because all you really have to work with is memory and processors (and I/O, but you can treat that like the other two).
I am far more interested in the progress of automating the development of programs than in the formalization of How Not to Do Stupid Things (TM). I choose languages and tools which save me time and repetition, because tedious (and mindless) repetition is a sure way to increase the probability of human error. Silly ideas of aesthetics and tradition are of no use to me.
Perhaps the new frontier of programming is not the language, but the development environment. Then again, that's really what a language is: an environment for managing the production of machine code. But environments are more than languages now, so why not exert some serious effort, and do some serious studies, of the impact of the whole environment?
--
My blog: The Bored Astronaut
Stand back. I've got a brain and I'm not afraid to use it.
There is plenty of room for OOP to evolve.
Go in the pattern direction, and add language support to make good practice easy.
C# has already started this process, by including event schemes and automatic get/setters.
Now what we need is language support to be able to remap functions from member objects.
That frees you up from having to inherit when you don't want to, and allows you to make really good
cuts of functionality cheaply.
There are so many good object structures that are just totally impractical to write, because 99% of your code would look like:
ThisObject::MethodA(all-the-params) { return mySubObject::MethodA( all-the-params ); }
If you could remap quickly and easily, we'd be in the Haranya Loka of design.
It pisses me off every time somebody comes along and thinks they can shoe-horn all possible solutions to all possible problems into a single programming style. So for everybody who's a newbie, let me impart a little wisdom to you so you don't have to learn it the hard way.
Use the right tool for the right job. Sometimes, a functional style is useful (especially when one's teaching programming language concepts and higher-order mathematics). Sometimes, procedural tools with abstract data types are useful. And sometimes, functional, procedural, and object-oriented styles can work together to solve a problem (such as the machine simulator I'm writing in Lisp).
Rant mode off.
I'm proud of my Northern Tibetian Heritage
Often, I wonder how often code is actually re-used, and adapted later on.
Both conditions will have to be met to make the big idea behing OOP work. I'm sort-of an P/R fan and programmer, and I see no reason to assume that OO as a whole has been a good thing.
Lets just get rid of it, never speak the words or acronym again, and revert to P/R programming. If someone could think up a great acronym for this process, I am convinced corporate management is quite willing to accept it.
Greenspun's Tenth Rule of Programming: "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp."
Hammers pound? I don't think so. Hammers don't do anything.
You soon learn that it should be:
Worker.UseTool(Hammer, Nail);
Then you realize that OOP is just a nice way to organize things, and that it's all just a prettier procedural anyway.
At the risk of stating the obvious, the ability to do generic programming (in the sense of working with arbitrary interfaces without needing the inheritance/OOP angle to specify that they're met) has been around for decades in many languages.
There's nothing inherently special about generic code. From a certain point of view, the very fact that generic algorithms and data structures are regarded as anything but the obvious default is just indicative of a flaw in the underlying models of languages that need templates etc.
I appreciate your enthusiasm, and generic programming is a fine idea, but if you think things like the STL and expression templates are original, you need to read up on things like functional programming, where vastly more powerful versions of the same concepts are routine. These libraries are very useful tools for languages that don't support the concepts natively, without a doubt, but magical they ain't.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
The "spaghetti" problem of multiple inheritance or of even multiple taxonomies is not really a problem in languages supporting type inference (I am sure about Haskell, perhaps OCAML as well).
I don't think OOP is a problem. In fact, OOP is a useful paradigm. The problem is that OOP should not be the only useful paradigm to be used. Type constructors, recursion, constraint programming, pattern matching, and of course type inference are other useful ones.
But what's even more important, OOP paradigm should be mixed with very dangerous paradigms, such as distructive assignment. Do you want your code being capable to change itself in an arbitrary way? No one loves buffer overflow. But why most of programmers are ok with destructive assignment? Variable value is a part of the (run-time) program code, it should not be modified - only created.
Interestingly, while mathematically educated programmers do already (how many decades) know that the future is for FP, programmers without good math background keep re-inventing the wheel involving structured programming, OOP, AOP (what next? TOP as taxonomy-oriented programming?) - all what was already existed in FP (and/or LP). How many more billions they will flush to toilet before realizing that?
Less is more !
There is a need for VB. VB is a great way to prototype a new product interface or set one up for a one shot tool. If you want the project to be truly useful however, you need to consider OOP or structured programming techniques during the design. I don't know how many times I have been handed somebody's little "VB" tool that has become indispensable to company operations, but needs "one more feature" and found out that code reuse to this person means yet another copy of the same 20 lines of code attached to every frickin object in the project. There in lies the inherent danger of VB. Anyone can learn enough to be dangerous. But when they start drowning, they call for the software guys to bail them out, and then the finger pointing begins.
"I went on a diet, swore off drinking and heavy eating. And in fourteen days, I had lost exactly two weeks. Joe E. Lewis
I'm all for a more declarative programming style where it's appropriate, but some data structures and algorithms are simply much more efficient if you change them in-place.
#include <std_iteration_vs_recursion_arguments.h>
Lots of pretentious academics who like to think they're clever because it justifies their existence will tell the journeyman programmers of the world that the tools they use suck, functional programming is technically superior, etc. But while theory is all very well if you live in an ivory tower, in the real world, we have to write the code that gets the job done.
If functional programming and such were so much better than procedural, OO, etc. in practice then the professional development industry would be using them as a matter of routine. As it stands, there are at least two very good reasons this is not the case: FP doesn't have critical mass (small installed base, small code base of libraries, limited number of programmers familiar with it) and the FP model has its own problems, which don't much show up in theory labs (hence most academics' ignorance of them, or willingness to overlook them) but bite you in seconds in the real world (hence many informed and highly mathematically educated programmers still reject FP for their work).
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.