George Blankenship 1

Transcription

1 The introduction to Object Oriented Design will be based upon the design of a system written in an Object Oriented language, Java. This done for two reasons. The first reason is that Java is the language of choice at GWU for multiple reasons. The primary reason is that a free Java development environment is publicly available for both Windows and Linux (Unix) environments. It is generally the choice for Open Source development. The secondary reason is that the design patterns are stated in terms that naturally match an object oriented language; however, with understanding the design patterns can be used in all language environments. One of the objectives of this class to delve deeply the design patterns and uncover the basic intent of each pattern. By uncovering the basic intent, the pattern can then be used in all environments. It should be clear that the unspoken, but obvious objective of OOD is the creation of design elements that can be re-used in many diverse systems. The design patterns focus on reusable components that are not specific to a given application space but specific to components that exist many diverse spaces. George Blankenship 1

2 This lecture is divided into three general topics. The first topic is the rationale for the study of OOD. To be teleported into the study of an arcane subject would be relatively disturbing. OOD must be put in a perspective since it is not long before the study of OOD drops down to the examination of the basic patterns used to create a design. The good news is the examination of the patterns means that we will not spend a long period of time tripping over terms that are difficult to understand since they do not seem to have substance. The bad news is that the jump to patterns does not frame the need for the patterns. The second topic is the a discussion of Object Oriented Programming (OOP). The beginning of the road to OOD is using an object oriented approach to programming. This approach has proved to be transformative to the whole world of software development. The software development approach is now the development of components that can be reused in a diverse space and extended to create new components that meet close, but different purposes. The third topic is a short overview of Java. The overview s objective to re-affirm the intrinsic relationship between Java and OOP and thus a good basis for an investigation into OOD. George Blankenship 2

3 To many, Computer Science is the study of the art of programming. One examines various programming languages, database engines and operating system operation. This approach is a new paradigm. In the past, computer science focused on the core hardware (architecture), the internal structure and components of an operating system and the algorithms used in the generation of an executable. We are going to spend some time looking at the basis of this new paradigm. We will ignore the hardware and the operating system. We will look at a virtual environment that is created by an entity like the Java Virtual Machine (JVM) that makes objects seem real. For those familiar with Java, they will find all of this discussion somewhat familiar, even old and perhaps annoying. But it is this virtual world that we assume is real. All of our coding and eventually design is based upon the assumption that this virtual world is the real world. The movement from OOP in our discussion to OOD will be smooth and perhaps imperceptible. We will always talk about life in the virtual world, but we must be able to extend the concepts to the real world. This extension of the concepts leads to an understanding of the world of OOD. George Blankenship 3

4 The world of programming can be compared to a discussion between two human beings. The discussion is in reality one sided. One human (the controller or source) is giving instructions to the other (the machine or recipient). At times the machine responds to queries from the controller. All other communication is really from the controller to the machine. The controller speaks in a very stylized language and the questions can only elicit responses on subjects about the machine or entities that the machine touches. The exchange from controller to machine must be in a precise language since the machine is not able to ask questions eliciting clarification. Each sentence (or message) from the controller to the machine must be in the language that the machine understands. The controller has a concept of the task that must be performed by the machine. The controller must divide the task into a set of instruction units that perform smaller tasks. For example, the controller might divide a task to remove a cover into a set of unscrew the cover retaining screws tasks and then a lift the cover task. There is a transformation from the concept in the controller s mind to the language of the machine. The conversation is, thus, a sequence of sentences in the language of the machine. George Blankenship 4

