CSC/ECE 517 Fall 2012/ch1b 1w44 as

Introduction

Object Oriented Design (OOD) is a methodology to develop a solution by creating structured objects which interact with each other through well defined interfaces. The object interaction involves invocation of required services and exchange of corresponding data. An object contains data and set of methods or procedures which act on that data. Access to data can be controlled based on access specifiers. The input to the problem is passed to the object through method invocations which are defined by the interfaces. Interfaces define the procedure name and the parameters. The object implements the methods of the interfaces and also encapsulate data needed for solving the problem which can include instances of other objects.

An example of Object Oriented Design

Class Person {
    String id;
    String name;
}

Class Student extends Person {
    List<Course> registeredCourses;
    int semester;
    ...
}

Class Instructor extends Person {
    List<Course> coursesTaught;
    ....
}

Student student = new Student(...);
student.getRegisteredClasses();
student.getAdvisor();
Instructor instructor = new Instructor(...);
instructor.getCoursesTaught();
instructor.getStudents();

In above example, two objects are created, one for the Student and another for Instructor. The main observation to be made is that the Student object interacts with the Instructor object to obtain the advisor's information. Similarly, the Instructor object interacts with the Student object to obtain the student information.

Advantages of Object Oriented Design

1) Code Reusablility
2) Real-World Modeling
3) Robustness and Reliability
4) Less Maintenance

Traits of a poor Object Oriented Design [link to code smell]

1) Misnomer: The name of variables, methods, Classes and instance objects are not indicative of the data and functionality that they represent.
2) Not following Single Responsibility Principle [1]: Designing a class which has many functiionalities.
3) More functionality in a single method.
4) Violating the DRY principle [2].
5) Overuse of inheritance mechanisms.
6) Anti-Patterns [3].
7) No proper documentation.

Next, we will define the success and failure of a Software and then some basic concepts of Object Oriented Design. In the later part, we discuss more in-depth of how poor designs lead to software failures. Finally, we discuss about methodology to avoid poor object oriented designs.

Software success and failure

What is software success

The general definition of software project success is - projects delivered on time, in scope (software quality is satisfied) and within planned costs. [1] It is just a most simplistic definition of software project success because it merely relies on the schedule and budget. In fact, it is hard to tell whether software is a success or failure one, because business success, at sometime, is more essential than technical success. [2] This means that the software which is being implemented must create value that business needed, such as making profit, rather than simply achieve the software goal and requirement.

In The Strategic Project Office, written by J. Kent Crawford, [3] we can find some more specific success criteria mentioned to address alignment between project goals, business requirements, and outcomes:

The organization’s strategies are executed according to plan. The organization’s shareholders are satisfied. The organization is financially successful. Projects are completed on schedule and on budget. Project customers are satisfied. Project resources are allocated optimally. Projects are aligned to the organization’s business strategy. The organization works on the right projects.

What is software failure

Compared with software success, it is relative easier to define software failure. It can be definite as “(1) being over-scheduled by more than 30% and/or, (2) being over-budget by more than 30% and/or, (3) the end product did not meet user requirements. These three criteria cover the schedule, budget, and requirement, all surrounded by quality that should comprise all projects.”[5].

Factors leading to software failure

Most software project can be considered partial failures since only few of them meet the schedule, cost and requirement objective. According to many studies, failure rate of software projects is between 50% - 80%. [6] In most of the cases, the software projects fail because we do not recognize that good engineering principles should be applied to software projects similar to building office buildings. Below are some factors that may lead to the software failure in no particular order:

Poor user input
It is possible that a titanic project which meets all the requirements ultimately may fail because the system did not meet the user's needs.

Vague requirement
People cannot design a process that assumes the requirement is stable. Projects can be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.

Poor cost and schedule estimation
Although it is unfair to call software project a failure when it cannot meet the budget and scheduled goals that were inherently unattainable, every software project has a minimum achievable cost and schedule.

Skills that doesn't match the job
This is an obvious reason; Example: Managers can perform poorly if they lead projects that do not match their strengths.

Communication breakdown
Communication breakdown may lead to low efficiency and even the project failure. Especially large software project which is done by different groups in various sites, same code may be tested two times because no one knows the other exist.

