Your analogy is well presented and useful. Curiously, I don't think of objects as machines - but as people.

The idea of a contract, of there being requirements and promises attached to each method call, to me is very much like any business transaction between two people. There are rules (the spec or API), and if those rules are fulfilled, every thing runs smoothly. But if the rules are broken, all hell breaks loose (irate voiceover: "C'mon! We had a deal, man!")...The spec is like a person's job description. Instantiation is like hiring someone to fill the job. The hiding of implementation is could be an opaque wall behind the person providing the service, out of which "the answer" magically comes from a small army of hidden workers...a paranoid Kafka-esque nightmare of sorts...

I hereby thank the editors for splitting up the huge article in three more manageable chunks. Often my mind starts to spin and I get sick when I see text that is more than say 3 pages long. Again, thank you so much!

Martin Gardner (who may be remembered for his Scientific American columns) once wrote that special-purpose elctronic logic machines had a short life because of the ability to manipulate lower-levels of formal logic in general-purpose computers via software. (Gardner, Logic Machines and Diagrams, p.137.)

Because a general-purpose machine assumes the roles of various executing objects, these objects may be perceived as being equivalent to a machine. The notion of purpose moves upward, above the actual machine to the notion of a virtual machine.

Accordingly, it may be useful to think of an object's interface as a controller, not unlike the classic thermostat example. An object (machine) may support more than one interface (controller). Each controller (interface) is distinguished by a particular objective of control (i.e., special purpose) to be realized by the machine.

The notions of purpose and control may be useful in exploiting the proposed metadata feature of J2SE 1.5. See Joshua Bloch's interview, which ...leads to a "declarative" programming style where the programmer says what should be done and tools emit the code to do it.

http://java.sun.com/features/2003/05/bloch_qa.html

I think people are missing the point, this is an issue about usability. It's a human factors problem.

see my blog:

http://www.freeroller.net/page/ceperez/20030514#human_factors_design_of_apis

Great article, I think it touches upon the heart of software engineering. It's a human factors thing, and one sentence that made the connection for me was:

"The two main qualities I look for in any machine are functionality and usability. "

This has actually been Jakob Nielsen's mantra for years, and trust me, he knows human factors:

From http://www.useit.com/alertbox/20000709_comments.html

<quote>
"I usually promote usability, but truth be told, a better model is to analyze the usefulness of a service which is a combination of two parameters:

1. Utility: what does the service do; how closely does it match users' needs
2. Usability: how easy, efficient, and pleasant is it to use the service

</quote>

Replace 'service' with 'object' (an interesting issue in its own right :) and you can see the similarity.

I guess my mantra should be 'to make usefull things usable'.

Some similar ideas are put forth in "Object Technology: A Manager's Guide" by David A. Taylor. I'm hoping Bill continues to move ahead with his book project; it will be a good read.

Thinking of objects as machines is one of the worst conceptualizations that you could ever make when doing OO development. If you want to re-label your “objects” as “modules” then I will whole heartedly agree with your approach, as I did with Developers in the mid 1980’s when modular programming was king. But back then the average system development was smaller and more engrossed in technology details that has not yet become standards. The goal of 99% of all system developments is to make the computers in a knowledge domain act and understand the domain like the humans do, in the same knowledge domain. This is, and has always been, the goal of OO development since it first started; BUT this goal is frequently not the goal of anyone who thinks OO programming languages are cool. OO development is not 99% OO programming. No modern development is influenced by its chosen programming languages by more than a few percent – or should not be. If it is, then you have the wrong mix of people on your team. An OO language merely captures User’s knowledge so that a Developer can use the program to teach a computer the same knowledge (by running the program).

If there is ever a mismatch between what the (human) Users understand and what the computers understand then a problem occurs every time a User speaks to a Developer about making a change to their program. The User describes the addition of a new "duck-like" feature to the program however the Developer goes and builds a "swan-like" feature. The Developer applies the “objects are machine” approach to the User’s requirements and comes up with a program structure. Obviously, the User interface must be as the User expects but the internal arrangement of the new knowledge in the computer’s mind (i.e. its knowledge) does not correspond to the arrangement of knowledge in the User’s mind. While this approach to system building works during the initial development, when the same Developers are onsite, it fails miserably during maintenance when they have left and new staff take up the reins.

