Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

If you read Working Effectively with Legacy Code, Clean Code, Refactoring: Improving the Design of Existing Code and Design Patterns you will get what I mean.

Many of the examples and topics discussed in these books aim at improved the quality and design of the code. It is my observation that most of the problems mentioned in these books revolve around turning a procedural or semi procedural code to a well structured object oriented code.

Think God objects, long switch cases, hard coded dependencies,..etc.

What actually drove me to ask such question is that I often hear people talking about functional programming and that it good to learn such languages even if you are doing object oriented programming as it affects your mindset and perspective of the code.

So to keep the topic constructive, focused and objective as much as possible:

  1. Is there any studies or evidence that learning procedural programming before object oriented programming leads to the infamous object oriented anti patterns?
  2. Does the same problem occur when learning OOP after FP?
  3. Is there a proper/proven way to approach OOP in general to avoid most of its pitfalls?
share|improve this question

closed as primarily opinion-based by gnat, JeffO, Bart van Ingen Schenau, gbjbaanb, MichaelT Feb 25 at 15:04

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

2  
Related: codinghorror.com/blog/2005/04/… –  Doc Brown Feb 25 at 12:39
1  
I think this is related to #3 - programmers.stackexchange.com/questions/216450/… –  JeffO Feb 25 at 13:08

3 Answers 3

Well, I don't have any "studies" or "evidence" at hand, but I am pretty sure most of the problems with bad code don't arise because programmers "have learned the wrong methodology" before starting with OOP. IMHO most of the problems arise because there are too many "developers":

  • who don't care about quality of their code

  • who don't care about self-improvement

  • who have never read any of the books you mentioned above

  • or if they read the books, they don't know how to apply the contents to their own process

  • who learned programming by <3 months of implementing some small games and utilities and then start to call themselves "professional programmers"

Fortunately, there are also a lot of other devs having an opposite understanding of their job and their craft. So IMHO the best way of bringing "good" OOP into an organization is having skilled senior programmers in your team teaching OOP to junior programmers on a daily basis, primarily by reviews and good examples. The methodology to "learn before OOP" is IMHO unimportant (though I expect a good programmer to have procedural, functional and OOP skills as well under his belt after some years of working in that field).

share|improve this answer
    
I totally agree with you last point. People really underestimate the importance of CR. –  Songo Feb 25 at 12:59

I think the problem is not so much people learning procedural programming first, but not learning object oriented design at all. I received my bachelor's degree in 2001. In my degree program, most of my classes were procedural, even though they were taught in Java at the end. I had one third of a semester learning LISP, and around one semester learning the mechanics of OOP, like how inheritance physically works, but not proper OO design.

Colleagues I've talked to who got their degrees in 2005 or later almost all had extensive training on object oriented design principles: design patterns, SOLID, etc. However, like me they had maybe one semester of a functional programming language, but no functional programming design principles.

I think most of the bad OOP code comes from people who know the mechanics, but never bothered to learn the design principles. I had to get the design principles through continuing education classes at work and my own self study. Not everyone has the motivation, but books (like the ones you mentioned), classes, and websites are out there for the taking.

As far as functional programming, I don't know anyone who learned it first. That sample size is probably too small to draw general conclusions. Unlike for OOP, information on functional programming design principles is still hard to come by in a manner that an average programmer can understand. People I know who can write clean and maintainable functional code mostly learned the design principles through a lot of personal trial and error and a handful of higher-level style guides like Twitter's Effective Scala.

Look at this question for an example of someone who had difficulty figuring out good functional programming design principles. Unfortunately, that's fairly typical of the result of someone trying to program functionally without guidance on design principles. There's no canonical "Clean Functional Code" book to point people to when they want to learn.

share|improve this answer

There is a vast number of programming paradigms, and each has its applications. Calling one inherently evil is not useful. Here is a list of interesting paradigms/language features

  • unstructured programming, e.g. assembly
  • imperative programming
  • structured programming: conditionals and loops instead of goto.
  • procedural programming: split the behavior into reusable subroutines.
  • modular programming: put your definitions in separate namespaces, which increases re-usability and encapsulation.
  • functional programming
    • higher-order functions: pass around references to functions
    • closures
    • pure functional languages: control side effects
  • object oriented programming
    • dynamic dispatch: method calls are resolved at run time. This allows for polymorphism.
    • inheritance: share behavior between implementations
  • declarative programming: say what you want, not how to get it

The most important of these are structured programming, procedural programming, and modular programming. Why do I put such an emphasis on modules? Because they are (a) absent in C (compilation units do not count), and (b) an important step between procedural and object-oriented code.

For example, the God Object is not primarily an object-oriented failure. Instead it's a failure to separate procedures into different modules, made worse by the fact that mainstream OOP languages like Java confuse classes with namespaces for procedures (any “static method” is not OOP).

There is no clear hierarchy between OOP and FP, because closures and objects are formally equivalent. However, an OOPer will miss dynamic dispatch, whereas an FPer might miss higher-order functions. The more important difference is however that FP tends towards declarative programming, whereas most OOP languages have imperative roots.

Learning to program is a good start for learning to program in an object-oriented manner. For example, subdividing a problem into smaller, unrelated problems is an important skill, which can be applied to PP, MP, FP, or OOP. One can produce decent “OO” code without actually using features like dynamic dispatch or inheritance (which is falling in disgrace anyway: use composition instead of inheritance).

share|improve this answer
    
agree, but lets not diss Inheritance to much, not when Composition is just a different form of inheritance, with its own issues. –  gbjbaanb Feb 25 at 13:48
    
@gbjbaanb In what way is composition a form of inheritance? –  Doval Feb 25 at 15:00
    
@Doval in that they both attempt to solve the same problem. See here for a good answer concerning the differences –  gbjbaanb Feb 25 at 15:30
    
@gbjbaanb That's a pretty big leap of logic. You could just as easily say object-oriented programming is a form of functional programming because they both attempt to solve the same problem, but that doesn't make it true. –  Doval Feb 25 at 15:34
1  
@Doval OOP is not about classes or interfaces or prototypes or inheritance hierarchies. It's about dynamic dispatch and shared behavior (see also this wikipedia article). How the behavior is shared is secondary. Composition and delegation are valid ways to extend objects. –  amon Feb 25 at 15:39

Not the answer you're looking for? Browse other questions tagged or ask your own question.