Object Programing vs Objective C

[rex ballard]

> My earlier posting regarding Objective C elicited a number of responses,
> many of whom wished to know more.
 
Many of these notes also apply to Object Oriented Design.
 
> The primary advantages of object programming and Objective C are
> improved modularity, reduced code bulk (lines of code), and a better
> mapping between many problems and the software.

This is a benefit of OOD as well as Objective C.
 
> I was originally attracted to object programming because it could have
> solved some of the problems I ran into developing a dynamic display editor
> (completed in C a year and a half ago).  Specifically, I think that using
> Objective C I could have built the editor in 4-5,000 lines of code rather
> than the 20,000 or so it actually took.  The result would have had better
> modularity and taken perhaps 35% less time to complete.  Powerful
> incentives.

Using Object Oriented Design, it was possible to condense 6 different audit
trail routines normally requiring 20,000 lines of code each into a single
package of less than 3,000 lines.  This included primitives normally included
with Objective C.  5/1 - 10/1 reduction is typical just from design.

> Objective C is a preprocessor for the C language.  It adds SMALLTALK-like
> messaging, objects, classes, and inheritance to C.
> Normal C code is passed through unchanged, so you keep all of C.

However, making transitions between "function calls" and "Object calls" can
get a bit confusing.  Normally, function calls are used in speed critical
situations.

> Objects contain both code and data.  The data is private and can (normally)
> only be accessed directly by the object's code (as usual in C, there are
> ways to get around this).  Every object is a member of a class.

> Each method corresponds to a message that the object
> understands.  Programming in Objective C is mostly a matter of writing
> classes.

 object -> data_pointer -> data
	   class_pointer -> Type_Class()
-------------------------------------------------------------
	Type_Class(Action)
	{
	    switch(Action)
	    case NEW:	malloc(...);	/* routine to create this object */
	    case PRINT: printf(...);	/* this is a "quicky cheat" */
	    case SCAN:	scanf(...);
	    default: SubType_Class(Action,...);	/* use lower level classes */
		/* default action would normally be a for loop calling
			each object (member) in the complex object. */
	}

> In summary, objects are chunks of code and data with a single pointer to
> the whole mess, rather than a pointer to the data and a pointer to each
> function that works on the data as in conventional data hiding approaches
> in C.  This improves modularity at a very fundimental level.

> Reduction in code bulk can save enormous amounts of money in large
> systems.  According to Putnam, a software metrician, life cycle software
> cost is proportional to the cube of code bulk.  Since theoretical
> consideration and some empirical evidence suggest that object
> programming can reduce code bulk by a factor of 2 to 10, in principle cost
> should be reduced by a factor of 8 to 1000.  I don't know if the savings are
> that large, but they may be substantial.

  5/1 - 10/1 reduction is typical just from Object Oriented Design.

> Object programming is not appropriate for all problems.  It has been used
> for compilers, operating systems, simulations, and user interfaces at
> least.  I'm not sure exactly what the boundaries of usefulness are.

  Normally, speed is a significant factor.


The easiest way to look at the benifits of Objective Design is to build
an Action/Data hierarchy/matrix.

For example: a record contains
update date (mm/dd/yy), creation date (mm/dd/yy), name, telphone ...

update date and creation date are different objects in the same class.

dd yy mm are different classes with common sub classes.

this is the "Class hierarchy".

The actions to Search and Sort are:
Search - input, get, compare, print
Sort   - get, compare, print 

The matrix becomes:

	date	name	phone  number string
input	 d	 d	 d	x	x
edit	 x	 x	 x	x	x
get	 d	 d	 d	x	x
compare	 x	 d	 x	x	x
print	 x	 d	 x	x	x

x=execute unique code
d=use default for each member of object (lower class)

instead of the number of lines/modules being actions*types*members
it becomes actions*(types)+members.
The basic concept is similar to that of sort(3), but with better organization.


After being introduced and thoroughly confused by PPI's concept of Object
Oriented Design, some books/articles to read for simplification/clarification
are:

Smalltalk-80 (The language and its implementation)  A comprehensive book on
both Object Oriented Design and Smalltalk-80.  Caution, after reading this,
you will want the real thing (Smalltalk-80).

FORTH Meets Smalltalk - Journal of Forth Application and Research.  Even
if you hate FORTH, this article describes in 10 pages, what would normally
take several weeks to digest.

Byte-Aug 1981. A whole series of articles on Smalltalk and Object Oriented
Design.

Also Byte 1984-5 contains some good articles, particularly the issue containing
"Software Frameworks" (I don't have it at my desk so I don't know which one)

Object Oriented Design combines the best of Yourdon and Warnier-Orr.  The
approach yields a complete design.

Summary:  Objective C is an excellent means to the stated end - concise
maintainable software.  Without a clear understanding of both Object
Oriented Design and Objective Programming, it is like a piano player
trying to play the violin for the first time.  The pianist knows
how to make beautiful music, but not on that instrument.

Objective C is only one of several approaches to Object Oriented Design,
others such as NEON, Smalltalk-80, and Smalltalk-in-FORTH offer such
advantages as interactive compilation, debug, and tracing.  Objective
C or an Object Oriented System in a compiled language offer better
speed.

Objective C boasts of Large Scale Integration of software, but you
still "solder in the chips".  Other alternatives offer MSI, but in
a "breadboard" environment.

Based on articles and course notes from PPI, I found their documentation
confusing, as did a number of engineers.  After doing further research
into the basic concept - often billed as Object Oriented Design, Software
Frameworks.  After reading other articles, the basic concepts of PPI
become much clearer.

I have no bias for or against any of these products, and the opinions
offered are my own/ they do not reflect policies or opinions of CCI.