CS 350 – Software Design The Object Paradigm – Chapter 1 If you were tasked to write code to access a description of shapes that were stored in a database and display them you might do the following: 1. Locate the list of shapes in the database 2. Open up the list of shapes 3. Sort the list according to some rules 4. Display the individual shapes on the monitor Any step can be further broken down. For example Step 4 could be broken down as follows: 1. Identify the type of shape 2. Get the location of the shape 3. Call the function that will display the shape, given the shape’s location This is known as functional decomposition.

CS 350 – Software Design The Object Paradigm – Chapter 1 One main program is responsible for controlling its subprograms Is this a good thing? History shows that it is not. The book implies it is far more easier to have some of the subfunctions responsible for their own behavior. This is called delegation. I agree with this, however I think the book really means that a program is easier to maintain if it is written with delegation. Many concepts in the book state that something is easier, however I think that most of the book doesn’t necessarily make the initial coding easier. Instead, it reduces the effort to maintain code in the long run. This should not be trivialized as writing a program that works the first time is easy. Writing a program that continues to meet the needs of its users is quite another challenge. As the book states, “Many bugs originate with changes to code.”

CS 350 – Software Design The Object Paradigm – Chapter 1 Ask yourself why do programs fail in the “real world.” Most of you should have had some co op experience and therefore a taste of the real world. In academics the problem you are solving is usually clearly laid out. Expectations are well defined. This is not the case in the real world. While a program can fail because: 1.Technological problems 2.Incompetent Programmers 3.Poor Management 4.Poor Development Tools The #1 reason projects fail is poor requirements gathering.

CS 350 – Software Design The Object Paradigm – Chapter 1 Why are requirements poor? 1.Requirements are incomplete 2.Requirements are often wrong 3.Requirements (and users) are misleading 4.Requirements do not tell the whole story This happens for a lot of reasons and they are often classified as the dreaded communication problems. While one tries to document requirements completely and properly, the reality is, for many reasons you will not achieve a perfect set of requirements. If you do not have good requirements, how can programmers possibly be expected to develop an application that meets the needs of the end user. The reality is, requirements always change.

CS 350 – Software Design The Object Paradigm – Chapter 1 Let’s look again at the problem of displaying shapes. One might break the problem into modules as follows: Function: Display Shape Input: Type of Shape, Description of Shape Action: switch (type of shape) case Square: put display function for square here case Circle: put display function for circle here The goal is that when a new type of shape is created, say a triangle, we only need to change one module. This is of course the goal, but not the reality. What happens if shapes can’t be stored the same way? How can they be passed to the same module?

CS 350 – Software Design The Object Paradigm – Chapter 1 An application’s maintainability is often measured by two factors: cohesion and coupling. Cohesion refers to how “closely the operations in a routine are related.” Coupling refers to “the strength of a connection between two routines.” So do we want our code to have weak or strong cohesion? Do we want our code to have tight or loose coupling? Code should have strong cohesion and loose coupling. Examples: A math library of routines to support trigonometry is weak or strong cohesion? An object calls another objects method with 8 parameter method is tight or loose coupling?

CS 350 – Software Design The Object Paradigm – Chapter 1 An application’s maintainability is often measured by two factors: cohesion and coupling. Cohesion refers to how “closely the operations in a routine are related.” Coupling refers to “the strength of a connection between two routines.” So do we want our code to have weak or strong cohesion? Do we want our code to have tight or loose coupling? Code should have strong cohesion and loose coupling. Examples: A math library of routines to support trigonometry is weak or strong cohesion? Since all the functions relate to one another. An object calls another objects method with 8 parameter method is tight or loose coupling? Since there are many parameters, if one changes (which is likely with a large number) then both objects are changed instead of one.

CS 350 – Software Design The Object Paradigm – Chapter 1 Fixing problems in code takes time. This is an obvious statement, I hope. However, not so obvious is what takes the time. Fixing the bug is not difficult. Finding a bug is. Consider a memory leak. Once you know where the leak is occurring, setting the pointer or disposing of the memory is easy. However, it may take you

