At 10:26 AM -0500 1/19/10, Bob McConnell wrote:
Some problems will fit into it, some don't.

I teach OOP thinking at the local college and haven't run into a problem that doesn't fit. For example, in my last class I had a woman who wanted to pick out a blue dress for her upcoming wedding anniversary. The class worked out the problem with a OOP solution.


Some people can look at problems and see objects and some can't.

That's for certain -- but in time just about everyone can understand the basic concepts of OOP.


But in most cases, it is not easy to take an
existing procedural program and re-map it into objects. It would be
easier to start over from the specification and write it from scratch in
the object model.

I agree with that because part of OOP is understanding/defining the problem through an object oriented perspective -- it's a paradigm shift in thinking.

However, a programmer who is good in procedural also understands problem solving. OOP and Procedural are just two different approaches and each brings it's own set of tools/problems to the table.


If you have been doing procedural programming, don't worry if you don't
figure it out right away. It is not an easy transition to make. Many of
us with decades of programming behind us will never be able to make that
switch. Our brains are too tightly locked into the previous thought

Bob McConnell

While I teach OOP, I don't write any OOP for clients. My charge is to do things quickly and OOP requires a considerable amount of analysis before creating a solution. In most cases, I don't have the time. Besides, I'm more of an agile programmer and that doesn't lend itself well to OOP, IMO.

Also IMO, one can argue the advantages that OOP and Design Patterns bring to the table over procedural, but after all is said and done, if you know your stuff in procedural, OOP is not going to provide you with much that you don't already have.




PHP General Mailing List (
To unsubscribe, visit:

Reply via email to