View source

You do not have permission to edit this page, for the following reasons:

• The action you have requested is limited to users in the group: Users.
• You must confirm your e-mail address before editing pages. Please set and validate your e-mail address through your user preferences.

You can view and copy the source of this page:

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. It should take you about one hour to read through this and all 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?" == What is OO programming & OO design? == Object Orientated (OO) programming is presently the most widely used software development paradigm in the world. In this methodology, sections of code are comprised into separate entities known as [[Class versus Object|classes]]. At runtime, objects are created as [[Instance|instances]] of that class. The prevalent school of thought suggests that, as OO designers, our job is to [[Model the real world|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. OO design is the process of rationalising the best methods of creating software in this paradigm. == 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 [[Method|methods]] to provide the behaviour of the class. On a higher level of abstraction, classes are grouped into some kind of [[Package versus Namespace|namespace]] (in Java, this is called a package). A key concept these languages address is that of [[Encapsulation|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|inheritance]]. This allows classes/objects to be specialisations of a more general type. Some languages allow for the related concepts of [[Multiple Inheritance|multiple inheritance]] and [[Interface|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|coupling]] and [[Abstraction|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|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 [[Design maxims|this page]] and [[Riel's heuristics|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|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|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 [[Behavioral completeness|behavioural completeness]] maxim. This states that each class/object should model a real world entity. When considering this maxim, the [[Single responsibility principle|single responsibility principle]] should be examined. This maxim has the potential to contrast with [[Don't repeat yourself|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|big design up front]] to [[Agile methods|agile methods]], a much more light weight solution. One of the most widely accepted versions of this is [[Extreme programming|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|code smells]] and corrected with the use of [[Refactoring|refactoring]]. If you want practice, check out the [[Design examples|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.

Return to One hour tour.