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.