I've finished a project in PHP of 13000+ lines in Procedural Style [because I'm very familiar with that, though I know OOP], and the project is running perfectly.

But should I convert it to OOP? [because the world is busy with OOP ]

My code doesn't need any of the feature of OOP [encapsulation, inheritance basically...]!

So what should I do?

And what kind of help I will get if I convert it to OOP ?

  • 21
    Please keep us informed if you have to alter this project. It would be interesting to know if you are glad you made this decision or regret it. – JeffO Apr 13 '11 at 13:22
  • 2
    You need encapsulation. OO is one way to get it; maybe you have another that works for you, but one way or another you need to control code dependencies. – Marcin Apr 13 '11 at 14:44
  • How about an anecdote for you: a few years ago I worked on a medium-sized web application written mostly in JavaScript (don't ask). The style of coding was largely procedural. When the project was nearing completion, I found myself dissatisfied with the way the code was written and rewrote a significant portion of it in OOP-JavaScript. This caused a delay in getting the project done, and we ended up doing relatively little maintenance on the project later on. I've always wondered if all of that coding was worth the effort ;-) – Pandincus Apr 13 '11 at 15:02
  • yes it was worth it. keeping the doors of reusability open s always worth it. – Chani Apr 14 '11 at 4:54
  • 1
    The question is: do you expect further development? Procedural programming is the easiest and fastest approach when you know EXACTLY what you need and it's not going to change. Any change to procedural code will be pain, in OOP it would be much easier. – Kamil Tomšík Apr 19 '11 at 5:47

My code doesn't need any of the feature of OOP

You have answered your own question - if you don't need OOP in this case and your project is working then don't convert it.

However, you should look at using OOP for your next project - but only if it's appropriate.

There's nothing intrinsically wrong with procedural programming - as long as it's used in the appropriate place.

| improve this answer | |
  • 2
    +1 of agree "you should look at using OOP for your next project". – Cary Chow Apr 13 '11 at 10:07
  • 11
    +1 yes, if it's working correctly don't fix it. – setzamora Apr 13 '11 at 10:11
  • 4
    I would say, if it is working correctly now, don't change it, but you never know what the next feature request is going to be. – JeffO Apr 13 '11 at 12:11
  • 7
    "you should look at using OOP for your next project", but don't use it unless it makes sense. Some things are better written procedurally, some are better fits for OOP. Use whatever is appropriate. – TMN Apr 13 '11 at 12:36
  • @TMN - that's implied - I should make it explicit. – ChrisF Apr 13 '11 at 12:39

No and not just because you don't need OOP.

If your program is already finished and working satisfactory then over 90% of the time it it is a wast of time to rewrite finished code for whatever reason.

OOP is not all powerful there are plenty of places where OOP should not be used so don't just use it because OOP is the trend.

| improve this answer | |
  • 1
    By "finished code" do you mean it works? – JeffO Apr 13 '11 at 12:05
  • @eff O yes sir ! it's perfect :) – Sourav Apr 13 '11 at 12:11
  • He said he has finished the project and it is running perfectly. To me this means that it is either ready to deliver to the customer or has been delivered to the customer assuming there is one. By finished I mean tested and ready to ship, of course if major bugs appear a rewrite may come into play. – Skeith Apr 13 '11 at 12:11
  • Please elaborate on the "plenty of places where OOP should not be used". – Falcon Apr 13 '11 at 12:54
  • 3
    @Falcon, no matter how well designed your OOP code is, but if the problem domain itself is poorly mapped to OO model, your OOP design is bound to be crappy. There are loads of problem domains which should never be expressed in terms of OOP. – SK-logic Apr 13 '11 at 14:11

My general take on paradigms (and why none of the three major paradigms is the right way or the wrong way to program):

Procedural programming is good when you have a problem that's simple at a high level (though it may be complex at a low level) and want to write correspondingly simple, linear code. It's arguably easier to write and understand than OO and functional if the problem isn't in need of strong decoupling anywhere. Examples: Numerics code, most small scrips, most small subproblems once you've broken things down using OO or functional.