The reason is simple. The new Developer comes in and listens to the User’s new requirements. These requirements are expressed in the language of the domain as the User understands the domain concepts. The Developer captures the new knowledge, the User wants to teach the computer, along with a bit of the knowledge the User currently thinks the computer has in its memory given to set the context of the development for the new Developer. The Developer goes to the program (the sole source of the computer’s knowledge) and tries to identify what must be there, according to the User’s description of the context. But, alas, they cannot locate that knowledge. The original Developer mushed it into what they thought was the best knowledge representation (When the analysis phase of a development takes too long people call it “analysis paralysis” as a derogatory expression implying the phase is a waste of time. However, when the situation I describe above occurs in a real project, I see worse cases of “Development Paralysis” than the former.)

The Developer is stuck. Why did the earlier Developer arrange code (the computer’s knowledge) as they did? Usually there is no trace of the original Developers thinking.

The route from capturing the User’s description of the knowledge that the computer must have (their requirements) to the expression of that knowledge in a programming language must be standardized. There is no need for cool “object is a machine” type of thinking. It slows the development process. Capture the knowledge the User wishes to give to the computer and you are done. Add a GUI and a database, and distribute the code across several hosts and you have the start of an implementation.

So far the OO approach does this very well up to and including domains that require deductions equivalent to those taught in AI classes (i.e. pretty sophisticated programs). The “objects as machine” or as personalities are irrelevant and distract the cool thinkers from the goal of completing the system in a most maintainable way. What the traditional OO approach has taught us is that very complex systems can be built and maintained by teams BUT they all have to know what they are doing. It is hard enough to extract knowledge from Users and record it in a standard form. Adding in the design steps of re-arranging the knowledge to YOUR way of thinking slows development and makes the program more difficult to maintain.

Thinking of objects as machines is one of the worst conceptualizations that you could ever make when doing OO development. If you want to re-label your “objects” as “modules” then I will whole heartedly agree with your approach, as I did with Developers in the mid 1980’s when modular programming was king. But back then the average system development was smaller and more engrossed in technology details that has not yet become standards. The goal of 99% of all system developments is to make the computers in a knowledge domain act and understand the domain like the humans do, in the same knowledge domain. This is, and has always been, the goal of OO development since it first started; BUT this goal is frequently not the goal of anyone who thinks OO programming languages are cool. OO development is not 99% OO programming. No modern development is influenced by its chosen programming languages by more than a few percent – or should not be. If it is, then you have the wrong mix of people on your team. An OO language merely captures User’s knowledge so that a Developer can use the program to teach a computer the same knowledge (by running the program).

If there is ever a mismatch between what the (human) Users understand and what the computers understand then a problem occurs every time a User speaks to a Developer about making a change to their program. The User describes the addition of a new "duck-like" feature to the program however the Developer goes and builds a "swan-like" feature. The Developer applies the “objects are machine” approach to the User’s requirements and comes up with a program structure. Obviously, the User interface must be as the User expects but the internal arrangement of the new knowledge in the computer’s mind (i.e. its knowledge) does not correspond to the arrangement of knowledge in the User’s mind. While this approach to system building works during the initial development, when the same Developers are onsite, it fails miserably during maintenance when they have left and new staff take up the reins.

The reason is simple. The new Developer comes in and listens to the User’s new requirements. These requirements are expressed in the language of the domain as the User understands the domain concepts. The Developer captures the new knowledge, the User wants to teach the computer, along with a bit of the knowledge the User currently thinks the computer has in its memory given to set the context of the development for the new Developer. The Developer goes to the program (the sole source of the computer’s knowledge) and tries to identify what must be there, according to the User’s description of the context. But, alas, they cannot locate that knowledge. The original Developer mushed it into what they thought was the best knowledge representation (When the analysis phase of a development takes too long people call it “analysis paralysis” as a derogatory expression implying the phase is a waste of time. However, when the situation I describe above occurs in a real project, I see worse cases of “Development Paralysis” than the former.)

The Developer is stuck. Why did the earlier Developer arrange code (the computer’s knowledge) as they did? Usually there is no trace of the original Developers thinking.

The route from capturing the User’s description of the knowledge that the computer must have (their requirements) to the expression of that knowledge in a programming language must be standardized. There is no need for cool “object is a machine” type of thinking. It slows the development process. Capture the knowledge the User wishes to give to the computer and you are done. Add a GUI and a database, and distribute the code across several hosts and you have the start of an implementation.

So far the OO approach does this very well up to and including domains that require deductions equivalent to those taught in AI classes (i.e. pretty sophisticated programs). The “objects as machine” or as personalities are irrelevant and distract the cool thinkers from the goal of completing the system in a most maintainable way. What the traditional OO approach has taught us is that very complex systems can be built and maintained by teams BUT they all have to know what they are doing. It is hard enough to extract knowledge from Users and record it in a standard form. Adding in the design steps of re-arranging the knowledge to YOUR way of thinking slows development and makes the program more difficult to maintain.

