I need explanations on OOP

[Guest]

I've been learning C++ and have trouble understanding oop. Can someone give me some reading material / videos on it?

[prolemur]

An object is basically a bunch of variables and functions.

 

So a human object would have name, height and age as instance variables and functions like eat, sleep and work for example.

[Guest]

An object is basically a bunch of variables and functions.

 

So a human object would have name, height and age as instance variables and functions like eat, sleep and work for example.

I got that much, I have trouble with implementing those concepts in c++

[b4ux1t3]

The problem I have with a lot of OOP tutorials, or even classes, is that they try to abstract things away from programming. Explaining OOP in terms of "Cats and Dogs are both Animals, but a Cat is not a Dog" is fine for basic OOP, but it doesn't really help you if you try to make anything more complicated than a text adventure.
 
Instead of thinking about classes, objects, whatever being real things, try to think of them as more of a collection of very specific functionalities.
 
For instance, let's abstract it out of computing for the time being (I know, I know, I just said don't do that. But, bear with me).
 
Let's say you have a class Cell. It has hundreds of children, all of which inherit things from it. In order to build a dog, what do you do? You don't just build a dog; you put together a bunch of different kinds of cells to make the different systems within the dog. There are cells whose sole purpose is to pick up an oxygen molecule if it is in the lungs, and then drop it off it it is near another cell that needs oxygen.
 
In the end, a big computer program isn't one big "thing". It is an amalgamation of many smaller things, just as a dog is made up of its organs, which are made up of its cells.

Now, what if scientists invented a cell that did exactly what the old ones did, but in a slightly different way. What if, say,it were more efficient for the cell that moves oxygen around to store the oxygen in a different way. If the scientists did their job right, they could replace all the "instances" of that kind of cell with their new cell, that technically works better, but doesn't affect, in any way, how the rest of the body works.

That is the key to OOP. Modularity, code reuse, and abstraction. So that you can pull out a class from one program and put in a class that does things better, but doesn't change the way the rest of the program works.

Note, this isn't a new concept specific to OOP. OOP is just a way to go about handling this modularity of code.
 
Going back to software, lets look at what would be a simple text editor.
 
You're going to need a few parts of that text editor. Let's say that it has an area to type your words and an area to do things like saving and opening and things like that. Now let's say it's going to be a graphical program, so we're also going to need something to put those elements in.

You'll have to forgive me, I can't remember *exactly* how C++ does inheritance. So this is going to be mostly pseudocode.

So, you're going to want a Menu class:
 
 

class Menu() inherits from Widget{    public void Save(file){        // Save stuff some how    }    public FilePointer Open(file){        // Open stuff some how    }}

 
Next, you're going to want your TextArea class:
 
 

class TextArea(FilePointer doc) inherits from Widget{    public void ReadKeyPress(){        // Read key presses some how    }    public void UpdateDocument(){        // Update the document some how    }}

 

Finally, you're going to want a Window class:
 
 

class Window{    public Widget[] Widgets    public void Close(){        // Close the window some how    }}

 

Your Window basically runs the show. It decides where and when to render the TextArea and Menu. It decides when to call TextArea.ReadKeyPress().

That said, it does not care, for instance, if the internals of how Menu.Open() works. All it cares about is that a file is still opened, and that file is passed over to the TextArea correctly.

Now, let's say you want to, instead, build a web browser. Good news everyone! We already have a Window and a Menu class built! We even have a TextArea class built, for the address bar and all the input fields on the web! Now we just need to build an HTML renderer, a network stack, etc. etc. . . Even more good news! Other people wrote libraries (classes!) that do all of those things! Time to combine them all together in my own program and. . .wow, I had to write almost no code at all!

But, seriously, you could literally build your own web browser out of bits and pieces of other browsers if you really wanted to. That's the whole "abstraction" part of OOP. That way, you can focus on making the specific features that you want to add, instead of having to rewrite (or, worse, adapt someone else's non-OOP version of) the wheel.


I hope that helped a bit. The long and short of it is that OOP focuses on code reuse and abstraction. Some would argue that it doesn't do a very good job. They might be right. Or it might depend on the language. All I know is that it's simply not taught very well. There is such a thing as too abstract.

 

Here is a pretty good Object Oriented Design tutorial series. He doesn't bandy about with huge layers of abstraction. He starts small, has you build a game, and eventually works up to building realistic programs using OOP.

[Nuluvius]

Now, what if scientists invented a cell that did exactly what the old ones did, but in a slightly different way. What if, say,it were more efficient for the cell that moves oxygen around to store the oxygen in a different way. If the scientists did their job right, they could replace all the "instances" of that kind of cell with their new cell, that technically works better, but doesn't affect, in any way, how the rest of the body works.

 

This is known as the Liskov substitution principle (LSP) and is part of Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion (SOLID).