CS 350 – Software Design The Object Paradigm – Chapter 1 Consider the example of an instructor at a conference. People in your class have another class to attend following yours, but don’t know where it is located. You are responsible to make sure everyone knows how to get to the next class. STRUCTURED PROGRAMMING APPROACH: 1. Get a list of people in the class 2. For each person on this list, do the following: 1.Find the next class he or she is taking 2.Find the location of that class 3.Find the way to get from your classroom to the next person’s class 4.Tell the person how to get to his or her next class. To do this would require the following procedures: 1. A way of getting the list of people in the class 2. A way of getting the schedule for each person in the class. 3. A program that gives someone directions from your classroom to any other classroom 4. A control program that works for each person in the class and does the required steps for each person

CS 350 – Software Design The Object Paradigm – Chapter 1 Is that reality? Probably not. More likely, you would post directions to go from this classroom to all other classrooms and then tell everyone in the class what you did and to use the directions to go to their next class. This is a philosophical difference. It’s a shift in responsibility. First Method: Responsibility is solely with the instructor, thus you, thus leads to insantity. Second Method: Responsibility is divided amongst others.

CS 350 – Software Design The Object Paradigm – Chapter 1 What happens when we change requirements? Say have a new type of student, aka a grad student. FIRST METHOD The control program would have to be modified to distinguish grad students from undergrad students. SECOND METHOD People are responsible for themselves, therefore the change would be localized to a routine for the new duty of the grad student. The control program does not change!

CS 350 – Software Design The Object Paradigm – Chapter 1 The Object Oriented Paradigm, centered on the concept of the object. Duh. What is an object? Traditionally: data with method. I myself used this loose definition. Better Definition: Things responsible for themselves. Conceptual Level View of an Object: An object is a set of responsibilities. Specification Level View of an Object: An object is a set of methods (behaviors) that can be invoked by other objects or itself. Implementation Level View of an Object: An object is code and data and the computational interactions between them.

CS 350 – Software Design The Object Paradigm – Chapter 1 An object’s interface is it’s collection of methods. A class has the following: –The data elements the object contains –The methods the object can do –The way these data elements and methods can be accessed

CS 350 – Software Design The Object Paradigm – Chapter 1 Object Oriented Approach to the “Classroom” Problem 1. Start the control program 2. Instantiate the collection of students in the classroom 3. Tell the collection to have the students go to their next class 4. The collection tells each student to go to his or her class 5. Each student – Finds where his next class is –Determines how to get there –Goes there 6. Done This works great with students, but if I add a grad student, then if the student class was called undergrad student I would have a problem, thus the need for an abstract class. Therefore, I need a general type that encompasses more than one specific type. I can have a Student class that includes both an undergrad student and a graduate student.

CS 350 – Software Design The Object Paradigm – Chapter 1 Abstract classes define what other, related classes can do. These “other” classes are classes that represent a particular type of related behavior. Such a class is called a concrete class. Therefore, UndergradStudent and GraduateStudent would be concrete classes. The relationship between an UndergradStudent and a Student class is called a is-a relationship. An is-a relationship is a form of inheritance. Abstract classes act as placeholders for other concrete classes. Abstract classes define the methods their derived classes must implement.

CS 350 – Software Design The Object Paradigm – Chapter 1 Three levels of accessibility: –Public – Anything can see it –Protected – Only objects of this class and derived classes can see it –Private – Only objects from this class can see it What level should you use? Many say the most restrictive, which would imply private. I think, in most cases, protected is good enough unless you have a really good reason not to want an inherited class to access or modify something. Encapsulation is not just about data, it’s about any kind of hiding! In our previous examples, the type of student is in essence hidden from the control program (in essence, because it has to instantiate it and thus know what type of object it is). This encapsulation is known as polymorphism. Polymorphism can be defined as the ability to refer to different derivation of a class in the same way, but getting the behavior appropriate to the derived class being referred to.

CS 350 – Software Design The Object Paradigm – Chapter 1 Special Methods: Constructors – Initialize or set up an object Destructors – Finalize or clean up an object when it is no longer needed. The book says destructors are called “when it has been deleted”. This is misleading. It depends on the language and the environment. When an object is deleted in some languages the run time environment decides when the object’s destructor is called. To me this is incredibly problematic as I like to put things like closing a database connection or saving data in a form or object’s destructor. If I don’t know what is called, very bad things can happen.