5 It is of prime importance that the sentences (instructions) to the machine be given with clarity and without ambiguity. This is the same objective of any dialog in any language. The recipient of a language message (sentence) has a grammar context that must be present in order to understand the message. The grammar of a language is key to understanding during a dialog between two conversing individuals (or systems). This requirement to enable effective communication is well known. For example, every student studies the grammar of their native language throughout their formative education. The child learns basic grammar from his or her parents. This grammar allows the student to be understood; however, it not until the student s education that the exploration of effective speaking and writing leads him or her to a real exploration of grammar. In a similar manner, the first programming is much like the child. Instructions are formulated, but the machine might perform the task with a propensity for error or with unfortunate side effects such as an inefficiency in language statements or processing. It is only through the study of the grammar of programming that one begins to understand how to write more effective instructions for the machine. The first occasion to observe better grammar is the observation of code written by more experience programmers with the assumption that experience leads to some sort of improvement in the use of the language. The second occasion is the build on the experience of individuals that have studied the grammar of programming in general or an individual programming language. This class is a study of the grammar of programming. George Blankenship 5

6 John von Neumann defined the world of computers. (Understand that the computer, as we know it, did not exist during his life.) He described the computer as a stored program device that could solve problems. The solution to the problem was achieved by dividing the problem into a sequence of steps that when completed solved the problem. Turning this statement around, a problem is solvable on a computer if it can be divided into a sequence of finite steps that lead to its solution. If this cannot be done, the problem is (at least probably) not solvable on a computer (or computable). This basic truth is the fundamental impetus for OOP (and thus OOD). The solution to a problem is described as a sequence of tasks that when performed properly lead to a solution. The tasks are a decomposition of the problem into manageable entities that are individually performed. The tasks can also be decomposed into smaller tasks that are focused on smaller pieces of the problem (computation). One might generalize a task such that it is able to be adapted to a set of similar computations. The generalized task is the class in a object oriented (or based) language. A task is an object; that is, an instance of a class. The introduction of the class concept allows the programmer to focus on the tasks that define the computation rather than becoming overwhelmed with the complete computation. The actual processing is encapsulated in the class (task). With the encapsulation one can focus on the overall computation thread and maintain separation between tasks. George Blankenship 6

7 The trick in OOP is the definition of an object. Most of the programming lessons focus on an object is a item to be manipulated and, especially, real like a person. Let s call these objects as in class real. These objects are defined in terms of the real world attributes such as employee identification, personal identification or physique. The attributes are changed or read by passing messages to the object requesting a change to an attributes or the current status (value) of an attribute. When an employee joins a company, an object representing the employee would be created with the attributes that describe the real individual. The would be passed to other system components so that the employee is joined to (establishes a relationship with) the component. For example, the employee object might be passed to a manager object to establish a manager/managed relationship. There is another class of objects is those objects that represent purely program processing. An object is something that can store information (the attributes of the object) and perform an operation on the stored information (classically the object moves ). A programmatic object might be something like a relationship chain. For example, one might desire to sort a set the real objects into those with a particular attribute value (green objects). Another programmatic object might perform a computation on real object. For example, a context object might examine a number of objects (environmental attributes of a number of sensors) and set the operational context of the system to night. The context object is examined when video camera objects are activated. The programmatic object does not represent something that can be perceived (seen, touched, or heard); however, these objects are fundamental to a system. George Blankenship 7

8 With these notions of an object, we need to ask the question, What is an object? (exactly). An object is a simple entity that has state and behavior. State is the aggregation of all the characteristics of the object or the values stored in the object. For example, the state of a human being is the aggregation of the physical characteristics, the mental characteristics, the emotional characteristics, and any other characteristics that are stored within the human. One of the states of a human is asleep. Another is running. And yet another is speaking. Within a system, the object representing the human might only store a small subset of the actual human s characteristics. The characteristics of stored in the object are call the attributes of the object. Another type of attribute is a relationship (programmatic object). The manager object is related to all of the managed objects. Behavior is set of actions that the object is able to perform. All actions that an object performs can only affect or involve the object attributes. For example, an object may have the ability to reveal its attributes; that is a behavior. An object may have the ability to change its attributes or perform a computation based upon its attributes. The manager object might be able to reveal the total salary of all of the managed objects. George Blankenship 8

