Object Oriented Software Design is an abstract practice that relates to Software Engineering or Computer Programming.
Schools: Computer Science | Engineering | Mathematics
Browse: Engineering and Technology
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:
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.
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 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:-
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.
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:
Statements of OO as a systematic set of principles include:
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
Below are some Object Oriented Software Design learning materials and more links
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]
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.
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.
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.
See also:
Tell us about yourself and what you intend to do here.