practical uses of OOP

Question

I recently had a debate with a colleague who is not a fan of OOP. What took my attention was what he said:

"What's the point of doing my coding in objects? if it's reuse then I can just create a library and call whatever functions I need for whatever task is at hand. Do I need these concepts of polymorphism, inheritance, interfaces, patterns or whatever?"

We are in a small company developing small projects for e-commerce sites and real estate

How can I take advantage of OOP in an "everyday, real-world" setup? or was oop really meant to solve complex problems and not intended for "everyday" development?

Answer 1

More than getting something to just work - your friend's point, a well designed OO design is easier to understand, to follow, to expand, to extend and to implement. It is so much easier for example to delegate work that categorically are similar or to hold data that should stay together (yes even a C struct is an object).

Answer 2

Well, I'm sure a lot of people will give a lot more academically correctly answers, but here's my take on a few of the most valuable advantages:

• OOP allows for better encapsulation
• OOP allows the programmer to think in more logical terms, making software projects easier to design and understand (if well designed)
• OOP is a time saver. For example, look at the things you can do with a C++ string object, vectors, etc. All that functionality (and much more) comes for "free." Now, those are really features of the class libraries and not OOP itself, but almost all OOP implementations come with nice class libraries. Can you implement all that stuff in C (or most of it)? Sure. But why write it yourself?

Answer 3

My personally view: context

When you program in OOP you have a greater awareness of the context. It helps you to organize the code in such a way that it is easier to understand because the real world is also object oriented.

Answer 4

The good things about OOP come from tying a set of data to a set of behaviors.

So, if you need to do many related operations on a related set of data, you can write many functions that operate on a struct, or you can use an object.

Objects give you some code reuse help in the form of inheritance.

IME, it is easier to work with an object with a known set of attributes and methods that it is to keep a set of complex structs and the functions that operate on them.

Some people will go on about inheritance and polymorphism. These are valuable, but the real value in OOP (in my opinion) comes from the nice way it encapsulates and associates data with behaviors.

Should you use OOP on your projects? That depends on how well your language supports OOP. That depends on the types of problems you need to solve.

But, if you are doing small websites, you are still talking about enough complexity that I would use OOP design given proper support in the development language.

Answer 5

Look at the use of Design Patterns and you'll see the utility of OOP. It's not just about encapsulation and reuse, but extensibility and maintainability. It's the interfaces that make things powerful.

A few examples:

• Implementing a stream (decorator pattern) without objects is difficult

• Adding a new operation to an existing system such as a new encryption type (strategy pattern) can be difficult without objects.

• Look at the way PostgresQL is implemented versus the way your database book says a database should be implemented and you'll see a big difference. The book will suggest node objects for each operator. Postgres uses myriad tables and macros to try to emulate these nodes. It is much less pretty and much harder to extend because of that.

The list goes on.

Answer 6

All programming paradigms have the same goal: hiding unneeded complexity.

Some problems are easily solved with an imperative paradigm, like your friend uses. Other problems are easily solved with an object-oriented paradigm. There are many other paradigms. The main ones (logic programming, functional programming, and imperative programming) are all equivalent to each other; object-oriented programming is usually thought as an extension to imperative programming.

Object-oriented programming is best used when the programmer is modeling items that are similar, but not the same. An imperative paradigm would put the different kinds of models into one function. An object-oriented paradigm separates the different kinds of models into different methods on related objects.

Your colleague seems to be stuck in one paradigm. Good luck.

Answer 7

Design trumps technology and methodology. Good designs tend to incorporate universal principals of complexity management such as law of demeter which is at the heart of what OO language features strive to codify.

Good design is not dependant on use of OO specific language features although it is typically in ones best interests to use them.

Answer 8

Not only does it make

• programming easier / more maintainable in the current situation for other people (and yourself)
• It is already allowing easier database CRUD (Create, Update, Delete) operations.

You can find more info about it looking up: - Java : Hibernate - Dot Net : Entity Framework

See even how LINQ (Visual Studio) can make your programming life MUCH easier.

• Also, you can start using design patterns for solving real life problems (design patterns are all about OO)

Perhaps it is even fun to demonstrate with a little demo:

