Jump to content

Let me clear up some misconceptions about Object Oriented Programming that we 've "learned " fr...


G+_Lee Crocker
 Share

Recommended Posts

Let me clear up some misconceptions about Object Oriented Programming that we've "learned" from the last two episodes, including a good basic definition we never got.

 

The idea, fundamentally, is one way a complex program is broken into smaller pieces. In a non-OO design, pieces of data may be grouped into structures, and functions can be grouped into modules, but these are independent of each other. In OO design, code is grouped into Objects, each of which contains data elements and functions that operate on that data--and only that data. To emphasize this, we call this kind of function a "method" of the object, meaning that it can only be called to operate on an object of the type for which it was designed. Each object represents a thing in the real world, or an abstract capability, a unit that only shares its data or methods with the outside in ways that it can control. The buzzwords here are "encapsulation" and "information hiding".

 

OO design can be, and often is, implemented in any language, even C or Assembly. "OO" languages make doing certain parts of it easier. In particular, these are features of some OO languages:

 

- Instantiation / creating objects: in order to operate on an object, you must create it in memory. Most, but not all, OO languages do memory management automatically for you, called garbage collection: objects can be created at any time, the system allocates memory for their data automatically, and releases it automatically when they are no longer being used. C++ is an OO language that does not do this, for example, so you still have to do memory management yourself.

 

- Invoking methods: After an object is created, methods are invoked on that object usually by the dot (.) operator: "rabbit.hop()" invokes the "hop" method of that particular rabbit object (in Objective-C, that would be "[rabbit hop];") Within the code for that method, most languages have a special name like "this" or "self" to refer to the object that the method was called on, so that it can be used to call other methods, or so that data elements of it can be changed. This is much like having an "understood" extra first argument to every function. In languages like Python and Go, this argument must be named explicitly. Languages with classes may also invoke methods on the class, in which case the method is called with an object representing the whole class (Python, Objective-C), or else no object at all (C++, C#, Java). JavaScript has a special "this" variable that means different things in different contexts and causes confusion and bugs.

 

- Classes: most OO languages have classes, which are akin to the fundamental types of a non-OO language. (Not all do--JavaScript, for example, has objects but not classes). A class represents a kind of object that you may want to create many of. This allows you to do things like share data among all the objects of the same class. Classes also often have "factory" methods, which are methods that create and return a newly-created object of that class after doing appropriate initialization.

 

- Constructors: many OO languages have special methods that are called when a new object is created so that you can "initialize" the object's data before any methods are called on it. Likewise, they may have destructor functions that can be used to free resources an object has claimed before removing it from memory. The Go language has methods it mistakenly calls constructors, but they are really just factory methods.

 

- Inheritance: Some languages allow you to define a class that inherits data and methods from another, adding only the bits that make it different. Often a complex hierarchy of classes is then developed, in which class has a place on a big tree. Calling a method on an object in such a hierarchy thus involves following the tree: I call the method "location()" on my "rabbit" object, it looks for that method in the "Rabbit" class; if not found, then it looks in the "Animal" class from which Rabbit inherits. Not there either? How about "LivingThing" class from which Animal inherits? No? How about "PhysicalThing" from which LivingThing inherits: bingo: PhysicalThings have a location, so all objects that inherit from it (or its children) will too. In JavaScript, without classes, objects inherit directly from other objects. Finding the right method this way is called "dispatching". Some languages (Like C++) allow a class to inherit from two or more parents ("multiple inheritance"). This is a truly dreadful idea that causes confusion and bugs.

 

- Abstract classes / interfaces: Some languages allow you to specify a class that you can't actually create objects from, but which can be inherited from. Our "LivingThing" class above might be such--you can't just create a LivingThing, it has to be some particular kind of LivingThing, which is a subclass. The abstract class "LivingThing" cannot itself be created, but it can contain data and methods common to all its subclasses. An "Interface" is a different kind of type than a class. It represents a type for all objects--regardless of their place in the object hierarchy--that contain a certain set of methods. This might be something like "Furry"--all furry things have a "shave()" method, whether they are Animals, Peaches, or TennisBalls. Languages without strongly typed variables like Python often use interfaces implicitly: if it looks furry, you can shave it; if it looks like a list, you can step through it, etc. Some languages may even allow user-defined objects that fit a certain interface to use built-in "operator" methods like + or []. C++, C# and Python do. Java and JavaScript do not.

 

- Overloading: A fundamental feature of OO languages is that method names need not be globally unique. The Animal class may have a "feed()" method, and the "SewingMachine" class may also have a "feed()" method, but these methods each do what's appropriate for each object, and have nothing to do with each other. Some also may allow methods with the same name but different kinds of parameters within a class: C++, C#, and Java do, Python does not.

Link to comment
Share on other sites

I wonder if emphasizing the organizational aspect of classes would help new programmers understand them better.  Very simply, a class is a collection of related code and data.  In other words, you got some functions that work with some variables.  Those variables aren't used anywhere else in your program.  You could keep these functions and variables together in their own file.  Why not package them up together in a reusable unit called a class?

 

Then you can show that classes can be further organized into "namespaces".  That's what the "namespace" stuff that you see when Visual Studio starts a new program for you: it creates a new namespace just for your program's classes.  Those mysterious "using" statements that you see also deal with namespaces.  In this case, the "using" statement just saves you from having to type out the fully qualified name of the classes you use from the .NET Framework Class Library.  For example, if you got rid of the "using System;" statement, then you would have to write out System.Console.WriteLine().  The Console class is in the System namespace.

 

Speaking of the Console class, have you noticed that we always just use the class to call methods on, and we never make a Console object?  You can't even instantiate an object of the Console class if you wanted to.  Hopefully the show will talk about this (static classes and methods) pretty soon, because it's used *a lot* in the .NET Framework Class Library.  

Link to comment
Share on other sites

Depending on the design of the program or what exactly is occurring behind the scenes you can use a few different things. The most common way that I used to use when programming in the gaming environment were simply using pointers. You can also use another object, as you said, and those are commonly called Mediator objects/classes. They are set up to handle interaction between objects or classes.

 

I prefer using pointers as they tend to be a bit more easy on the system and less code.

 

More info on mediator patterns: http://en.wikipedia.org/wiki/Mediator_pattern

 

I can explain more if no one else does. I'm on my phone right now and will check back later when I get home.

Link to comment
Share on other sites

metheavyable that's part of it. When you're simply changing the return type, that's static polymorphism (function/method overloading, early binding... It has many names). In reality, you're not always just changing the return type, you're creating different functions with the same name, but different 'stuff' happens in each function depending on how it's called.

 

Example:

 

class Math

{

int add(int value1, int value2)

{

return (value1+value2);

}

 

int add(int value1, int value2, int value3)

{

return (value1+value2+value3);

}

 

static void Main()

{

int a = 1;

int b = 2;

int c = 3;

int d = 4;

 

Math m = new Math();

 

m.add(a,b);

 

m.add(b,c,d);

 

}

}

 

add(a,b) uses the first function and add (b,c,d) uses the second function.

 

Dynamic Polymorphism (late binding, method/function overriding...) is basically overriding base class functions with subclass function declarations.

 

Base class Animal has a function named sound (does nothing here, just declared).

 

Sub class Dog (base class is Animal) also has a function called sound, but this function 'barks'.

 

Sub class Cat (base class is Animal) also has a function called sound, but this function 'meows'.

 

I just did this on my phone, so sorry if it's formatted funny and I hope it made sense - I'm terrible with words... That's why I'm a programmer and not a writer ;)

Link to comment
Share on other sites

 Share

×
×
  • Create New...