Poor architecture
This is because people never think ahead about what is likely to change. Once the software is developed in an inflexible way, it may be outdate quickly after it is released and may cause problems because it cannot deal with the continue change incomes. For this reason, we come to realize why OOD is so important in software development.

Concepts of Object Oriented Design (OOD)

Object Oriented Design (OOD) is the concept that forces programmers to plan out their code in order to have a better flowing program [7]. Simply speaking, OOD is all about objects. An object can be considered as a “black box” which receives and sends messages. Code (sequence of computer instructions) and data (information that instructions operates on) are included in this “black box”. [8] Interface is used in the object and everything an object can do is represented by its message interface. OOD mechanisms such as inheritance, polymorphism, information hiding and coupling, can influence quality characteristics like reliability or maintainability [19].

Language Concepts

The 5 Basic Concepts of Object Oriented Design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Encapsulation:Encapsulation refers to a tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class).

Data Protection:Data Protection is the ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.

Inheritance:Inheritance defines the ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data.

Interface:Interface is a definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object.

Polymorphism:Polymorphism refers to the ability to define different functions or classes as having the same name but taking different data types.

Programming Concepts

There are several concepts that were derived from the new languages once they became popular. The new standards that came around pushed on three major things:

Re-usability:The ability to reuse code for multiple applications. If a programmer has already written a power function, then it should be written that any program can make a call to that function and it should work exactly the same.

Privacy:This is important for large programs and preventing loss of data.

Documentation:The commenting of a program in mark up that will not be converted to machine code. This mark up can be as long as the programmer wants, and allows for comprehensive information to be passed on to new programmers. This is important for both the re-usability and the maintainability of programs.

How to achieve a good OOD

“Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.”--Kernighan & Plauger

At the heart of great design are a set of principles and patterns. Design principles form the foundation of good object-oriented design and design patterns provide general repeatable solutions for common software problems. [10]

Design principles

Design principles are guidelines and heuristics for a good object oriented designs. There are many different design principles of Object-Oriented Design. Here are 4 major principles of them:

Encapsulation
In a nutshell, Encapsulation is the hiding of data implementation by restricting access to accessors and mutators. An accessor, usually in the form of properties in OOP, is a method that is used to ask an object about itself. Accessor has a get method, which is an accessor method. Mutator is used to modify the state of an object. It is a public method, and hides the implementation of exactly how the data gets modified.

Abstraction
Abstraction is the development of a software object. It denotes a model, a view, or some other focused-representations for an object we can actually find in the real world. It can be used to decompose complex systems into smaller by software developers.

Inheritance
Objects can relate to each other with either a “has a”, “uses a” or an “is a” relationship. “Is a” is the inheritance way of object relationship.[11]

Polymorphism
Meaning one name, many forms, polymorphism manifests itself by having multiple methods all with the same name, but slightly different functionality. There are two basic types of polymorphism: overriding, also called run-time polymorphism, and overloading, which is referred to as compile-time polymorphism.

Design patterns

Design pattern is a general reusable solution to a commonly occurring problem within a given context. It is a template describing how to solve a problem, which cannot be transformed directly into code. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. [12]

There are many types of design patterns, like

Creator
As one of the most common activities in an object-oriented system, creator pattern maintains a fundamental property of the relationship between objects of particular classes: class is responsible for creating objects. That is to say, creator pattern is responsible for creating an object of class.

Controller
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. [13]

High Cohesion
High cohesion means that the responsibilities of a given element are strongly related and highly focused. It is an evaluative pattern generally used in support of Low Coupling, which can keep objects appropriately focused, manageable and understandable.

Indirection
By assigning the responsibility of mediation between two elements to an intermediate object, the Indirection pattern supports low coupling and reuse potential between them. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. [13]

Protected Variations
By wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface, the Protected Variations pattern protects elements from the variations on other elements, like objects, systems and subsystems.

Effective Use Cases

Essential use cases are abstrat, lightweight, technology-free dialogues of user intension and system responsibility, that effectively capture requirements for design ofa system [22]. Working with essential use cases yeilds further benefits: analysts can take advantage of recurring patterns in essential use cases and the crucial common vocabulary of responsibilities lets designers trace directly from the essential use cases to the objects in their design.[22]

Tips for a good OOD

There are some tips that can be used in designing to enhance and improve the object-oriented projects.

