Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

My mother did her college thesis in Fortran, and now (over a decade later) needs to learn c++ for fluids simulations. She is able to understand all of the procedural programming, but no matter how hard I try to explain objects to her, it doesn't stick. (I do a lot of work with Java, so I know how objects work) I think I might be explaining it in too high-level ways, so it isn't really making sense to someone who's never worked with them at all and grew up in the age of purely procedural programming.

Is there any simple way I can explain them to her that will help her understand?

share|improve this question
1  
You can build a bird house without becoming a carpenter. Maybe she can start on the project doing it her/procedural way and you could show her how to refactor in a OOP way. Sometimes it's not "I don't get OOP" but "I don't get why you go to all that trouble" –  JeffO Oct 21 '12 at 18:34
2  
@jgauffin Structs? In Fortran 77? –  starblue Oct 21 '12 at 18:40
3  
Does she really need to program object-oriented herself, or is it sufficient to use OpenFOAM in a sort-of procedural way? –  starblue Oct 21 '12 at 18:49
3  
Please don't spoil a pure soul! It is perfectly possible to code in C++ without ever touching any of the abominable OOP stuff. –  SK-logic Oct 22 '12 at 8:46
1  
I totally agree with my previous poster. Your perception of what OOP is and what she needs to use that library may be quite different from each other. I would contact the mailing list of that library and ask some senior users how they approach problems with the lib. Please don't try to 'teach' her OOP it will only lead to misunderstanding, while not solving her problem. –  AndreasScheinert Oct 22 '12 at 9:53
show 6 more comments

8 Answers

up vote 13 down vote accepted

Short answer: no.

Long answer: There no "simple way" because OOP is far than simple. Procedural programming is all about "variables" and "if then goto". Everything else is syntactic sugar, but those four things are all of what procedural programming is about. Once you get them nothing can stop you.

OOP is a way to organize variables and pieces of code. How many patterns are there to define OOP? 25? 30? Even teachers who learned OOP from different languages and backgrounds don't agree on its own definition, so ... how can it be simple?

I don't know how you came to that, but since your mother has similar experience to mine, I can tell you how I came to that.

I was programming in C in a very large project. It was 1988. Many programmers organizing modules and libraries, with the difficulty of avoiding interference in other jobs and keep a good segregation of duties.

We came to a "solution" that was put all interrelated global data into structs, placing in those struct some function pointers where callbacks were required. We generalized in that way what we called io_mask (sort of textual mode dialog boxes) and graphic_manager etc. etc.

In 1996 It was very easy to discover that those structs were named "classes" and those function pointers replaced by member function and virtual functions, or with links to other objects (called behaviors) by other programmers who renewed that old project.

I started to understand OOP when I started to feel the need for it: segregation, polymorphism, and runtime defined behaviors.

Today I work with OOP, but I don't think of it as a doctrine to serve: just a "common idiom" (set of ...) that let us speak together without the need to provide long explanations and descriptions all the time. In fact, more a "convention" than anything else. After all, all OOP does is -again- "if then goto": it just does it "multilayered". Hence abstraction and idioms over idioms.

Ignore them. Until she doesn't fell the need for them don't even try to explain: she will feel them just as a complicated way to do simple things. And she is right... until what she does is -in fact- simple.

No one will think to "organize a desk" if there just four things on top. It make sense when the things on top start to interfere each other. That's the time for OOP to come in.

You don't need OOP to work with C++. The entire C++ standard library is not designed in term of OOP (although it can cooperate with it), and C++ is not Java.

In all my experience the worst C++ teachers and C++ programmers are the one who come form Java, teaching all their prejudice about everything is not OOP, denaturating a language like C++ that is not (just) for OOP.

Let me suggest a good book for those who want to approach C++: Accelerated C++: it will bring you into C++ idioms without pretending to follow a predefined doctrine.

share|improve this answer
    
She needs to know c++ to work with OpenFOAM, so she'll definitely need to know classes soon. I think she understands the basic ideas behind it. For some reason, though, she seems to be getting stuck on the 'dot structure'. (i.e. System.out.println(), except in c++) –  Zonedabone Oct 21 '12 at 17:33
    
@Zonedabone, it is quite easy to understand (and to explain) an operational semantics of classes, virtual methods, etc (just as this answer suggests). It's not a rocket science. Just stay away from the useless and irrelevant OOP "abstractions". –  SK-logic Oct 22 '12 at 8:49
    
OOP is (sort-of) simple, C++ "OOP" is not. Take Smalltalk (object has instance variables and a class, class has methods, you send message to and object which is serviced by a method, that's basically it). Prototype-oriented OOP can even put classes off the equation. --- That's why I would recommend (if possible) to only use subset (no private, no protected, no const, no multiple inheritance, all methods virtual, all destructors virtual etc.) so the model is simpler. Add other things later. –  herby Oct 22 '12 at 16:36
add comment

Tell her to think of objects like objects in the real world. For example the whole world can be a mix of object oriented programming(in C++) with some sort of functional programming(probably done in god's language, Lisp).

Take an object, for example the lawn mower, it has a certain attributes, and it can do a certain thing. (object and class)

Then tell her about a better lawn mower which is an extension of the lawn mower you already have. Tell her its better but still builds on the same mechanism(inheritance).

Then tell her about yourself. Tell her you can sometimes become a lawn mowing expert but you're actually a programmer and do it for a living. This is like you acting as two different entities at the same time. This is polymorphism.

By the time she gets this, tell her about how to implement these things in the language she has to learn(C++).

Then tell her, if she has to write a simulation of this world in the computer world, she will have to learn how to do it.

When she knows how to convert her thoughts of real world into program code. she would have learnt how to program in object oriented programming language.

share|improve this answer
1  
Cool answer. +1. –  H2CO3 Oct 21 '12 at 16:33
    
@H2CO3 thanks :) –  Prototype Stark Oct 21 '12 at 16:35
    
This perfect. Thank you so much. Sorry for getting the se wrong, but I guess someone had an answer. –  Zonedabone Oct 21 '12 at 16:35
    
@Zonedabone no problem, I took 1 year to learn OOP(I learnt on my own), But I used the same examples :) and suddenly felt enlightened. LOL –  Prototype Stark Oct 21 '12 at 16:37
2  
No, no, no, no, no! In my experience "think about objects in the real world" is a terrible way to explain OOP to someone that doesn't already understand it. It leads to bizarre misunderstandings and misapplications of OOP, and often merely deepens the confusion. –  JSBձոգչ Nov 8 '12 at 23:55
show 1 more comment

