What are OOP's Jargons and Complexities?

What are OOP's Jargons and Complexities
Xah Lee, 20050128

The Rise of Classes, Methods, Objects

In computer languages, often a function definition looks like this:
subroutine f (x1, x2, ...) {
variables ...
do this or that
}

In advanced languages such as LISP family, it is not uncommon to define
functions inside a function. For example:
subroutine f (x1, x2, ...) {
variables...
subroutine f1 (x1...) {...}
subroutine f2 (x1...) {...}
}

Often these f1 f2 inner functions are used inside f, and are not
relevant outside of f. Such power of the language gradually developed
into a style of programing. For example:
subroutine a_surface () {
coordinatesList = ...;
subroutine translate (distance) {...}
subroutine rotate (angle) {..}
}

Such a style is that the a_surface is no longer viewed as a function.
But instead, a boxed set of functions, centered around a piece of data.
And, all functions for manipulating this piece of data are all embodied
in this function. For example:
subroutine a_surface (arg) {
coordinatesList = ...
subroutine translate (distance) {set coordinatesList to translated
version}
subroutine rotate (angle) {set coordinatesList to rotated version}
subroutine return () {return coordinatesList}

if (no arg) {return coordinatesList}
else { apply arg to coordinatesList }
}

In this way, one uses a_surface as a data, which comes with its owe set
of functions:
mySurface = a_surface();
mySurface(rotate(angle)); // now the surface data has been
rotated
mySurface(translate(distance)); // now its translated
newSurface = mySurface(return())

So now, a_surface is no longer viewed as a subroutine, but a boxed set
of things centered around a piece of data. All functions that work on
the data are included in the boxed set. This paradigm possible in
functional languages has refined so much so that it spread to other
groups and became known as Object Oriented Programing, and complete
languages with new syntax catered to such scheme emerged.

In such languages, instead of writing them like this:
mySurface = a_surface();
mySurface(rotate(angle));

the syntax is changed to like this, for example:
mySurface = new a_surface();
mySurfaceRotated = mySurface.rotate(angle);

In such languages, the super subroutine a_surface is no longer called a
function or subroutine. It is now called a “Class”. And nowthe
variable holding the function "mySurface = a_surface()" is now called a
“Object”. Subroutines inside the function a_surface() are no longer
called inner-subroutines. They are called “Methods”. The act of
assigning a super-subroutine to a variable is called instantiation.

This style of programing and language have become so fanatical that in
such dedicated languages like Java, everything in the language are
“Classes”. One can no longer just define a variable or subroutine.
Instead, one creates these meta-subroutine “Classes”. Everything
one do are inside Classes. And one assign Classes inside these Classes
to create “Objects”. And one uses “Methods”to manipulate
Objects. In this fashion, even basic primitives like numbers, strings,
and lists are no longer atomic entities. They are now Classes.

For example, in Java, a string is a class String. And inside the class
String, there are Methods to manipulate strings, such as finding the
number of chars, or extracting parts of the string. This can get very
complicated. For example, in Java, there are actually two Classes of
strings: One is String, and the other is StringBuffer. Which one to use
depends on whether you intend to change the data.

So, a simple code like this in normal languages:
a = "a string";
b = "another one";
c = join(a,b);
print c;

or in lisp style
(set a "a string")
(set b "another one")
(set c (join a b))
(print c)

becomes in pure OOP languages:
public class test {
public static void main(String[] args) {
String a = new String("a string");
String b = new String("another one");
StringBuffer c = new StringBuffer(40);
c.append(a); c.append(b);
System.out.println(c.toString());
}
}

Here, the "new String" creates a String object. The "new
StringBuffer(40)" creates the changeable string object StringBuffer,
with room for 40 chars. "append" is a method of StringBuffer. It is
used to join two Strings.

Notice the syntax "c.append(a)", which we can view it as calling a
inner subroutine "append", on a super subroutine that has been assigned
to c, where, the inner subroutine modifies the inner data by appending
a to it.

