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.
...checking your code more than usual? When I read the PR on this, that's all I got from it. The guy went to great lengths to make something that was common sense practice sound like some new idea.
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."
If it's on the internet, it must be true. And, now, it's on the internet!
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
I had a class in which we had to design via Extreme Programming (XP).
The essential idea, was to create your program by outlining a bunch of modular components, and create tests for those components. Then you would program the various components (features) one by one, and after you program one, you test it until it passes all the tests that you required of it. Once that's done, you go on and build the next set of features, repeating the process of test and pass, each time you add new code. What's cool, is that you can add features as your resources permit later on in the project.
The MAJOR advantage of XP is that the cost of changing your program becomes constant after a while, unlike traditional programming where the cost of change becomes exponential!! That's really cool!!!
...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.
With tests thrown in?
What about run time efficiency? Wouldn't 100% modular code result in inefficient CPU usage?
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.
A few years back I did an undergrad thesis on what I liked to call "Framework-Oriented Programming." It tried to distinguish that as distinctly different from (and better than!) OOP, though these days what the OOP people are doing is not as distinguishible as it was back then. (It was written when C++ was still dominant, not Java.) Nonetheless, it is still possible to build non-OO frameworks using the definition in that paper in languages like C. Though I don't really know why anyone would want to, heh heh. HTML available here, though be warned: it was unfortunately created using "Save as HTML" in evil MS Word so may look funky in some browsers. Certainly not a perfect paper, but perhaps some may find it an interesting approach. If it perhaps is not worthy of the name "paradigm" or is seen as an offshoot of OOP rather than a replacement paradigm, it nonetheless is now a fairly prominent approach in the OOP crowd these days.
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!!!!
Shell scripts and .bat files are the wave of the future. . .
You are not the customer.
The future will be in declarative languages such as haskell or prolog.
The "flow chart model" of computing is and will always be error prone.
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.
Cómo podían el aspecto, el patrón, y la programación extrema substituir OOP? Eso es absurdo. La programación del aspecto no tiene herencia (esa yo está enterada de) así que es un modelo más débil que OO. Aunque "... herencia excesiva de la composición del favor ", él no significamos debemos eliminarlo! También, dónde el comportamiento polimórfico del método del aspecto? Los basar de la fundación del diseño del patrón en OO. quitan OO y el patrón no puede existir. La programación extrema no tiene nada hacer con cualquiera del antedicho. No es uniforme una arquitectura. Vive bajo noción equivocada que puesto que el equipo-ana'lisis trabaja bien, equipo-programando debe trabajar bien también; -)
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....
With tests thrown in?
Yes. That's a big part of the XP rules. This was a heavily graded principle in my class. XP says that you don't move past the new features that you have added until they past the tests. This ensures that they work right, and that you don't have to come back to them later on.
What about run time efficiency? Wouldn't 100% modular code result in inefficient CPU usage?
No modular in the sense you're thinking. What I mean't in the parent to your post was: modular in the sense that you program in "chunks". These chunks are integrated features into the program. Take for example, you want to program a simple little thing to read in numbers, compute them, and then display them.
Well, first you would program the interface to read in numbers. You'd test that, and be sure it worked (past the tests) before you moved on, say, a readInValues(); kinda function.
Then you would go to the next feature, computing the numbers, where computeNums() went something like A + B + C / D = answer. You'd test that, and make sure it passes before you leave this.
Then you want to print them out, so you write and test printResults().
That's what I mean by programming modularly, sorry for the misunderstanding. Actually, the individual modules, or steps could be a combination of several functions/features, or other stuff. Like a mod step to revise a current implementation you have already made if needed. You see, it isn't modular in the sense that you were thinking, but more like basic object oriented programming structure. Should you need to add features as you go, or later, the cost of change isn't that much, naturally.
interface inheritance (bad) vs. implementation inheritance.(good)
This is, of course addressed by both the Bridge and Strategy patterns.
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.
Maybe ./ should have a feature like creating a snapshot of a website.
./ servers !!
When posting some new thing you should first link to the snapshot and _then_ link to the real site.
This would (maybe) push some of the load to the
Did anyone else notice that an article about pOOP mentioned a conference named PLoP? Is Beavis coming up with these names or something?
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
... we programmers are logicians.
No good language or paradigm is going to limit logic so that it cannot be complex, or by extension over complex.
To wish otherwise is to hope for a fire that cannot burn. You can protect yourself from burns, but having a type of fire that does not burn is not the way, you give up it's main benefit.
So with logical systems, to prohibit spaghetti is also to prohibit the use of logic, as such, itself.
Hey... guys... stop hoping for magic and just STOP SHOOTING YOURSELF IN THE FOOT... it's not the gun's fault.
-pyrrho
suddenly everything looks like a nail.
This sums up the behaviour of most OO newbies.
My dog++ sucks too!
Ok, look at how Mozilla's Bugzilla usually handles the /. effect (eg. a separate page for /. referals). Setup a simple static page giving people permission to mirror when refered from a /. page. Maybe even have a static copy of your site available as a .torrent and encourage people to use that and start the mirroring process.
True it would be nice if the editors gave these sites some warning, but maybe the webmasters should make some preparations ahead of time.
Overrated / Underrated : Moderation
where the hell does XP come in to this?
.. because
what crack monkey thought up XP anyway?
christ. why are idiots successful?
other idiots pay them.
hammer.pound( static_cast(screw));
-pyrrho
oops, should have previewed... should have been...
hammer.pound( static_cast< Nail >(screw)) ;
-pyrrho
A real summary of the article: a behind-the-times coder reads up on the current industry literature, and announces: "Gee, you guys really think hard about this stuff, don't you? That programming stuff sure is confusing! After a cuple weeks of reading, I'm really confused, therefore it must be over-complicated and redundant. Okay, I'm gonna go back to making clay pots now."
--
CPAN rules. - Guido van Rossum
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.
First you're making the grand assumption that the ideal of OOP has been accomplished. It hasn't. Go re-read what Alan Kay has to say on the subject.
If you think C++/Java are the "pinnacle" of OOP then you're sadly mistaken.
Therefore I can't help but look at the programming aspect of Extreme Programming and just say, "Oh, now here's a winner! I wonder if I have to wear cool jeans and say officially hip nonsense for this to work?"
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
Yes, OOP is about to be not replaced, but seriously eclipsed. It will become just another tool in a (good) programmer's bag. A quiet revolution is happening as we speak (write), and it will rock the software world.
Sadly, the article is completely missing it: I am talking about Generic Programming and templates.
The constructs possible using it are truly staggering. It is changing the way we THINK about our programs. And the tools it is producing are breath-taking.
Developers who used Loki, Boost, STL or WTL know what I am talking about. Read the Andrei Alexandrescu's book and prepare to be amazed.
Sadly, Java will miss it entirely as well. No, the added support for generics in 1.5 does NOT count. It can't hold a candle to CPP's templates and it too much of an aftertought.
But it's not for everybody. Not all developers are ready for the revolution. The one-language code monkeys for example, will be left behind (they're the guys with the "Java/C++/C rocks! and everything else sux"). Also the scripters (aka sysadmins) won't care: they are not even the target audience.
But the real programmers, the ones of us who see the language as a tool for the task at hand, not a religion, are ready.
Viva la revolucion!
Most of the programmers I end up working behind can't even master OOP. Ever see 10000 lines of code in a main method?
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
Sheesh, what a dull article. First, it goes over the history of programming languages yet again, and then lists a few methodologies and ideas that everyone's already heard of.
There's no revolution here, folks. Move along.
In the '70s, example programs tend to have a sausage-grinder structure: Inputs enter at one end, and outputs emerge at the other. Programs written in this style have not disappeared, but they are no longer the center of attention.
This idea that modern programing is not about input one one side and output on the other is probably why it is still near impossible to write programs without bugs.
The last real revolution in programming was not OOP but programs like Visual Basic which let people design interfaces without a single line of code.
The next real revolution will be when code will be used only to create small modules which focus on ONE thing (following the model : input on one side and output on the other) and when the "linking" of these modules will be done with a CAD-like GUI.
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.
I recall seeing a very flame filled debate recently in which people argued vehemently that languages such as Java do not every NEED the ability to manipulate memory. What I didn't understand was why it always seems to be extremes that are practiced. "Why should I always have to bother with pointers?" is just as good a question as "Why should I be restricted from every tweaking the memory usage?" I think that eventually a paradigm will be implemented that better portrays the human method of communication, representation of the abstract and humans' use of patterns in general.
I do think it is silly when people use bad design and bad programming then blame the language. However, I think there should be an easier method to quickly represent contructs, logic and flow of data that can when needed be easily drilled down to accomidate whatever level of detail or granularity I require. Sure you can do a bit of that if you use scripting languages, but at what cost to speed? Hmm, so it is optimization you are after then? A good compiler should be able to take a very high level language and well... compile it and create static compile time code of those things you have flagged as being able to be statically optimized and linked (or that you did not flag to be optimized).
I think behind the actual language, behind the actual official paradigm is a problem of methodology that needs to be addressed. Just like a business that is growing fast, there needs to be a good set of processes in place so that the confusion of new hires is lessened and you are more productive. However, there is no official process of any type of business. You have to adapt and you have to adapt your process, this in of itself requires a methodology that most MBA's lack. Sure they know the literature and phrases inside and out but the underlying spirit is not present.
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).
Maybe the focus on new development techniques (patterns, xp) rather than new languages is because entrenched programming languages are not going to be discarded any more?
.NET, It would of struggled without them.
I can't see people suddenly stopping programming in C, C++, or Java. A new language to gain widespread acceptance needs a huge library or backwards compatibility. Microsoft provided the libraries for
So maybe the focus over time is going to be in things like AOP, XP and Patterns which don't replace the current languages, but make programmers more efficient and allow them to deal with the continually increasing complexity of these systems.
Then again maybe the next big jump was web services. They make the programming language an implementation detail.
"strong typing as a fundamental mechanism for OO" Strong typing (compilation time type checking) exists in C/C++ Java,... but has nothing to do with OO as such. The first 'real' OO language (Smalltalk) has runtime type checking. No casting, no template/generics mechanisms necessary. Takes a lot of overhead out of programming... Not really new. Still, I agree with your conclusion about strong typing.
If you want to see what the future of real world programming looks like, like no further than Boost. I say this because Boost demonstrates the programming techniques of the future that work on compilers available now. In theory, Boost techniques work on any standards compliant C++ compiler. Given that most compilers these days are still pretty weak on their standards compliance, the friendly Boosters have already coded a great number of work arounds so you can still use the libraries.
Something that you might find surprising, though, is that the future is the past. Sort of. The future is shaping up to be a synthesis of great ideas from the past. Functional programming and metaprogramming are making a resurgence, except this time in moderation. You see, in the melting pot that is C++, you're not forced into any particular paradigm, and you get to use what works best for each subproblem. The real beauty, though, is that only library writers really need to be experts in this multi-paradigm thing; application writers can go about their merry business relatively unaffected, except with libraries so powerful you can't understand until you've tried them.
For a sample of libraries to really blow your mind, check out
1) Boost Lambda Library, which adds lambda function capabilities to C++. This is a staggering because C++ doesn't have lambda functions (like Lisp does).
2) Spirit Parser Framework lets you write parsers in a natural EBNF type notation, without the need to run a seperate pre-processing tool like Lex/Yacc (Flex/Bison).
3) Meta Programming Library. This ones a little tougher to wrap your head around if you've never tried writing generically reusable libraries. This is a library designed for other library writers, so #1 and #2 above make extensive use of this.
4) Preprocessor Library. This is a library to help you do meta programming with the C/C++ preprocessor. See, not all inovation is coming from those new fangled template things. You'll just have to look at the examples to get why it's cool.
The best part is that, unlike Perl 6, you can use this stuff now. Play around with, see how it works. You will be stunned, amazed, awed, etc by what these people have done. And you don't have to "get it" to use it.
Woohoo... and I thought that four years ago when I was instructed to use lexx and yacc that I was using antiquated technology. But the whole time using it I kept hearing my professor from ten years back saying "someday you will need to know this."
come on fhqwhgads
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?
The word I see there is "generative", which I interpreted to be something quite different from the generics and templates discussions that happen with C/C++ and soon Java.
-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.
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.
The problem of multiple inheritance he mentiones to justify the use of Aspect Programming is solved by interfaces in Java. That does imho not need a new software design but a good design of an OOP language.
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.
The nice thing about a new paradigm is that you know it will be obsoleted by the next one before it has to prove its worth.
Engineering is the art of compromise.
This is SO true. I believe that the majority of languages out there today are being designed by morons, for morons. Anyone who is too lazy to learn a new programming paradigm from the roots up is too lazy to program well.
That is all.
And your comment that OOP problems are the same everywhere and mostly people oriented is also addressed in the part of the article about 'pattern programmers':
Your comments that compilers should complain about magic numbers sounds good, as well as the "don't take others' toys" comment (myFoo.getList().calculateMarbleSize().insertInto
Your next sentence mentions tools though, and at least in Java, there are tools to detect those for the meantime,
PMD looks like a good one.
I've had some success with using tools like these and some peer review, which is mostly peers running the tool on the whole codebase and saying, "Why is this like this" when you write something that breaks it.
-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.
""" ... This leads to situations where you've got horribly bloated code that runs slow as hell.
However most OOP programmers try to over-OO everything.
"""
Note that you're much more likely to avoid this problem if you're required to have somebody who's bored out of their skull sitting beside you nagging you to get back to programming the actual features so you can both go home.
That's how I've seen pair-programming work -- you're either doing something interesting or you're trying to come up with something interesting to avoid doing something that's too dang boring (rather than just plowing through and being miserable with your job) because the person who's not on the keyboard has to be entertained as well.
Heck, I'd be gladly pair-program with a Business Analyst (because I've got l33t communicaiton skillz) if my company could afford to get somebody local and focused on features. "Here's the proof for feature XYZ, based on your F-Spec. Now we're implementing feature XYZ. Here's steps 1 and 2 and 3. Good? Done, Check. Moving on."
Wish wish wish wish wish.
what are the benifits over OOP?
is it like building a a room rather than building a thing? if so, why not build a room and fill it with things? so you get aspect object oriented programming.
the two seem complimentary to me.
I am the Alpha and the Omega-3
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.
There's a good and quick article, written by Paul Graham on why his new 100 year language isn't obect-oriented. I think those LISP designers were on to something...
ain't it all objective anyway? or should i use the word relative to be more precise? :)
Lord of the Binges.
Why would the article mention generic programming? For one thing, generic programming has been around since the stone age of computing. (Think LISP.) It's definitely not post-OOP. The fact that Java and C++ are just now adding it is just an artifact of the way Java and C++ are engineered to run.
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
Somebody should do something, but is it Slashdot's fault that the model on which the web is built is fundamentally bad at this kind of thing?
Mirrors of web sites are a giant, gross hack. There is a namespace of documents, and suddenly I'm supposed to think of a document as existing in another part of the namespace just because of some vagaries of how heavily loaded some server happens to be right now? That's the kind of thing that indicates that a software system really isn't doing everything it could / should to make humans' lives easier.
In the commercial world, theoretically sound languages will become popular if and when the tools, user base and code base reach critical mass. These are the things that make the best practical tools of today (Java, C++, VB, etc.) popular, in spite of their well-known flaws.
I have high hopes for programming by specification, as in functional languages and such, but they, too, have their flaws. In particular, while they're dead neat for modelling calculations that just need to give you the right answer by whatever means necessary, they suck for modelling the concept of interaction with the outside world because they have problems repesenting the flow of time. Unfortunately, the benefits and problems are inherently tied together in a specification approach; the very things that give one also give the other.
What's needed, and my take on the next big thing in programming, is a language (textual or otherwise) that can represent both the flow of time to deal with interactions and pure specifications of the calculations and data manipulation to be done as a result, preferably with both being conceptually independent of the underlying machine. For example, I'd like things like threading and synchronisation to be mostly implicit, and I/O to be defined in terms of sequences of interactions and how they relate, much as in a specification language you can write a complex mathematical expression and only care that you get the right answer, without knowing where the calculation was performed, whether it used multiple threads/processors, etc. Of course, there will always be a certain need to understand the underlying model, just as when doing floating point maths you have to understand basic numerical analysis to avoid nasty surprises.
Some languages are heading in this direction already, but I don't know of any that's close to my ideal goal. When one comes along that reaches a critical mass of interest, the industry will start to change, slowly but surely, to adopt the theoretically superior approach. I'm not sure that language actually exists yet, though, nor what might act as the catalyst to get it to critical mass -- maybe the power of the Internet and enough geeks in senior developer positions taking a liking to the idea when it comes along?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.
So often people assume everyone knows every acronym, and those of us who browse this site to learn about stuff often feel left out. So thanks for defining POOP!
O~ Him that studies revenge keeps his own wounds green. -- Francis Bacon
The article's title indicates that there would be a successor the the OOP paradigm. I read through all the boring stuff that even a beginning programmer knows about hoping to finally be presented with what the successor paradigm to OOP could be. But the article ended before addressing the topic mentioned in it's headline.
What a waste of time.
This is the most intelligent thing I've read all week. Well said.
Revolution = Evolution
If all the various classes of objects that have a rotate method need to send a message to the update display method, why can't the inheritance mechanism provide for that by having an inherited rotate method that, instead of being replaced by a rotate method included in the inheriting class, just invoke them both? What would be needed is a special primitive to be used in the superior rotate method that indicates where the inferior rotate method is applied. Suppose that mechanism is an "inferior" statement. The superior rotate method might be as small as having code to first do "inferior" followed by "update display" and that's all. This would be more mechanical than AOP promises, but at least it would avoid having the display updated before the rotation.
now we need to go OSS in diesel cars
I think the author makes a good point that different programming paradigms are suited to particular problem domains. I think it is not well understood when different models are the most suitable, and even when we do it is too hard to mix paradigms within the same program, or the language of choice doesn't support the best option.
Modelling a GUI interface is done very naturally with OOP because is easy to isolate separate independent components, but OOPs seem less well suited to problems involving relationships across many types of data where structured, relational or functional paradigms are more suited. (I think the average database backed website is a good example - or a mathemetical engineering application)
Perhaps in the future programmers will better understand better which mixtures of paradigms to use and languages will allow this better. Progress will probably also be made in bridging the gulf between programming models so they may be more easily used together. An example of this is EJB-QL (part of the EJB 2.1 spec), a relational-like query language that works on top of EJB objects.
Just let programmers program! The recommended protocol is to work in pairs, two programmers huddling over a single keyboard, checking their own work as they go along. Is it a fad? A cult?
.. ;)
When I read this I can stop to laugth when I see my Boss, who propose Extreme Programming and he hate gay
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."
Declarative languages do not display these flaws and for that reason will eventually dominate. Although declarative languages are somewhat more difficult to learn, programs written in such languages are much more amenable to change than are other programming languages. They are also highly expressive, requiring a minimum of code to perform a task.
SQL and other relational database languages are a very limited subset of declarative languages, yet relational databases dominate the database niche and far outnumber object-oriented databases.
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.
In your effort to be pendantic, you have picked apart an example while missing the point entirely!
Good for you, cause you might have had to think about there point otherwise.
The Kruger Dunning explains most post on
" I told my manager in a design meeting that we should do all new development using SHIT techniques and SHIT tools and SHIT constructs. Now I'm unemployed like the rest of you."
The Kruger Dunning explains most post on
Man, you got totally ownx0red by that PD guy. I recommend you go cut off your dick immediately and bury it in the backyard. On second thought, cut off your dick and mail it to PD, so he can put it on his wall like a trophy. YOU HAVE FAILED IT.
and inside Worker...
void Worker::UseTool(Hammer ham, Nail nail)
{
ham.pound(nail);
}
assuming you have an assortment of tools and nails, surely you don't want all the tool and part logic in the Worker itself... whats the point of that?
We don't want to simulate the real world, we are abstracting the logic needed to implement an algorithm.
-pyrrho
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.
>> you don't want all the tool and part logic in the Worker...
Uh... We don't?
>> We don't want to simulate the real world
On the contrary, that is precisely what OOP is trying to do.
Besides, my example is not bases on the assumption that OOP models the real world. It's based on experience. Hammer.Pound() becomes restrictive and hard to maintain. As it turns out, the real world approach is just better.
So why does Hammer.Pound() make more sense than Nail.GetPounded()? Or Board.GetNailed()? None of them make sense, yet that's what OOP classes teach.
Generic programming has the right approach, such as the STL. You don't List.Sort(), you Sort(List). If you want pure OOP, Perhaps it would be better to have an Organizer class, and do Organizer::Sort(List) (you'd have to do that in Java or C#). It becomes more obvious when like objects have to interact. Which object does the work? How do you decide? You don't! You create another class to do the work: Copier::Append(List1.Begin(), List1.End(), List2), or even Comparer::CompareNoCase(String1, String2). This helps eliminate the SwissArmyKnife approach (like a string class that knows how to write itself to a socket or grep itself). It keeps things simple, modular, and flexible.
I think what this shows is that the procedural approach is just as valid as it ever was, and that it sure is nicer to work with once we have OOP to help us organize things logically.
Any "enteprise" programmer has dealt with SQL, so we've all done declarative programming. But mixing SQL with procedural code highlights the impedance mismatch between objects and database tables.
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 !
Explain. I think he hit the nail on the head.
Mozart-Oz is an example of a language that goes way beyond a simple OO paradign(and incorporates features of Functional, Logic and Constraint programming. The thing that most language designers (including the Mozart-Oz folks) miss is that much of business programming is built around _relational_ semantics(i.e. the basis of SQL).
I think languages are not everything in order to reduce complexity and make things run smoothly.
For example, a process in which even a trivial thing takes a week or two at best to approve and in which iterations take a very short time is broken. This is because if you get stuck in the approval part and it takes longer than the iteration, it means that component and all components which depend on it will be delayed.
That kind of model is just a big bad waterfall in disguise even if it's aiming to be an evolutionary process.
Sometimes you need to use the best tool for the job at hand, and strangely enough, VB is sometimes that tool.
No, I'm not a VB programmer. But I understand the need for VB programmers.
Not all projects need C++ or Java's overhead. The overhead being the need for a C++ or Java programmer when all you need is a part time programmer, someone who does other tasks, but knows a little VB.
I like to think of VB as the glue that ties more complex apps together for a custom job.
Mother of all OOP criticism websites. This author lives to bash OO up down and all around.
The weaknesses that led to the decline of CODASYL network databases and the rise of relational technology are glaringly apparent in OOP: lack of a adequate mathematical model...
These webpages describes the lack of "math" in a bit more detail:
http://www.geocities.com/tablizer/core1.htm
http://www.c2.com/cgi/wiki?OoLacksMathArgument
Table-ized A.I.
Spot-on, archeopterix!
The Bronze Age didn't replace the Iron Age; iron was still used.
The Information Age didn't replace the Industrial Age/Atomic Age/Space Age; the things that named those ages are still used.
A newer age and newer technologies build on and/or encompass the old.
Parts of the older technologies are abandoned or relegated to the "little-used" catagory as they become obsolete (animal-driven wooden plows, self-modifying code, slide rules), but many other things remain (planting in rows, satellites, nuclear power plants, mostly sequential program execution, octal/hexidecimal notation).
Similarly, the post-OO world will probably encompass OO and use many aspects of it.
So the useful concepts of OO will not "go away", any more than have the useful concepts of structured programming, assembly-language programming, or even machine-language programming, when something new came along.
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
I'm glad someone said this :)
m e(HAMMER_WORKER_NAME)); // // //
Unfortunately real-world practice is usually quite diffenent, even when correctly modeled:
final HAMMER_WORKER_NAME = "worker.hammer";
try {
Worker w = Worker.getInstance(Messages.getInstance().getByNa
Hammer h = Hammer.getFromPool();
Nail n = NailStore.getInstance().createNail();
h.setNail(n);
w.setHammer(h);
Thread t = new Thread(w);
t.start();
} catch (WorkerException e) {
} catch (HammerException e) {
} catch (NailException e) {
}
Sad but true.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
What we really need is a separation of concerns. A combination of declarative languages (possibly visual as well) and language for specifying how to implement the declared functionality. This should be a language like the imperative languages we use now to implement programs, but a transformation language.
We do declarative language for each aspect of an application, not only restricted to the data model, but also including the Model/View/Command and the user-interface.
Meta programming!!! it is the future(!!!). The main functionality of a computer is to run an algorithm over some data in order to compute some results needed. So, what is the next step in programming ? My opinion is that it should be meta-programming. That is, separation of algorithm coding and of the implementation details.
Today's programmers have a hard task to perform: they must think about the algorithm along with memory management, types, the side effects and they must remember the APIs in 100% detail, even to the smallest flag which can make or break their application. Wouldn't it be more efficient if a programmer could concetrate on the algorithm only, and then apply the implementation details ? I know I would be much more productive. In other words, programming should become more abstract than it is right now. Of course, this should be complementary to the current available techniques.
On the other hand, some algorithms depend on the implementation details. That's a problem for the language designers to solve though.
C++ templates are quite close to this, but they are quite complicated. ML and Haskel have some similar functionality.
There are two language groups that cover what you want, and have been around since at least the early seventies; you should look at Lucid and its derivatives (GLu and Lustre being the most interesting), and derivatives of CSP such as newsqueak and limbo
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....
Do you have a specific semi-realistic example? Most examples and claims I have seen of OO making software easier to change make some rather odd assumptions about the likelyhood of certain changes occuring. I don't know whether the change scenarios suggested are purposely rigged or the author has been warped by too many unrealistic textbook shape, animal, and device driver examples.
Table-ized A.I.
Yo man ... feel the algo-rythm!
Pathman, Free (as in GPL) 3D Pac Man
Yes, that's right... I was confused back there.
As in Common Lisp CLOS, the most powerful OO system on earth.
Don't mistake C++ or Java for OO - they lack the dynamism originally envisaged as part of OO, and are crippled by single-dispatch, poor typing systems, and in Java, single-inheritance.
Java-OO + "component-based programming" (e.g. JavaBeans or C++&Qt) == what was originally though of as OO in Smalltalk and Lisp.
Paradoxically, of course, Lisp is so powerful anyway you seldom have to bother with the OO constructs.
Are we descending into Taoism here, or is it just me?
OO is about encapsulation and modularisation, you should never write code that isn't encapsualted or modular(well maybe extream protoryping) other wise I will call you monkey boy.
If you want to write buggy, hard to maintain, poorly designed code then sure, ignore OO.
e.g.
piss poor code
myfunction (larlar){
static int imAFool;
}
better code
struct thisisanobject{
int imnotafool;
}
myfunction (thisisanobject* , larlar){
}
hey, and the better code has no threading problems.
thank God the internet isn't a human right.
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.
An interesting approach that should be investigated is concurrency oriented programming.
More details here: http://ll2.ai.mit.edu/talks/armstrong.pdf
Joe Armstrong explains in the conference why and how it can overcome conceptions problems when designing concurrent applications.
--
Mickaël Rémond
http://www.erlang-projects.org/
Since when is a pentagram (five-star) a pentagon (five sides)?
I count 10 distinct sides on the pentagon... does anyone else?
Fuzzy membership seems to be a component that could be expanded upon and refined to help solve this problem. BTW, this problem happens all the time not just in software but I am sure everyone here knows of that. Fuzzy sets can be a bitch unless you setup either heavy restrictions (ouch) or setup a very robust system of processes and procedures that can be adopted and they themselves be combined, inherited and abstracted. Otherwise you get such a wide variety of classifications and categories that you might as well have never even used any paradigm. Seems to me we should focus on the meta aspects of the paradigms, methods, processes and encapsulations (categorization and classification). Instead of saying, "Hmmm, OOP has some flaws... lets just start all over with something incompatable" you should treat it as EVOLUTIONARY.
OOP should NOT be used to model the real world - that's an easy path to an overly complicated model. In this case, we're deciding that the hammer class is where (most of) the work gets implemented, and then we define things in terms of that hammer. We could have decided to implement everything in terms of the nail instead, and that might make sense for some problems.
There are many programming paradigms and all have their own reason and justification. There are functional, declarative, logical, object-oriented and generative techniques. Some programming languages incorporate more than one of them. All these paradigms serve a certain purpose and object-orientiation
Modelling however is a different beast. There is only one truly natural way of modelling and it is object-oriented. Is is simply due to the fact, that we think of the world as consisting of objects having properties, behavior and eventually state.
So, object-orientiation, as we know it today, will eventually replaced, or more probably enhanced, by something different, but not modelling.
Give us another decade or so, and we'll grow up.
I might be a bit more inclined to believe the article if the example given wasn't one of the standard OOP pitfalls -- implementing object properties using inheritance.
OO is stuck between a rock and a hard-place. Inheritance is what makes OO unique and "intuitive" to some people. If you don't use inheritance for domain modeling, then you are essentially creating a "network database" sort of thing, and these were discredited in the 70's.
Thus, you either have disco or trees.
Note that for communication and infrastructure components, I don't have a real problem with OO. It is when it tries model domains that OO has failed. Thus, OO works well for GUI API's, FTP API's, etc., but used to model the entities and behavior of the particular organization at hand, OO has some really unpleasent flaws.
Perhaps under *ideal* conditions, OO is wonderful. However, many "average" programmers seem to get OO really wrong. Should paradigms be chosen for what the best programmers do with it or what the average programmer does with it?
OO might be like trying to use quantum mechanics and relativity when plain ol Newtonian physics might be more appropriate. Teach them Newton well instead of quantum poorly.
When I read about these attempts to come up with the perfect language to handle variations of pentagons, it reminds me of the classic 'Bert and Ernie' skit where Bert assigns Ernie the task of cleaning a pile of toys in their apartment.
After Bert's departure, Ernie decides he must first come up with a taxonomy system - first, he'll pick up the red things. Hmmm, the only red toy is a fire truck. So he puts it down. Ok, pick up the toys with wheels. Same result - only a fire truck. What about the toys with ladders? Still one toy, a fire truck.
By this time Bert, enraged, returns to find that Ernie has accomplished nothing. We can learn many things from this, but mainly...
Getting the job done is what counts, not how cleanly you do it. Devise mechanisms when it really helps get the job done, else risk making the mechanism a job in and of itself.
--matt
Does it hurt to hear them lying? Was this the only world you had?
>> you don't want all the tool and part logic in the Worker...
:)
>Uh... We don't?
yeah, we don't. For example, one time I was working on an online-role playing game. If we added a new item to the world, we just want to download the logic and art for that new item. We want to download a hammer and a nail... not new player code. The player of course has something akin to player::UseObject(Article, Article), but the logic to execute the interaction is in the hammer and/or nail classes where it belongs. All the player knows is that it's useable, and that useing something potentially includes a target (what it's used on). The logic in the player, or worker, is minimal.
>> We don't want to simulate the real world
>On the contrary, that is precisely what OOP is trying to do.
no. OOP is fundamentally the encapsulation of structures of data with the functions that work on that data. How you model things is up to you.
I know a lot of people get into "noun and verb" nonsense (total nonsense!) and into simulating real things, as if a Window is an abstraction of a Window. However, that's just their mistake.
Programs are machines made of logic. Objects are logical entities, they should abstract logical relationships, not real things, they should not directly model their metaphor! Objects model various kinds of coupling (from rigid to loose), various types of structuring data, etc.
Of course this is just my humble opinion (which happens to be right in this case).
PS: btw, I LOVE the STL approach... and I don't think there is anything that violates OOP, although it uses some paradigms outside the OOP paradigm, that IS C++ OOP... multiparadigmed OOP. Of course I know this is an OOP defined a little differently than an "OOP purists" would. But the purists can get back to me when they agree among themselves on some defintions, any definition of just about anything. Purists are notorious for never quite deciding the nature of the Pure... oh yeah, because there is no purity, just engineering.
-pyrrho
> You don't List.Sort(), you Sort(List).
Actually, if you're using the standard library's linked list class (std::list), you do use the List.Sort() form...
nested blockquotes?
Liberty uber alles.
Modelling however is a different beast. There is only one truly natural way of modelling and it is object-oriented. Is is simply due to the fact, that we think of the world as consisting of objects having properties, behavior and eventually state.
You are so full of shit. Stop dictating to me how to "think naturally".