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 ?
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.
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.
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.
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.
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) :
and even in these scenarios it may still not be necessary to convert your project to OOP.
Both can be good, both can be bad. But retrofitting one to look like the other is never a good idea.
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.
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.