And in the above Java example, StringBuffer class has another method
"toString()" used to convert this into a String Class, necessary
because System.out.println's parameter requires a String type, not
StringBuffer.

For a example of the complexity of classes and methods, see the Java
documentation for the StringBuffer class at
http://java.sun.com/j2se/1.4.2/docs/...ingBuffer.html
(local copy)

In the same way, numbers in Java have become a formalization of many
classes: Double, Float, Integer, Long... and each has a bunch of
"methods" to operate or convert from one to the other.

Instead of
aNumber = 3;
print aNumber^3;

In Java the programer needs to master the ins and outs of the several
number classes, and decide which one to use. (and if a program later
needs to change from one type of number to another, it is often
cumbersome.)

This Object Oriented Programing style and dedicated languages (such as
C++, Java) have become a fad like wild fire among the programing mass
of ignoramuses in the industry. Partly because of the data-centric new
perspective, partly because the novelty and mysticism of new syntax and
jargonization.

It is especially hyped by the opportunist Sun Microsystems with the
inception of Java, internet, and web applications booms around 1995. At
those times, OOP (and Java) were thought to revolutionize the industry
and solve all software engineering problems, in particular by certain
"reuse of components" concept that was thought to come with OOP.

As part of this new syntax and purity, where everything in a program is
of Classes and Objects and Methods, many complex issues and concept
have arisen in OOP.

We now know that the jargon Class is originally and effectively just a
boxed set of data and subroutines, all defined inside a subroutine. And
the jargon "Object" is just a variable that has been set to this super
subroutine. And the inner subroutines are what's called Methods.

----------
to be continued tomorrow.

This is part of an installment of the article
“What are OOP's Jargons and Complexities”
by Xah Lee, 20050128. The full text is at
http://xahlee.org/Periodic_dosage_dir/t2/oop.html

© Copyright 2005 by Xah Lee. Verbatim duplication of the complete
article for non-profit purposes is granted.

The article is published in the following newsgroups:
comp.lang.c,comp.lang.c++,comp.lang.lisp,comp.unix.programmer
comp.lang.python,comp.lang.perl.misc,comp.lang.scheme,comp.lang.java.programmer
comp.lang.functional,comp.object,comp.software-eng,comp.software.patterns

Xah
xah@xahlee.org
∑ http://xahlee.org/

Xah,

> The article is published in the following newsgroups:

Are you interested in critical review of the article, or just trying to
make new friends ?

Laurent

On 23 May 2005 08:40:28 -0700
"Xah Lee" <xah@xahlee.org> wrote:

> to be continued tomorrow.

Hopefully not.

___________________
/| /| | |
||__|| | Please do |
/ O O\__ NOT |
/ \ feed the |
/ \ \ troll |
/ _ \ \ ______________|
/ |\____\ \ ||
/ | | | |\____/ ||
/ \|_|_|/ \ __||
/ / \ |____| ||
/ | | /| | --|
| | |// |____ --|
* _ | |_|_|_| | \-/
*-- _--\ _ \ // |
/ _ \\ _ // | /
* / \_ /- | - | |
* ___ c_c_c_C/ \C_c_c_c____________


--
Stefaan
--
As complexity rises, precise statements lose meaning,
and meaningful statements lose precision. -- Lotfi Zadeh

Stefaan A Eeckels wrote:

> > to be continued tomorrow.
>
> Hopefully not.

Stefaan, accusations of trolling are a mud that splatters easily on the
thrower.

--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand

On Mon, 23 May 2005 19:03:51 GMT
"Phlip" <phlip_cpp@yahoo.com> wrote:

> Stefaan, accusations of trolling are a mud that splatters easily on the
> thrower.

It's a foul-mouthed troll in Unix newsgroups, and posted this same
drivel in comp.lang.c,comp.lang.c++,comp.lang.lisp, and
comp.unix.programmer (but as a separate post from the one here). One of
its previous efforts (crossposted to comp.lang.lisp,comp.lang.scheme,
comp.lang.c, comp.unix.programmer and comp.lang.functional) started as
follows:

| Let me expose one another fucking incompetent part of Python doc, in
| illustration of the Info Tech industry's masturbation and ignorant
| nature.

and another one (cross-posted to comp.unix.programmer,alt.unix.geeks,
comp.os.linux.advocacy and comp.unix.solaris):

| please spread the debunking of the truncating line business of the
| fucking unix-loving fuckheads, as outlines here:
| http://xahlee.org/UnixResource_dir/w...cate_line.html

The less reaction it gets, the faster it'll disappear.

--
Stefaan
--
As complexity rises, precise statements lose meaning,
and meaningful statements lose precision. -- Lotfi Zadeh

The Rise of “Static” versus “Instance” variables

In a normal programing language, variables inside functions are used by
the function, called local variables.

In OOP paradigm, as we've seen, super-subroutines (classes) are
assigned to variables (instantiation), and the inner-subroutines
(methods) are called thru the variables (objects). Because of this
mechanism, what's once known as local variables (class variables) can
now also be accessed thru the assigned variable (objet) by design. In
OOP parlance, this is to say that a class's variables can be accessed
thru the object reference, such as in myObject.data=4. For example:
mySurface = new a_surface();
mySurface.coordinatesList={...} // assign initial coordinates

However, sometimes a programmer only needs a collection of variables.
For exmple, a list of colors:
black = "#000000";
gray = "#808080";
green = "#008000";

In pure OOP, data as these now come with a subroutine (class) wrapper:
class listOfColors() {
black = "#000000";
gray = "#808080";
green = "#008000";
}

Now to access these values, normally one needs to assign this
subroutine (class) to a variable (instantiation) as to create a object:
myColors = new listOfColors(); // instantiation! (creating a "object")
newColor = myColors.black;

As a workaround of this extraneous step is the birth of the concept of
“static” variables. (with the keyword “static” in Java) When a
variable is declared static, that variable can be accessed without
needing to instantiate its class. Example:
class listOfColors() {
static black = "#000000";
static gray = "#808080";
static green = "#008000";
}
newColor = listOfColors.black; // no instantiation required

The issue of staticality is also applicable to inner-subroutines
(methods). For example, if you are writing a collection of math
functions such as Sine, Cosine, Tangent... etc, you don't really want
to create a instance in order to use. Example:
class mathFunctions() {
static sin (x) {...}; // a static method
...
}
print mathFunctions.sin(1); // no need to create object before use


The non-static variant of variables and methods are called “instance
variables” or “instance methods”, or collectively “instance
members”. Note that static members and instance members are very
different. With static members, variables and methods can be called
without creating a object. But more subtly, for a static variable,
there is just one copy of the variable; for instance variables, each
object maintains its own copy of the variable. A class can declare just
some variables static. So, when multiple objects are created from the
class, some variables will share values while others having independent
copies. For example:
class a_surface() {
static pi; // a static variable
coordinatesList; // a instance variable
...
};
a_surface.pi=3.1415926; // assign value of pi for all
a_surface objects
mySurface1 = new a_surface();
mySurface1.coordinatesList={...} // assign coordinates to one a_surface
object
mySurface2 = new a_surface();
mySurface2.coordinatesList={...} // assign coordinates to another
a_surface object

The issues of static versus instance members, is one complexity arising
out of OOP.

------------
to be continued tomorrow.

This is part of an installment of the article
“What are OOP's Jargons and Complexities”
by Xah Lee, 20050128. The full text is at
http://xahlee.org/Periodic_dosage_dir/t2/oop.html

© Copyright 2005 by Xah Lee. Verbatim duplication of the complete
article for non-profit purposes is granted.

The article is published in the following newsgroups:
comp.lang.c,comp.lang.c++,comp.lang.lisp,comp.unix.programmer
comp.lang.python,comp.lang.perl.misc,comp.lang.scheme,comp.lang.java.programmer
comp.lang.functional,comp.object,comp.software-eng,comp.software.patterns

Xah
xah@xahlee.org
∑ http://xahlee.org/

The Rise of “Constructors” and “Accessors”

