How do i get out of the habit of procedural programming and into object oriented programming?

Question

I\'m hoping to get some tips to kinda help me break out of what i consider after all these years a bad habit of procedural programming. Every time i attempt to do a project

Answer 1

I think it helps to first skim over some existing, decent, proven object-oriented code (e.g. Qt source code) so you can get a feel for "how it's done". After that, learning from a book or creating your own framework will be much more effective.

In general, it really helps to see things in context before reading about and practicing them, as it gives you moments to say to yourself, "Oh, that's why they did that!" At least that's how it works for me.

Answer 2

The hard part of OO is which stuff should be put together into one object. As you already mentioned the evolution of your source code, here you have a simple guideline on how to evolve your source code towards an OO design:

"Put stuff together that changes together."

When two pieces of code have similar change velocities, that's a hint that they should be placed in the same object. When the change velocities are different, consider placing them in different objects.

This is also known as "Change Velocity".

If you follow that guideline your code will naturally evolve towards a good OO design. Why?

Fragments of code often have similar change velocities if they access a common representation. Every time the representation changes, all the pieces of code that use it must change at once. This is part of the reason we use objects as modules to encapsulate representation. Separating interface from implementation makes sense under this guideline too - the implementation changing more often and thus having a higher change velocity.

If a class has a stable part and an unstable part, that's a difference in change velocity that suggests moving the stable part to a (possibly abstract) base class.

Similarly, if a class has two parts which change equally often but at different times or in different directions (that is to say, for different reasons), then that again suggests refactoring the class.

Sometimes replace "class" with "method". For example, if one line of a method is likely to change more often than the rest - perhaps it is the line which creates a new object instance and contains the name of its class - consider moving it to its own routine. Then subclasses can easily effect their change by overriding it.

I came across this concept on C2 wiki many years ago, but I've rarely seen it used since. I find it very useful. It expresses some crucial underlying motivation of object oriented design. Of course, it's therefore blindingly obvious.

These are changes of the program. There is another sense of change velocity - you don't want instance variables changing at different rate, or rather that is a sign of potential problems. For example, in a graphics editor you shouldn't keep the figures and the handles in the same collection, because the figures change once a minute or once an hour and the handles change once a second or once a minute.

In a somewhat larger view, you want a system to be able to change fast enough to keep up with the changes in the business.

PS: the other principle that you should follow is "Law of Demeter", that is, an object should only talk to its friends. Friends are: yourself, instance variables, parameters, locals, and members of friendly collections - but not globals and static variables.

Answer 3

Don't.

First, learn writing. Second, learn user experience and interaction design. Third, learn business analysis. Fourth, learn role modeling.

Now that you know what objects are, you will come to see that objects are not found in code. They are found at runtime; in the space between the machine and the user's mind. This is what object orientation really means. Unfortunately recent academia has twisted it into an engineering concept. Nothing could be further off the mark. And try as they might to emulate, the end result is crap. Why? Because the "OOP" paradigm as the industry knows it today is built on a fundamentally flawed idea: decompositional analysis of identity. How is this flawed? Because identity in and of itself is meaningless. It is void. In a mathematical sense, in a philosophical sense. This is not how a human being perceives and interacts with the world.

Canon: Alan Kay, Trygve Reenskaug, James (Jim) Coplien

How I wish I was in your position. :)

Answer 4

1. I believe that the mechanics of OOP seem completely arbitrary and make no sense until you read a book on design patterns and understand the "why" of it. I recommend Head First Design Patterns. I thought OOP was ridiculous and completely useless until I picked up this book and saw what it was actually good for.

2. OO makes a lot more sense when you understand function pointers and how it relates to indirect function calls and late binding. Play around with function pointers in C, C++, or D for a little while and get a feel for what they're for and how they work. The polymorphism/virtual function part of OO is just another layer of abstraction on top of this.

3. Procedural is the right tool for some jobs. Don't act like it's wrong. IMHO all three major paradigms (procedural, OO, functional) are valuable even at a fine-grained level, within a single module. I tend to prefer:

Procedural is good when my problem is simple (or I've already factored it enough with functional and OO that I now have a subproblem that I consider simple) and I want the most straightforward solution without a lot of abstraction getting in the way.

Object-oriented is good when my problem is more complex and has lots of state that makes sense in the context of the problem domain. In these cases the existence of state is not an implementation detail, but the exact representation is one that I prefer to abstract away.

Functional is good when my problem is complex but has no state that makes sense at the level of the problem domain. From the perspective of the problem domain, the existence of state is an implementation detail.

Answer 5

Step 1. Read a good Design Patterns book. http://www.oodesign.com/

Step 2. Pick something you already know and rework it from an OO perspective. This is the Code Dojo approach. Take a problem that you already understand, and define the object classes.

I did this -- and wrote down what I did.

See http://homepage.mac.com/s_lott/books/oodesign.html#book-oodesign

You can do the same series of exercises to get the hang of OO design and code.

Answer 6

First, congrats on taking steps to learn something new! I hate it when developers decide to NOT evolve with technology.

As far as moving from procedural programming to OOP, I would say that one thing that you can do is take an existing app (as others have mentioned) and, before you even open a text editor, sit down and think about how each aspect of the application would be converted. I have found that more than half of OO programming is defining the conceptual objects in your mind first.

Again, I will agree with everyone's recommendations on design patterns. Specifically, I would look into the MVC (Model-View-Controller) pattern as this one might be the easiest one to grasp. You have already written code, so you should be able to look at your existing applications and begin putting each part into the M,V or C categories.

Best of luck and have fun!