Defining OOP for a new programmer [closed]

Answer 1

Don't waste time "defining" OOP.

Just use an OOP language for all your examples.

Objects are trivially obvious. The real world is full of objects.

Don't "define" objects. Just show programming examples, the 'objectness' will be obvious.

People with no programming background don't have silly expectations based on procedural programming.

People who learned COBOL or Basic will have problems.

---

Parts of this depend on the language. Some languages make OOP hard.

For example, in C++, the "class" is just definitional. It doesn't exist as a discrete object at run-time.

In Java and C++, some things are objects, but a few "primitive" types are not objects.

Some languages make OOP easier.

Python and Smalltalk everything is an object. There are no primitive types to muddy the waters. When you learn OO in a language like Python, the objectness is clear and obvious because it pervades everything. Just like the real world, where objects are everywhere.

Answer 2

It's strange. You're asking about teaching OOP to people who know nothing about PROGRAMMING and everyone is answering "How to teach OOP?"

The answer is, you do not. How do you teach functional programming to someone who has never programmed? You don't. You have functions, code is crammed into them, they get reused, etc. In Java, all of your code must be in a class. What is a class? It's, first and foremost, a place to put your code. Programs start at the Main method. Later on, you can instantiate it, and each class has its own methods and properties. And then you talk about static methods and variables. And then sometime later you talk about polimorphism and inheritance. And sometime in there they begin to design their own APIs and use servlets and persistent classes or whatever the latest thing to implement is (snervlets? IHibernate?)

But if you've never seen programming before, there is no need to sit down and have the big OOP chat. That is only necessary if you're saving someone from non-OOP programming. Just teach programming. OOP programming? Is there any other kind? Yes, but we're not teaching that today, so let's not worry about it.

[By analogy: when you go to a martial arts class, they don't usually spend a lot of time explaining. First you stretch, they make you work out, and then they teach you some techniques. If you're interested in figuring just which martial art you're studying, you head to the library.]

Answer 3

Any explanation of OOP depends strongly on the explainer's interpretation of the concept. My interpretation of the concept goes something like this.

The real world is largely understood as a set of actors. Each actor has a collection of properties and behaviors. In most cases, the properties of an actor is expressed in terms of it's behaviors, in relation to its interaction with other actors.

A computer program is usually a simulation of some real-world process, so it usually helps the programmer to build the program based on a actors-behaviors-properties model. That is, each element of the whole program can be divided into smaller programs that represent single actors.

Of course you can only take that so far. Not everything we want to model is a single actor. For instance, currency is conserved, but in many ways infinitely sub dividable.

Also, other ways of modeling the real world may offer more rigorous correctness guarantees at the cost of a greater abstraction, such as a relational model, which derives from set theory. OOP has no such mathematical foundation.