• Let's say you need to store employees, accounts, members, books in a text file in a similar way.

.PS. I tried writing it in a PSEUDO way :)

the OO way

Code you call: io.file.save(objectsCollection.ourFunctionForSaving())

class objectsCollection

function ourFunctionForSaving() As String

String _Objects

   for each _Object in objectsCollection
         Objects &= _Object & "-"
   end for

return _Objects end method

NON-OO Way

I don't think i'll write down non-oo code. But think of it :)

NOW LET'S SAY

In the OO way. The above class is the parent class of all methods for saving the books, employees, members, accounts, ... What happens if we want to change the way of saving to a textfile? For example, to make it compactible with a current standard (.CVS).

And let's say we would like to add a load function, how much code do you need to write? In the OO- way you only need the add a New Sub method which can split all the data into parameters (This happens once).

Let your collegue think about that :)

Answer 9

Around 1994 I was trying to make sense of OOP and C++ at the same time, and found myself frustrated, even though I could understand in principle what the value of OOP was. I was so used to being able to mess with the state of any part of the application from other languages (mostly Basic, Assembly, and Pascal-family languages) that it seemed like I was giving up productivity in favor of some academic abstraction. Unfortunately, my first few encounters with OO frameworks like MFC made it easier to hack, but didn't necessarily provide much in the way of enlightenment.

It was only through a combination of persistence, exposure to alternate (non-C++) ways of dealing with objects, and careful analysis of OO code that both 1) worked and 2) read more coherently and intuitively than the equivalent procedural code that I started to really get it. And 15 years later, I'm regularly surprised at new (to me) discoveries of clever, yet impressively simple OO solutions that I can't imagine doing as neatly in a procedural approach.

I've been going through the same set of struggles trying to make sense of the functional programming paradigm over the last couple of years. To paraphrase Paul Graham, when you're looking down the power continuum, you see everything that's missing. When you're looking up the power continuum, you don't see the power, you just see weirdness.

I think, in order to commit to doing something a different way, you have to 1) see someone obviously being more productive with more powerful constructs and 2) suspend disbelief when you find yourself hitting a wall. It probably helps to have a mentor who is at least a tiny bit further along in their understanding of the new paradigm, too.

Barring the gumption required to suspend disbelief, if you want someone to quickly grok the value of an OO model, I think you could do a lot worse than to ask someone to spend a week with the Pragmatic Programmers book on Rails. It unfortunately does leave out a lot of the details of how the magic works, but it's a pretty good introduction to the power of a system of OO abstractions. If, after working through that book, your colleague still doesn't see the value of OO for some reason, he/she may be a hopeless case. But if they're willing to spend a little time working with an approach that has a strongly opinionated OO design that works, and gets them from 0-60 far faster than doing the same thing in a procedural language, there may just be hope. I think that's true even if your work doesn't involve web development.

I'm not so sure that bringing up the "real world" would be as much a selling point as a working framework for writing good apps, because it turns out that, especially in statically typed languages like C# and Java, modeling the real world often requires tortuous abstractions. You can see a concrete example of the difficulty of modeling the real world by looking at thousands of people struggling to model something as ostensibly simple as the geometric abstraction of "shape" (shape, ellipse, circle).

Answer 10

The power of most programming languages is in the abstractions that they make available. Object Oriented programming provides a very powerful system of abstractions in the way it allows you to manage relationships between related ideas or actions.

Consider the task of calculating areas for an arbitrary and expanding collection of shapes. Any programmer can quickly write functions for the area of a circle, square, triangle, ect. and store them in a library. The difficulty comes when trying to write a program that identifies and calculates the area of an arbitrary shape. Each time you add a new kind of shape, say a pentagon, you would need to update and extend something like an IF or CASE structure to allow your program to identify the new shape and call the correct area routine from your "library of functions". After a while, the maintenance costs associated with this approach begin to pile up.

With object-oriented programming, a lot of this comes free-- just define a Shape class that contains an area method. Then it doesn't really matter what specific shape you're dealing with at run time, just make each geometrical figure an object that inherits from Shape and call the area method. The Object Oriented paradigm handles the details of whether at this moment in time, with this user input, do we need to calculate the area of a circle, triangle, square, pentagon or the ellipse option that was just added half a minute ago.

