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."
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.
not to be confused with this flavor of spaghetti.
"And this is my boy, Sherman. Speak, Sherman." "Hello." "Good boy."
Please read the article before you post.
The article states:
Most of the post-OOP initiatives do not aim to supplant object-oriented programming; they seek to refine or improve or reinvigorate it. A case in point is aspect-oriented programming, or AOP.
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.
This is meaningless logic. You might as well say, "A motorcycle is worse than a car because it doesn't have four wheels." No. If it had 4 wheels, it would BE a car. A paradigm that competes with OO is not weaker just by virtue of not BEING OO.
/syle
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 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.
I believe ChaoticChaos was responding to this: ... the possible successors to OOP
;-)
This was contained in the body of the submission, which certainly would imply that the submitter hadn't read the article, either.
Neopets - the best free game on the Int
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.
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.
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.
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
As a manager at a manufacturer, I'll let you in on a little secret: This is true in all areas of business, not just IT. A good inventory manager is worth his weight in gold (and ours is quite fat...); a lousy inventory manager will drag the whole damn company down.
I have to say that, after a few years of reading Slashdot, it seems like programmers have a perpetual thirtysomething syndrome going on--the perception that our problems are somehow unique. They're not. Reread the Hacker FAQ for Managers, and every time the word "hacker", "coder", or "programmer" appears, mentally substitute "employee" and see if you don't get a general management guide that makes sense.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
I would even argue that you don't really need inheritance.
:-)
Consider a simple GUI. In this GUI you have a button, a checkbox, a label and an edit box. All of these things are widgets. Does it not make sense to use a base widget class instead of rewriting all the common related functionality they all have? Now add a radio button. It's related to a checkbox. Perhaps it also makes sense to have the checkbox and radio button share a common ancestor as well.
I can hear people say "that's what functions are for!". True, that is what they are for. But if a function is only useful for a widget related structure, doesn't it make sense to encapsulate that function with that structure?
No, you don't need inheritance. But sometimes it's damned useful.
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
So have I. But no one here is arguing that OOP is the only appropriate paradigm for all problem domains.
In the past I have made some comments on what I think plain old C could become if it incorporated some modulization features.
Be careful with this. If you don't watch yourself it could end up becoming Objective C
A Government Is a Body of People, Usually Notably Ungoverned