CS 350

1
CS 350 Software DesignThe 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
• Locate the list of shapes in the database
• Open up the list of shapes
• Sort the list according to some rules
• Display the individual shapes on the monitor
• Any step can be further broken down. For example
  Step 4 could be broken down as follows
• Identify the type of shape
• Get the location of the shape
• Call the function that will display the shape,
  given the shapes location
• This is known as functional decomposition.

2
CS 350 Software DesignThe 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
  doesnt 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.

3
CS 350 Software DesignThe 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
• Technological problems
• Incompetent Programmers
• Poor Management
• Poor Development Tools
• The 1 reason projects fail is poor requirements
  gathering.

4
CS 350 Software DesignThe Object Paradigm
Chapter 1

• Why are requirements poor?
• Requirements are incomplete
• Requirements are often wrong
• Requirements (and users) are misleading
• 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.

5
CS 350 Software DesignThe Object Paradigm
Chapter 1

• Lets 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 cant be stored the same
  way? How can they be passed to the same module?

6
CS 350 Software DesignThe Object Paradigm
Chapter 1

• An applications 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?

7
CS 350 Software DesignThe Object Paradigm
Chapter 1

• An applications 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.

8
CS 350 Software DesignThe 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

9
CS 350 Software DesignThe 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 dont know
  where it is located. You are responsible to make
  sure everyone knows how to get to the next class.
• STRUCTURED PROGRAMMING APPROACH
• Get a list of people in the class
• For each person on this list, do the following
• Find the next class he or she is taking
• Find the location of that class
• Find the way to get from your classroom to the
  next persons class
• Tell the person how to get to his or her next
  class.
• To do this would require the following
  procedures
• A way of getting the list of people in the class
• A way of getting the schedule for each person in
  the class.
• A program that gives someone directions from
  your classroom to any other classroom
• A control program that works for each person in
  the class and does the required steps for each
  person

10
CS 350 Software DesignThe 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. Its 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.

11
CS 350 Software DesignThe 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!

12
CS 350 Software DesignThe 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.

13
CS 350 Software DesignThe Object Paradigm
Chapter 1

• An objects interface is its 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

14
CS 350 Software DesignThe Object Paradigm
Chapter 1

• Object Oriented Approach to the Classroom
  Problem
• Start the control program
• Instantiate the collection of students in the
  classroom
• Tell the collection to have the students go to
  their next class
• The collection tells each student to go to his
  or her class
• Each student
• Finds where his next class is
• Determines how to get there
• Goes there
• 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.

15
CS 350 Software DesignThe 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.

16
CS 350 Software DesignThe 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, its 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.

17
CS 350 Software DesignThe 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 objects 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 objects
  destructor. If I dont know what is called, very
  bad things can happen.