Object Oriented Software Design

Background

Before software can be created, its purpose must be defined. The design of a piece of software is usually captured in some kind of document—all but the most trivial software projects benefit from good design documentation, particularly when there is more than one participant involved in the creation of the software. Two major classes of design documentation have been placed into practice:

Requirements – The requirements define the intended functionality of the software for users and external systems. For example, one requirement of an automated teller machine is that the users that meet certain criteria must be able to withdraw cash.
Specifications – The specifications state the constraints that must be met by users and external systems before the software will function properly (as defined by the requirements). For example, part of the specification of some automated teller machines is that the user must bring a bank card and swipe it in the machine. Users who do not comply with this part of the specification will be unable to use it.

The initial practice of designing software often focuses on creating work products that capture the desired requirements and specifications of the proposed software. There are many different approaches to software design, but most software will never reach a point where all of the desired requirements are met because the requirements will change and grow as soon as the software goes into use. So, software design is principally concerned with designing software that is expected to continuously evolve to meet an ever-changing list of requirements. It is far easier to make sense of software design and development processes when this crucially important, but subtle notion is grasped: good design is about creating software that can evolve and adapt over a long period of time and an indefinite number of versions, it is not chiefly concerned with creating a pristine finished product that is intended to remain untouched upon completion.

The first software was designed with a procedural paradigm in mind. The procedural paradigm envisions software simply as a list of instructions, usually contained across many files, to be executed. As computers became more powerful, programs grew to a size that made this approach unmanageable without adopting designs specifying complex organizational procedures for keeping track of all of the files containing these instructions. Since then, many programming paradigms have been envisioned, the most popular of which is the object oriented paradigm.

Supporting the object oriented paradigm is the process of object oriented design, or OOD. OOD aims to design software such that it is broken up into manageable chunks called classes. A class is a unit of code that contains information and defines behaviors that manage that information. In this way, the information managed by the class can only be changed by the outside world in the ways defined by the class. The world outside that class need not understand the details of how such information must be manipulated; ensuring that the information is complete and consistent is managed within the class itself, greatly simplifying the task of working with that information for the outside world.

Basics: Classes & Inheritance

The fundamental unit of an object oriented system is the class. A class is a set of data and the behaviors that operate upon that data. Each behavior is captured in a method, which is a function associated with a class. A class defines a type of object that can exist within the system.