Use Lots of Objects
By adding lots of objects, it is easy to make each object has and only has one job. Once you understand the architecture, it helps to avoid changing massive amounts of code when we modify the code.

Use Interfaces to Make APIs Predictable
Interfaces allow for strict type hinting, and by type hinting you can ensure that certain methods are always available for your use. [14]Each interface will provide the model to utilize. The utilization of a particular interface will cause the implementations of a few methods.

Use Dependency Injection
Using dependency injection can make testing and feature addition easier. While, it makes testing impossible by instantiating objects directly in the code, or grabbing objects out of singletons.

Create Loosely Coupled Classes
When a developer gives each object only one responsibility, they tightly couple objects together. Objects will often request information from other objects, and while this is not avoidable in all situations, these tightly coupled classes that rely on one another’s functionality makes pulling those objects apart impossible.[14]

Poor OOD Leads to Software Failures

In technical term, software failure is possibly due to software bugs or the poor software design, such as bad OOD. In the figure 2, we can see the cyclic behavior of failure. A fault or bug will cause errors. And errors in the system lead to the subsequent failure. In most of the cases, the software system comprises multiple components in which one failure may result in bugs or errors in another component.

Figure 2 cyclic Fault behavior

Factors may lead to Poor OOD

Bad practice in code will always lead to the poor OOD. Here are some common ones[15]:

Classes that break the Single Responsibility Principle (SRP) and perform too many actions
Goal of Design: A class should have only one reason to change Consider the example below:

Class TransportDetails {
  List<TransportType> modes;
  List<Location> locations;

  Location getViaTouristPlaces() {
  }
}

Class TransportMode {
  TransportType type;
  ...

}

Class Location {
  String name;
  ...
}

In above example, TransportDetails class is responsible for both the mode of transport and locations violating the single responsibility principle. Instead, it can only be responsible for modes of transport and TransportMode can be responsible for locations.

Classes that break the Don't Repeat Yourself (DRY)
Consider example below:

Class Employee {
  String name;
  ...
}

Class Manager {
  String name;
  ...
}

Favor Composition over Inheritance: too much inheritance instead of composition, i.e. Classes that derive from a sub-type purely so they get functionality for free

Class Location {
  String name;
  ...
}

Class TransportDetails {
  List<Location> locations;

  List<Location> getViaTouristPlaces() {
  }

  List<Location> getViaTouristPlaces(Location l1, Location l2) {
  }
}

Class Flight extends TransportDetails {
  ...
}

In the above example, instead of having a sub-class for Flight, Class TransportDetails can have a new field which is TransportMode which represents different modes of transport such as flight, bus, train etc.

Class TransportMode {
  String name;
  ...

}

Class Location {
  String name;
  ...
}

Class TransportDetails {
  List<TransportMode> modes;
  List<Location> locations;

  Location getViaTouristPlaces() {
  }
}

Software design anti-patterns