9 This brings us to the real reason for exploring this orientation (or focus) on objects. The use of objects in software may not seem reasonable or useful, at least at first. It may seem to be outright bizarre. It does position us to discover those components of the computation that might be generalized and re-used within the system or in another system. The most expensive component of a computation is not the electricity consumed performing the computation. It is not the cost of designing and building the computation engine. It is the cost of the design of the computation. In reality, cost is not just a function of design or creation, but design, creation and re-use. If the reuse is high, it will overwhelm the design and creation (manufacture) costs. An automobile manufacturer amortizes the design and manufacturing costs across the manufacturing of many, many automobiles. A computer manufacturer amortizes the development and manufacturing costs across many, many computers. If we can generalize an object and use in many times in an individual system, the cost to code (manufacture) the object is lessen. If one can use the object in multiple systems, the cost drops again (through amortization). George Blankenship 9

10 The generalization of an object is a class. An object is an instance of the class. Multiple objects can be instances of the same class. Each object is an independent entity and is not aware of other instances. In order to become aware, a relationship object (programmatic object) must be created (from a programmatic class). The class defines both the attributes of any object that can be an instance of the class and the behavior that can be exhibited by any object. The behavior of an object that is an instance of the class is initiated through the methods defined by the class. To clarify, a class defines the attributes of each object that is an instance of the class and the methods defined by the class are the access points to the behavior of the object instance. For example, if one wishes for an object to have a behavior that reveals the value of an attribute, the class must define a method that would be the access point to initiate the behavior. Each behavior that an instance object is to exhibit must have a method defined in the class. A class defines the attributes for each instance object and the methods that are used to affect the instantiated object s behavior. George Blankenship 10

11 The attributes of the class define the information stored within an instance object. There are two approaches to the definition of the attributes in a class. One approach allows the attributes on an instance object to be directly accessed; that is, the scope of the attributes is public (visible outside the object). This affords an efficiency of access. It has a tendency to globalize the data space. The other approach is to not allow public access to instance object attributes. All access is defined by the behavior of the instance objects; that is, the class must define a method to perform any direct manipulation of the attributes. The class must define a get method to read the current value of an attribute and a set method to change the current value of an attribute. Without these methods the attribute is not accessible. The first approach (public attributes) defeats the concept of encapsulation. Encapsulation principle hides the interior of an instance object and only exposes its behavior (public methods). Encapsulation allows the programmer to focus on the computation steps. The object s behavior is initiated by passing a message through a public entrance (method). The object s behavior is computation that was defined by task created in the decomposition of the overall computation. George Blankenship 11

12 The methods defined by the class are used to initiate the behavior of instance objects of the class. If one considers a decomposition of a computation (problem solution), the instance objects are steps in the decomposition. The methods (or the behavior initiated by a method) are the actual processing performed during the decomposed task. The invocation of a method includes a set of parameter values that are input to the method processing; the set of parameter values are described as a message. This approach allows one to describe the computation as a communication between the objects of a system. This approach continues the concept of decomposing a problem into a set of distinct tasks. The tasks communicate with each other via messages. With this approach, the problem space can be expanded to cover problems that require the use of distributed systems. With strict enforcement of encapsulation rules one can now describe the component classes by the public entrance (application program interface API) of the class. The API defines the behavior of all instance objects of the class. The set of classes now becomes a toolkit with the behavior of each tool defined by its API. George Blankenship 12

13 A system is now defined by the classes that are used to create the system. The coding focus is on the class. The actual processing is done by instances of the classes that are the system. In an completely object world even the system (program) is an instance object. An instance object is instantiated. The OS instantiates the program and invokes the method that starts the execution. The OS sends the program a message that defines the context for the execution (start up parameters). The commonly accepted procedure for instantiation of an object is the use of the special operator new. The new operator creates an instance of a class; an instance is created using the notation new <class name>(<object initialization message>). Once an instance object (object) has been created, the public attributes can be referenced using the notation object.<attribute name> and the public methods can be accessed using the notation object.<method name>(<input message>). While this notation is the Java syntax, it is also the syntax of most of the other OOP programming languages. George Blankenship 13

