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.
–
JeffOApr 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.
–
MarcinApr 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 ;-)
–
PandincusApr 13 '11 at 15:02

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šíkApr 19 '11 at 5:47

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.
–
JeffOApr 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.
–
TMNApr 13 '11 at 12:36

@TMN - that's implied - I should make it explicit.
–
ChrisF♦Apr 13 '11 at 12:39

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.
–
SkeithApr 13 '11 at 12:11

Please elaborate on the "plenty of places where OOP should not be used".
–
FalconApr 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-logicApr 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.

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.

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 ?
–
SouravApr 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 GrooteApr 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
–
WildlingApr 13 '11 at 12:53

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.

"as far as you can" sounds so very wrong to me. Use what you need, don't use paradigms for the sake of using them.
–
HtbaaApr 13 '11 at 13:00

I would agree - OOP is not mostly about inheritance, and encapsulation can only help maintenance.
–
MarcinApr 13 '11 at 14:42

@Htbaa why would he use "for the sake of using them". thats your mind making stuff up. please dont make us suffer from your stupid interpretations. i meant it in a totally different sense. and yes OOP shud be used unless u think you can yourself write all the code in the world. write a simple "space invasion" program without OOP and i'll be your butler for the rest of your life.
–
WildlingApr 13 '11 at 19:12

@Marcin how can you say "can only help maintenance" . my employer would not even consider 1/10 th of what she pays me if i wrote code that isnt maintainable.
–
WildlingApr 13 '11 at 19:14

1

@Ryuzaki Please expand your answer to back up your opinion with some facts and include some of the advantages you speak of. Thanks.
–
Anna Lear♦Apr 14 '11 at 14:27