Good API designs happen when designers have a user-oriented focus and a philosophy that values both the functionality and the usability of the resulting API.

Does the object model of the interpreted domain reflect use of objects in terms of their collective associations when activated. Can it be added too as simply ? Simply put are there Objects available to provide for the environments requirements ? If so , then you have defined the machine aspect of the software. Machines have parts. They may be useless but can reasonably be apart of an objects instance. For example : Brakes on an automobile are not used when stepping on the gas pedal, except sometimes. That's machine accountability with an invariant twist.

To set the proper places for your machine and its parts fit it to the computer. Will it fit on which type of machines is a further defining question of your objects ? That's a utility perspective applied to the objects.

Without loosing a natural perspective of the objects within an object model set the objects up to work efficiently.


Test it, measure it, run it, sell it, add to it, tune it.

Yes, Objects make machines and is comprised of object parts. They are a natural interpretation of natural environments extended from the human machine or is that....the machine human.


Hawker.

i am not sure where to post this but i have discovered a fractal formula that looks incredibly like an interference pattern of a hologram... is there any way to convert this to see if it contains a holographic image?Fractal1 {
fractal:
title="Fractal1" width=640 height=480 layers=1 resolution=720
credits="JAMES;1/3/2006"
layer:
method=multipass caption="Background" opacity=100
mapping:
center=0/0 magn=0.0009765625
formula:
maxiter=100 percheck=off filename="ldm.ufm" entry="DM0" p_p1=0.5/0.0
p_Op1=Addition p_Op2=Multiplication p_r1=None p_je=yes p_seed=0/0
p_bailout=4.0 f_fn1=cotan f_fn2=sqr f_fn3=cabs f_fn4=recip
inside:
transfer=none
outside:
transfer=linear
gradient:
smooth=yes rotation=-428 index=-328 color=16121855 index=-228
color=46591 index=-128 color=156 index=-428 color=8716288
opacity:
smooth=no index=0 opacity=255
}

ldm.ufm:DM0 {
;100 simple formulas rolled into 1
init:
z = @fn3(pixel)
loop:
if (@je == true)
z = @fn4(z^2) + @seed
endif
if @Op1 == 0
pp1 = z + p1
elseif @Op1 == 1
pp1 = z - p1
elseif @Op1 == 2
pp1 = z * p1
elseif @Op1 == 3
pp1 = z / p1
else
pp1 = z ^ p1
endif
if (@r1 == 1 || @r1 == 3)
if pp1 == 0
pp1 = 1e-20
endif
pp1 = 1/pp1
endif
if @Op2 == 0
pp2 = p1+fn1(fn2(pp1))
elseif @Op2 == 1
pp2 = p1-fn1(fn2(pp1))
elseif @Op2 == 2
pp2 = p1*fn1(fn2(pp1))
elseif @Op2 == 3
pp2 = p1/fn1(fn2(pp1))
else
pp2 = p1^fn1(fn2(pp1))
endif
if (@r1 == 2 || @r1 == 3)
if pp2 == 0
pp2 = 1e-20
endif
pp2 = 1/pp2
endif
z=pp2
bailout:
|z|<=@bailout
default:
title="DM0"
method = multipass
periodicity = 0
param p1
caption="Parameter 1"
default=(0.5,0.0)
endparam
param Op1
caption = "Operator 1"
enum = "Addition" "Subtraction" "Multiplication" "Division" "Exponent"
hint = "P1 [Op2] fn1(fn2(z [Op1] P1))"
default = 0
endparam
param Op2
caption = "Operator 2"
enum = "Addition" "Subtraction" "Multiplication" "Division" "Exponent"
hint = "P1 [Op2] fn1(fn2(z [Op1] P1))"
default = 2
endparam
param r1
caption="Reciprocate"
enum = "None" "Recip Oper1" "Recip Oper2" "Both"
default = 0
endparam
param je
caption = "Julia Component"
default = false
endparam
param seed
caption = "Julia Seed"
default = (0,0)
endparam
param bailout
caption="Bailout"
default=4.0
endparam
func fn1
caption = "Function 1"
default = sinh()
endfunc
func fn2
caption = "Function 2"
default = sqr()
endfunc
func fn3
caption = "Function 3"
default = ident()
endfunc
func fn4
caption = "Julia Function"
default = ident()
endfunc
}