Bill Venners writes: "Objects are invisible machines that programmers use as tools. When you design an object, you design a machine for programmers. I feel thinking of objects as machines is helpful, because it encourages you to focus not only on functionality when you design objects, but also on usability."
The two main qualities I look for in any machine are functionality and usability. If I buy a new cyclometer for my bicycle, for example, I want that cyclometer to work well -- to reliably keep accurate time, distance, and speed records. But I also want it to be easy to use. I want services I request often, such as switching the display between distance, time of day, and speed, to be quick and easy to access. I don't mind if less-used services, such as setting my tire size or the current time, are more difficult to access. But in no case do I want to invest more than a few minutes of my time pressing buttons or consulting the instruction booklet to access any functionality offered by my cyclometer.
Similarly, if I instantiate a class in an API, I want the resulting object to work well. I want the object to do what it promises to do, in an efficient manner, every time I ask it. But I also want the object to be easy to use. I want its interface to allow me, with no more than a few minutes searching through the API documentation, to figure out how to make the object perform the desired service.
What do you think of the ideas presented in the article? Do you see design in this way?
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.
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:
<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 1980s 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 Users 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 Users 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 computers mind (i.e. its knowledge) does not correspond to the arrangement of knowledge in the Users 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 Users 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 computers knowledge) and tries to identify what must be there, according to the Users 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 computers knowledge) as they did? Usually there is no trace of the original Developers thinking.
The route from capturing the Users 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 1980s 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 Users 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 Users 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 computers mind (i.e. its knowledge) does not correspond to the arrangement of knowledge in the Users 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 Users 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 computers knowledge) and tries to identify what must be there, according to the Users 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 computers knowledge) as they did? Usually there is no trace of the original Developers thinking.
The route from capturing the Users 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.
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 }
Previous Topic
