One hour tour

From CSSEMediaWiki
Revision as of 13:43, 12 September 2009 by Matthew Harward (Talk | contribs)
Jump to: navigation, search

Welcome to Object Orientated Design and the COSC427 wiki. This page will assume a basic knowledge of programming and computer science. On this page, we will not discuss the price of cheese, but hopefully you should gain a stronger understanding of object orientated design - have a read of each of the links presented.

If you are already familiar with OO programming, feel free to skip to the heading: "What are the most important ideas in OO design?"

Contents

What is OO Programming & OO Design?

Object Orientated Programming is presently the most widely used software development paradigm in the world. In this methodology, sections of code are comprised into separate sections known as classes. At runtime, objects are created as instances of that class. The prevalent school of thought suggests that, as OO designers, our job is to model the real world. This means that the objects that are creating have boundaries that reflect what we would expect of similar objects in the real world. The term "Separation of concerns" is used to describe this idea.

What are the underlying concepts in OO programming?

OO programming is a generic term for programming in an OO fashion. In order to achieve this, certain programming languages are designed to fulfil this paradigm. Java, C++ and C# are currently the most popular OO languages; however a vast range of others exist. These include, to name a few, Smalltalk, Eiffel, JavaScript, Action Script 3, and Visual Basic. It is important to note that the classification of languages into the OO paradigm is not clear cut and may be strongly debated among practitioners.

These languages tend to contain the same types of features (as well as the unique features that define them). As mentioned above, this centres around the concepts of classes and objects. Classes, as blueprints for objects, consist of fields to define data within the class, constructors to provide the initial behaviour of objects and methods to provide the behaviour of the class. On a higher level of abstraction, classes are grouped into some kind of namespace (in Java, this is called a package). A key concept these languages address is that of encapsulation, that is where information is visible. It may be visible within globally, within a namespace, class, object, method or even smaller code block.

In addition, an important concept is inheritance. This allows classes/objects to be specialisations of a more general type. Some languages allow for the related concepts of multiple inheritance and interfaces.

What are the most important ideas in OO design?

OO design promotes, through some form of process, the design, architecting, and implementation of an OO software system. The key issues in this are covered below.

Software has the potential to be tremendously large and complex. Managing complexity talks about this phenomenon and the steps required to combat it. Two partial solutions to this are the use of coupling and abstraction to remove this complexity.

In our description above, we mentioned the difference between classes and objects and the levels of visibility. This is a vital concept in OO Design and is best described in the Encapsulation boundary page. More background information to this is described on the Information hiding page.

Finally, software reuse is a major idea that needs to be considered when designing software. Should classes be designed to be reused in other scenarios?

Given these wide arching issues, the further questions deal with the potential solutions to these problems and ideas.

What ideas/maxims are good to follow?

Various authors have proposed a whole variety of "maxims" which should be followed, and there are a lot! Don't believe it? Then just check out the number of entries on this page and this one. These range in complexity and in controversy. Some of the ones we consider most interesting are presented. It is important to note that these ideas are entirely open to criticism!

An important idea is that of design by contract. This is a general case of another well known maxim called the Liskov substitution principle. They posit that designs superclasses should specify a "contract" that subclasses need to follow. This rule is closely related to the open-closed principle, this states that entities should be extensible but not modifiable. In following these ideas, we also follow [[Program to the interface not the implementation]|program to the interface not the implementation].

Another way of approaching this is to investigate the behavioural completeness maxim. This states that each class/object should model a real world entity. When considering this maxim, the single responsibility principle should be examined. This maxim has the potential to contrast with don't repeat yourself.

If developers can't agree on anything else, they all seem to agree on this rule - Goto considered harmful

How do we follow these ideas?

Now that we have an idea of the problems and the suggested maxims for dealing with them, some concrete solutions can be proposed. From a high level of abstraction, the process used to design the software is very important. In recent years a trend has occurred from heavy weight processes that attempt to do big design up front to agile methods, a much more light weight solution. One of the most widely accepted versions of this is extreme programming.

Now we have a way to organise our development team, we need some help with the architectural development of the program. Design patterns is a primary mechanism to allow this to happen. These provide a way of solving a common design problem. Some of the most commonly used are Singleton, Strategy and Composite. Design patterns only help us with more general developments, if we want more specialised solutions, Analysis patterns can help.

Developers often find themselves looking at badly written code, as maintenance is a primary concern of developers. Antipatterns provide solutions to higher level problems. Low level problems can be identified with the use of code smells and corrected with the use of refactoring.

If you want practice, check out the design examples page for some scenarios.

Finally, if all else fails, follow this rule - Keep it simple.

Where to next?

If you want further information, there are whole range of further material available. The best place to start looking is the Resources page which provides information about known texts on the subject area and important papers and websites on the field. For full sets of the ideas provided above and much more information, check out the OO wisdom page. If you are interested in the story behind this material, OO culture can provide further details.

Personal tools