- 1.1 Nature of an Object
- 1.2 What Is a Software Object?
- 1.3 Gaining an Understanding
- 1.4 Software Components
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.4 Software Components
Although we allude to software components having an analogy to hardware chips, this is only true in a most general sense. Software components created with the rich vocabularies of the programming language, and based upon the constructs created by the programmer's mind, have a far greater range of flexibility and power for problem solving than hardware chips. Of course, therein lays a great deal of the complexity nature of software programs. However, the software components ride on top of the hardware chips adding another complete level of abstraction. The deterministic logic involved in a complex LSI chip is very impressive. But the LSI chip is very limited in the possibility of forming any synergist relationship with a human mental object.
The more we dwell upon the direction of the .NET Framework's object model, in all its technologies, the more it seems to feel like we are externalizing the mind's use of mental object behavior mechanics. Certainly, the object relationships formed with linking and embedding of software objects, via interfaces, doesn't look much like the dendrite distribution of influences on clusters of neurons. But certainly now, one software object is starting to effect one or more other software objects to accomplish its goal.
Let's look at a control object or collection of control objects from an everyday practical standpoint that we are using in other engineering fields. One of our early loves is the automobile. We can hardly wait to learn how to drive one. Notice, we said drive one, any one. We have done such a great job on our encapsulation and interface exposure that we can learn to drive any kind and be able to drive any other kind. The automobile object we interact with has three primary interface controls: steering wheel, throttle, and brake. We realize that encapsulated within that automobile object is many internal functions. We can be assured that these control interfaces will not change from automobile object to automobile object. In other words, if we go from a General Motors car to a Ford car we can depend on the same functionality of these control interfaces.
Another characteristic of a software object is persistence. Persistence of an object is learned very early by a child. Eventually, when we show a child a toy and then hide it behind our back, the child knows the toy still exists. The child has now conceptualized the toy object as part of its mental set of objects. As the programmer does a mental conceptualization of various software objects, this will lead to a high level of persistence of the objects in the programmer's mind. Because one of the main features of standard software objects is reusability, the efficiency of the programmer will continue to increase as the standard objects are conceptualized in the programmer's mental model.
Polymorphic behavior is another characteristic that can be implemented in a software object. Probably one of the earlier forms that a child realizes has different behavior, based upon form, is the chair object. The chair object is polymorphic in that its behavior depends on its form. We have rocking chairs, kitchen chairs, lounge chairs, and so on. This idea of form and related behavior has created a whole field of study called morphology. Certainly, this is a key idea in how we relate cognitively to various objects. Not only does the clustering of our objects have form relationships, the internal constructs of the objects have a form relationship. There is a definite relationship between the logic flow of a program and the placement of the various meaningful chunks of a program. This is somewhat different than a pure polymorphic nature of a function, but does point out that we should be aware of the morphology of our objects and their parts and placement in our program.