Recently I was assigned a task of creating a calculator with functions addition, subtraction, multiplication, division and power using Object Oriented Programming. I successfully completed this task. However afterwards I reprogrammed the whole program without using Object Oriented technique/method.

The thing I noticed that my code length was reduced quite significantly and it was quite understandable. So my question here is when should I use Object Oriented Programming? Is it okay to create programs without Object Orientation in Object Oriented Language? Kindly help me out on this one.

PS: I am not asking here to tell me merits of Object Oriented Programming over procedural programming.

  • 12
    There is absolutely no reason to avoid applying different techniques as needed. You as the programmer will need to weigh the pros and cons on a case by case basis. Quite often it comes down to personal style. – ChaosPandion Dec 23 '14 at 4:56
  • 3
    I've never had it be an issue. The language was nearly always a prescribed tool given the team and/or other architecture. – user40980 Dec 23 '14 at 5:37
  • 4
  • 8
    Implementing the same program with and without OO techniques is a good exercise to learn something, I cannot understand why some people here seem to deny this or downvote you. But the problem with your question is that it was already asked here more than once, in different forms. And though you deny it, you are asking about merits of Object Oriented Programming over procedural programming. And C++ is not an OO language, it is an hybrid language. – Doc Brown Dec 23 '14 at 5:59
  • 3
    Add a feature that displays the formula you've entered and then add a square root function (Don't do this first, that would be cheating.) and let us know what you think. – JeffO Dec 23 '14 at 12:41

C++ is not "just" an OO language, it is a multi-paradigm language. So it allows you to decide for or against OO programming, or to mix them both. Using OO techniques adds more structure to your program - from which you will benefit when your program reaches a certain size or complexity. This additional structure, however, comes for the price of additional lines of code. So for "small" programs the best way to go is often to implement them in a non-OO style first, and add more and more OO techniques later when the program starts to grow over the years (which will probably not happen to "exercise" programs, but is the typical life cycle for lots of business programs).

The tricky part is not to miss the point in time when the complexity of your program reaches the size which demands more structure. Otherwise you will end up with a huge pile of spaghetti code.

  • If simple "exercise" programs starts to evolve, best way is to implement it in such a manner that it can be re factored afterwards. Thank you for sharing that :) +1 – FaizanRabbani Dec 23 '14 at 6:32
  • @CarlSmith: absolutely. But when I wrote my answer, I tried to focus on the points and scale of the actual question. – Doc Brown Aug 22 '19 at 5:33

How do professional programmers make judgement call on whether to go for OOP or not? It would be really helpful for me.

For me, there are two decision points. First, sometimes it will be obvious at the beginning. There will be lots of similar types that all share common methods that differ widely in their implementation details. For example, I was building a workflow system, and I needed the ability to implement arbitrary tasks. To run the task, I implemented a base class that each task inherited from, with an Execute() abstract method. The inheriting classes supplied the implementation, but the workflow system could begin the execution without knowing anything about what kind of task was being run.

Most projects aren't that clear-cut though. The second decision point is when a subset of the project has grown into a huge tangle of if-then statements or switch-case statements, and especially when those if-then statements require a lot of setup code to run correctly. I feel myself starting to lose the logic of what I'm trying to accomplish, and the code starts to feel fragile. At that point, it is usually a sign that it is time to refactor the code into base classes with specific implementations.

A big part of switching to an object-oriented style as opposed to a functional style is converting if-then statements into "run this action" statements. Instead of a huge set of if-then statements, you just tell the code to run its action. Which action is actually run depends on the implementation you supplied.

For example, here's the functional style in C#-style pseudocode:

if ( action == "email" ) { 
else if ( action == "sms" ) { 
else if ( action == "web" ) { 
    endpoint = "";
    confirmWeb(endpoint, userinfo);

But maybe you could rewrite that to something like this:

interface IConfirmable {
    void Confirm(UserInfo userinfo);

public class ConfirmEmail : IConfirmable { 
    public void Confirm(UserInfo userinfo) {
        // do the appropriate thing to confirm via email

public class ConfirmSms : IConfirmable { 
    public void Confirm(UserInfo userinfo) {
        // do the appropriate thing to confirm via email

public class ConfirmWeb : IConfirmable { 
    // this is a constructor
    public ConfirmWeb(string endpoint) { 

    public void Confirm(UserInfo userinfo) {
        // do the appropriate thing to confirm via web

And then the code itself:

// An implementation that decides which implementation of the base class to use
// This replaces the if-then statements in the functional programmming.
IConfirmable confirmer = ConfirmerFactory.GetConfirmer();

// get the userinfo however you get it, 
// which would be the same way you get it in the functional example.
UserInfo userinfo = ...;

// perform the action.

Now, when there is very little code inside the if-then, this looks like a lot of work to get no benefit. And when there is very little code in the if-then, that is correct: that's a lot of work for code that is harder to understand.

But the object-oriented style really shines when you have more than one action than just the Confirm() method that needs to be performed. Maybe you have an initialization routine, three or more action methods that can be run, and a Cleanup() method. The base algorithm is identical, except it makes its calls into the appropriate objects that implement a common base class. Now you start to see a real benefit to the object oriented style: the base algorithm is much easier to read than if it was checking if-then statements at every step of the way.

  • +1 for detailed analysis. :) I have few thoughts on this. – FaizanRabbani Dec 23 '14 at 6:08
  • 1
    Aside: please stop posting "thanks" comments on every answer. We prefer to focus on just questions and answers, not discussion. – Philip Kendall Dec 23 '14 at 6:34
  • 5
    That example is more imperative than functional. – OrangeDog Dec 23 '14 at 9:58
  • Cf. the chain-of-responsibility pattern. – Eric Dec 23 '14 at 10:16
  • 1
    Just a note, when you're leaning towards a bunch of if/else or switch statements, it's always an option to consider some sort of lookupt table. So another way to rewrite that goes along the lines of var dict = new Dictionary<string,Action<UserInfo>{ { "email", callEmailFunction }, { "sms", callSmsFunction } }; dict[ action ]( userInfo ); (dict can be static, error handling omitted) – stijn Dec 23 '14 at 18:37

Yes, it is perfectly normal to use old style code, provided the scope of your project is well known or is limited. If you plan on extending your program or project OOP is one way to go, because you can maintain and extend your code seamlessly, on the other hand if you planned it and have come to a conclusion that you are never going to plan extensibility of the project you make then writing code without OOP would suffice. It doesn't mean if you use non OOP approach you can never upgrade your project but then it would be a tedious thing to do. OOP is to help us visualize our concept as though it were a real life organism because we understand those better than anything else.

  • 1
    "It doesn't mean if you use non OOP approach you can never upgrade your project but then it would be a tedious thing to do.": OOP helps to extend your project when most extensions involve adding new classes (e.g. adding new widgets to a GUI). When most extensions involve adding new operations, then a procedural design can be more effective. – Giorgio Dec 23 '14 at 14:58
  • 1
    Since when is "not object oriented" called "old style"? – DanielSank Dec 23 '14 at 20:06

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