It is instructive to consider an example. An object is related to its class much in the same way a specific dog (let's call him Rover) is related to the class of all dogs. In the object oriented approach we say that Rover is an instance of a dog. Similarly, we would refer to an object as an instance of a particular class. Just as Rover and Fido are two distinct instances of dogs, at any given time there may be many instances of a particular class existing in an object oriented system.

If we are designing an object oriented system designed to represent dogs, then, we would use this analogy to create a class called Dog. On this class we can define variables like hairColor, hairLength, eyeColor, weight, height, etc. We can also define behaviors that all dogs share such as eat(), sleep(), bark(), and run(). The behaviors we define may use the state stored in the variables to determine how to correctly carry out the behavior (for instance, a large dog will eat more and bark louder than a small dog). When we instantiate, or create, a new dog we would initialize it with all the properties of the specific dog we wish to represent. So, even though we'd have two instances of the Dog class in our system, fido and rover, they would exhibit the same behaviors in different ways based on their individual state.

There are three principles fundamental to the definition of all object oriented software: encapsulation, inheritance, and polymorphism. We will discuss each in turn, but it's important to realize that all three principles work in combination to define a particular class.

The principle of encapsulation refers to the scope and visibility of state within a class. It is important for each class to define behaviors usable by the outside world in such a way that the internal state is not known outside the object, nor would it be necessary for that state to be known for objects of the class to serve a purpose within the system. Encapsulation goes hand-in-hand with the principle of information hiding, which says that any information that need not be known by outside agents should be hidden from view. In this way, the outside world sees only what it needs to see in order to use the object, simplifying its usage. To use the example above, the eat() method of our Dog class might use a very complex algorithm based on the weight, height, and any other characteristics of that particular dog to calculate how much food it should eat when invoked. The outside world ought to regard the particular process used by the class with disinterest—it simply calls the eat() method and, from that outside perspective, the dog eats.

Inheritance refers to a particular relationship that two or more classes can share. After we define our Dog class, we may wish to design some classes that represent particular breeds: German Shepherd, Pointer, and Retriever, for example. All of these are different kinds of dogs. As such, any behavior or characteristic our more generic Dog class contains ought to also be contained by each of these classes. It would be a terrible waste of effort, however, to duplicate all of the work we've done defining those characteristics and behaviors on the Dog class. Furthermore, whenever we update such code shared by all dogs (such as when fixing a bug), we would have to apply the same update to all classes with copies of that same code. Fortunately, because object oriented systems allow inheritance, we need not define the same functionality multiple times. We can simply say that the different breeds of dog extend or inherit from the Dog class, and instances of those classes automatically get all of the characteristics and behaviors defined on Dog.

Polymorphism refers to a particular feature of classes that define an inheritance relationship. Above, we said that a Pointer is a specific kind of Dog, and therefore the Pointer class can extend the Dog class. Once this inheritance-type relationship is defined between these two classes, the outside world can treat any pointer specifically as a pointer, or it may also treat it more generally as simply a dog. When dealing with a particular instance, in fact, the outside world need not even know its dealing with a pointer. For example, if the Pointer class defines an additional behavior unique to pointers, such as point(), when dealing with an instance of the Pointer class—let's call this particular dog pointy—we may invoke the point() method and observe Pointy point. However, if we are only interested in requesting that Pointy do things that all dogs can do, such as eat() and sleep(), we may forget altogether that Pointy is in fact a Pointer and simply treat him just as though he were directly an instance of the Dog class. Polymorphism is the ability of objects to behave as though they are instances of a superclass.

Design Patterns

Design patterns are well-recognized solutions to common design requirements. These are strongly recommended to study, as they provide clean & effective solutions which may be commonly used in many places throughout an application design. For learners, they provide good design options with less need to carefully evaluate OO principles.

The 'Gang of Four' Design Patterns book originally propelled design patterns to popularity.

Patterns are divided into 3 categories; addressing 'creation', 'structure', and 'behavioral' patterns.

Patterns of especial note include:-

Creational

Structural

Behavioral

UML

Considering & communicating OO design requires a common language to be understood. For OO, the most popular formalism -- besides code itself -- is UML.

UML defines widely-recognized diagrams such as Class diagram, Activity diagram, Use-Case diagram and Sequence diagrams which can effectively formalize & communicate design.

UML - Unified Modeling Language

OO Principles

Beyond a few classes, there become many possibilities with how to place behavior & structure responsibility in an OO design. OO principles help provide guidelines & metrics by which _good design_ could be formalized. They go beyond Design Patterns (though most were invented earlier); they provide the justification & underpinning by which design patterns were originally identified.

Various principles have been suggested or formalized. These include:

preferring Composition/ Delegation to Inheritance;
Law of Demeter
Single responsibility principle
Open/closed principle
Liskov substitution principle
Interface segregation principle
Dependency inversion principle
OO is more about 'doing' than 'being'

Statements of OO as a systematic set of principles include:

About this lesson

Contributors, Mirwin, CQ and Twhitmore.nz can take you more deeply into this study, if you care to read on. If you know this topic and have something to contribute, You are quite welcome to sign up at the bottom of the page. Anyone can edit this page or contribute anonymously.

Anyone can ask a question, post a comment or read in-depth discussion on the Talk page.

Where would you like to go from here?

Instructor picks: Software Engineering • Object-Oriented Programming • UML - Unified Modeling Language

Other Kinds of Computer Programming

Resources

Below are some Object Oriented Software Design learning materials and more links

Links for tutorials, Ebooks, and other materials available online

Data Structures and Algorithms with Object-Oriented Design Patterns in Java [1]

An index of object oriented technologies and online reference materials. [2]

A Stanford Course Page with useful links. [3]

Introductory Articles

http://www.developer.com/tech/article.php/3304881 – Excellent material! Navigation is hell. Have requested permission to insert index/TOC links here.

The articles listed and linked to directly below are written by Matt Weisfeld are [www.developer.com available to read for free] and are good starting points for chapters in a book he has written. The Thought Process, is also available.

Local Topics

Design Patterns - A design pattern is a recurring theme that people have found in software engineering. It is a template from which a new solution may be tailored to fit the current design challenge.

Using design patterns is greatly assisted by an adequate UML (Unified Modeling Language) diagraming tool. One such is [[4]].

A good exercise for learner here would be to find a design pattern one needs to learn or can use productively somewhere in a real design. Users can then submit some good examples from the detailed design documentation related to the pattern here. These figures can be discussed and improved here at Wikiversity and presented to Wikipedia or Wikibooks.

A set of design patterns expressed online in UML and English. [5]

Participants, Goals, and Proposed Methods

Tell us about yourself and what you intend to do here.

Mirwin 09:56, 3 November 2006 (UTC) I intend to engage in studying, hunting and gathering around the web while learning to do object oriented design in Java using free tools. I will place links to nuggets here and some notes and thoughts regarding design issues and problems. Currently I am working on little space games and jFreeRails for practical design, coding, testing and debugging experience with the fine free automation tools, operating systems and applications now available online.

The java learners or already enabled may be interested in this subtrail Practical Object Oriented Game Design in Java which the game designersA_Hands-On_Introduction_to_Game_Design_and_Production_Processes have set up for their hackers and software engineers. These trails are supporting the community learning project designing the cisLunarFreighter game.

CQ 18:56, 3 November 2006 (UTC) Ditto on Mirwin's objectives, but I'm more Perl-oriented than Java. I'm also interested in develping a greater understanding of UML and applying it to modeling and diagramming MediaWiki and perhaps even Wikiversity itself using open source/free UML tools.
Severoon 10:37, 19 January 2008 (UTC) I am a full-time software development professional currently employed in a technology-forward research & development lab. I have over 10 years experience in the industry with a strong focus on Java enterprise systems. In the last year I have taken on primarily architectural and project lead responsibilities. Besides having written most of the content above, I intend to capture on these pages the most important aspects of object-oriented design and development.
TW (discuss • contribs) 05:32, 7 October 2015 (UTC) As an architect with 20 years experience, I'm interested to bring some insights into Design Patterns, OO guidelines & actual use of OO in solving non-trivial software problems.
sign up here!