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
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.
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.
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
An inscrutable, unmaintainable, architecturally weak procedural design that saves 100 lines of code is *NEVER* preferable to a strong OOP design. I would gather you have never seen what good OOP looks like and have only been exposed to garbage like MFC or worked with poorly written Java code. Good OOP design has a negligble effect on performance and memory usage (note: MFC is not a good OOP design). If you really have something process intensive, like a 3d rendering engine with lots of inline code or even assembly code, those algorithms can still be encapsulated within an OO framework without harming anything.
Most people with your opinion are those who write crappy procedural code that never has to be maintained by anyone else (including yourself, 2 years later), and have no clue whatsoever on how to do OOP, and their early attempts (as well as the attempts of their coworkers) worked like crap. Nothing wrong with that, but its annoying when someone ignorant attempts to speak authoritatively.
The truth is of course that crap programmers will write crap programs in any language, while good programmers will do a good job no matter what tools he has available. In the end it always comes down to people.
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?
I have to disagree. It's unlikely that a programmer who can write good test won't write good code. TDD isn't about traditional testing. Its about expressing design through testing. In that environment, if you are writing good tests it means that you have correctly and completely expressed the design in a way that can be automatically validated. Also, implementation of the tests depends on virtually all the skills required to write good code. If you can write good tests for TDD, then you can also write good code.
All of the skills for writing good tests and writing good code are gained through experience. TDD is not a substitute for experience, it is a method for exploiting experience.
Every development methodology has a tendency to get stuck at a local optimum.
There are techniques in evolutionary computation to get out of a local optimum (adaptive mutation rates, forking, migration, restarts,
XP provides a low risk way to do the same. Sweeping design changes that would ordinarily force a project manager to mainline prozac can be handled with very little risk. I've seen it done... I've done it myself.
exactly, the problem isn't unique. Just people with Phd's think some stupid concept will solve a human problem.
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."
There is a language which allows for this kind of "access qualifier". It's called Eiffel. In the classic example, only the TELLER and BANK classes have access to the balance feature of the ACCOUNT class.
:= stash + acc.balance
class ACCOUNT
feature { TELLER }
balance: INTEGER
end
-- this causes problems:
class ROBBER
feature
stash: INTEGER
do_something(acc: ACCOUNT) is
do
stash
end
end
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.