14 A simple example of instantiation notation is: Test testing = new Test(); Creates an instance object of the class Test with the object using the <null> message for initialization. The name of the object is testing. A simple example of the invocation of a behavior action is: testing.behaviorone(7, testing ); Invokes the method behaviorone passing the message 7, testing. This would cause the processing (behavoir) defined in the behaviorone message of the class to be performed. George Blankenship 14

15 Through inheritance a class B is able to inherit the characteristics of another class A. If class A has five attributes (A 1, A 2, A 3, A 4 and A 5 ), then B also has the attributes. If class A has three methods (M 1, M 2, and M 3 ), then B also has the methods. The class A is a proper subclass of B; all of the attributes and methods of class A are also attributes of B. The class B has the same behavior as the class A. Through inheritance we can build a class tree with all classes in the tree having the characteristics of the root of the tree. While this capability of creating a class tree with uniform characteristics, some implementations of OOP allow a class to redefine the inherited attributes and methods. This re-definition is call overloading. When a method is overloaded, the behavior of the new class changes. Thus the fact that class B has a sub-signature of class A, it may have a completely different behavior. The overload capability may lead to confusion when one is performing a code analysis. One of the objectives of the object oriented approach was to remove the need to inspect the code of every sub-component. George Blankenship 15

16 Through encapsulation one is able to hide the complexity of a class. A class A is able to define objects that will reside inside instantiations of the class A. The interior objects are completely hidden from the public view. The behavior of the class A includes the behavior of the interior objects. Through encapsulation one is able to build an extremely complex computational engine with a specialized interface tailor to a particular task. This allows the instantiation of a complex object with a simple interface. On the class web page in the section for Lesson 3, there is a link to the GCB Application Framework. This link will open the javadoc for the framework. The class MainGUI builds a simple window with a menu bar, text display area and the room for a panel that can be tailored for an individual application or not even present. The has a simple interface for the components of an application (system). The components can add to the menu bar, display text in the text display area and get the system clock in a standard form. The objective of this encapsulation is to supply a useful GUI for a diverse set of applications with a minimal investment. This approach does force the developer of the application to use the simple widgets of the GUI rather than (perhaps) more elegant widgets. George Blankenship 16

17 Since the objective of OOP is to reduce the coding of an application to the decomposition of the computation into tasks (objects), the design of an object oriented system can be reduced to addresses the relationships between object and the reuse of an approach that implements a relationship. That is the design objective is to create a design that has reusable and extendable components. Later in this class I will discuss an application that I developed for another class. This application (SerialLink) is used to help students validate their code to handle a serial communications link. This application s design uses the a set of object orients design concepts to create reusable components; these design concepts are focus in the GCB Application Framework that I mentioned earlier. For example, the GUI software is design to be embellished by a snap-in; in the case of SerialLink, the snap in is the class ConfigurationPanel. This snap-in add a panel to the GUI that includes a set of widgets to define the operating parameters. The actual validation engine uses a finite state machine (FSM) to control the processing of messages that move across the communication line. There are three snap-in to the FSM component that define analysis machines tailored to special conditions. The class AnswerConnection defines a snap-in to process incoming calls, while the class DialConnection defines a snap-in to generate an outgoing call. The class EchoConnection defines a snap-in to echo messages received on an active call. The class SerialConnection is a controlling component that interrogates the ConfigurationPanel for operating parameters and starts appropriate FSMs. The design of this system reuses classes that would answer the classic design issues in any system. George Blankenship 17

