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

What is the point in using object-oriented programming when you cannot find good reasons or motivation to do so?

You must be motivated by the need to conceive and manipulate ideas as objects. There are people who feel the need to be perceptive of concepts, flow or functions rather than objects and they are then motivated towards programming oriented towards concepts, ideas, or functional flow.

Some 13 years ago, I switched to c++ from c simply because there were ideas I needed but c would not easily perform. In short, my need motivated my programming oriented towards objects.

The object-oriented mind-set

First, you have bytes, chars, integers and floats.

Then your programme starts being cluttered with all kinds of variables, local and static. Then you decide to group them into structs because you figured that all the variables which are commonly passed around.

Conglomeration of data

So like printer's info should have all its variables enclosed into the Printer struct:

{id, name, location,
 impactType(laser|inkjet|ribbon),
  manufacturer, networkAddr},
  etc.

So that now, when you call function after function over printer info, you don't have functions with a long list of arguments or a large collection of static variables with huge possibilities of cross-talk.

Incorporation of information

But data conglomeration is not good enough. I still have to depend on a bunch of functions to process the data. Therefore, I had a smart idea or incorporating function pointers into the Printer struct.

{id, name, location,
 impactType(laser|inkjet|ribbon),
 manufacturer, networkAddr,
 *print(struct printer),
 *clean(struct printer)
}

Data graduates into information when data contains the processes on how to treat/perceive the data.

Quantization of information

Now laser, ribbon and inkjet printers do not all have the same set of information but they all have a most common set of denominators (LCD) in information:

Info common to any printer: id, name, location, etc

Info found only in ribbon printers: usedCycles, ribbon(fabric|cellophane), colourBands, etc

Info found only in inkjet: ink cartridges, etc

Info found only in lasers: ...

For me and many object-oriented cohorts, we prefer to quantize all the common info into one common information encapsulation, rather than define a separate struct/encapsulation for each printer type.

Then, we prefer to use a framework which would manage all the function referencing for each type of printer because not all printers print or are cleaned the same way.

So your preference/motivation oriented away from objects is telling you that your programming life is easier if you do not use objects? That you prefer to manage all those structural complexities yourself. You must not have written enough software to feel that way.

The necessity of laziness

Some people say - necessity is the mother of creativity. (as well as, Love of money is the root of evil).

But to me and my cohorts - laziness in the face of necessity are the parents of creativity. (as well as the lack of money is the other parent of evil).

Therefore, I urge you to adopt a lazy attitude towards programming so that the principle of the shortest path would kick into your life and you'll find but have no other choice than to graduate towards orienting yourself towards programming with objects.

Answer 2

You might consider using the CRC (Class/Responsibility/Collaboration) card approach to OO design. This is nothing too scary - just a way to sort out what your objects should be, and which object should be responsible for which tasks by writing stuff down on a bunch of file cards to help clarify your thoughts.

It was originally designed as a teaching tool for OO thought, and might work for you. The original paper is at: http://c2.com/doc/oopsla89/paper.html

A poster above suggested programming in Smalltalk to force you into OO habits, and to an extent that's a good suggestion - Smalltalk certainly did me a lot of good, but

a) you may not have the spare time to learn a new language. If you do, great.

b) I used to tutor a university course in OO programming, using Smalltalk, and the students did an excellent job of proving that old joke about how "You can write FORTRAN in any language".

Finally: when I was learning about OO (from books) I got the impression that you subclassed a lot, creating complicated class hierarchies. When I started working with OO programmers I realised it didn't happen as often as I thought. I think everyone makes this mistake when they're learning.

Answer 3

The only way to write better code is to write more code. Take a project you've implemented procedurally and convert it to OOP (assuming you're working in a language that supports both). You'll probably end up with a fragile, tightly coupled solution the first time around, but that's ok. Take the bad OOP implementation and start refactoring it into something better. Eventually, you'll figure out what works, and what doesn't.

When you're ready to take the next step, pick up a Design Patterns book and learn some of the OOP design terminology. This isn't strictly necessary, but it will give you a better grasp of some of the common problems and solutions.

Answer 4

The OO mindset is based on principles that lie at a much more basic level than design patterns. Design patterns are somehow fashionable these days (and have been for a while), and they are useful, but they are just one more layer that you can put upon more basic stuff that you absolutely must learn and master if you want to do OO properly. In other words: you can do OO perfectly without design patterns. In fact, many of us did OO well before the phrase "design patterns" was even coined.

Now, there is stuff you can't do without. I suggest you start at the basics. Read and understand "Object-Oriented Software Construction" 2nd edition by Bertrand Meyer. It's probably the best book on OO programming around, both in width and depth. That is if you're interested in programming.

Answer 5

There are already quite a few answers about where to find information on programming in an object-oriented fashion. Indeed, there are many great books out there that will define the basic concepts however I think the question was more on how to "stick with it" through development for someone new to the method.

Of the many concepts in object-oriented programming, the main one that will keep you on track as a newcomer is encapsulation. Does my class know how to take care of itself? Does my class have behaviour? If it doesn't, then you don't have a class, you have a structure and you'll likely be writing a lot of procedures to change its state (as it's said, "you are back to writing C in Java"). Does my class only expose methods publicly that are required for its use? Those questions may not be terribly elaborated upon but perhaps consider this thought experiment when designing your classes: What if each one of your application's classes were to be developed and maintained by a different developer on the internet and the classes also had to interact with eachother over the internet. Would each developer agree that the class they are writing and maintaining adheres to the single responsibility principle and therefore be happy that they aren't maintaining what should be someone elses code?

Regarding the design of class interfaces, consider writing all of the code that uses your classes first. Don't worry about what has to happen at the metal yet. You should be able to stub out the entire program in terms of the class relationships before you write your first bit-twiddling implementation detail. If you can't do this without twiddling bits or making a variable public, then it is time to go back to your class relationship diagram and see if you are missing an abstraction. Phrased another way, use your code before you write your code. Do this first, and you might be suprised how clean your code and interfaces turn out if you've never done it before.

While design patterns are certainly good to learn, and some are extremely powerful, they aren't generally intrinsically object-oriented and as some argue (and I tend to agree) design patterns are often just exposed weaknesses in the language. One language's design patterns is another's basic founding principles. So when starting, don't get hung up on whether or not some relationship is a good candidate for a bridge or a facade; this is not specific to object-oriented thought, this is related to what a specific language's constructs afford.

Answer 6

I think you should convince yourself by researching all of the downsides with procedural programming, for example (some buzzwords following, watch out): scope, state ... practically you'd be able to extract many terms just by reading examples of design patterns (read: common examples of using objects together.)

Stressing yourself into learning something you don't believe in won't get you anywhere. Start being really critical on your earlier work and refactor it to avoid copied code and using the global scope, and you'll find yourself wanting more.