Object oriented code is good when you need to strongly decouple concerns because you may have more than one implementation of some concerns. Example: Most large business software. You may, for example, want to strongly decouple business logic from presentation logic because they probably will need to change independently.

Functional-style programming is good when you need strong separation of mechanism from policy. Having a mechanism function that accepts a policy function is a nice pattern. (I learned about it by looking at the D programming language's std.algorithm module.) Abstracting away mutable state at the boundary between policy and mechanism code generally makes the API easier to reason about. If mutable state is used privately in either, this is an implementation detail. Functional programming's other strength is concurrency, for self-evident reasons.

| improve this answer | |
  • Thanks for the great answer describing each type of programming paradigm and providing examples of when/how to use them. – Kevin Peno Apr 13 '11 at 17:25

Code never "needs OOP". It's programmers, insofar as they are able to think in different modes, who envision that this or that particular problem "needs" $PARADIGM or is best solved that way.

It is often the case that programmers who only know one paradigm think that their paradigm is the greatest. One size fits all, and we all must sleep in Procrustes' bed, if this or that is currently fashionable.

| improve this answer | |

You should only convert your project to OOP if there is a clear indication of need for OOP. Possible scenarios in which this may occur are (among others) :

  • scaling up the project
  • adding more developers to the team

and even in these scenarios it may still not be necessary to convert your project to OOP.

| improve this answer | |
  • Good point, but can you tell me why it will be problem to scale up the project or adding more developer in the team if it's a procedural code ? – Sourav Apr 13 '11 at 12:12
  • Scaling up the project may involve adding complex relational structures to the application model, in which case, it may become profitable to switch to OOP. If the application scales up bit by bit, and would in the long run turn out to be easier to realise or understand in OOP, new developers may 'catch up' faster, if the code is OOP. Leaving behind a legacy of non-OO code may turn out to be a problem later on when the project gets bigger. one more of those cases where 'things are the way they are because they got that way' – Timothy Groote Apr 13 '11 at 12:15
  • 3
    this is exactly what came to my mind when i read the question. he says he has written 13 K lines of code. i hope it wont be wasted by using only once. and if it has to be reused then oop would become a must. otherwise it would become a nightmare for the new developers – Chani Apr 13 '11 at 12:53

Both can be good, both can be bad. But retrofitting one to look like the other is never a good idea.

| improve this answer | |

If you think back to why OO was invented, you'll see that you don't need OOP at all, but sometimes it makes your life a lot easier.

Back in the days of C coding, a very large program could become quite messy and difficult to keep working with. So they invented ways of splitting it up into modular chunks. OOP takes this approach and makes it even more modular, putting data with those chunks of program logic so they are even more separated from the rest of the code.

This allows you to write bigger and bigger programs, safe that you've changed your huge elephant of a task into a hundred mice-sized tasks instead. The added bonus is that you can take some of these 'mice' and reuse them in other programs!

Of course, the real world is not quite like that, and object reuse never quite caught on in the way it was intended, but it doesn't mean it's a useless paradigm.

What is useless is an over-reliance on either style of coding. Anyone who does OO with a thousand tiny, insignificant classes is not really doing it right - they're making a maintenance nightmare for themselves (or someone else). Anyone writing a procedural application that is only 3 functions is also making life hard. The best way is the middlle ground, large-ish objects (sometimes called components which is where we looked to be going once upon a time) that can provide a fair amount of stand-alone code and data that is much more likely to be reused in isolation from the rest of your app.

My advice for next time: try writing your usual procedural code, but create a single object of your main data structure. See how you find that working with it is easier than passing data around from function to function.

| improve this answer | |

My code doesn't need any of the feature of OOP [encapsulation, inheritance basically...]!

How do you know that?

Do you need to maintain this project? Are there any new features planned? There will be other people who will be developing with you? Did you repeat yourself? Is the code hard to grasp?

If the answer is "yes", than maybe you should start thinking about setting up an OOP skeleton and going this way.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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