An old friend claimed I had the shortest definition he knew of OO programming, and I've found that it works for some people (and not for others):

Object-oriented programming is data with an opinion. You don't move the chair, you ask the chair to move itself. You don't sort the list, you ask it to sort itself (perhaps with a hint). Etc.

The idea is to get the person thinking differently about how things get done inside their program.

share|improve this answer
add comment

I would explain it in two steps, or maybe four, depending on how much you like to split your concepts.

Step 1: Introduce her to structures. It's a fairly small step from Fortran data types to structures. Step 1a: make sure she understandard dynamic memory allocation and pointers.

Step 2: add procedures associated only with those structures. Step 2a: add inheritance based on building larger structures which "wrap" smaller structures.

To a Fortran programmer, the "wow" factor will be that it's a lot for the compiler to keep track of. Yup. That's what compilers are for...

share|improve this answer
    
I think she understands the process behind objects. It just that for some reason she doesn't understand the dots. ('.') It's really weird. I guess when you start coding when everything has to be done manually (allocation and stuff) you know how the inner workings of modern languages work without knowing how to work them. –  Zonedabone Oct 21 '12 at 21:22
add comment

If she did her thesis a decade ago, she probably used Fortan 90 or 95, in which case the thing to is talk about it in relationship to derived data types. If it was long enough ago that she used Fortran 77, then introduce her to derived data types in Fortran 90 and then talk about it...

I wouldn't go into polymorphism and inheritance, until after she has grasped encapsulation, as they can be viewed as special cases and extensions of encapsulation. I would probably start her on a language that either allows free functions or static classes.

share|improve this answer
    
Well, a decade ago, I had some courses of Fortran, in master's degree. But only Fortran 77... –  Jean-Claude Arbaut Aug 26 '13 at 10:13
add comment

Once she understands structures, I think the next key point will be to recognize that object-oriented programming serves as a means of confining the set of methods to which a thing may be passed, to the set of methods which could actually be applied to that thing.

In non-object-oriented programming, if one is using separate data types for a Tree and a LinkedList, one would have to use different methods for adding a node to each. Non-object-oriented languages would generally squawk if one tried to name both methods AddItem, since any given name can only refer to one method, thus leading one to create method names like AddTreeItem, AddLinkedListItem, RemoveTreeItem, etc. Such an approach works, but it's a bit ugly. Conceptually, the methods AddTreeItem and RemoveTreeItem seem to belong together, but the names don't sort that way. One could rewrite the names as TreeAddItem, TreeRemoveItem, LinkedListAddItem, etc. but that would put a lot of "redundant noise" at the start of each method invocation. The vast majority of method calls in a typical program will have three essential pieces of information: (1) what section of the source code contains the method; (2) which of the methods in section is being used; (3) what piece of data is being acted upon? In many cases, the type of data being acted upon will be sufficient to identify which code section the method belongs to, so part (1) of the above is redundant. It's easier to visually identify material at the start of a statement than material elsewhere, so a coding/naming style like TreeAddItem(myTree, whatever) ends up putting the least useful piece of information in the prime spot.

By contrast, using object-oriented programming, one would effectively name methods as Tree.AddItem, etc. and a statement like myTree.AddItem(whatever) would cause a compiler to say, essentially, "Hmm... myTree is of type Tree, so this code should invoke Tree.AddItem(). It's not necessary to specify the Tree. when calling AddItem since the compiler knows the type of myTree. Conceptually, a statement like myTree.AddItem(whatever) is equivalent to Tree.AddItem(myTree, whatever), and some object-oriented languages may allow both forms as equivalent; in fact, most languages omit the first parameter from the function specification and instead have methods that are defined in a class like Tree implicitly take a parameter of type Tree, and assign it a name like this, self, or Me.

Object-oriented programming languages often include a variety of additional features such as inheritance, virtual functions, etc. which are very useful in many applications, but even without those features the ability to group functions according to the things they operate upon is very useful.

share|improve this answer
add comment

Object-oriented programming—in the class-oriented sense relevant here—is about coupling a data representation with the code that manipulates it. It makes sense if the following things make sense:

  • Coupling: defining an operation alongside the data representation it works on

  • Late binding: choosing a combination of data representation and behaviour at runtime

  • Encapsulation: ensuring that data is valid by construction and won’t be later invalidated

That’s all. Like any technology, at its heart it’s simply a convenience, from which many developments have later followed. Once you understand the basics, the rest follows in time.

share|improve this answer
add comment

I would suggest downloading BlueJ, playing with it for 20 minutes then having her play with it for 20 minutes.

The way it visualizes classes, interfaces and inheritence is so obvious and intuitive that it really gives you an instant understanding as you implement something--anything.

It even shows you directly the difference between a class and an object

It won't give any deep insights into OO design patterns, but it will give a fantastic overview of the concepts.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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