In software engineering, an anti-pattern (or anti-pattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[16].Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible.

Anti-patterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations.[17] In OOP, the anti-patterns of software design and object-oriented design are dangerous. They will result in bugs and errors in practice, and then finally lead to the failures of software. Here are the examples:[18]

• Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
• Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
• Big ball of mud: A system with no recognizable structure
• Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
• Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
• Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
• Input kludge: Failing to specify and implement the handling of possibly invalid input
• Interface bloat: Making an interface so powerful that it is extremely difficult to implement
• Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
• Race hazard: Failing to see the consequence of different orders of events
• Stovepipe system: A barely maintainable assemblage of ill-related components

Object oriented design anti-patterns

• Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
• BaseBean: Inheriting functionality from a utility class rather than delegating to it
• Call super: Requiring subclasses to call a superclass's overridden method
• Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
• Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
• Constant interface: Using interfaces to define constants
• God object: Concentrating too many functions in a single part of the design (class)
• Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
• Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
• Poltergeists: Objects whose sole purpose is to pass information to another object
• Sequential coupling: A class that requires its methods to be called in a particular order
• Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

How to Prevent Bad OOD

One of the major causes of limited success in adopting object-oriented methodologies is the failure of management and design teams to riecognize and plan for the scope of this change [23]. If preventive measure are taken software failure can be avoided and organisations can benefit from OOD. Assessing quality of sojtware at the design level will provide ease and higher accuracy for users[25]

Some of the methods are listed below.

Identifying Code Smells

Code Smellsor Bad smells are used to identify problematic classes in object-oriented design[20]. They can also be used to measure the evolvability of software [21]. code smells are broadly classified into 5 categories [21].

An image showing classification of code smells

Figure 1: An image showing classification of code smells

Group Name	Smells in Group	Discussion
The Bloaters	-Long Method -Large Class -Primitive Obsession -Long Parameter List -DataClumps	Bloater smells represents something that has grown so large that it cannot be effectively handled. It seems likely that these smells grow a little bit at a time. Hopefully nobody designs, e.g., Long Methods. Primitive Obsession is actually more of a symptom that causes bloats than a bloat itself. The same holds for Data Clumps. When a Primitive Obsession exists, there are no small classes for small entities (e.g. phone numbers). Thus, the functionality is added to some other class, which increases the class and method size in the software. With Data Clumps there exists a set of primitives that always appear together (e.g. 3 integers for RGB colors). Since these data items are not encapsulated in a class this increases the sizes of methods and classes.
The Object-Orientation Abusers	-Switch Statements -Temporary Field -Refused Bequest -Alternative Classes with Different Interfaces	The common denominator for the smells in the Object-Orientation Abuser category is that they represent cases where the solution does not fully exploit the possibilities of object-oriented design. For example, a Switch Statement might be considered acceptable or even good design in procedural programming, but is something that should be avoided in object-oriented programming. The situation where switch statements or type codes are needed should be handled by creating subclasses. Parallel Inheritance Hierarchies and Refused Bequest smells lack proper inheritance design, which is one of the key elements in object-oriented programming. The Alternative Classes with Different Interfaces smell lacks a common interface for closely related classes, so it can also be considered a certain type of inheritance misuse. The Temporary Field smell means a case in which a variable is in the class scope, when it should be in method scope. This violates the information hiding principle.
The Change Preventers	-Divergent Change -Shotgun Surgery -Parallel Inheritance Hierarchies	Change Preventers are smells is that hinder changing or further developing the software These smells violate the rule suggested by Fowler and Beck which says that classes and possible changes should have a one-to-one relationship. For example, changes to the database only affect one class, while changes to calculation formulas only affect the other class. The Divergent Change smell means that we have a single class that needs to be modified by many different types of changes. With the Shotgun Surgery smell the situation is the opposite, we need to modify many classes when making a single change to a system (change several classes when changing database from one vendor to another) Parallel Inheritance Hierarchies, which means a duplicated class hierarchy, was originally placed in OO-abusers. One could also place it inside of The Dispensables since there is redundant logic that should be replaced.
The Dispensables	-Lazy class -Data class -Duplicate Code -Dead Code -Speculative Generality	The common thing for the Dispensable smells is that they all represent something unnecessary that should be removed from the source code. This group contains two types of smells (dispensable classes and dispensable code), but since they violate the same principle, we will look at them together. If a class is not doing enough it needs to be removed or its responsibility needs to be increased. This is the case with the Lazy class and the Data class smells. Code that is not used or is redundant needs to be removed. This is the case with Duplicate Code, Speculative Generality and Dead Code smells.
The Couplers	-Feature Envy -Inappropriate Intimacy -Message Chains -Middle Man	This group has four coupling-related smells. One design principle that has been around for decades is low coupling (Stevens et al. 1974) . This group has 3 smells that represent high coupling. Middle Man smell on the other hand represent a problem that might be created when trying to avoid high coupling with constant delegation. Middle Man is a class that is doing too much simple delegation instead of really contributing to the application. The Feature Envy smell means a case where one method is too interested in other classes, and the Inappropriate Intimacy smell means that two classes are coupled tightly to each other. Message Chains is a smell where class A needs data from class D. To access this data, class A needs to retrieve object C from object B (A and B have a direct reference). When class A gets object C it then asks C to get object D. When class A finally has a reference to class D, A asks D for the data it needs. The problem here is that A becomes unnecessarily coupled to classes B, C, and D, when it only needs some piece of data from class D. The following example illustrates the message chain smell: A.getB().getC().getD().getTheNeededData() Of course, I could make an argument that these smells should belong to the Object-Orientation abusers group, but since they all focus strictly on coupling, I think it makes the taxonomy more understandable if they are introduced in a group of their own.

Table 1: Code Smells Clasification

MOOD (Metrics for Object Oriented Design)

Impact of Object-Oriented design on software quality characteristics can be experimentally evaluated. A suite of metrics for OO-design, called MOOD, was adopted to measure the use of OO design mechanisms [24]. The FCM (Factors, Criteria, Measurement) model indicates that software quality depends on the software quality measurement.[25]

                                       Factors ---> Criteria ---> Measurement

Motivations behind the MOOD set definition include:

• Coverage of basic structural mechanisms of the object-oriented paradigm such as encapsulation, inheritance, polymorphism and message-passing.
• Formal definition to avoid subjectivity of measurement and thus allow replicability.
• Size independence to allow inter-projecl comparison,thus fostering cumulative knowledge.
• Language independence to broaden the applicability of this metric set by allowing comparison of heterogeneous system implementations.

MOOD includes the following metrics:

• Method Hiding Factor (MHF)
• Attribute Hiding Factor (AHF)
• Method Inheritance Factor (MIF)
• Attribute Inheritance Factor (AIF)
• Polymorphism Factor (POF)
• Coupling Factor (COF)

Each of these metrics refers to a basic structural mechanism of the object-oriented paradigm as encapsulation (MHF and AHF), inheritance (MIF and AIF), polymorphism (POF) and message-passing (COF). The MOOD metrics definitions make no reference to specific language constructs. However, since each language has its own constructs that allow for implementation of OO mechanisms in more or less detail.

References

[1]http://www.zdnet.com/blog/projectfailures/cio-analysis-defining-it-project-success-and-failure/12524
[2] http://www.42spikes.com/post/What-is-Software-Success.aspx
[3] http://www.crcpress.com/product/isbn/9781439838129
[4] J. C. Laprie (Ed.). Dependability: Basic Concepts and Terminology. Springer-Verlag, Wein, New York, 1992.
[5] http://ac-support.europe.umuc.edu/~meinkej/inss690/wilson.htm
[6] http://www.it-cortex.com/Stat_Failure_Rate.htm
[7] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[8] http://softwaredesign.com/objects.html
[9] http://www.selectbs.com/process-maturity/what-is-object-oriented-design
[10] http://www.objectmentor.com/omSolutions/oops_what.html
[11]http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/ [12]http://webcache.googleusercontent.com/search?q=cache:TwYgDNxgxUMJ:en.wikipedia.org/wiki/Design_pattern_%28computer_science%29+object+oriented+design+patterns&cd=3&hl=en&ct=clnk&gl=us
[13] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
[14] http://www.brandonsavage.net/five-tips-to-make-good-object-oriented-code-better/
[15]http://stackoverflow.com/questions/345698/what-are-the-tell-tale-signs-of-bad-object-oriented-design
[16]Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'"p. 225. ISBN 0-201-72219-4.
[17]http://sourcemaking.com/antipatterns
[18]http://en.wikipedia.org/wiki/Anti-pattern
[19]Evaluating the Impact of Object-Oriented Design on Software Quality. Fernando Brito e Abreu and WalcClio Melo. 0-8186-7364-8196 0 1996 IEEE, Proceedings of METRICS ’96
[20]An Investigation of Bad Smells in Object-Oriented Design, Raed Shatnawi and Wei Li, Proceedings of the Third International Conference on Information Technology: New Generations (ITNG'06) 0-7695-2497-4/06 © 2006 IEEE
[21]Subjective evaluation of software evolvability using code smells: An empirical study, Mika V. Mantyla & Casper Lassenius Published online: 27 May 2006
[22]Essential Use Cases and Responsibility in ObjectOriented Development, Robert Biddle, James Noble, Ewan Tempero, Copyright © 2001
[23]The Reality of Ob j ect-Oriented Technology in the Corporation, Jean Scholtz
[24]Evaluating the Impact of Object-Oriented Design on Software Quality, Fernando Brito e Abreu and WalcClio Melo, 0-8186-7364-8196 0 1996 IEEE Proceedings of METRICS ’96.
[25] Quality Metrics of Object Oriented Design for Software Development and Re-development, K. Liu, S. Zhou and H. Yang, 0-7695-0825-i/00 © 2000 IEEE