Pike's article didn't say much.
Bill Burdick shot his collections comment all to hell (and exposed Pike's ignorance).
Guys like Matt Asplin con give OO a bad name.
Too many people think they are doing OO when they're not.
The Java community now talks about POJO's. We shouldn't need a special word for something that's suppose to be a signficant part of the solution if we're using OO properly.

I would agree with this article. Even object oriented design has somewhat been changed to accomodate technical issues with web application servers, serialization, and other technical or performance issues. In pure OO theory, you would construct objects exactly as they exist. An object with attributes and methods that do everything that the object could do. To solve issues with EJB's, serialization, etc, new approaches (or design patterns) have been widely accepted as OO design. That is why quite often beans (objects) are separate from command classes (their actions). This has become so common place that it is second nature for OO designers. Many would argue that these patterns really are OO, and I would say that be re-definition, yes, but not from general theory.

I agree with Pike in principle. Why would you limit yourself into always using a circular saw, if you could have a radial arm saw too? Strict o-o languages fail to provide the additional capabilities necessary to allow the language to fit many types of problems, and that is why multi-paradigm languages/programming are increasingly popular. A language like Mozart/Oz, which provides the salient features of o-o, functional, logic, constraint, and concurrent program in a unified system, should be more productive, in my opinion, than either o-o alone or the .Net CLR approach of combining multiple, disparate languages that compile to the same byte code.

I think the author misses the point. It is one thing to be a developer and develop an application in UNIX. It is another thing altogether to be more of an architect/developer and develop an application for a customer in whatever operating system. OO is about abstraction and "good" abstraction at that, for developing commercial applications (where the environment is not necessarily known when the project starts, the team may not be mature enough etc.), good design is essential and to me OO offers "better" design than structured programming (or other programming paradigm).
Sure it is not a one-size-fits-all solution but it should be the building block.
The limitations the author said (and some agreed and improved upon) are too centered on Java. If one uses a fully OO languague such as Smalltalk for example, there are no such limitations because everything is an object (a paradigm difficult to accept for some) - Java for example has primitives, which for good or for worse, makes the languague "less" OO since now not every construct in the language is an object (yeah there are primitive wrappers - but it gets cumbersome and is not practical).

Too much of a good thing will always yield unsatisfactory results. For me, what's important is what the customer wants, regardless of languages, tools, processes, or methodologies. If the customer wants the solution only,
then I am happy to do it for him with the best language,
tools, processes, or methodology that I know that will
produce a result that is beyond his/her expectations.
But if the customer is an OO purist and is very particular about how the solution is developed and written, then so be it. All things have flaws, OO included. But in the end the customer defines a job well done.

Also, I have to agree that patterns have made OO development easier and understandable. I am still waiting to see experts of non-OO languages produce their own set of patterns that will helpful to other developers.
This may help attract OO-dogmatists to non-OO languages.

OO design seems to be a religion for some developers. I can't begin to list the number of projects that were simple to begin with and some OO perfection worshiper turned them into a "perfect" OO nightmare!!

A couple years ago I delivered a project to a client that hasn't failed once since it's rollout but a colleague (an OO worshiper) called it a kludge because I didn't strictly follow his idea of OO perfection. Yet if I had done it his way it would have consumed at least twice the system resources, taken longer to develop, *increased* the number of lines of code and would have been *less* able to deal with oddities in the data I was receiving. At the same time, his design of OO greatness on a related project for the same client failed to meet the client's requirements and his project was cancelled.

OO is like drinking alcohol... know when to say when.
There are times to use objects and time to say KISS... Keep It Simple Stupid! Anyone that obsesses about using objects for everything needs to take a step back and ask what it has gained them. Just being OO does not make a program smaller, easier to maintain or more reliable.

On the other hand, Id hate to do without it. By using an OO design for handling similar data types and by implementing a handful of optimizations ONCE instead of 20+ times I was able to cut the code size of another project by 75% and decrease system CPU usage by several orders of magnitude from the previous design.

The problem with script kiddies nowadays is that they don't have a firm grasp of fundamental programming concepts before they dive into the OO pool.

A solid structured-programming foundation is necessary to manage any software project. First and foremost, an OO designer must learn how to control the granularity and responsibilities of objects.

A typical (flawed) OO design concept goes like this:
"I want to build a castle. My castle is made of bricks. I will design a brick class such that every brick knows how to build itself into a castle." That may work for genetic algorithms like DNA, but very quickly becomes unmanageable in the real world.

I agree with Bill Hughes. I'm also glad there are also pragmatists like Pike. There have been far too many times when I've been programming in Java that I've thought to myself, "These (java library designer) guys have gone too far in coming up with a sophomoric solution that, instead of making my job easier, has needlessly complicated the issue."

regards,
Dar7yl.

All i can say is thank gof for Design Patterns and alur and gang for J2EE Design patterns.It takes OO and makes it G"OO"D :)

I spent 3 years developing an open source RAD system for J2EE (www.structuredsoft.com). What we discovered is that one limitation of object orientation -- specifically as it is learned by the typical Java developer -- is that "I need to design and write everything in terms of objects." This simply is not useful in many situations.

Consider, for example, that one cannot RUN a Java program without a main() method, which is a procedural program. What VB developers learned that made them quickly productive is that it is more important for RAD development to effectively USE objects as opposed to CREATE objects. When you don't have the objects you need, then you can create them. And object-oriented design and languages are excellent for that.

The genius of good programming, then is knowing the boundaries of design where different idioms (OOA/D/P, procedural scripting, data-oriented stored procedures, etc.) should be employed.

What's more frustrating is that Microsoft sits and laughs at the Java community as it gets its shorts in a bunch about the purity of the language. I'm glad that there are "ivory tower" philosophers and PhDs in the Java community, and I'm glad there are multi-lingual scientists of computer programming like Bill Burdick, too. But I'm also glad there are also pragmatists like Pike to help us challenge our thinking about what works when.

"If your a hammer everything looks like a nail" -- As a concientous consultant, developer, and/or manager of technology projects, we must understand the tasks and the context of the tasks we are dealing with in our technology universe. Only then can we hope to make a valid selection of tools, methodologies, and/or design approaches and hope that will be close to an elegant solution or ideal programming meta-framework.

Although I agree with the general concept that OO is one of many good tools you can use to get computing done, I have to disagree with Pike about collections and polymorphism in OO languages. His statements seem directed at strongly typed OO langs. What about CLOS (LISP), Smalltalk, Ruby, and Python?
Collections work just fine in those languages and you don't have to use any "machinations" at all to use them.