One hour tour
m (→What ideas/maxims are good to follow?) |
m (Reverted edits by Ebybymic (Talk); changed back to last version by Warwick Irwin) |
||
| (18 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| − | 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. | + | 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 [http://agecon2.tamu.edu/people/faculty/capps-oral/agec%20635/Readings/At-Home%20Consumption%20of%20Cheese%20-%20A%20Purchase-Infrequency%20Model.pdf 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?" | + | If you are already familiar with OO programming, feel free to skip to the heading: [[One hour tour#What are the most important ideas in OO design?|"What are the most important ideas in OO design?"]] |
| − | == What is OO | + | == What is OO programming & OO design? == |
| − | Object | + | Object Oriented (OO) programming is presently the most widely used software development paradigm in the world. In this methodology, sections of code are composed 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? == | == What are the underlying concepts in OO programming? == | ||
| Line 11: | Line 13: | ||
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. | 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 | + | 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 different [[Package versus Namespace|namespaces]] (in Java, these are 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 an 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]]. | 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]]. | ||
| Line 29: | Line 31: | ||
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! | 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 | + | 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]]. | 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]]. | ||
| Line 37: | Line 39: | ||
== How do we follow these ideas? == | == 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 | + | 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]] | + | Now we have a way to organise our development team, we need some help with the architectural development of the program. [[Design patterns]] are a primary mechanism to allow this to happen. These provide a way of solving common design problems. 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|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]]. | 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]]. | ||
| Line 47: | Line 49: | ||
Finally, if all else fails, follow this rule - [[Keep it simple]]. | 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. | 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. | ||
Latest revision as of 03:23, 25 November 2010
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?"
Contents |
What is OO programming & OO design?
Object Oriented (OO) programming is presently the most widely used software development paradigm in the world. In this methodology, sections of code are composed into separate entities 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.
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 methods to provide the behaviour of the class. On a higher level of abstraction, classes are grouped into different namespaces (in Java, these are 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 an 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.
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 are a primary mechanism to allow this to happen. These provide a way of solving common design problems. 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.
