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 in OOP i end up eventually reverting to procedural. I guess i'm not completely convinced with OOP (even though i think i've heard everything good about it!).

So i guess any good practical examples of common programming tasks that i often carry out such as user authentication/management, data parsing, CMS/Blogging/eComs are the kinda of things i do often, yet i haven't been able to get my head around how to do them in OOP and away from procedural, especially as the systems i build tend to work and work well.

One thing i can see as a downfall to my development, is that i do reuse my code often, and it often needs more rewrites and improvement, but i sometimes consider this as a natural evolution of my software development.

Yet i want to change! to my fellow programmers, help :) any tips on how i can break out of this nasty habbit?

Comments

"Tell, don't ask," and "Law of Demeter," and "Open-Closed Principle."

Written by Dave Jarvis

Don't think procedural programming is a nasty habit. If you truly are better with procedural programming and are able to reuse your code, why the urge to change? The creator says web sites should be done in the simplest of ways (that's what I get from reading his blog). Try oop to learn more than one way to do your work, but don't think you are doing things wrong :)

Written by AntonioCS

it's generally seen as a stigma by my peers, so after so many people provide such comments, it makes you wonder if maybe you should be doing something in another way...

Written by Shadi Almosri

Another alternative to OOP is functional programming. Simple, powerful, and gives reusable code. Don't limit yourself to OOP, it may simply not suit your style.

Written by Tchalvak

Have you tried electro-convulsive therapy? :-)

Written by Stephen C

Please update the question with current language skills.

Written by S.Lott

I think OOP is more like a incremental improvement of procedural rather than a paradigm shift. C++ is a clear example

Written by GogaRieger

@GogaRieger: Many folks argue that C++ is not really object-oriented, since the class objects don't really exist at run-time. It's more of procedural with a veneer of objects. Real OO is usually reserved for Smalltalk, Python, Java, Ruby, Simula, CLU, LOOPS, etc.)

Written by S.Lott

Accepted Answer

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.

Written by Blessed Geek
This page was build to provide you fast access to the question and the direct accepted answer.
The content is written by members of the stackoverflow.com community.
It is licensed under cc-wiki