I am often making the statement that many programmers who think they are object-oriented (OO) programmers are procedural programmers using an object-oriented language. In this piece I hope to explain clearly what I mean.
For the past ten years I've been interacting with professional programmers enrolled in the Masters of Software Engineering program at Carroll University. In general these people are bright and clever at solving algorithmically-oriented problems. However, they often struggle with learning techniques in OO programming and design - particularly with the idea of assigning responsibility for actions among a collection of objects working in harmony. They have learned to solve programming problems in a procedural manner and when presented with the OO paradigm, they quickly learn the OO language but fall into patterns where they use the OO language to program procedurally. Talented procedural programmers need to expand their capabilities to meet the demands of more complex software.
There are many different interpretations of what procedural programming means. For example UncleBob Martin has stated that inverted dependencies is a sign of procedural programming(Martin, 19XX). I like this definition but I think it takes someone who already understands how to "object think" to grok it. I will continue here with more discussion of what I mean by procedural programming.
For me the first sign of a procedural programmer is the centralization of responsibility which is seen when we find objects that are doing too many things. Also, within these mega-classes are found methods that are also doing too many things and generally contain large conditional logic structures. The cognitive process used to create these types of programs indicates either ignorance of or a misunderstanding of the goals of OO programming. Or, if the goals are understood, the method for achieving these goals has never been learned. At this point the discussion could easily segue into an "objects first" debate which will be considered in some other piece. For me which side of the "objects first" debate one may take is irrelevant, it is clear that somewhere in the progammer's education, a critical step in their thinking processes has not occurred. These types of programmers are not suited for creating large enterprise software systems. These types of programmers create what are known as Big Balls of Mud.
Subscribe to:
Post Comments (Atom)
Centralization of responsibility might be by no means a bad approach.
ReplyDeleteMaking every object think for itself is great, as an OOP enthusiastic, i live in an OOP world. But it's upto the programmer/designer to mute few fundamental level objects, to improvize the overall system.
Every object thinking for for itself is the right approach and it goes recursive to the extent of atoms, protons electrons. (which is what we live in right now - Matrix), however it is a little about at what level we make objects stop recursively calling it's children's thought process.
"if" condition is all about making a system artificially intelligent. Without "if" we can work wonders, we can produce system of super stability ever possible, but then it's a little dumb a system. "if" just helps grow a brain in any object we want and helps resolve the issue at higher level if it seems to be alright, depending on the system we are designing.
If we are designing life then every object for itself to the extreme might make sense, but not all ways. One of the coolest example being each and every one of us, HUMAN. centralized. it uses interfaces/objects to get the state and then a human's sub-object are handled by a single processor. Our programmer could decided to install a mini-brain in each but he did not choose to. If he had, then a body wouldn't have stayed in one piece, in harmony. So it's about choice.
We should respect OOP and OOP has been designed to respect programmer's decision as well.