A instantiation, is when a variable is assigned a super-subroutine
(class). A variable assigned such a super-subroutine is now called a
instance of a class or a object.

In OOP practice, certain inner-subroutines (methods) have developed
into specialized purposes. A inner-subroutine that is always called
when the super-subroutine is assigned to a variable (instantiation), is
called a constructor or initializer. These specialized
inner-subroutines are sometimes given a special status in the language.
For example in Java the language, constructors are different from
methods.

In OOP, it has developed into a practice that in general the data
inside super-subroutines are supposed to be changed only by the
super-subroutine's inner-subroutines, as opposed to by reference thru
the super-subroutine. (In OOP parlance: class's variables are supposed
to be accessed/changed only by the class's methods.) Though this
practice is not universal or absolute. Inner-subroutines that change or
return the value of variables are called accessors. For example, in
Java, a string class's method length() is a accessor.

Because constructors are usually treated as a special method at the
language level, its concept and linguistic issues is a OOP machinery
complexity, while the Accessor concept is a OOP engineering complexity.

-----
to be continued tomorrow.

This is part of an installment of the article
“What are OOP's Jargons and Complexities”
by Xah Lee, 20050128. The full text is at
http://xahlee.org/Periodic_dosage_dir/t2/oop.html

© Copyright 2005 by Xah Lee. Verbatim duplication of the complete
article for non-profit purposes is granted.

The article is published in the following newsgroups:
comp.lang.c,comp.lang.c++,comp.lang.lisp,comp.unix.programmer
comp.lang.python,comp.lang.perl.misc,comp.lang.scheme,comp.lang.java.programmer
comp.lang.functional,comp.object,comp.software-eng,comp.software.patterns

Xah
xah@xahlee.org
∑ http://xahlee.org/

The Rise of “Constructors” and “Accessors”

A instantiation, is when a variable is assigned a super-subroutine
(class). A variable assigned such a super-subroutine is now called a
instance of a class or a object.

In OOP practice, certain inner-subroutines (methods) have developed
into specialized purposes. A inner-subroutine that is always called
when the super-subroutine is assigned to a variable (instantiation), is
called a constructor or initializer. These specialized
inner-subroutines are sometimes given a special status in the language.
For example in Java the language, constructors are different from
methods.

In OOP, it has developed into a practice that in general the data
inside super-subroutines are supposed to be changed only by the
super-subroutine's inner-subroutines, as opposed to by reference thru
the super-subroutine. (In OOP parlance: class's variables are supposed
to be accessed/changed only by the class's methods.) Though this
practice is not universal or absolute. Inner-subroutines that change or
return the value of variables are called accessors. For example, in
Java, a string class's method length() is a accessor.

Because constructors are usually treated as a special method at the
language level, its concept and linguistic issues is a OOP machinery
complexity, while the Accessor concept is a OOP engineering complexity.

-----
to be continued tomorrow.

This is part of an installment of the article
“What are OOP's Jargons and Complexities”
by Xah Lee, 20050128. The full text is at
http://xahlee.org/Periodic_dosage_dir/t2/oop.html

© Copyright 2005 by Xah Lee. Verbatim duplication of the complete
article for non-profit purposes is granted.

The article is published in the following newsgroups:
comp.lang.c,comp.lang.c++,comp.lang.lisp,comp.unix.programmer
comp.lang.python,comp.lang.perl.misc,comp.lang.scheme,comp.lang.java.programmer
comp.lang.functional,comp.object,comp.software-eng,comp.software.patterns

Xah
xah@xahlee.org
∑ http://xahlee.org/

I think u have got most of thigns correct except things about OO.

The jargons, if u like to call it so, of OO are
1. Abstraction - The most powerful benefit that we derive form
programming OO way is abstraction. Modeling of problem space in terms
of objects, i.e the software entities should tend to emulate actual
behaviour as envisaged or showed by real world entity.

Other jargons used in context of OO are
polymorphism

then inheritance

may not be in same order for everyone.

Now Computer world needs more of people with better abstraction than
geeks who tends to lost in subroutings, ADT, loop, switch, recursive
calls, inline etc.

the Rise of “Access Specifiers” (or, the Scoping Complexityof OOP)

In programing, a variable has a scope — meaning where the variable
can be seen. Normally, there are two basic models: dynamically scoped
and lexically scoped. Dynamic scoping is basically a time based system,
while lexical scoping is text based (like “what you see is what you
get”). For example, consider the following code:
subroutine f() {return y}
{y=3; print f()}

In dynamic scoping, the printed result is 3, because during evaluation
of the block all values of y is set to 3. In lexical scoping, “y”
is printed because any y in the block is set to 3 before f is called.
With regards to language implementation, Dynamic Scoping is the
no-brainer of the two, and is the model used in earlier languages. Most
of the time, lexical scoping is more natural and desired.

Scoping is also applicable to subroutines. That is to say, where
subroutines can be seen. A subroutine's scope is usually at the level
of source file (or a concept of a module/package/library), because
subroutines are often used in the top level of a source file, as
opposed to inside a code block like variables.

In general, the complexity of scoping is really just how deeply nested
a name appears. For example see in the following code:
name1; // top level names. Usually subroutines, or global
variables.
{
name2 // second level names. Usually variables inside subroutines.
{
name3 // deeper level names. Less often used in structured
programing.
}
}

If a programing language uses only one single file of commands in
sequence as in the early languages such as BASIC, there would be no
scoping concept. The whole program is of one single scope.

OOP has created a immense scoping complexity because its mode of
computing is calling nested subroutines (methods) inside subroutines
(classes). We detail some aspects in the following.

In OOP, variables inside subroutines (class variables) can also be
accessed thru a reference the subroutine is assigned to (that is, a
object). In OOP parlance: a variable in a class has a scope, while the
same variable when the class is instantiated (a objet) is a different
scoping issue. In other words, OOP created a new entity “variable
thru reference” that comes with its own scoping issue. For example:
class a_surface() {
coordinates={...}; // a variable
}

class main() {
mySurface = new a_surface();
mySurface.coordinates = {...}; // the same variable
}

In the above code, the variable “coordinates” appears in two
places. Once as defined inside a_surface, and once as a instantiated
version of a_surface, that is, a object. The variable as thru the
object reference apparently has a entirely different scoping issue than
the same variable inside the subroutine (class) definition. The
question for OOP language designers is: what should the scope be for
variables referred thru objects? Within the class the object is
created? within the class the variable is defined? globally? (and what
about inherited classes? (we will cover OOP inheritance later))

As we've seen, methods are just inner-subroutines, and creating objects
to call methods is OOP's paradigm. In this way, names at the
second-level programing structure often associate with variables (and
inner-subroutines), is now brought to the forefront. This is to say,
the scoping of subroutines are raised to a level of complexity as the
scoping of variables. (they are now both in the 2nd level of names (or
deeper).)

All in all, the scoping complexities of OOP as applied to different OOP
entities (classes, class variables, class's methods, object variables
and methods) is manifested as access specifiers in Java. In Java,
access specifiers are keywords “private”, “protected”,
“public”, used to declare the scope of a entity. Together with a
default scope of no-declaration, they create 4 types of scope, and have
entirely different effects when used upon a variable, a method, a
constructor, and a class.

See this tutorial of Java's access specifiers for detail:
http://xahlee.org/java-a-day/access_specifiers.html
-----
to be continued tomorrow.

This is part of an installment of the article
“What are OOP's Jargons and Complexities”
by Xah Lee, 20050128. The full text is at
http://xahlee.org/Periodic_dosage_dir/t2/oop.html

© Copyright 2005 by Xah Lee. Verbatim duplication of the complete
article for non-profit purposes is granted.

The article is published in the following newsgroups:
comp.lang.c,comp.lang.c++,comp.lang.lisp,comp.unix.programmer
comp.lang.python,comp.lang.perl.misc,comp.lang.scheme,comp.lang.java.programmer
comp.lang.functional,comp.object,comp.software-eng,comp.software.patterns

Xah
xah@xahlee.org
∑ http://xahlee.org/