What if you decided to change the interface behind the way the area function was called? With Object Oriented programming you would just update the Shape class and the changes automagically propagate to all entities that inherit from that class. With a non Object Oriented system you would be facing the task of slogging through your "library of functions" and updating each individual interface.

In summary, Object Oriented programming provides a powerful form of abstraction that can save you time and effort by eliminating repetition in your code and streamlining extensions and maintenance.

Answer 11

Besides theoretical aspects mentioned, there are also immediate practical advantages of OOP against structured programming:

You type less and code becomes more fluent. Instead of calling functions like CreateFile(name), WriteFile(handle, position, buffer, size), ReadFile(handle, position, buffer, size) you declare a File a which keeps handle and position itself and you only call a.Create(name), a.Write(buffer, size), a.Read(buffer, size).

You type even less. When implementing file functions you'll have to implement validity checks for parameters passed for every function call. Protection levels in OOP allows you to do these checks only once and reuse these values without implementing sanity checks each and every time, yet keeps you safe.

You become more flexible. A code doesn't have to know what specific functions it's dealing with. If your function takes a Stream object as a parameter, based on the object passed your function can either write to a file, to a memory block or to a network connection just by calling a.Write() without even knowing it. This increases code reuse. In structured programming you have to re-invent OOP and pass around function pointer tables in order to achieve same functionality. OOP does this for you with additional type safety.

You start with a higher abstraction of thinking when defining building blocks for your software. Instead of thinking each and every single file access function that you need to implement, you start by thinking "I need a File class" and put aside thinking its contents later. This makes software prototyping faster.

Code reuse becomes much easier because you are enforced to encapsulate your functionality into a single "class". Since you don't name your class FileAndWindow you immediately adapt yourself to that kind of "single class for a single job" pattern and this allows you reuse File and Window classes later in different code much easier.

Answer 12

In domains where state and behavior are poorly aligned, Object-Orientation reduces the overall dependency density (i.e. complexity) within these domains, which makes the resulting systems less brittle.

This is because the essence of Object-Orientation is based on the fact that, organizationally, it doesn't dustinguish between state and behavior at all, treating both uniformly as "features". Objects are just sets of features clumpled to minimize overall dependency.

In other domains, Object-Orientation is not the best approach. There are different language paradigms for different problems. Experienced developers know this, and are willing to use whatever language is closest to the domain.

Answer 13

To me, the power of OOP doesn't show itself until you start talking about inheritance and polymorphism.

If one's argument for OOP rests the concept of encapsulation and abstraction, well that isn't a very convincing argument for me. I can write a huge library and only document the interfaces to it that I want the user to be aware of, or I can rely on language-level constructs like packages in Ada to make fields private and only expose what it is that I want to expose.

However, the real advantage comes when I've written code in a generic hierarchy so that it can be reused later such that the same exact code interfaces are used for different functionality to achieve the same result.

Why is this handy? Because I can stand on the shoulders of giants to accomplish my current task. The idea is that I can boil the parts of a problem down to the most basic parts, the objects that compose the objects that compose... the objects that compose the project. By using a class that defines behavior very well in the general case, I can use that same proven code to build a more specific version of the same thing, and then a more specific version of the same thing, and then yet an even more specific version of the same thing. The key is that each of these entities has commonality that has already been coded and tested, and there is no need to reimpliment it again later. If I don't use inheritance for this, I end up reimplementing the common functionality or explicitly linking my new code against the old code, which provides a scenario for me to introduce control flow bugs.

Polymorphism is very handy in instances where I need to achieve a certain functionality from an object, but the same functionality is also needed from similar, but unique types. For instance, in Qt, there is the idea of inserting items onto a model so that the data can be displayed and you can easily maintain metadata for that object. Without polymorphism, I would need to bother myself with much more detail than I currently do (I.E. i would need to implement the same code interfaces that conduct the same business logic as the item that was originally intended to go on the model). Because the base class of my data-bound object interacts natively with the model, I can instead insert metadata onto this model with no trouble. I get what I need out of the object with no concern over what the model needs, and the model gets what it needs with no concern over what I have added to the class.