Mithat Konar (the wiki)

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Object-Orientation Fundamentals ======

===== Why object-orientation? =====
**Object-oriented programming** came about to support **object-oriented analysis and design** (OOAD).

But why objects?

OOAD was created to try to solve some of the issues involved in designing and managing large applications.

It represents a shift in the way you typically approach a problem when using procedural/structured programming. With procedural/structured programming thinking, a developer typically thinks in terms of, "What needs to //happen//?" It tends to focus on creating a set of functions or subroutines to do the things that need to get done. Thus, the modularity in procedural programming derives primarily from the "verbs" in the system.

In object-oriented thinking, you start with, "What are the components (i.e., objects) that make up the problem?" Once you identify those, you then ask, "How do they behave?" and then, "How do the components interact?" So, the modularity in object-oriented thinking derives primarily from the "nouns" in the system.

You can //analyze// and //design// your problem using this //object-oriented// perspective and then implement the design in any language. However, the implementation is made //much// easier and more robust when the language has the necessary support for defining and using objects. Such a language is an **object-oriented language**.

So, OOAD facilitates a higher level of modular thinking. And, especially with an object-oriented language, it allows for very effective project management of large applications.

===== Object-oriented concepts =====

The concept of an object in computing comes directly from the concept of an "object" in the real world. The concepts central to understanding object-orientation in programming are:

  * state
  * behavior
  * encapsulation and protection
  * self-governance

We next explore each of these in the context of an object from the real world: a microwave oven.

==== State ====
At any given instant, a microwave oven has a particular state:

  * //Is it cooking?//
  * //At what power level?// 
  * //How much cooking time is left?// 
  * //What time does it think it is?//
  * And so on.

All these attributes, which can be defined in terms of data, collectively define the oven's state. 

==== Behavior ====

A given microwave oven also has predefined **behavior**:

  * //Push the "1" button// → start cooking at maximum power for one minute.
  * //Push the "+30sec" button// → start cooking for 30 seconds at maximum power or add 30 seconds to the cooking time if it's already cooking.
  * //Push a magical combination of buttons// → set the internal clock.
  * And so on.

These operations are ones that happen to be public-facing (i.e., operations a user can engage). We call this public-facing behavior (i.e., the operations a user can engage) the oven's **interface**. There might also be operations that go on inside the oven that the user will never be aware of to support the oven's functioning. These are not part of the oven's interface but are important behaviors all the same.

====  Encapsulation and protection ====
As a user, I change the state of the oven by engaging one or more of the operations in the oven's interface. In other words, I'm not expected to open up the oven and hack at its guts to make the  magnetron work at maximum level for whatever time I want. As a user of the oven, if I am a typical user, I don't really care. I only need to know what changes in state to expect from the "cook 1 minute" or "add 30 seconds" operations.

Along the same lines, when I change the clock's setting by pushing the buttons to engage the "set current time" operation, the innards of the oven takes care of all the details of getting the data to the right place, etc. As a user, I don't need to know exactly how it does it. I only need to know what to expect from the operation.

This idea of "not caring about how it works---I only need to know what it does" is the essence of **encapsulation** (literally, "to place in a capsule") in object design. Someone who wants to use the microwave oven only needs to know what to expect when using the public-facing interface.

In fact, even if I wanted to get at, for example, magnetron inside or directly change the clock's setting, I couldn't---at least not without a whole lot of pain and bother. The oven's insides are normally protected against public fiddling by screws and scary labels. And assuming that I actually manage to open it up, I would still need to know, say, where the clock module is, what its electronics parameters are, and a whole bunch of other hackery. No thanks. It's better to just use the designed-in public-facing behavior---its interface---than get a PhD in microwave oven design.

Keeping someone out of stuff they should not be allowed to access is called **protection** or sometimes **information hiding**. In many (but not all) languages, properly hiding things the user has no business getting into is considered part of encapsulation.

==== Objects ====
Our microwave oven takes responsibility for managing its own state using a set of predetermined behaviors. This makes it a **self-governing entity**: an entity that takes responsibility for managing its own state through a set of predetermined behaviors.

Object-oriented languages are languages that let you create self-governing entities. Such self-governing entities are called **objects**.

To put it another way, an object is a program entity that encapsulates state and behavior for some meaningful abstraction. It does this by using attributes and operations involving those attributes.

==== Class-based object-orientation ====

{{:python:about_python:farberware4241-200.jpeg?nolink|}}

I have a Farberware 4241 microwave oven in my office. It's small, but it gets the job done. There is a factory somewhere making these by the thousands. All the Farberware 4241s they make come from a master plan: a plan that defines what the Farberware 4241 //is//. In object-oriented design terminology, we would call that master plan a **class**. A class contains all the specifications needed to make a particular kind of object.

Languages that support **class-based object-oriented programming** let you define classes at a very high level. Once you've defined a class you can then create **instances**: objects created from a class. The process of creating an instance from a class is called **instantiation**.

Thus my oven is an instance of a Farberware 4241, and you might say the Farberware factory spends it's entire day instantiating 4241 ovens.

==== Prototype-based object-orientation ====

There is another kind of object-orientation called **prototype-based object-orientation** or **prototype-based programming**. This is the kind of object-orientation used in JavaScript and some other languages.((C++, Java, C#, and PHP support only class-based object-orientation. JavaScript and Ruby are inherently prototype-based, though "modern" JavaScript (ES6 and beyond) can emulate class-based inheritance. Objective-C is class-based but lets you do prototype-based programming.)) I will leave it to you to get your Google on and learn more about prototype-based object-orientation if you want.


==== Ovens and code ====
So, you now get the idea of objects in the physical world. Learning how this relates to computer code is your next step.

Copyright © 2011-2020 Mithat Konar. All rights reserved.