18 The use of OOD reduces the specifics of a system design to a set of templates (or approaches) to three fundamental aspects of every system. The first aspect is the creation of objects. On the surface this does not seem to a significant issue of a design, but in reality the creation of objects is a critical design component. There are objects within every system that have unique features that are imparted at creation. Unless these features are taken into consideration, the implementation of the design becomes convoluted and difficult with trap-doors that may cause issues at execution time. The creation of objects will be the first design aspect to be considered after we finish the overview lectures. The second aspect is the structure of system components. Selected objects within a system may form a set of objects with a special relationship. Once again, unless these special relationships are taken into consideration with classes supporting the relationships, the design and its implementation become tedious. The structure of system components is the second area of design to be considered. The third aspect is the behavior of system components. There are accepted approaches computational engines that are the best approach. The computational components of a system should use these approaches and, if possible, use computational classes to simplify the addition of these components. The SerialLink application above uses a FSM as the core computational component. A standard class StateMachine was included in GCB Application Framework to allow an application to use an FSM as the core of its computational approach. George Blankenship 18

19 Java is an object-based programming language. As with an language Java defines the form (syntax) and meaning (semantics) of the statements in the language. Java uses the C syntax and semantics, but extended them for use in a OOP environment. Java, unlike C++, is intrinsically object oriented. While C++ has object oriented statement constructs, it supports normal C constructs; one can float in and out of OOP when using C++. Every element of a Java program is a class; every executable component is an object. I must admit that Java supports class level code (static methods and attributes), but static methods are not really the same as C code. There is a discussion on the Java heritage that I m ignoring. Java was developed by Sun as a OOP language that required a system specific environment (JVM). The result is that Java is now available on just about every system and the Java applications are transportable from system to system without modification. This objective has been a focus of the computer industry for decades. Sun placed Java in the public domain, but had and has a major influence on the Java standard. It has been claimed that Java was really Sun s pin to pierce the Microsoft/Intel lock of computer systems. Paranoia has taken over and various software and hardware suppliers have reacted with alternatives to Java. The alternatives to Java close enough to be ignored in our study of OOD. George Blankenship 19

20 Java is a very special language in its approach to computation. Most languages create an executable that is specific to a particular hardware platform or OS/hardware platform. Java uses a variation of a interpreted language such as Perl or VB. The Java compiler generates an intermediate code called byte code. This is the model used by the early C compilers when they generated machine independent code so that a single C compiler could be mated up with a machine specific link editor. It is also the model set by Pascal with its p-code. The Java byte code is interpreted by the JVM. The JVM is OS/machine specific. With the JVM as an interpreter, the Java byte code is machine and OS independent. The byte code is packaged in a class file which may be free standing or in a compress file (jar file). A Java application may be transported from system to system just by copying the class or jar files. The downside to the JVM is that interpretation carries a performance cost. The early Java applications were notoriously slow. The JVM now includes a JIT compiler (Just In Time) that compiles Java classes before use so that the second use of a class will not require the interpretation component of the JVM. George Blankenship 20

21 When one looks at a Java program one sees that every line of code in defined in a class. Java does not allow for any code outside a class. The initial entry is a static method in one of the classes. That method must create the first object that will actually start the application s computation. The computation of a Java application only exists in the use of the objects created during execution. This approach injects Java deep into the OOP paradigm. All of the advantages that result from an object orientation are present in Java along with any of the constraints and difficulties. We will look at Java in the next section of this lecture and the next two sections. George Blankenship 21

22 One of the benefits of being object oriented is that the elements of a system are clearly defined; they are the classes. When documenting a system, the documentation can be reduced to the documentation of the classes. With encapsulation, the interior of the class is not (normally) germane to the documentation of the class. The documentation is based upon the signature of the class (the public attributes and the public methods). With the appropriate stylized comments, the documentation can be automatically generated as a set of web pages; earlier in this session, I reference the documentation (javadoc) web site for the GCB Application Framework. The web site was automatically generated from the source. The end result of basing all of the code on classes and the automatic generate of the documentation is that code reuse (class reuse) is encouraged. The next section is the first of three sections devoted to a review of Java. George Blankenship 22