Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 10 ot

2009-11-10T13:11:23Z

Cybo: /* A peanut butter jelly sandwich in the kitchen */

= Introduction =

This article discusses “Object Think” brainstorming methodology. It is intended for experienced programmers who write their code in Object oriented style. This article should be viewed as a guideline and not as a set of rules that must be enforced. In this article the word “entity” means a real-life entity, i.e. chair, apple, bird, shopping cart etc. The word “object” means a model that is used to describe a real-life entity.

Here is what [1] says about object think and object oriented development:

Poor object thinkers put data and functions into objects haphazardly. At best, they use a set of guidelines they find difficult to explain. This makes their models and code difficult to understand and brittle to changes in requirements and system growth. When requirements change, a brittle object model must significantly alter its structure by redefining objects. Object models built through functional analysis are filled with objects representing functions which makes them notoriously brittle as changes in functional requirements render objects obsolete, and reorder collaborations among them.

Good object thinkers apply consistent principles for distributing data and functions; they can explain and justify the results in their object models by relating them back to the objects in the business domain. Object models built with object think remain stable as the requirements and the system evolve because the model mirrors real-world objects and their relationships. New requirements mean more of the domain is being modeled or more responsibilities are being given to the objects that are already modeled. These changes are neatly encapsulated in a stable object model by adding new objects and expanding objects’ responsibilities. Objects do not change their meaning or lose collaborators, so the underlying structure of the model remains intact even as layers are snapped on top of it.

= What is “Object Think”? =
“Object Think” is a brainstorming methodology for architecting software. This methodology encourages a developer to think just like real-life entities. An object will abstract the entity’s responsibilities, collaborations, and even it’s “persona”. In other words the developer is encouraged to “think” like an entity, “behave” like an entity and even “talk” like an entity. It is a good idea to adopt a first-person voice during development of a model of an entity by an object. I.e. I’m an object. What do I know about myself? What do I know about the world around me? What can I do with myself? What can I with others? What is my function? e.t.c.

Here are a set of principles that were outlined by [1] when developing with object think:
* '''Personify Objects.''' Object model a domain by imagining its entities as active, knowing objects, capable of performing complex actions.
* '''Give Object Responsibilities.''' Turn information about a real-world entity and the actions performed on it into responsibilities of the object representing the entity.
* '''Object’s responsibilities.''' An object’s responsibilities are: whom I know – my collaborations with others; what I do – my services; and what I know – my properties
* '''Talk Like an Object.''' To scope an object’s responsibilities, imagine yourself as the object, and adopt the first-person voice when discussing it.

Let’s consider several examples which will help us better understand what object think is and how it works

= Examples =
== A shopping cart in the e-commerce application ==

I’m a shopping cart. I know how many products are in me. I know the total price of the products in me. I can empty myself by throwing everything away from me or by going through a checkout. I know that I’m used by a user.

From this we can see that this object most likely will contain a set of product objects, total_price property, an empty method which can be used in two ways, either by going through a checkout or by the user who can empty it out.

== A tire in the tire manufacturing plant ==

I’m a tire. I know my manufacturer. I know that if I haven’t passed the testing stage I will be recycled, and I did pass a testing stage I will be used. I know what components I’m made of and their quantity. I know the exact process of how I’m made. I know brands and models of cars I should be used with. I know the date of my manufacturing and the date I was put on a wheel of a car. I know the mileage I should be used for. I know my warranty. I also know how I should be recycled.

From this example certain methods can be clearly seen: manufacture, recycle, a method to return if the testing was passed, return the date of manufacturing, and the date a tire was placed on a wheel, return models and brands of cars that this tire is compatible.
It also can be seen that a tire will contain other objects inside of it, such as components it is made of.

== A peanut butter jelly sandwich in the kitchen ==

This example was taken from [1], [2]

I’m a peanut butter jelly sandwich. I’m always made with two slices of the same type of bread. I know that a thin bread slice cannot support chunky peanut butter (assumption) and a thin bread slice cannot support a heavy application of ingredient. I know that one bread slice must contain peanut butter and the other must contain jelly.

This example is a bit harder than previous two. Here are the requirements that we can derive from this description:
* a sandwich requires two slices of the same type of bread
* a thin bread slice cannot support chunky peanut butter
* a thin bread slice cannot support a heavy application of an ingredient
* one bread slice must contain peanut butter and the other must contain jelly.

Now consider the peanut-butter-and-jelly sandwich business process. Creating the application transaction is the crucial step in the business process of building a peanut-butter-and-jelly sandwich because this step verifies the business rules as it tries to link the application object to its ingredient and bread slice collaborators. So, which object makes the application transaction? Is it (a) the sandwich, (b) the slice, (c) the ingredient, or (d) the ingredient manager-controller?

Clearly, the choice is between the bread slice and the ingredient; they are the collaborators of the application, and they have the relevant information and business rules. Use first-person object think to pick between the two. For the bread slice, object think says, "I am a bread slice. I have an ingredient applied on me in either a light or heavy amount." For the ingredient, object think says, "I am an ingredient. I apply myself to a bread slice in either a light or heavy amount." Notice that the action of applying ingredient is third-person for a bread slice and first-person for an ingredient. Obviously, the correct answer is (c); an ingredient creates the application object when it applies itself on a bread slice.

[http://ptgmedia.pearsoncmg.com/images/sam_abney1_objectthink/elementLinks/sam_abney1_fig01.jpg Figure] for a complete Peanut-Butter Sandwich object model. [1], [2]

= References =
[1] Streamlined Object Modeling, Jill Nicola, Mark Mayfield, Mike Abney

[2] http://www.informit.com/articles/article.aspx?p=25184&seqNum=3

[3] http://cfunited.com/blog/index.cfm/2007/7/4/Simon-Horwith--Object-Think--Common-Sense-Software-Architecture

CSC/ECE 517 Fall 2009/wiki3 10 ot

2009-11-10T13:11:00Z

Cybo: /* A peanut butter jelly sandwich in the kitchen */

= Introduction =

This article discusses “Object Think” brainstorming methodology. It is intended for experienced programmers who write their code in Object oriented style. This article should be viewed as a guideline and not as a set of rules that must be enforced. In this article the word “entity” means a real-life entity, i.e. chair, apple, bird, shopping cart etc. The word “object” means a model that is used to describe a real-life entity.

Here is what [1] says about object think and object oriented development:

Poor object thinkers put data and functions into objects haphazardly. At best, they use a set of guidelines they find difficult to explain. This makes their models and code difficult to understand and brittle to changes in requirements and system growth. When requirements change, a brittle object model must significantly alter its structure by redefining objects. Object models built through functional analysis are filled with objects representing functions which makes them notoriously brittle as changes in functional requirements render objects obsolete, and reorder collaborations among them.

Good object thinkers apply consistent principles for distributing data and functions; they can explain and justify the results in their object models by relating them back to the objects in the business domain. Object models built with object think remain stable as the requirements and the system evolve because the model mirrors real-world objects and their relationships. New requirements mean more of the domain is being modeled or more responsibilities are being given to the objects that are already modeled. These changes are neatly encapsulated in a stable object model by adding new objects and expanding objects’ responsibilities. Objects do not change their meaning or lose collaborators, so the underlying structure of the model remains intact even as layers are snapped on top of it.

= What is “Object Think”? =
“Object Think” is a brainstorming methodology for architecting software. This methodology encourages a developer to think just like real-life entities. An object will abstract the entity’s responsibilities, collaborations, and even it’s “persona”. In other words the developer is encouraged to “think” like an entity, “behave” like an entity and even “talk” like an entity. It is a good idea to adopt a first-person voice during development of a model of an entity by an object. I.e. I’m an object. What do I know about myself? What do I know about the world around me? What can I do with myself? What can I with others? What is my function? e.t.c.

Here are a set of principles that were outlined by [1] when developing with object think:
* '''Personify Objects.''' Object model a domain by imagining its entities as active, knowing objects, capable of performing complex actions.
* '''Give Object Responsibilities.''' Turn information about a real-world entity and the actions performed on it into responsibilities of the object representing the entity.
* '''Object’s responsibilities.''' An object’s responsibilities are: whom I know – my collaborations with others; what I do – my services; and what I know – my properties
* '''Talk Like an Object.''' To scope an object’s responsibilities, imagine yourself as the object, and adopt the first-person voice when discussing it.

Let’s consider several examples which will help us better understand what object think is and how it works

= Examples =
== A shopping cart in the e-commerce application ==

I’m a shopping cart. I know how many products are in me. I know the total price of the products in me. I can empty myself by throwing everything away from me or by going through a checkout. I know that I’m used by a user.

From this we can see that this object most likely will contain a set of product objects, total_price property, an empty method which can be used in two ways, either by going through a checkout or by the user who can empty it out.

== A tire in the tire manufacturing plant ==

I’m a tire. I know my manufacturer. I know that if I haven’t passed the testing stage I will be recycled, and I did pass a testing stage I will be used. I know what components I’m made of and their quantity. I know the exact process of how I’m made. I know brands and models of cars I should be used with. I know the date of my manufacturing and the date I was put on a wheel of a car. I know the mileage I should be used for. I know my warranty. I also know how I should be recycled.

From this example certain methods can be clearly seen: manufacture, recycle, a method to return if the testing was passed, return the date of manufacturing, and the date a tire was placed on a wheel, return models and brands of cars that this tire is compatible.
It also can be seen that a tire will contain other objects inside of it, such as components it is made of.

== A peanut butter jelly sandwich in the kitchen ==

This example was taken from [1] and [2]

I’m a peanut butter jelly sandwich. I’m always made with two slices of the same type of bread. I know that a thin bread slice cannot support chunky peanut butter (assumption) and a thin bread slice cannot support a heavy application of ingredient. I know that one bread slice must contain peanut butter and the other must contain jelly.

This example is a bit harder than previous two. Here are the requirements that we can derive from this description:
* a sandwich requires two slices of the same type of bread
* a thin bread slice cannot support chunky peanut butter
* a thin bread slice cannot support a heavy application of an ingredient
* one bread slice must contain peanut butter and the other must contain jelly.

Now consider the peanut-butter-and-jelly sandwich business process. Creating the application transaction is the crucial step in the business process of building a peanut-butter-and-jelly sandwich because this step verifies the business rules as it tries to link the application object to its ingredient and bread slice collaborators. So, which object makes the application transaction? Is it (a) the sandwich, (b) the slice, (c) the ingredient, or (d) the ingredient manager-controller?

Clearly, the choice is between the bread slice and the ingredient; they are the collaborators of the application, and they have the relevant information and business rules. Use first-person object think to pick between the two. For the bread slice, object think says, "I am a bread slice. I have an ingredient applied on me in either a light or heavy amount." For the ingredient, object think says, "I am an ingredient. I apply myself to a bread slice in either a light or heavy amount." Notice that the action of applying ingredient is third-person for a bread slice and first-person for an ingredient. Obviously, the correct answer is (c); an ingredient creates the application object when it applies itself on a bread slice.

[http://ptgmedia.pearsoncmg.com/images/sam_abney1_objectthink/elementLinks/sam_abney1_fig01.jpg Figure] for a complete Peanut-Butter Sandwich object model. [1] and [2]

= References =
[1] Streamlined Object Modeling, Jill Nicola, Mark Mayfield, Mike Abney

[2] http://www.informit.com/articles/article.aspx?p=25184&seqNum=3

[3] http://cfunited.com/blog/index.cfm/2007/7/4/Simon-Horwith--Object-Think--Common-Sense-Software-Architecture

CSC/ECE 517 Fall 2009/wiki3 10 ot

2009-11-10T13:09:21Z

Cybo: /* A peanut butter jelly sandwich in the kitchen */

= Introduction =

This article discusses “Object Think” brainstorming methodology. It is intended for experienced programmers who write their code in Object oriented style. This article should be viewed as a guideline and not as a set of rules that must be enforced. In this article the word “entity” means a real-life entity, i.e. chair, apple, bird, shopping cart etc. The word “object” means a model that is used to describe a real-life entity.

Here is what [1] says about object think and object oriented development:

Poor object thinkers put data and functions into objects haphazardly. At best, they use a set of guidelines they find difficult to explain. This makes their models and code difficult to understand and brittle to changes in requirements and system growth. When requirements change, a brittle object model must significantly alter its structure by redefining objects. Object models built through functional analysis are filled with objects representing functions which makes them notoriously brittle as changes in functional requirements render objects obsolete, and reorder collaborations among them.

Good object thinkers apply consistent principles for distributing data and functions; they can explain and justify the results in their object models by relating them back to the objects in the business domain. Object models built with object think remain stable as the requirements and the system evolve because the model mirrors real-world objects and their relationships. New requirements mean more of the domain is being modeled or more responsibilities are being given to the objects that are already modeled. These changes are neatly encapsulated in a stable object model by adding new objects and expanding objects’ responsibilities. Objects do not change their meaning or lose collaborators, so the underlying structure of the model remains intact even as layers are snapped on top of it.

= What is “Object Think”? =
“Object Think” is a brainstorming methodology for architecting software. This methodology encourages a developer to think just like real-life entities. An object will abstract the entity’s responsibilities, collaborations, and even it’s “persona”. In other words the developer is encouraged to “think” like an entity, “behave” like an entity and even “talk” like an entity. It is a good idea to adopt a first-person voice during development of a model of an entity by an object. I.e. I’m an object. What do I know about myself? What do I know about the world around me? What can I do with myself? What can I with others? What is my function? e.t.c.

Here are a set of principles that were outlined by [1] when developing with object think:
* '''Personify Objects.''' Object model a domain by imagining its entities as active, knowing objects, capable of performing complex actions.
* '''Give Object Responsibilities.''' Turn information about a real-world entity and the actions performed on it into responsibilities of the object representing the entity.
* '''Object’s responsibilities.''' An object’s responsibilities are: whom I know – my collaborations with others; what I do – my services; and what I know – my properties
* '''Talk Like an Object.''' To scope an object’s responsibilities, imagine yourself as the object, and adopt the first-person voice when discussing it.

Let’s consider several examples which will help us better understand what object think is and how it works

= Examples =
== A shopping cart in the e-commerce application ==

I’m a shopping cart. I know how many products are in me. I know the total price of the products in me. I can empty myself by throwing everything away from me or by going through a checkout. I know that I’m used by a user.

From this we can see that this object most likely will contain a set of product objects, total_price property, an empty method which can be used in two ways, either by going through a checkout or by the user who can empty it out.

== A tire in the tire manufacturing plant ==

I’m a tire. I know my manufacturer. I know that if I haven’t passed the testing stage I will be recycled, and I did pass a testing stage I will be used. I know what components I’m made of and their quantity. I know the exact process of how I’m made. I know brands and models of cars I should be used with. I know the date of my manufacturing and the date I was put on a wheel of a car. I know the mileage I should be used for. I know my warranty. I also know how I should be recycled.

From this example certain methods can be clearly seen: manufacture, recycle, a method to return if the testing was passed, return the date of manufacturing, and the date a tire was placed on a wheel, return models and brands of cars that this tire is compatible.
It also can be seen that a tire will contain other objects inside of it, such as components it is made of.

== A peanut butter jelly sandwich in the kitchen ==

This example was taken from [2]

I’m a peanut butter jelly sandwich. I’m always made with two slices of the same type of bread. I know that a thin bread slice cannot support chunky peanut butter (assumption) and a thin bread slice cannot support a heavy application of ingredient. I know that one bread slice must contain peanut butter and the other must contain jelly.

This example is a bit harder than previous two. Here are the requirements that we can derive from this description:
* a sandwich requires two slices of the same type of bread
* a thin bread slice cannot support chunky peanut butter
* a thin bread slice cannot support a heavy application of an ingredient
* one bread slice must contain peanut butter and the other must contain jelly.

Now consider the peanut-butter-and-jelly sandwich business process. Creating the application transaction is the crucial step in the business process of building a peanut-butter-and-jelly sandwich because this step verifies the business rules as it tries to link the application object to its ingredient and bread slice collaborators. So, which object makes the application transaction? Is it (a) the sandwich, (b) the slice, (c) the ingredient, or (d) the ingredient manager-controller?

Clearly, the choice is between the bread slice and the ingredient; they are the collaborators of the application, and they have the relevant information and business rules. Use first-person object think to pick between the two. For the bread slice, object think says, "I am a bread slice. I have an ingredient applied on me in either a light or heavy amount." For the ingredient, object think says, "I am an ingredient. I apply myself to a bread slice in either a light or heavy amount." Notice that the action of applying ingredient is third-person for a bread slice and first-person for an ingredient. Obviously, the correct answer is (c); an ingredient creates the application object when it applies itself on a bread slice.

[http://ptgmedia.pearsoncmg.com/images/sam_abney1_objectthink/elementLinks/sam_abney1_fig01.jpg Figure] for a complete Peanut-Butter Sandwich object model. [2]

= References =
[1] Streamlined Object Modeling, Jill Nicola, Mark Mayfield, Mike Abney

[2] http://www.informit.com/articles/article.aspx?p=25184&seqNum=3

[3] http://cfunited.com/blog/index.cfm/2007/7/4/Simon-Horwith--Object-Think--Common-Sense-Software-Architecture

CSC/ECE 517 Fall 2009/wiki3 10 ot

2009-11-10T13:04:43Z

Cybo: /* References */

= Introduction =

This article discusses “Object Think” brainstorming methodology. It is intended for experienced programmers who write their code in Object oriented style. This article should be viewed as a guideline and not as a set of rules that must be enforced. In this article the word “entity” means a real-life entity, i.e. chair, apple, bird, shopping cart etc. The word “object” means a model that is used to describe a real-life entity.

Here is what [1] says about object think and object oriented development:

Poor object thinkers put data and functions into objects haphazardly. At best, they use a set of guidelines they find difficult to explain. This makes their models and code difficult to understand and brittle to changes in requirements and system growth. When requirements change, a brittle object model must significantly alter its structure by redefining objects. Object models built through functional analysis are filled with objects representing functions which makes them notoriously brittle as changes in functional requirements render objects obsolete, and reorder collaborations among them.

Good object thinkers apply consistent principles for distributing data and functions; they can explain and justify the results in their object models by relating them back to the objects in the business domain. Object models built with object think remain stable as the requirements and the system evolve because the model mirrors real-world objects and their relationships. New requirements mean more of the domain is being modeled or more responsibilities are being given to the objects that are already modeled. These changes are neatly encapsulated in a stable object model by adding new objects and expanding objects’ responsibilities. Objects do not change their meaning or lose collaborators, so the underlying structure of the model remains intact even as layers are snapped on top of it.

= What is “Object Think”? =
“Object Think” is a brainstorming methodology for architecting software. This methodology encourages a developer to think just like real-life entities. An object will abstract the entity’s responsibilities, collaborations, and even it’s “persona”. In other words the developer is encouraged to “think” like an entity, “behave” like an entity and even “talk” like an entity. It is a good idea to adopt a first-person voice during development of a model of an entity by an object. I.e. I’m an object. What do I know about myself? What do I know about the world around me? What can I do with myself? What can I with others? What is my function? e.t.c.

Here are a set of principles that were outlined by [1] when developing with object think:
* '''Personify Objects.''' Object model a domain by imagining its entities as active, knowing objects, capable of performing complex actions.
* '''Give Object Responsibilities.''' Turn information about a real-world entity and the actions performed on it into responsibilities of the object representing the entity.
* '''Object’s responsibilities.''' An object’s responsibilities are: whom I know – my collaborations with others; what I do – my services; and what I know – my properties
* '''Talk Like an Object.''' To scope an object’s responsibilities, imagine yourself as the object, and adopt the first-person voice when discussing it.

Let’s consider several examples which will help us better understand what object think is and how it works

= Examples =
== A shopping cart in the e-commerce application ==

I’m a shopping cart. I know how many products are in me. I know the total price of the products in me. I can empty myself by throwing everything away from me or by going through a checkout. I know that I’m used by a user.

From this we can see that this object most likely will contain a set of product objects, total_price property, an empty method which can be used in two ways, either by going through a checkout or by the user who can empty it out.

== A tire in the tire manufacturing plant ==

I’m a tire. I know my manufacturer. I know that if I haven’t passed the testing stage I will be recycled, and I did pass a testing stage I will be used. I know what components I’m made of and their quantity. I know the exact process of how I’m made. I know brands and models of cars I should be used with. I know the date of my manufacturing and the date I was put on a wheel of a car. I know the mileage I should be used for. I know my warranty. I also know how I should be recycled.

From this example certain methods can be clearly seen: manufacture, recycle, a method to return if the testing was passed, return the date of manufacturing, and the date a tire was placed on a wheel, return models and brands of cars that this tire is compatible.
It also can be seen that a tire will contain other objects inside of it, such as components it is made of.

== A peanut butter jelly sandwich in the kitchen ==

This example was taken from [2]

I’m a peanut butter jelly sandwich. I’m always made with two slices of the same type of bread. I know that a thin bread slice cannot support chunky peanut butter (assumption) and a thin bread slice cannot support a heavy application of ingredient. I know that one bread slice must contain peanut butter and the other must contain jelly.

This example is a bit harder than previous two. Here are the requirements that we can derive from this description:
* a sandwich requires two slices of the same type of bread
* a thin bread slice cannot support chunky peanut butter
* a thin bread slice cannot support a heavy application of an ingredient
* one bread slice must contain peanut butter and the other must contain jelly.

Now consider the peanut-butter-and-jelly sandwich business process. Creating the application transaction is the crucial step in the business process of building a peanut-butter-and-jelly sandwich because this step verifies the business rules as it tries to link the application object to its ingredient and bread slice collaborators. So, which object makes the application transaction? Is it (a) the sandwich, (b) the slice, (c) the ingredient, or (d) the ingredient manager-controller?

Clearly, the choice is between the bread slice and the ingredient; they are the collaborators of the application, and they have the relevant information and business rules. Use first-person object think to pick between the two. For the bread slice, object think says, "I am a bread slice. I have an ingredient applied on me in either a light or heavy amount." For the ingredient, object think says, "I am an ingredient. I apply myself to a bread slice in either a light or heavy amount." Notice that the action of applying ingredient is third-person for a bread slice and first-person for an ingredient. Obviously, the correct answer is (c); an ingredient creates the application object when it applies itself on a bread slice.

[http://ptgmedia.pearsoncmg.com/images/sam_abney1_objectthink/elementLinks/sam_abney1_fig01.jpg Figure] for a complete Peanut-Butter Sandwich object model. [2]

Promotes a new way of thinking. Way of thinking before you develop. Object are a little more intelligent. Think like an object – anthropomorphism. Objects are composable.
How To use “Object Think”
Must plan
Everything is an object. Literraly replicate everything in the business
Paper Prototyping
Semantic Net Diagram
Use a language common to the domain being described.

= References =
[1] Streamlined Object Modeling, Jill Nicola, Mark Mayfield, Mike Abney

[2] http://www.informit.com/articles/article.aspx?p=25184&seqNum=3

[3] http://cfunited.com/blog/index.cfm/2007/7/4/Simon-Horwith--Object-Think--Common-Sense-Software-Architecture

CSC/ECE 517 Fall 2009/wiki3 10 ot

2009-11-10T13:01:13Z

Cybo: /* Introduction */

= Introduction =

This article discusses “Object Think” brainstorming methodology. It is intended for experienced programmers who write their code in Object oriented style. This article should be viewed as a guideline and not as a set of rules that must be enforced. In this article the word “entity” means a real-life entity, i.e. chair, apple, bird, shopping cart etc. The word “object” means a model that is used to describe a real-life entity.

Here is what [1] says about object think and object oriented development:

Poor object thinkers put data and functions into objects haphazardly. At best, they use a set of guidelines they find difficult to explain. This makes their models and code difficult to understand and brittle to changes in requirements and system growth. When requirements change, a brittle object model must significantly alter its structure by redefining objects. Object models built through functional analysis are filled with objects representing functions which makes them notoriously brittle as changes in functional requirements render objects obsolete, and reorder collaborations among them.

Good object thinkers apply consistent principles for distributing data and functions; they can explain and justify the results in their object models by relating them back to the objects in the business domain. Object models built with object think remain stable as the requirements and the system evolve because the model mirrors real-world objects and their relationships. New requirements mean more of the domain is being modeled or more responsibilities are being given to the objects that are already modeled. These changes are neatly encapsulated in a stable object model by adding new objects and expanding objects’ responsibilities. Objects do not change their meaning or lose collaborators, so the underlying structure of the model remains intact even as layers are snapped on top of it.

= What is “Object Think”? =
“Object Think” is a brainstorming methodology for architecting software. This methodology encourages a developer to think just like real-life entities. An object will abstract the entity’s responsibilities, collaborations, and even it’s “persona”. In other words the developer is encouraged to “think” like an entity, “behave” like an entity and even “talk” like an entity. It is a good idea to adopt a first-person voice during development of a model of an entity by an object. I.e. I’m an object. What do I know about myself? What do I know about the world around me? What can I do with myself? What can I with others? What is my function? e.t.c.

Here are a set of principles that were outlined by [1] when developing with object think:
* '''Personify Objects.''' Object model a domain by imagining its entities as active, knowing objects, capable of performing complex actions.
* '''Give Object Responsibilities.''' Turn information about a real-world entity and the actions performed on it into responsibilities of the object representing the entity.
* '''Object’s responsibilities.''' An object’s responsibilities are: whom I know – my collaborations with others; what I do – my services; and what I know – my properties
* '''Talk Like an Object.''' To scope an object’s responsibilities, imagine yourself as the object, and adopt the first-person voice when discussing it.

Let’s consider several examples which will help us better understand what object think is and how it works

= Examples =
== A shopping cart in the e-commerce application ==

I’m a shopping cart. I know how many products are in me. I know the total price of the products in me. I can empty myself by throwing everything away from me or by going through a checkout. I know that I’m used by a user.

From this we can see that this object most likely will contain a set of product objects, total_price property, an empty method which can be used in two ways, either by going through a checkout or by the user who can empty it out.

== A tire in the tire manufacturing plant ==

I’m a tire. I know my manufacturer. I know that if I haven’t passed the testing stage I will be recycled, and I did pass a testing stage I will be used. I know what components I’m made of and their quantity. I know the exact process of how I’m made. I know brands and models of cars I should be used with. I know the date of my manufacturing and the date I was put on a wheel of a car. I know the mileage I should be used for. I know my warranty. I also know how I should be recycled.

From this example certain methods can be clearly seen: manufacture, recycle, a method to return if the testing was passed, return the date of manufacturing, and the date a tire was placed on a wheel, return models and brands of cars that this tire is compatible.
It also can be seen that a tire will contain other objects inside of it, such as components it is made of.

== A peanut butter jelly sandwich in the kitchen ==

This example was taken from [2]

I’m a peanut butter jelly sandwich. I’m always made with two slices of the same type of bread. I know that a thin bread slice cannot support chunky peanut butter (assumption) and a thin bread slice cannot support a heavy application of ingredient. I know that one bread slice must contain peanut butter and the other must contain jelly.

This example is a bit harder than previous two. Here are the requirements that we can derive from this description:
* a sandwich requires two slices of the same type of bread
* a thin bread slice cannot support chunky peanut butter
* a thin bread slice cannot support a heavy application of an ingredient
* one bread slice must contain peanut butter and the other must contain jelly.

Now consider the peanut-butter-and-jelly sandwich business process. Creating the application transaction is the crucial step in the business process of building a peanut-butter-and-jelly sandwich because this step verifies the business rules as it tries to link the application object to its ingredient and bread slice collaborators. So, which object makes the application transaction? Is it (a) the sandwich, (b) the slice, (c) the ingredient, or (d) the ingredient manager-controller?

Clearly, the choice is between the bread slice and the ingredient; they are the collaborators of the application, and they have the relevant information and business rules. Use first-person object think to pick between the two. For the bread slice, object think says, "I am a bread slice. I have an ingredient applied on me in either a light or heavy amount." For the ingredient, object think says, "I am an ingredient. I apply myself to a bread slice in either a light or heavy amount." Notice that the action of applying ingredient is third-person for a bread slice and first-person for an ingredient. Obviously, the correct answer is (c); an ingredient creates the application object when it applies itself on a bread slice.

[http://ptgmedia.pearsoncmg.com/images/sam_abney1_objectthink/elementLinks/sam_abney1_fig01.jpg Figure] for a complete Peanut-Butter Sandwich object model. [2]

Promotes a new way of thinking. Way of thinking before you develop. Object are a little more intelligent. Think like an object – anthropomorphism. Objects are composable.
How To use “Object Think”
Must plan
Everything is an object. Literraly replicate everything in the business
Paper Prototyping
Semantic Net Diagram
Use a language common to the domain being described.

= References =
[1] Streamlined Object Modeling, Jill Nicola, Mark Mayfield, Mike Abney

[2] http://www.informit.com/articles/article.aspx?p=25184&seqNum=3

CSC/ECE 517 Fall 2009/wiki3 10 ot

2009-11-10T12:56:42Z

Cybo:

= Introduction =

This article discusses “Object Think” brainstorming methodology. It is intended for experienced programmers who write their code in Object oriented style. This article should be viewed as a guideline and not as a set of rules that must be enforced. In this article the word “entity” means a real-life entity means a real-life entity, i.e. chair, apple, bird, shopping cart etc. The word “object” means a model that is used to describe a real-life entity.

Here is what [1] says about object think and object oriented development:

Poor object thinkers put data and functions into objects haphazardly. At best, they use a set of guidelines they find difficult to explain. This makes their models and code difficult to understand and brittle to changes in requirements and system growth. When requirements change, a brittle object model must significantly alter its structure by redefining objects. Object models built through functional analysis are filled with objects representing functions which makes them notoriously brittle as changes in functional requirements render objects obsolete, and reorder collaborations among them.

Good object thinkers apply consistent principles for distributing data and functions; they can explain and justify the results in their object models by relating them back to the objects in the business domain. Object models built with object think remain stable as the requirements and the system evolve because the model mirrors real-world objects and their relationships. New requirements mean more of the domain is being modeled or more responsibilities are being given to the objects that are already modeled. These changes are neatly encapsulated in a stable object model by adding new objects and expanding objects’ responsibilities. Objects do not change their meaning or lose collaborators, so the underlying structure of the model remains intact even as layers are snapped on top of it.

= What is “Object Think”? =
“Object Think” is a brainstorming methodology for architecting software. This methodology encourages a developer to think just like real-life entities. An object will abstract the entity’s responsibilities, collaborations, and even it’s “persona”. In other words the developer is encouraged to “think” like an entity, “behave” like an entity and even “talk” like an entity. It is a good idea to adopt a first-person voice during development of a model of an entity by an object. I.e. I’m an object. What do I know about myself? What do I know about the world around me? What can I do with myself? What can I with others? What is my function? e.t.c.

Here are a set of principles that were outlined by [1] when developing with object think:
* '''Personify Objects.''' Object model a domain by imagining its entities as active, knowing objects, capable of performing complex actions.
* '''Give Object Responsibilities.''' Turn information about a real-world entity and the actions performed on it into responsibilities of the object representing the entity.
* '''Object’s responsibilities.''' An object’s responsibilities are: whom I know – my collaborations with others; what I do – my services; and what I know – my properties
* '''Talk Like an Object.''' To scope an object’s responsibilities, imagine yourself as the object, and adopt the first-person voice when discussing it.

Let’s consider several examples which will help us better understand what object think is and how it works

= Examples =
== A shopping cart in the e-commerce application ==

I’m a shopping cart. I know how many products are in me. I know the total price of the products in me. I can empty myself by throwing everything away from me or by going through a checkout. I know that I’m used by a user.

From this we can see that this object most likely will contain a set of product objects, total_price property, an empty method which can be used in two ways, either by going through a checkout or by the user who can empty it out.

== A tire in the tire manufacturing plant ==

I’m a tire. I know my manufacturer. I know that if I haven’t passed the testing stage I will be recycled, and I did pass a testing stage I will be used. I know what components I’m made of and their quantity. I know the exact process of how I’m made. I know brands and models of cars I should be used with. I know the date of my manufacturing and the date I was put on a wheel of a car. I know the mileage I should be used for. I know my warranty. I also know how I should be recycled.

From this example certain methods can be clearly seen: manufacture, recycle, a method to return if the testing was passed, return the date of manufacturing, and the date a tire was placed on a wheel, return models and brands of cars that this tire is compatible.
It also can be seen that a tire will contain other objects inside of it, such as components it is made of.

== A peanut butter jelly sandwich in the kitchen ==

This example was taken from [2]

I’m a peanut butter jelly sandwich. I’m always made with two slices of the same type of bread. I know that a thin bread slice cannot support chunky peanut butter (assumption) and a thin bread slice cannot support a heavy application of ingredient. I know that one bread slice must contain peanut butter and the other must contain jelly.

This example is a bit harder than previous two. Here are the requirements that we can derive from this description:
* a sandwich requires two slices of the same type of bread
* a thin bread slice cannot support chunky peanut butter
* a thin bread slice cannot support a heavy application of an ingredient
* one bread slice must contain peanut butter and the other must contain jelly.

Now consider the peanut-butter-and-jelly sandwich business process. Creating the application transaction is the crucial step in the business process of building a peanut-butter-and-jelly sandwich because this step verifies the business rules as it tries to link the application object to its ingredient and bread slice collaborators. So, which object makes the application transaction? Is it (a) the sandwich, (b) the slice, (c) the ingredient, or (d) the ingredient manager-controller?

Clearly, the choice is between the bread slice and the ingredient; they are the collaborators of the application, and they have the relevant information and business rules. Use first-person object think to pick between the two. For the bread slice, object think says, "I am a bread slice. I have an ingredient applied on me in either a light or heavy amount." For the ingredient, object think says, "I am an ingredient. I apply myself to a bread slice in either a light or heavy amount." Notice that the action of applying ingredient is third-person for a bread slice and first-person for an ingredient. Obviously, the correct answer is (c); an ingredient creates the application object when it applies itself on a bread slice.

[http://ptgmedia.pearsoncmg.com/images/sam_abney1_objectthink/elementLinks/sam_abney1_fig01.jpg Figure] for a complete Peanut-Butter Sandwich object model. [2]

Promotes a new way of thinking. Way of thinking before you develop. Object are a little more intelligent. Think like an object – anthropomorphism. Objects are composable.
How To use “Object Think”
Must plan
Everything is an object. Literraly replicate everything in the business
Paper Prototyping
Semantic Net Diagram
Use a language common to the domain being described.

= References =
[1] Streamlined Object Modeling, Jill Nicola, Mark Mayfield, Mike Abney

[2] http://www.informit.com/articles/article.aspx?p=25184&seqNum=3

CSC/ECE 517 Fall 2009/wiki3 10 ot

2009-11-10T12:55:57Z

Cybo:

= Introduction =

This article discusses “Object Think” brainstorming methodology. It is intended for experienced programmers who write their code in Object oriented style. This article should be viewed as a guideline and not as a set of rules that must be enforced. In this article the word “entity” means a real-life entity means a real-life entity, i.e. chair, apple, bird, shopping cart etc. The word “object” means a model that is used to describe a real-life entity.

Here is what [1] says about object think and object oriented development:

Poor object thinkers put data and functions into objects haphazardly. At best, they use a set of guidelines they find difficult to explain. This makes their models and code difficult to understand and brittle to changes in requirements and system growth. When requirements change, a brittle object model must significantly alter its structure by redefining objects. Object models built through functional analysis are filled with objects representing functions which makes them notoriously brittle as changes in functional requirements render objects obsolete, and reorder collaborations among them.

Good object thinkers apply consistent principles for distributing data and functions; they can explain and justify the results in their object models by relating them back to the objects in the business domain. Object models built with object think remain stable as the requirements and the system evolve because the model mirrors real-world objects and their relationships. New requirements mean more of the domain is being modeled or more responsibilities are being given to the objects that are already modeled. These changes are neatly encapsulated in a stable object model by adding new objects and expanding objects’ responsibilities. Objects do not change their meaning or lose collaborators, so the underlying structure of the model remains intact even as layers are snapped on top of it.

= What is “Object Think”? =
“Object Think” is a brainstorming methodology for architecting software. This methodology encourages a developer to think just like real-life entities. An object will abstract the entity’s responsibilities, collaborations, and even it’s “persona”. In other words the developer is encouraged to “think” like an entity, “behave” like an entity and even “talk” like an entity. It is a good idea to adopt a first-person voice during development of a model of an entity by an object. I.e. I’m an object. What do I know about myself? What do I know about the world around me? What can I do with myself? What can I with others? What is my function? e.t.c.

Here are a set of principles that were outlined by [1] when developing with object think:
* '''Personify Objects.''' Object model a domain by imagining its entities as active, knowing objects, capable of performing complex actions.
* '''Give Object Responsibilities.''' Turn information about a real-world entity and the actions performed on it into responsibilities of the object representing the entity.
* '''Object’s responsibilities.''' An object’s responsibilities are: whom I know – my collaborations with others; what I do – my services; and what I know – my properties
* '''Talk Like an Object.''' To scope an object’s responsibilities, imagine yourself as the object, and adopt the first-person voice when discussing it.

Let’s consider several examples which will help us better understand what object think is and how it works

= Examples =
== A shopping cart in the e-commerce application ==

I’m a shopping cart. I know how many products are in me. I know the total price of the products in me. I can empty myself by throwing everything away from me or by going through a checkout. I know that I’m used by a user.

From this we can see that this object most likely will contain a set of product objects, total_price property, an empty method which can be used in two ways, either by going through a checkout or by the user who can empty it out.

== A tire in the tire manufacturing plant ==

I’m a tire. I know my manufacturer. I know that if I haven’t passed the testing stage I will be recycled, and I did pass a testing stage I will be used. I know what components I’m made of and their quantity. I know the exact process of how I’m made. I know brands and models of cars I should be used with. I know the date of my manufacturing and the date I was put on a wheel of a car. I know the mileage I should be used for. I know my warranty. I also know how I should be recycled.

From this example certain methods can be clearly seen: manufacture, recycle, a method to return if the testing was passed, return the date of manufacturing, and the date a tire was placed on a wheel, return models and brands of cars that this tire is compatible.
It also can be seen that a tire will contain other objects inside of it, such as components it is made of.

== A peanut butter jelly sandwich in the kitchen ==

This example was taken from [2]

I’m a peanut butter jelly sandwich. I’m always made with two slices of the same type of bread. I know that a thin bread slice cannot support chunky peanut butter (assumption) and a thin bread slice cannot support a heavy application of ingredient. I know that one bread slice must contain peanut butter and the other must contain jelly.

This example is a bit harder than previous two. Here are the requirements that we can derive from this description:
* a sandwich requires two slices of the same type of bread
* a thin bread slice cannot support chunky peanut butter
* a thin bread slice cannot support a heavy application of an ingredient
* one bread slice must contain peanut butter and the other must contain jelly.

Now consider the peanut-butter-and-jelly sandwich business process. Creating the application transaction is the crucial step in the business process of building a peanut-butter-and-jelly sandwich because this step verifies the business rules as it tries to link the application object to its ingredient and bread slice collaborators. So, which object makes the application transaction? Is it (a) the sandwich, (b) the slice, (c) the ingredient, or (d) the ingredient manager-controller?

Clearly, the choice is between the bread slice and the ingredient; they are the collaborators of the application, and they have the relevant information and business rules. Use first-person object think to pick between the two. For the bread slice, object think says, "I am a bread slice. I have an ingredient applied on me in either a light or heavy amount." For the ingredient, object think says, "I am an ingredient. I apply myself to a bread slice in either a light or heavy amount." Notice that the action of applying ingredient is third-person for a bread slice and first-person for an ingredient. Obviously, the correct answer is (c); an ingredient creates the application object when it applies itself on a bread slice.

[http://ptgmedia.pearsoncmg.com/images/sam_abney1_objectthink/elementLinks/sam_abney1_fig01.jpg Figure] for a complete Peanut-Butter Sandwich object model. [2]

Promotes a new way of thinking. Way of thinking before you develop. Object are a little more intelligent. Think like an object – anthropomorphism. Objects are composable.
How To use “Object Think”
Must plan
Everything is an object. Literraly replicate everything in the business
Paper Prototyping
Semantic Net Diagram
Use a language common to the domain being described.

= References =
[1] Streamlined Object Modeling, Jill Nicola, Mark Mayfield, Mike Abney

[2] http://www.informit.com/articles/article.aspx?p=25184&seqNum=3

CSC/ECE 517 Fall 2009/wiki3 10 ot

2009-11-10T12:54:05Z

Cybo:

= Introduction =

This article discusses “Object Think” brainstorming methodology. It is intended for experienced programmers who write their code in Object oriented style. This article should be viewed as a guideline and not as a set of rules that must be enforced. In this article the word “entity” means a real-life entity means a real-life entity, i.e. chair, apple, bird, shopping cart etc. The word “object” means a model that is used to describe a real-life entity.

Here is what [1] says about object think and object oriented development:

Poor object thinkers put data and functions into objects haphazardly. At best, they use a set of guidelines they find difficult to explain. This makes their models and code difficult to understand and brittle to changes in requirements and system growth. When requirements change, a brittle object model must significantly alter its structure by redefining objects. Object models built through functional analysis are filled with objects representing functions which makes them notoriously brittle as changes in functional requirements render objects obsolete, and reorder collaborations among them.

Good object thinkers apply consistent principles for distributing data and functions; they can explain and justify the results in their object models by relating them back to the objects in the business domain. Object models built with object think remain stable as the requirements and the system evolve because the model mirrors real-world objects and their relationships. New requirements mean more of the domain is being modeled or more responsibilities are being given to the objects that are already modeled. These changes are neatly encapsulated in a stable object model by adding new objects and expanding objects’ responsibilities. Objects do not change their meaning or lose collaborators, so the underlying structure of the model remains intact even as layers are snapped on top of it.

= What is “Object Think”? =
“Object Think” is a brainstorming methodology for architecting software. This methodology encourages a developer to think just like real-life entities. An object will abstract the entity’s responsibilities, collaborations, and even it’s “persona”. In other words the developer is encouraged to “think” like an entity, “behave” like an entity and even “talk” like an entity. It is a good idea to adopt a first-person voice during development of a model of an entity by an object. I.e. I’m an object. What do I know about myself? What do I know about the world around me? What can I do with myself? What can I with others? What is my function? e.t.c.

Here are a set of principles that were outlined by [1] when developing with object think:
* '''Personify Objects.''' Object model a domain by imagining its entities as active, knowing objects, capable of performing complex actions.
* '''Give Object Responsibilities.''' Turn information about a real-world entity and the actions performed on it into responsibilities of the object representing the entity.
* '''Object’s responsibilities.''' An object’s responsibilities are: whom I know – my collaborations with others; what I do – my services; and what I know – my properties
* '''Talk Like an Object.''' To scope an object’s responsibilities, imagine yourself as the object, and adopt the first-person voice when discussing it.

Let’s consider several examples which will help us better understand what object think is and how it works

= Examples =
== A shopping cart in the e-commerce application ==

I’m a shopping cart. I know how many products are in me. I know the total price of the products in me. I can empty myself by throwing everything away from me or by going through a checkout. I know that I’m used by a user.

From this we can see that this object most likely will contain a set of product objects, total_price property, an empty method which can be used in two ways, either by going through a checkout or by the user who can empty it out.

== A tire in the tire manufacturing plant ==

I’m a tire. I know my manufacturer. I know that if I haven’t passed the testing stage I will be recycled, and I did pass a testing stage I will be used. I know what components I’m made of and their quantity. I know the exact process of how I’m made. I know brands and models of cars I should be used with. I know the date of my manufacturing and the date I was put on a wheel of a car. I know the mileage I should be used for. I know my warranty. I also know how I should be recycled.

From this example certain methods can be clearly seen: manufacture, recycle, a method to return if the testing was passed, return the date of manufacturing, and the date a tire was placed on a wheel, return models and brands of cars that this tire is compatible.
It also can be seen that a tire will contain other objects inside of it, such as components it is made of.

== A peanut butter jelly sandwich in the kitchen ==

This example was taken from [2]

I’m a peanut butter jelly sandwich. I’m always made with two slices of the same type of bread. I know that a thin bread slice cannot support chunky peanut butter (assumption) and a thin bread slice cannot support a heavy application of ingredient. I know that one bread slice must contain peanut butter and the other must contain jelly.

This example is a bit harder than previous two. Here are the requirements that we can derive from this description:
* a sandwich requires two slices of the same type of bread
* a thin bread slice cannot support chunky peanut butter
* a thin bread slice cannot support a heavy application of an ingredient
* one bread slice must contain peanut butter and the other must contain jelly.

Now consider the peanut-butter-and-jelly sandwich business process. Creating the application transaction is the crucial step in the business process of building a peanut-butter-and-jelly sandwich because this step verifies the business rules as it tries to link the application object to its ingredient and bread slice collaborators. So, which object makes the application transaction? Is it (a) the sandwich, (b) the slice, (c) the ingredient, or (d) the ingredient manager-controller?

Clearly, the choice is between the bread slice and the ingredient; they are the collaborators of the application, and they have the relevant information and business rules. Use first-person object think to pick between the two. For the bread slice, object think says, "I am a bread slice. I have an ingredient applied on me in either a light or heavy amount." For the ingredient, object think says, "I am an ingredient. I apply myself to a bread slice in either a light or heavy amount." Notice that the action of applying ingredient is third-person for a bread slice and first-person for an ingredient. Obviously, the correct answer is (c); an ingredient creates the application object when it applies itself on a bread slice.

[[Image:image.jpg]]

[http://ptgmedia.pearsoncmg.com/images/sam_abney1_objectthink/elementLinks/sam_abney1_fig01.jpg Here] is the figure for a Peanut-Butter Sandwich object model.

Promotes a new way of thinking. Way of thinking before you develop. Object are a little more intelligent. Think like an object – anthropomorphism. Objects are composable.
How To use “Object Think”
Must plan
Everything is an object. Literraly replicate everything in the business
Paper Prototyping
Semantic Net Diagram
Use a language common to the domain being described.

= References =
[1] Streamlined Object Modeling, Jill Nicola, Mark Mayfield, Mike Abney

[2] http://www.informit.com/articles/article.aspx?p=25184&seqNum=3

CSC/ECE 517 Fall 2009/wiki3 10 ot

2009-11-10T12:52:39Z

Cybo:

= Introduction =

This article discusses “Object Think” brainstorming methodology. It is intended for experienced programmers who write their code in Object oriented style. This article should be viewed as a guideline and not as a set of rules that must be enforced. In this article the word “entity” means a real-life entity means a real-life entity, i.e. chair, apple, bird, shopping cart etc. The word “object” means a model that is used to describe a real-life entity.

Here is what [1] says about object think and object oriented development:

Poor object thinkers put data and functions into objects haphazardly. At best, they use a set of guidelines they find difficult to explain. This makes their models and code difficult to understand and brittle to changes in requirements and system growth. When requirements change, a brittle object model must significantly alter its structure by redefining objects. Object models built through functional analysis are filled with objects representing functions which makes them notoriously brittle as changes in functional requirements render objects obsolete, and reorder collaborations among them.

Good object thinkers apply consistent principles for distributing data and functions; they can explain and justify the results in their object models by relating them back to the objects in the business domain. Object models built with object think remain stable as the requirements and the system evolve because the model mirrors real-world objects and their relationships. New requirements mean more of the domain is being modeled or more responsibilities are being given to the objects that are already modeled. These changes are neatly encapsulated in a stable object model by adding new objects and expanding objects’ responsibilities. Objects do not change their meaning or lose collaborators, so the underlying structure of the model remains intact even as layers are snapped on top of it.

= What is “Object Think”? =
“Object Think” is a brainstorming methodology for architecting software. This methodology encourages a developer to think just like real-life entities. An object will abstract the entity’s responsibilities, collaborations, and even it’s “persona”. In other words the developer is encouraged to “think” like an entity, “behave” like an entity and even “talk” like an entity. It is a good idea to adopt a first-person voice during development of a model of an entity by an object. I.e. I’m an object. What do I know about myself? What do I know about the world around me? What can I do with myself? What can I with others? What is my function? e.t.c.

Here are a set of principles that were outlined by [1] when developing with object think:
* '''Personify Objects.''' Object model a domain by imagining its entities as active, knowing objects, capable of performing complex actions.
* '''Give Object Responsibilities.''' Turn information about a real-world entity and the actions performed on it into responsibilities of the object representing the entity.
* '''Object’s responsibilities.''' An object’s responsibilities are: whom I know – my collaborations with others; what I do – my services; and what I know – my properties
* '''Talk Like an Object.''' To scope an object’s responsibilities, imagine yourself as the object, and adopt the first-person voice when discussing it.

Let’s consider several examples which will help us better understand what object think is and how it works

= Examples =
== A shopping cart in the e-commerce application ==

I’m a shopping cart. I know how many products are in me. I know the total price of the products in me. I can empty myself by throwing everything away from me or by going through a checkout. I know that I’m used by a user.

From this we can see that this object most likely will contain a set of product objects, total_price property, an empty method which can be used in two ways, either by going through a checkout or by the user who can empty it out.

== A tire in the tire manufacturing plant ==

I’m a tire. I know my manufacturer. I know that if I haven’t passed the testing stage I will be recycled, and I did pass a testing stage I will be used. I know what components I’m made of and their quantity. I know the exact process of how I’m made. I know brands and models of cars I should be used with. I know the date of my manufacturing and the date I was put on a wheel of a car. I know the mileage I should be used for. I know my warranty. I also know how I should be recycled.

From this example certain methods can be clearly seen: manufacture, recycle, a method to return if the testing was passed, return the date of manufacturing, and the date a tire was placed on a wheel, return models and brands of cars that this tire is compatible.
It also can be seen that a tire will contain other objects inside of it, such as components it is made of.

== A peanut butter jelly sandwich in the kitchen ==

This example was taken from [2]

I’m a peanut butter jelly sandwich. I’m always made with two slices of the same type of bread. I know that a thin bread slice cannot support chunky peanut butter (assumption) and a thin bread slice cannot support a heavy application of ingredient. I know that one bread slice must contain peanut butter and the other must contain jelly.

This example is a bit harder than previous two. Here are the requirements that we can derive from this description:
* a sandwich requires two slices of the same type of bread
* a thin bread slice cannot support chunky peanut butter
* a thin bread slice cannot support a heavy application of an ingredient
* one bread slice must contain peanut butter and the other must contain jelly.

Now consider the peanut-butter-and-jelly sandwich business process. Creating the application transaction is the crucial step in the business process of building a peanut-butter-and-jelly sandwich because this step verifies the business rules as it tries to link the application object to its ingredient and bread slice collaborators. So, which object makes the application transaction? Is it (a) the sandwich, (b) the slice, (c) the ingredient, or (d) the ingredient manager-controller?

Clearly, the choice is between the bread slice and the ingredient; they are the collaborators of the application, and they have the relevant information and business rules. Use first-person object think to pick between the two. For the bread slice, object think says, "I am a bread slice. I have an ingredient applied on me in either a light or heavy amount." For the ingredient, object think says, "I am an ingredient. I apply myself to a bread slice in either a light or heavy amount." Notice that the action of applying ingredient is third-person for a bread slice and first-person for an ingredient. Obviously, the correct answer is (c); an ingredient creates the application object when it applies itself on a bread slice.

[[Image:http://ptgmedia.pearsoncmg.com/images/sam_abney1_objectthink/elementLinks/sam_abney1_fig01.jpg]]

[http://ptgmedia.pearsoncmg.com/images/sam_abney1_objectthink/elementLinks/sam_abney1_fig01.jpg Here] is the figure for a Peanut-Butter Sandwich object model.

Promotes a new way of thinking. Way of thinking before you develop. Object are a little more intelligent. Think like an object – anthropomorphism. Objects are composable.
How To use “Object Think”
Must plan
Everything is an object. Literraly replicate everything in the business
Paper Prototyping
Semantic Net Diagram
Use a language common to the domain being described.

= References =
[1] Streamlined Object Modeling, Jill Nicola, Mark Mayfield, Mike Abney

[2] http://www.informit.com/articles/article.aspx?p=25184&seqNum=3

CSC/ECE 517 Fall 2009/wiki3 10 ot

2009-11-10T12:50:06Z

Cybo: /* A peanut butter jelly sandwich in the kitchen */

= Introduction =

This article discusses “Object Think” brainstorming methodology. It is intended for experienced programmers who write their code in Object oriented style. This article should be viewed as a guideline and not as a set of rules that must be enforced. In this article the word “entity” means a real-life entity means a real-life entity, i.e. chair, apple, bird, shopping cart etc. The word “object” means a model that is used to describe a real-life entity.

Here is what [1] says about object think and object oriented development:

Poor object thinkers put data and functions into objects haphazardly. At best, they use a set of guidelines they find difficult to explain. This makes their models and code difficult to understand and brittle to changes in requirements and system growth. When requirements change, a brittle object model must significantly alter its structure by redefining objects. Object models built through functional analysis are filled with objects representing functions which makes them notoriously brittle as changes in functional requirements render objects obsolete, and reorder collaborations among them.

Good object thinkers apply consistent principles for distributing data and functions; they can explain and justify the results in their object models by relating them back to the objects in the business domain. Object models built with object think remain stable as the requirements and the system evolve because the model mirrors real-world objects and their relationships. New requirements mean more of the domain is being modeled or more responsibilities are being given to the objects that are already modeled. These changes are neatly encapsulated in a stable object model by adding new objects and expanding objects’ responsibilities. Objects do not change their meaning or lose collaborators, so the underlying structure of the model remains intact even as layers are snapped on top of it.

= What is “Object Think”? =
“Object Think” is a brainstorming methodology for architecting software. This methodology encourages a developer to think just like real-life entities. An object will abstract the entity’s responsibilities, collaborations, and even it’s “persona”. In other words the developer is encouraged to “think” like an entity, “behave” like an entity and even “talk” like an entity. It is a good idea to adopt a first-person voice during development of a model of an entity by an object. I.e. I’m an object. What do I know about myself? What do I know about the world around me? What can I do with myself? What can I with others? What is my function? e.t.c.

Here are a set of principles that were outlined by [1] when developing with object think:
* '''Personify Objects.''' Object model a domain by imagining its entities as active, knowing objects, capable of performing complex actions.
* '''Give Object Responsibilities.''' Turn information about a real-world entity and the actions performed on it into responsibilities of the object representing the entity.
* '''Object’s responsibilities.''' An object’s responsibilities are: whom I know – my collaborations with others; what I do – my services; and what I know – my properties
* '''Talk Like an Object.''' To scope an object’s responsibilities, imagine yourself as the object, and adopt the first-person voice when discussing it.

Let’s consider several examples which will help us better understand what object think is and how it works

= Examples =
== A shopping cart in the e-commerce application ==

I’m a shopping cart. I know how many products are in me. I know the total price of the products in me. I can empty myself by throwing everything away from me or by going through a checkout. I know that I’m used by a user.

From this we can see that this object most likely will contain a set of product objects, total_price property, an empty method which can be used in two ways, either by going through a checkout or by the user who can empty it out.

== A tire in the tire manufacturing plant ==

I’m a tire. I know my manufacturer. I know that if I haven’t passed the testing stage I will be recycled, and I did pass a testing stage I will be used. I know what components I’m made of and their quantity. I know the exact process of how I’m made. I know brands and models of cars I should be used with. I know the date of my manufacturing and the date I was put on a wheel of a car. I know the mileage I should be used for. I know my warranty. I also know how I should be recycled.

From this example certain methods can be clearly seen: manufacture, recycle, a method to return if the testing was passed, return the date of manufacturing, and the date a tire was placed on a wheel, return models and brands of cars that this tire is compatible.
It also can be seen that a tire will contain other objects inside of it, such as components it is made of.

== A peanut butter jelly sandwich in the kitchen ==

This example was taken from [2]

I’m a peanut butter jelly sandwich. I’m always made with two slices of the same type of bread. I know that a thin bread slice cannot support chunky peanut butter (assumption) and a thin bread slice cannot support a heavy application of ingredient. I know that one bread slice must contain peanut butter and the other must contain jelly.

This example is a bit harder than previous two. Here are the requirements that we can derive from this description:
* a sandwich requires two slices of the same type of bread
* a thin bread slice cannot support chunky peanut butter
* a thin bread slice cannot support a heavy application of an ingredient
* one bread slice must contain peanut butter and the other must contain jelly.

Now consider the peanut-butter-and-jelly sandwich business process. Creating the application transaction is the crucial step in the business process of building a peanut-butter-and-jelly sandwich because this step verifies the business rules as it tries to link the application object to its ingredient and bread slice collaborators. So, which object makes the application transaction? Is it (a) the sandwich, (b) the slice, (c) the ingredient, or (d) the ingredient manager-controller?

Clearly, the choice is between the bread slice and the ingredient; they are the collaborators of the application, and they have the relevant information and business rules. Use first-person object think to pick between the two. For the bread slice, object think says, "I am a bread slice. I have an ingredient applied on me in either a light or heavy amount." For the ingredient, object think says, "I am an ingredient. I apply myself to a bread slice in either a light or heavy amount." Notice that the action of applying ingredient is third-person for a bread slice and first-person for an ingredient. Obviously, the correct answer is (c); an ingredient creates the application object when it applies itself on a bread slice.

[http://ptgmedia.pearsoncmg.com/images/sam_abney1_objectthink/elementLinks/sam_abney1_fig01.jpg Here] is the figure for a Peanut-Butter Sandwich object model.

Promotes a new way of thinking. Way of thinking before you develop. Object are a little more intelligent. Think like an object – anthropomorphism. Objects are composable.
How To use “Object Think”
Must plan
Everything is an object. Literraly replicate everything in the business
Paper Prototyping
Semantic Net Diagram
Use a language common to the domain being described.

= References =
[1] Streamlined Object Modeling, Jill Nicola, Mark Mayfield, Mike Abney

[2] http://www.informit.com/articles/article.aspx?p=25184&seqNum=3

CSC/ECE 517 Fall 2009/wiki3 10 ot

2009-11-10T12:39:54Z

Cybo: /* A peanut butter jelly sandwich in the kitchen */

= Introduction =

This article discusses “Object Think” brainstorming methodology. It is intended for experienced programmers who write their code in Object oriented style. This article should be viewed as a guideline and not as a set of rules that must be enforced. In this article the word “entity” means a real-life entity means a real-life entity, i.e. chair, apple, bird, shopping cart etc. The word “object” means a model that is used to describe a real-life entity.

Here is what [1] says about object think and object oriented development:

Poor object thinkers put data and functions into objects haphazardly. At best, they use a set of guidelines they find difficult to explain. This makes their models and code difficult to understand and brittle to changes in requirements and system growth. When requirements change, a brittle object model must significantly alter its structure by redefining objects. Object models built through functional analysis are filled with objects representing functions which makes them notoriously brittle as changes in functional requirements render objects obsolete, and reorder collaborations among them.

Good object thinkers apply consistent principles for distributing data and functions; they can explain and justify the results in their object models by relating them back to the objects in the business domain. Object models built with object think remain stable as the requirements and the system evolve because the model mirrors real-world objects and their relationships. New requirements mean more of the domain is being modeled or more responsibilities are being given to the objects that are already modeled. These changes are neatly encapsulated in a stable object model by adding new objects and expanding objects’ responsibilities. Objects do not change their meaning or lose collaborators, so the underlying structure of the model remains intact even as layers are snapped on top of it.

= What is “Object Think”? =
“Object Think” is a brainstorming methodology for architecting software. This methodology encourages a developer to think just like real-life entities. An object will abstract the entity’s responsibilities, collaborations, and even it’s “persona”. In other words the developer is encouraged to “think” like an entity, “behave” like an entity and even “talk” like an entity. It is a good idea to adopt a first-person voice during development of a model of an entity by an object. I.e. I’m an object. What do I know about myself? What do I know about the world around me? What can I do with myself? What can I with others? What is my function? e.t.c.

Here are a set of principles that were outlined by [1] when developing with object think:
* '''Personify Objects.''' Object model a domain by imagining its entities as active, knowing objects, capable of performing complex actions.
* '''Give Object Responsibilities.''' Turn information about a real-world entity and the actions performed on it into responsibilities of the object representing the entity.
* '''Object’s responsibilities.''' An object’s responsibilities are: whom I know – my collaborations with others; what I do – my services; and what I know – my properties
* '''Talk Like an Object.''' To scope an object’s responsibilities, imagine yourself as the object, and adopt the first-person voice when discussing it.

Let’s consider several examples which will help us better understand what object think is and how it works

= Examples =
== A shopping cart in the e-commerce application ==

I’m a shopping cart. I know how many products are in me. I know the total price of the products in me. I can empty myself by throwing everything away from me or by going through a checkout. I know that I’m used by a user.

From this we can see that this object most likely will contain a set of product objects, total_price property, an empty method which can be used in two ways, either by going through a checkout or by the user who can empty it out.

== A tire in the tire manufacturing plant ==

I’m a tire. I know my manufacturer. I know that if I haven’t passed the testing stage I will be recycled, and I did pass a testing stage I will be used. I know what components I’m made of and their quantity. I know the exact process of how I’m made. I know brands and models of cars I should be used with. I know the date of my manufacturing and the date I was put on a wheel of a car. I know the mileage I should be used for. I know my warranty. I also know how I should be recycled.

From this example certain methods can be clearly seen: manufacture, recycle, a method to return if the testing was passed, return the date of manufacturing, and the date a tire was placed on a wheel, return models and brands of cars that this tire is compatible.
It also can be seen that a tire will contain other objects inside of it, such as components it is made of.

== A peanut butter jelly sandwich in the kitchen ==

I’m a peanut butter jelly sandwich. I’m always made with two slices of the same type of bread. I know that a thin bread slice cannot support chunky peanut butter (assumption) and a thin bread slice cannot support a heavy application of ingredient. I know that one bread slice must contain peanut butter and the other must contain jelly.

This example is a bit harder than previous two. But we can see from here that in this example that sandwich consists of other objects, such as peanut butter, jelly, and bread. The sandwich “knows” how it must make itself, it know that certain types of bread won’t support certain type of ingredient.

Promotes a new way of thinking. Way of thinking before you develop. Object are a little more intelligent. Think like an object – anthropomorphism. Objects are composable.
How To use “Object Think”
Must plan
Everything is an object. Literraly replicate everything in the business
Paper Prototyping
Semantic Net Diagram
Use a language common to the domain being described.

= References =
[1] Streamlined Object Modeling, Jill Nicola, Mark Mayfield, Mike Abney

[2] http://www.informit.com/articles/article.aspx?p=25184&seqNum=3

CSC/ECE 517 Fall 2009/wiki3 10 ot

2009-11-10T12:37:00Z

Cybo: /* A tire in the tire manufacturing plant */

= Introduction =

This article discusses “Object Think” brainstorming methodology. It is intended for experienced programmers who write their code in Object oriented style. This article should be viewed as a guideline and not as a set of rules that must be enforced. In this article the word “entity” means a real-life entity means a real-life entity, i.e. chair, apple, bird, shopping cart etc. The word “object” means a model that is used to describe a real-life entity.

Here is what [1] says about object think and object oriented development:

Poor object thinkers put data and functions into objects haphazardly. At best, they use a set of guidelines they find difficult to explain. This makes their models and code difficult to understand and brittle to changes in requirements and system growth. When requirements change, a brittle object model must significantly alter its structure by redefining objects. Object models built through functional analysis are filled with objects representing functions which makes them notoriously brittle as changes in functional requirements render objects obsolete, and reorder collaborations among them.

Good object thinkers apply consistent principles for distributing data and functions; they can explain and justify the results in their object models by relating them back to the objects in the business domain. Object models built with object think remain stable as the requirements and the system evolve because the model mirrors real-world objects and their relationships. New requirements mean more of the domain is being modeled or more responsibilities are being given to the objects that are already modeled. These changes are neatly encapsulated in a stable object model by adding new objects and expanding objects’ responsibilities. Objects do not change their meaning or lose collaborators, so the underlying structure of the model remains intact even as layers are snapped on top of it.

= What is “Object Think”? =
“Object Think” is a brainstorming methodology for architecting software. This methodology encourages a developer to think just like real-life entities. An object will abstract the entity’s responsibilities, collaborations, and even it’s “persona”. In other words the developer is encouraged to “think” like an entity, “behave” like an entity and even “talk” like an entity. It is a good idea to adopt a first-person voice during development of a model of an entity by an object. I.e. I’m an object. What do I know about myself? What do I know about the world around me? What can I do with myself? What can I with others? What is my function? e.t.c.

Here are a set of principles that were outlined by [1] when developing with object think:
* '''Personify Objects.''' Object model a domain by imagining its entities as active, knowing objects, capable of performing complex actions.
* '''Give Object Responsibilities.''' Turn information about a real-world entity and the actions performed on it into responsibilities of the object representing the entity.
* '''Object’s responsibilities.''' An object’s responsibilities are: whom I know – my collaborations with others; what I do – my services; and what I know – my properties
* '''Talk Like an Object.''' To scope an object’s responsibilities, imagine yourself as the object, and adopt the first-person voice when discussing it.

Let’s consider several examples which will help us better understand what object think is and how it works

= Examples =
== A shopping cart in the e-commerce application ==

I’m a shopping cart. I know how many products are in me. I know the total price of the products in me. I can empty myself by throwing everything away from me or by going through a checkout. I know that I’m used by a user.

From this we can see that this object most likely will contain a set of product objects, total_price property, an empty method which can be used in two ways, either by going through a checkout or by the user who can empty it out.

== A tire in the tire manufacturing plant ==

I’m a tire. I know my manufacturer. I know that if I haven’t passed the testing stage I will be recycled, and I did pass a testing stage I will be used. I know what components I’m made of and their quantity. I know the exact process of how I’m made. I know brands and models of cars I should be used with. I know the date of my manufacturing and the date I was put on a wheel of a car. I know the mileage I should be used for. I know my warranty. I also know how I should be recycled.

From this example certain methods can be clearly seen: manufacture, recycle, a method to return if the testing was passed, return the date of manufacturing, and the date a tire was placed on a wheel, return models and brands of cars that this tire is compatible.
It also can be seen that a tire will contain other objects inside of it, such as components it is made of.

== A peanut butter jelly sandwich in the kitchen ==

I’m a peanut butter jelly sandwich. I’m always made with two slices of the same type of bread. I know that a thin bread slice cannot support chunky peanut butter (assumption) and a thin bread slice cannot support a heavy application of ingredient. I know that one bread slice must contain peanut butter and the other must contain jelly.

This example is a bit harder than previous two. But we can see from here that in this example that sandwich consists of other objects, such as peanut butter, jelly, and bread. The sandwich “knows” how it must make itself, since it know that certain types of bread won’t support certain type of ingredient.

Promotes a new way of thinking. Way of thinking before you develop. Object are a little more intelligent. Think like an object – anthropomorphism. Objects are composable.
How To use “Object Think”
Must plan
Everything is an object. Literraly replicate everything in the business
Paper Prototyping
Semantic Net Diagram
Use a language common to the domain being described.

= References =
[1] Streamlined Object Modeling, Jill Nicola, Mark Mayfield, Mike Abney

[2] http://www.informit.com/articles/article.aspx?p=25184&seqNum=3

CSC/ECE 517 Fall 2009/wiki3 10 ot

2009-11-10T12:34:08Z

Cybo:

= Introduction =

This article discusses “Object Think” brainstorming methodology. It is intended for experienced programmers who write their code in Object oriented style. This article should be viewed as a guideline and not as a set of rules that must be enforced. In this article the word “entity” means a real-life entity means a real-life entity, i.e. chair, apple, bird, shopping cart etc. The word “object” means a model that is used to describe a real-life entity.

Here is what [1] says about object think and object oriented development:

Poor object thinkers put data and functions into objects haphazardly. At best, they use a set of guidelines they find difficult to explain. This makes their models and code difficult to understand and brittle to changes in requirements and system growth. When requirements change, a brittle object model must significantly alter its structure by redefining objects. Object models built through functional analysis are filled with objects representing functions which makes them notoriously brittle as changes in functional requirements render objects obsolete, and reorder collaborations among them.

Good object thinkers apply consistent principles for distributing data and functions; they can explain and justify the results in their object models by relating them back to the objects in the business domain. Object models built with object think remain stable as the requirements and the system evolve because the model mirrors real-world objects and their relationships. New requirements mean more of the domain is being modeled or more responsibilities are being given to the objects that are already modeled. These changes are neatly encapsulated in a stable object model by adding new objects and expanding objects’ responsibilities. Objects do not change their meaning or lose collaborators, so the underlying structure of the model remains intact even as layers are snapped on top of it.

= What is “Object Think”? =
“Object Think” is a brainstorming methodology for architecting software. This methodology encourages a developer to think just like real-life entities. An object will abstract the entity’s responsibilities, collaborations, and even it’s “persona”. In other words the developer is encouraged to “think” like an entity, “behave” like an entity and even “talk” like an entity. It is a good idea to adopt a first-person voice during development of a model of an entity by an object. I.e. I’m an object. What do I know about myself? What do I know about the world around me? What can I do with myself? What can I with others? What is my function? e.t.c.

Here are a set of principles that were outlined by [1] when developing with object think:
* '''Personify Objects.''' Object model a domain by imagining its entities as active, knowing objects, capable of performing complex actions.
* '''Give Object Responsibilities.''' Turn information about a real-world entity and the actions performed on it into responsibilities of the object representing the entity.
* '''Object’s responsibilities.''' An object’s responsibilities are: whom I know – my collaborations with others; what I do – my services; and what I know – my properties
* '''Talk Like an Object.''' To scope an object’s responsibilities, imagine yourself as the object, and adopt the first-person voice when discussing it.

Let’s consider several examples which will help us better understand what object think is and how it works

= Examples =
== A shopping cart in the e-commerce application ==

I’m a shopping cart. I know how many products are in me. I know the total price of the products in me. I can empty myself by throwing everything away from me or by going through a checkout. I know that I’m used by a user.

From this we can see that this object most likely will contain a set of product objects, total_price property, an empty method which can be used in two ways, either by going through a checkout or by the user who can empty it out.

== A tire in the tire manufacturing plant ==

I’m a tire. I know my manufacturer. I know that if I haven’t passed the testing stage I will be recycled, and I did pass a testing stage I will be used. I know what components I’m made of and their quantity. I know the exact process of how I’m made. I know brands and models of cars I should be used with. I know the date of my manufacturing and the date I was put on a wheel of a car. I know the mileage I should be used for. I know my warranty. I also know how I should be recycled.

From this example certain methods can be clearly seen: manufacture, recycle, a method to return if the testing was passed, return the date of manufacturing, and the date was placed on a wheel, return models and brands of cars that this tire is compatible.
It also can be seen that a tire will contain other objects inside of it, such as components it is made of.

== A peanut butter jelly sandwich in the kitchen ==

I’m a peanut butter jelly sandwich. I’m always made with two slices of the same type of bread. I know that a thin bread slice cannot support chunky peanut butter (assumption) and a thin bread slice cannot support a heavy application of ingredient. I know that one bread slice must contain peanut butter and the other must contain jelly.

This example is a bit harder than previous two. But we can see from here that in this example that sandwich consists of other objects, such as peanut butter, jelly, and bread. The sandwich “knows” how it must make itself, since it know that certain types of bread won’t support certain type of ingredient.

Promotes a new way of thinking. Way of thinking before you develop. Object are a little more intelligent. Think like an object – anthropomorphism. Objects are composable.
How To use “Object Think”
Must plan
Everything is an object. Literraly replicate everything in the business
Paper Prototyping
Semantic Net Diagram
Use a language common to the domain being described.

= References =
[1] Streamlined Object Modeling, Jill Nicola, Mark Mayfield, Mike Abney

[2] http://www.informit.com/articles/article.aspx?p=25184&seqNum=3

CSC/ECE 517 Fall 2009/wiki3 10 ot

2009-11-10T12:31:35Z

Cybo:

= Introduction =

This article discusses “Object Think” brainstorming methodology. It is intended for experienced programmers who write their code in Object oriented style. This article should be viewed as a guideline and not as a set of rules that must be enforced. In this article the word “entity” means a real-life entity means a real-life entity, i.e. chair, apple, bird, shopping cart etc. The word “object” means a model that is used to describe a real-life entity.

Here is what [1] says about object think and object oriented development:

Poor object thinkers put data and functions into objects haphazardly. At best, they use a set of guidelines they find difficult to explain. This makes their models and code difficult to understand and brittle to changes in requirements and system growth. When requirements change, a brittle object model must significantly alter its structure by redefining objects. Object models built through functional analysis are filled with objects representing functions which makes them notoriously brittle as changes in functional requirements render objects obsolete, and reorder collaborations among them.

Good object thinkers apply consistent principles for distributing data and functions; they can explain and justify the results in their object models by relating them back to the objects in the business domain. Object models built with object think remain stable as the requirements and the system evolve because the model mirrors real-world objects and their relationships. New requirements mean more of the domain is being modeled or more responsibilities are being given to the objects that are already modeled. These changes are neatly encapsulated in a stable object model by adding new objects and expanding objects’ responsibilities. Objects do not change their meaning or lose collaborators, so the underlying structure of the model remains intact even as layers are snapped on top of it.

= What is “Object Think”? =
“Object Think” is a brainstorming methodology for architecting software. This methodology encourages a developer to think just like real-life entities. An object will abstract the entity’s responsibilities, collaborations, and even it’s “persona”. In other words the developer is encouraged to “think” like an entity, “behave” like an entity and even “talk” like an entity. It is a good idea to adopt a first-person voice during development of a model of an entity by an object. I.e. I’m an object. What do I know about myself? What do I know about the world around me? What can I do with myself? What can I with others? What is my function? e.t.c.

Here are a set of principles that were outlined by [1] when developing with object think:
* '''Personify Objects.''' Object model a domain by imagining its entities as active, knowing objects, capable of performing complex actions.
* '''Give Object Responsibilities.''' Turn information about a real-world entity and the actions performed on it into responsibilities of the object representing the entity.
* '''Object’s responsibilities.''' An object’s responsibilities are: whom I know – my collaborations with others; what I do – my services; and what I know – my properties
* '''Talk Like an Object.''' To scope an object’s responsibilities, imagine yourself as the object, and adopt the first-person voice when discussing it.

Let’s consider several examples which will help us better understand what object think is and how it works

= Examples =
== A shopping cart in the e-commerce application ==

I’m a shopping cart. I know how many products are in me. I know the total price of the products in me. I can empty myself by throwing everything away from me or by going through a checkout. I know that I’m used by a user.

From this we can see that this object most likely will contain a set of product objects, total_price property, an empty method which can be used in two ways, either by going through a checkout or by the user who can empty it out.

== A tire in the tire manufacturing plant ==

I’m a tire. I know my manufacturer. I know that if I haven’t passed the testing stage I will be recycled, and I did pass a testing stage I will be used. I know what components I’m made of and their quantity. I know the exact process of how I’m made. I know brands and models of cars I should be used with. I know the date of my manufacturing and the date I was put on a wheel of a car. I know the mileage I should be used for. I know my warranty. I also know how I should be recycled.

From this example certain methods can be clearly seen: manufacture, recycle, a method to return if the testing was passed, return the date of manufacturing, and the date was placed on a wheel, return models and brands of cars that this tire is compatible.
It also can be seen that a tire will contain other objects inside of it, such as components it is made of.

== A peanut butter jelly sandwich in the kitchen ==

I’m a peanut butter jelly sandwich. I’m always made with two slices of the same type of bread. I know that a thin bread slice cannot support chunky peanut butter (assumption) and a thin bread slice cannot support a heavy application of ingredient. I know that one bread slice must contain peanut butter and the other must contain jelly.

This example is a bit harder than previous two. But we can see from here that in this example that sandwich consists of other objects, such as peanut butter, jelly, and bread. The sandwich “knows” how it must make itself, since it know that certain types of bread won’t support certain type of ingredient.

Promotes a new way of thinking. Way of thinking before you develop. Object are a little more intelligent. Think like an object – anthropomorphism. Objects are composable.
How To use “Object Think”
Must plan
Everything is an object. Literraly replicate everything in the business
Paper Prototyping
Semantic Net Diagram
Use a language common to the domain being described.

[1] Streamlined Object Modeling, Jill Nicola, Mark Mayfield, Mike Abney
[2] http://www.informit.com/articles/article.aspx?p=25184&seqNum=3

CSC/ECE 517 Fall 2009/wiki3 10 ot

2009-11-10T12:30:45Z

Cybo:

= Introduction =

This article discusses “Object Think” brainstorming methodology. It is intended for experienced programmers who write their code in Object oriented style. This article should be viewed as a guideline and not as a set of rules that must be enforced. In this article the word “entity” means a real-life entity means a real-life entity, i.e. chair, apple, bird, shopping cart etc. The word “object” means a model that is used to describe a real-life entity.

Here is what [1] says about object think and object oriented development:

Poor object thinkers put data and functions into objects haphazardly. At best, they use a set of guidelines they find difficult to explain. This makes their models and code difficult to understand and brittle to changes in requirements and system growth. When requirements change, a brittle object model must significantly alter its structure by redefining objects. Object models built through functional analysis are filled with objects representing functions which makes them notoriously brittle as changes in functional requirements render objects obsolete, and reorder collaborations among them.

Good object thinkers apply consistent principles for distributing data and functions; they can explain and justify the results in their object models by relating them back to the objects in the business domain. Object models built with object think remain stable as the requirements and the system evolve because the model mirrors real-world objects and their relationships. New requirements mean more of the domain is being modeled or more responsibilities are being given to the objects that are already modeled. These changes are neatly encapsulated in a stable object model by adding new objects and expanding objects’ responsibilities. Objects do not change their meaning or lose collaborators, so the underlying structure of the model remains intact even as layers are snapped on top of it.

= What is “Object Think”? =
“Object Think” is a brainstorming methodology for architecting software. This methodology encourages a developer to think just like real-life entities. An object will abstract the entity’s responsibilities, collaborations, and even it’s “persona”. In other words the developer is encouraged to “think” like an entity, “behave” like an entity and even “talk” like an entity. It is a good idea to adopt a first-person voice during development of a model of an entity by an object. I.e. I’m an object. What do I know about myself? What do I know about the world around me? What can I do with myself? What can I with others? What is my function? e.t.c.

Here are a set of principles that were outlined by [1] when developing with object think:
* '''Personify Objects.''' Object model a domain by imagining its entities as active, knowing objects, capable of performing complex actions.
* '''Give Object Responsibilities.''' Turn information about a real-world entity and the actions performed on it into responsibilities of the object representing the entity.
* '''Object’s responsibilities.''' An object’s responsibilities are: whom I know – my collaborations with others; what I do – my services; and what I know – my properties
* '''Talk Like an Object.''' To scope an object’s responsibilities, imagine yourself as the object, and adopt the first-person voice when discussing it.

Let’s consider several examples which will help us better understand what object think is and how it works

= Examples =
== A shopping cart in the e-commerce application ==

I’m a shopping cart. I know how many products are in me. I know the total price of the products in me. I can empty myself by throwing everything away from me or by going through a checkout. I know that I’m used by a user.

From this we can see that this object most likely will contain a set of product objects, total_price property, an empty method which can be used in two ways, either by going through a checkout or by the user who can empty it out.

== A tire in the tire manufacturing plant ==

I’m a tire. I know my manufacturer. I know that if I haven’t passed the testing stage I will be recycled, and I did pass a testing stage I will be used. I know what components I’m made of and their quantity. I know the exact process of how I’m made. I know brands and models of cars I should be used with. I know the date of my manufacturing and the date I was put on a wheel of a car. I know the mileage I should be used for. I know my warranty. I also know how I should be recycled.

From this example certain methods can be clearly seen: manufacture, recycle, a method to return if the testing was passed, return the date of manufacturing, and the date was placed on a wheel, return models and brands of cars that this tire is compatible.
It also can be seen that a tire will contain other objects inside of it, such as components it is made of.

== A peanut butter jelly sandwich in the kitchen == [2]

I’m a peanut butter jelly sandwich. I’m always made with two slices of the same type of bread. I know that a thin bread slice cannot support chunky peanut butter (assumption) and a thin bread slice cannot support a heavy application of ingredient. I know that one bread slice must contain peanut butter and the other must contain jelly.

This example is a bit harder than previous two. But we can see from here that in this example that sandwich consists of other objects, such as peanut butter, jelly, and bread. The sandwich “knows” how it must make itself, since it know that certain types of bread won’t support certain type of ingredient.

Promotes a new way of thinking. Way of thinking before you develop. Object are a little more intelligent. Think like an object – anthropomorphism. Objects are composable.
How To use “Object Think”
Must plan
Everything is an object. Literraly replicate everything in the business
Paper Prototyping
Semantic Net Diagram
Use a language common to the domain being described.

[1] Streamlined Object Modeling, Jill Nicola, Mark Mayfield, Mike Abney
[2] http://www.informit.com/articles/article.aspx?p=25184&seqNum=3

CSC/ECE 517 Fall 2009/wiki3 10 ot

2009-11-10T12:30:00Z

Cybo:

= Introduction =

This article discusses “Object Think” brainstorming methodology. It is intended for experienced programmers who write their code in Object oriented style. This article should be viewed as a guideline and not as a set of rules that must be enforced. In this article the word “entity” means a real-life entity means a real-life entity, i.e. chair, apple, bird, shopping cart etc. The word “object” means a model that is used to describe a real-life entity.

Here is what [1] says about object think and object oriented development:

Poor object thinkers put data and functions into objects haphazardly. At best, they use a set of guidelines they find difficult to explain. This makes their models and code difficult to understand and brittle to changes in requirements and system growth. When requirements change, a brittle object model must significantly alter its structure by redefining objects. Object models built through functional analysis are filled with objects representing functions which makes them notoriously brittle as changes in functional requirements render objects obsolete, and reorder collaborations among them.

Good object thinkers apply consistent principles for distributing data and functions; they can explain and justify the results in their object models by relating them back to the objects in the business domain. Object models built with object think remain stable as the requirements and the system evolve because the model mirrors real-world objects and their relationships. New requirements mean more of the domain is being modeled or more responsibilities are being given to the objects that are already modeled. These changes are neatly encapsulated in a stable object model by adding new objects and expanding objects’ responsibilities. Objects do not change their meaning or lose collaborators, so the underlying structure of the model remains intact even as layers are snapped on top of it.

= What is “Object Think”? =
“Object Think” is a brainstorming methodology for architecting software. This methodology encourages a developer to think just like real-life entities. An object will abstract the entity’s responsibilities, collaborations, and even it’s “persona”. In other words the developer is encouraged to “think” like an entity, “behave” like an entity and even “talk” like an entity. It is a good idea to adopt a first-person voice during development of a model of an entity by an object. I.e. I’m an object. What do I know about myself? What do I know about the world around me? What can I do with myself? What can I with others? What is my function? e.t.c.

Here are a set of principles that were outlined by [1] when developing with object think:
* '''Personify Objects.''' Object model a domain by imagining its entities as active, knowing objects, capable of performing complex actions.
* '''Give Object Responsibilities.''' Turn information about a real-world entity and the actions performed on it into responsibilities of the object representing the entity.
* '''Object’s responsibilities.''' An object’s responsibilities are: whom I know – my collaborations with others; what I do – my services; and what I know – my properties
* '''Talk Like an Object.''' To scope an object’s responsibilities, imagine yourself as the object, and adopt the first-person voice when discussing it.

Let’s consider several examples which will help us better understand what object think is and how it works

= Examples =
== A shopping cart in the e-commerce application ==

I’m a shopping cart. I know how many products are in me. I know the total price of the products in me. I can empty myself by throwing everything away from me or by going through a checkout. I know that I’m used by a user.

From this we can see that this object most likely will contain a set of product objects, total_price property, an empty method which can be used in two ways, either by going through a checkout or by the user who can empty it out.

== A tire in the tire manufacturing plant ==

I’m a tire. I know my manufacturer. I know that if I haven’t passed the testing stage I will be recycled, and I did pass a testing stage I will be used. I know what components I’m made of and their quantity. I know the exact process of how I’m made. I know brands and models of cars I should be used with. I know the date of my manufacturing and the date I was put on a wheel of a car. I know the mileage I should be used for. I know my warranty. I also know how I should be recycled.

From this example certain methods can be clearly seen: manufacture, recycle, a method to return if the testing was passed, return the date of manufacturing, and the date was placed on a wheel, return models and brands of cars that this tire is compatible.
It also can be seen that a tire will contain other objects inside of it, such as components it is made of.

== A peanut butter jelly sandwich in the kitchen ==[2]

I’m a peanut butter jelly sandwich. I’m always made with two slices of the same type of bread. I know that a thin bread slice cannot support chunky peanut butter (assumption) and a thin bread slice cannot support a heavy application of ingredient. I know that one bread slice must contain peanut butter and the other must contain jelly.

This example is a bit harder than previous two. But we can see from here that in this example that sandwich consists of other objects, such as peanut butter, jelly, and bread. The sandwich “knows” how it must make itself, since it know that certain types of bread won’t support certain type of ingredient.

Promotes a new way of thinking. Way of thinking before you develop. Object are a little more intelligent. Think like an object – anthropomorphism. Objects are composable.
How To use “Object Think”
Must plan
Everything is an object. Literraly replicate everything in the business
Paper Prototyping
Semantic Net Diagram
Use a language common to the domain being described.

[1] Streamlined Object Modeling, Jill Nicola, Mark Mayfield, Mike Abney
[2] http://www.informit.com/articles/article.aspx?p=25184&seqNum=3

CSC/ECE 517 Fall 2009/wiki3 10 ot

2009-11-10T12:28:32Z

Cybo:

= Introduction =

This article discusses “Object Think” brainstorming methodology. It is intended for experienced programmers who write their code in Object oriented style. This article should be viewed as a guideline and not as a set of rules that must be enforced. In this article the word “entity” means a real-life entity means a real-life entity, i.e. chair, apple, bird, shopping cart etc. The word “object” means a model that is used to describe a real-life entity.

Here is what [1] says about object think and object oriented development:

Poor object thinkers put data and functions into objects haphazardly. At best, they use a set of guidelines they find difficult to explain. This makes their models and code difficult to understand and brittle to changes in requirements and system growth. When requirements change, a brittle object model must significantly alter its structure by redefining objects. Object models built through functional analysis are filled with objects representing functions which makes them notoriously brittle as changes in functional requirements render objects obsolete, and reorder collaborations among them.

Good object thinkers apply consistent principles for distributing data and functions; they can explain and justify the results in their object models by relating them back to the objects in the business domain. Object models built with object think remain stable as the requirements and the system evolve because the model mirrors real-world objects and their relationships. New requirements mean more of the domain is being modeled or more responsibilities are being given to the objects that are already modeled. These changes are neatly encapsulated in a stable object model by adding new objects and expanding objects’ responsibilities. Objects do not change their meaning or lose collaborators, so the underlying structure of the model remains intact even as layers are snapped on top of it.

= What is “Object Think”? =
“Object Think” is a brainstorming methodology for architecting software. This methodology encourages a developer to think just like real-life entities. An object will abstract the entity’s responsibilities, collaborations, and even it’s “persona”. In other words the developer is encouraged to “think” like an entity, “behave” like an entity and even “talk” like an entity. It is a good idea to adopt a first-person voice during development of a model of an entity by an object. I.e. I’m an object. What do I know about myself? What do I know about the world around me? What can I do with myself? What can I with others? What is my function? e.t.c.

Here are a set of principles that were outlined by [1] when developing with object think:
* '''Personify Objects.''' Object model a domain by imagining its entities as active, knowing objects, capable of performing complex actions.
* '''Give Object Responsibilities.''' Turn information about a real-world entity and the actions performed on it into responsibilities of the object representing the entity.
* '''Object’s responsibilities.''' An object’s responsibilities are: whom I know – my collaborations with others; what I do – my services; and what I know – my properties
* '''Talk Like an Object.''' To scope an object’s responsibilities, imagine yourself as the object, and adopt the first-person voice when discussing it.

Let’s consider several examples which will help us better understand what object think is and how it works

= Examples =
== A shopping cart in the e-commerce application. ==

I’m a shopping cart. I know how many products are in me. I know the total price of the products in me. I can empty myself by throwing everything away from me or by going through a checkout. I know that I’m used by a user.

From this we can see that this object most likely will contain a set of product objects, total_price property, an empty method which can be used in two ways, either by going through a checkout or by the user who can empty it out.

== A tire in the tire manufacturing plant. ==

I’m a tire. I know my manufacturer. I know that if I haven’t passed the testing stage I will be recycled, and I did pass a testing stage I will be used. I know what components I’m made of and their quantity. I know the exact process of how I’m made. I know brands and models of cars I should be used with. I know the date of my manufacturing and the date I was put on a wheel of a car. I know the mileage I should be used for. I know my warranty. I also know how I should be recycled.

From this example certain methods can be clearly seen: manufacture, recycle, a method to return if the testing was passed, return the date of manufacturing, and the date was placed on a wheel, return models and brands of cars that this tire is compatible.
It also can be seen that a tire will contain other objects inside of it, such as components it is made of.

== A peanut butter jelly sandwich in the kitchen. [2] ==

I’m a peanut butter jelly sandwich. I’m always made with two slices of the same type of bread. I know that a thin bread slice cannot support chunky peanut butter (assumption) and a thin bread slice cannot support a heavy application of ingredient. I know that one bread slice must contain peanut butter and the other must contain jelly.

This example is a bit harder than previous two. But we can see from here that in this example that sandwich consists of other objects, such as peanut butter, jelly, and bread. The sandwich “knows” how it must make itself, since it know that certain types of bread won’t support certain type of ingredient.

Promotes a new way of thinking. Way of thinking before you develop. Object are a little more intelligent. Think like an object – anthropomorphism. Objects are composable.
How To use “Object Think”
Must plan
Everything is an object. Literraly replicate everything in the business
Paper Prototyping
Semantic Net Diagram
Use a language common to the domain being described.

[1] Streamlined Object Modeling, Jill Nicola, Mark Mayfield, Mike Abney
[2] http://www.informit.com/articles/article.aspx?p=25184&seqNum=3

CSC/ECE 517 Fall 2009/wiki3 10 ot

2009-11-10T12:25:15Z

Cybo:

Introduction

This article discusses “Object Think” brainstorming methodology. It is intended for experienced programmers who write their code in Object oriented style. This article should be viewed as a guideline and not as a set of rules that must be enforced. In this article the word “entity” means a real-life entity means a real-life entity, i.e. chair, apple, bird, shopping cart etc. The word “object” means a model that is used to describe a real-life entity.

Here is what [1] says about object think and object oriented development:

Poor object thinkers put data and functions into objects haphazardly. At best, they use a set of guidelines they find difficult to explain. This makes their models and code difficult to understand and brittle to changes in requirements and system growth. When requirements change, a brittle object model must significantly alter its structure by redefining objects. Object models built through functional analysis are filled with objects representing functions which makes them notoriously brittle as changes in functional requirements render objects obsolete, and reorder collaborations among them.

Good object thinkers apply consistent principles for distributing data and functions; they can explain and justify the results in their object models by relating them back to the objects in the business domain. Object models built with object think remain stable as the requirements and the system evolve because the model mirrors real-world objects and their relationships. New requirements mean more of the domain is being modeled or more responsibilities are being given to the objects that are already modeled. These changes are neatly encapsulated in a stable object model by adding new objects and expanding objects’ responsibilities. Objects do not change their meaning or lose collaborators, so the underlying structure of the model remains intact even as layers are snapped on top of it.

What is “Object Think”?
“Object Think” is a brainstorming methodology for architecting software. This methodology encourages a developer to think just like real-life entities. An object will abstract the entity’s responsibilities, collaborations, and even it’s “persona”. In other words the developer is encouraged to “think” like an entity, “behave” like an entity and even “talk” like an entity. It is a good idea to adopt a first-person voice during development of a model of an entity by an object. I.e. I’m an object. What do I know about myself? What do I know about the world around me? What can I do with myself? What can I with others? What is my function? e.t.c.

Here are a set of principles that were outlined by [1] when developing with object think:
1. Personify Objects. Object model a domain by imagining its entities as active, knowing objects, capable of performing complex actions.
2. Give Object Responsibilities. Turn information about a real-world entity and the actions performed on it into responsibilities of the object representing the entity.
3. Object’s responsibilities. An object’s responsibilities are: whom I know – my collaborations with others; what I do – my services; and what I know – my properties
4. Talk Like an Object. To scope an object’s responsibilities, imagine yourself as the object, and adopt the first-person voice when discussing it.

Let’s consider an example which will help us better understand what object think is and how it works

Examples:
A shopping cart in the e-commerce application.

I’m a shopping cart. I know how many products are in me. I know the total price of the products in me. I can empty myself by throwing everything away from me or by going through a checkout. I know that I’m used by a user.

From this we can see that this object most likely will contain a set of product objects, total_price property, an empty method which can be used in two ways, either by going through a checkout or by the user who can empty it out.

A tire in the tire manufacturing plant.

I’m a tire. I know my manufacturer. I know that if I haven’t passed the testing stage I will be recycled, and I did pass a testing stage I will be used. I know what components I’m made of and their quantity. I know the exact process of how I’m made. I know brands and models of cars I should be used with. I know the date of my manufacturing and the date I was put on a wheel of a car. I know the mileage I should be used for. I know my warranty. I also know how I should be recycled.

From this example certain methods can be clearly seen: manufacture, recycle, a method to return if the testing was passed, return the date of manufacturing, and the date was placed on a wheel, return models and brands of cars that this tire is compatible.
It also can be seen that a tire will contain other objects inside of it, such as components it is made of.

A peanut butter jelly sandwich in the kitchen. [2]

I’m a peanut butter jelly sandwich. I’m always made with two slices of the same type of bread. I know that a thin bread slice cannot support chunky peanut butter (assumption) and a thin bread slice cannot support a heavy application of ingredient. I know that one bread slice must contain peanut butter and the other must contain jelly.

This example is a bit harder than previous two. But we can see from here that in this example that sandwich consists of other objects, such as peanut butter, jelly, and bread. The sandwich “knows” how it must make itself, since it know that certain types of bread won’t support certain type of ingredient.

Promotes a new way of thinking. Way of thinking before you develop. Object are a little more intelligent. Think like an object – anthropomorphism. Objects are composable.
How To use “Object Think”
Must plan
Everything is an object. Literraly replicate everything in the business
Paper Prototyping
Semantic Net Diagram
Use a language common to the domain being described.

[1] Streamlined Object Modeling, Jill Nicola, Mark Mayfield, Mike Abney
[2] http://www.informit.com/articles/article.aspx?p=25184&seqNum=3

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-15T01:56:45Z

Cybo: /* Links */

= Introduction =
Patterns are often classified into creational, structural, and behavioral categories. However, this leaves a large number of patterns in each group, with no easy way of remembering all of them. What classifications and strategies have been developed to help programmers remember patterns, so that they can apply them at opportune moments?

This article is intended for experienced programmers who are well in versatile patterns. It is not intended to familiarize the reader with the concept of a design pattern. If interested in learning what design patterns are please refer to [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]. The intent of the article is not to describe existing patterns and their usage but rather introduce a other ways of categorizing and cataloging of patterns.

This article relies heavily on the [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation by Imed Hammouda and Jakub Rudzki]. We would like to thank them for their contribution to the field of design patterns and helping us to better understand pattern classification.

= Definition =

A pattern is a solution to a problem in its context. A context is specific to the domain in which the problem is being solved. For example, in computer science software engineers often are surrounded by problems in similar contexts such as web and database infrastructure. Within these contexts there are repeatable solutions. Those solutions when described abstractly are are what we call patterns. A pattern in itself is not a finished solution to a problem but rather a template on how to solve a given problem which can arise in a variety of different situations (contexts)[1]

The goal of patterns is to recognize and make use of a library of knowledge that can be used to solve problems. Often times, the same problems are 're-solved' without learning from the past experiences. As long as we have similar contexts we will have patterns or knowledge that develop from those solved problems.

== Example ==
The company you work for decides to switch a different database vendor which in turn requires you to change the interface for a set of objects in the software you designed.
It turns out that the change of interface is a common problem not just for the databases but in general in software development. In this case you would use a Adapter pattern in the context of database development.

= Problem =

The problem with patterns is classification and recognition or usage, i.e. what type of patterns to use for each given case. For example, a pattern that is not classified correctly will not be remembered and used. Several attempts to classify patterns has been made. The existing software classification of patterns uses the categories of:

* Structural
* Behavioral
* Creational

While these are good starting points for patterns, it is very hard to make use of this information in different contexts.

= Existing Work =

[http://c2.com/cgi/wiki?GangOfFour The Gang of Four] patterns are the most famous. They are classified according to creational, structural and behavioral groups. There is also a J2EE catalog of patterns by SUN. These are all classified as J2EE patterns but they can be split into presentation, business, and integration tier patterns.

There is a good [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation] regarding pattern classification by Imed Hammouda and Jakub Rudzki. In the presentation they suggest that patterns can be classifed by:

* Domain
* Paradigm
* Granularity
* Purpose
* Scope
* Discipline

== Domain ==

Domain specific classification may help make patterns more useful in various contexts. This is because the solution to the problem will be more specific to the context. Below are some examples of domain specific classification.

'''[http://en.wikipedia.org/wiki/Factory_method_pattern Factory method]''' - Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.[1]
'''[http://en.wikipedia.org/wiki/Object_pool Object pool]''' - Avoid expensive acquisition and release of resources by recycling objects that are no longer in use.[1]

'''[http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]''' - Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.[1]

'''[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]''' - Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.[1]

== Paradigm ==
Paradigm classification is a categorization of a pattern according a programming paradigm. In [http://en.wikipedia.org/wiki/Object-oriented_programming OOP] patterns take forms of classes, objects and inheritance while in [http://en.wikipedia.org/wiki/Imperative_programming imperative programming] patterns take form of procedures and functions.

Below are examples of patterns for functional logic languages taken from [2] and [3]

'''Opaque Type''' - Ensure that values of a datatype are hidden.

'''Locally Defined Global Identifier''' - Ensure that a local name is globally unique.

'''Incremental Solution''' - Compute solutions in an incremental manner.

'''Concurrent Distinct Choices''' - Ensure that a mapping from indexes to values is injective.

'''Constrained Constructor''' - Prevent invoking a constructor that might create invalid data.

== Granularity ==
This kind of categorization refers to the system level where the patterns are used at. For this category it is sometimes hard to draw a border between levels and the pattern might be used at different granularity categories. Below are the examples of pattern classification based on granularity classification. These examples were taken from [2] and [4]

'''Architectural patterns''' - refer to a software system at high level. Examples of these patterns would be [http://en.wikipedia.org/wiki/Layer_%28object-oriented_design%29 Layer], [http://en.wikipedia.org/wiki/Model-View-Controller Model-View-Controller] and [http://en.wikipedia.org/wiki/Multitier_architecture Multitier architecture]

'''Design patterns''' - focus on subsystems and components. Examples of these patters would be [http://en.wikipedia.org/wiki/Factory_method_pattern Factory method], [http://en.wikipedia.org/wiki/Object_pool Object pool] and [http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]

'''Idioms''' - address the lowest level of a software system. A good example of these would be [http://c2.com/cgi/wiki?JavaIdioms Java Idioms]

== Purpose ==
Purpose represents a specific type of a problem a pattern is trying to solve. It is the most useful criterion since it describes the exact situation where the pattern is used.

Below are examples which were taken from [2] and [5]

'''Architectural support patterns''' - represent the strategic decisions for the organization of real-time applications.

'''Collaboration and distribution''' - patterns provide solutions to common application domain problems in real-time systems.

'''Safety and reliability patterns''' - deal with common problems of safety and reliability.

'''Behavioral patterns''' - provide different implementation solutions involving multiple objects.

== Scope ==
Scope classification is categorization of patterns according to features implemented in a given pattern. As an example in [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented design] patterns can be classified using either class inheritance or object composition

== Discipline ==
It is perhaps the easiest and most natural way to classify patterns, i.e. categorize them according to a field or discipline where they are used, i.e. music, engineering, or economy. It is unlikely (but not impossible) that a pattern used in one discipline becomes relevant to another.

= Article Definitions =
'''Gang of Four''' - also known as GoF. The authors of the Design Patterns book.

'''''M''odel-''V''iew-''C''ontroller''' - MVC for short, Architectural design pattern.

= Related Links =

* [http://www.cs.helsinki.fi/u/salaakso/patterns/index.html User Interface]
* [http://vis.berkeley.edu/papers/infovis_design_patterns/ Information Visualization]
* [http://simson.net/thesis/ Computer Security]
* [http://developer.yahoo.com/ypatterns/ Web Applications]
* [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification]
* [http://pattron.net/default.aspx A pattern catalog]
* [http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm Classification of Object Oriented Design Patterns]
* [http://www.patternforge.net/wiki/images/0/0c/Kudelka.pdf New Pattern Classification Approach]
* [http://java.sun.com/blueprints/patterns/catalog.html J2EE Patterns]

= References =
[1] [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]

[2] [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification] by Imed Hammouda & Jakub Rudzki

[3] S. Antoy and M. Hanus. “Functional Logic Design Patterns”. In Proc. Of the 6thInternational Symposium on Functional and Logic Programming (FLOPS 2002), Aizu (Japan), Springer LNCS 2441, pp. 67-87, 2002.

[4] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerland and M. Stal. ”Pattern-Oriented Software Architecture: A System of Patterns”. Wiley , (1996).

[5] B. P. Douglass. “Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns”, Addison-Wesley, 19.

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-15T01:55:58Z

Cybo: /* Discipline */

= Introduction =
Patterns are often classified into creational, structural, and behavioral categories. However, this leaves a large number of patterns in each group, with no easy way of remembering all of them. What classifications and strategies have been developed to help programmers remember patterns, so that they can apply them at opportune moments?

This article is intended for experienced programmers who are well in versatile patterns. It is not intended to familiarize the reader with the concept of a design pattern. If interested in learning what design patterns are please refer to [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]. The intent of the article is not to describe existing patterns and their usage but rather introduce a other ways of categorizing and cataloging of patterns.

This article relies heavily on the [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation by Imed Hammouda and Jakub Rudzki]. We would like to thank them for their contribution to the field of design patterns and helping us to better understand pattern classification.

= Definition =

A pattern is a solution to a problem in its context. A context is specific to the domain in which the problem is being solved. For example, in computer science software engineers often are surrounded by problems in similar contexts such as web and database infrastructure. Within these contexts there are repeatable solutions. Those solutions when described abstractly are are what we call patterns. A pattern in itself is not a finished solution to a problem but rather a template on how to solve a given problem which can arise in a variety of different situations (contexts)[1]

The goal of patterns is to recognize and make use of a library of knowledge that can be used to solve problems. Often times, the same problems are 're-solved' without learning from the past experiences. As long as we have similar contexts we will have patterns or knowledge that develop from those solved problems.

== Example ==
The company you work for decides to switch a different database vendor which in turn requires you to change the interface for a set of objects in the software you designed.
It turns out that the change of interface is a common problem not just for the databases but in general in software development. In this case you would use a Adapter pattern in the context of database development.

= Problem =

The problem with patterns is classification and recognition or usage, i.e. what type of patterns to use for each given case. For example, a pattern that is not classified correctly will not be remembered and used. Several attempts to classify patterns has been made. The existing software classification of patterns uses the categories of:

* Structural
* Behavioral
* Creational

While these are good starting points for patterns, it is very hard to make use of this information in different contexts.

= Existing Work =

[http://c2.com/cgi/wiki?GangOfFour The Gang of Four] patterns are the most famous. They are classified according to creational, structural and behavioral groups. There is also a J2EE catalog of patterns by SUN. These are all classified as J2EE patterns but they can be split into presentation, business, and integration tier patterns.

There is a good [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation] regarding pattern classification by Imed Hammouda and Jakub Rudzki. In the presentation they suggest that patterns can be classifed by:

* Domain
* Paradigm
* Granularity
* Purpose
* Scope
* Discipline

== Domain ==

Domain specific classification may help make patterns more useful in various contexts. This is because the solution to the problem will be more specific to the context. Below are some examples of domain specific classification.

'''[http://en.wikipedia.org/wiki/Factory_method_pattern Factory method]''' - Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.[1]
'''[http://en.wikipedia.org/wiki/Object_pool Object pool]''' - Avoid expensive acquisition and release of resources by recycling objects that are no longer in use.[1]

'''[http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]''' - Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.[1]

'''[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]''' - Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.[1]

== Paradigm ==
Paradigm classification is a categorization of a pattern according a programming paradigm. In [http://en.wikipedia.org/wiki/Object-oriented_programming OOP] patterns take forms of classes, objects and inheritance while in [http://en.wikipedia.org/wiki/Imperative_programming imperative programming] patterns take form of procedures and functions.

Below are examples of patterns for functional logic languages taken from [2] and [3]

'''Opaque Type''' - Ensure that values of a datatype are hidden.

'''Locally Defined Global Identifier''' - Ensure that a local name is globally unique.

'''Incremental Solution''' - Compute solutions in an incremental manner.

'''Concurrent Distinct Choices''' - Ensure that a mapping from indexes to values is injective.

'''Constrained Constructor''' - Prevent invoking a constructor that might create invalid data.

== Granularity ==
This kind of categorization refers to the system level where the patterns are used at. For this category it is sometimes hard to draw a border between levels and the pattern might be used at different granularity categories. Below are the examples of pattern classification based on granularity classification. These examples were taken from [2] and [4]

'''Architectural patterns''' - refer to a software system at high level. Examples of these patterns would be [http://en.wikipedia.org/wiki/Layer_%28object-oriented_design%29 Layer], [http://en.wikipedia.org/wiki/Model-View-Controller Model-View-Controller] and [http://en.wikipedia.org/wiki/Multitier_architecture Multitier architecture]

'''Design patterns''' - focus on subsystems and components. Examples of these patters would be [http://en.wikipedia.org/wiki/Factory_method_pattern Factory method], [http://en.wikipedia.org/wiki/Object_pool Object pool] and [http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]

'''Idioms''' - address the lowest level of a software system. A good example of these would be [http://c2.com/cgi/wiki?JavaIdioms Java Idioms]

== Purpose ==
Purpose represents a specific type of a problem a pattern is trying to solve. It is the most useful criterion since it describes the exact situation where the pattern is used.

Below are examples which were taken from [2] and [5]

'''Architectural support patterns''' - represent the strategic decisions for the organization of real-time applications.

'''Collaboration and distribution''' - patterns provide solutions to common application domain problems in real-time systems.

'''Safety and reliability patterns''' - deal with common problems of safety and reliability.

'''Behavioral patterns''' - provide different implementation solutions involving multiple objects.

== Scope ==
Scope classification is categorization of patterns according to features implemented in a given pattern. As an example in [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented design] patterns can be classified using either class inheritance or object composition

== Discipline ==
It is perhaps the easiest and most natural way to classify patterns, i.e. categorize them according to a field or discipline where they are used, i.e. music, engineering, or economy. It is unlikely (but not impossible) that a pattern used in one discipline becomes relevant to another.

= Article Definitions =
'''Gang of Four''' - also known as GoF. The authors of the Design Patterns book.

'''''M''odel-''V''iew-''C''ontroller''' - MVC for short, Architectural design pattern.

= Links =

* [http://www.cs.helsinki.fi/u/salaakso/patterns/index.html User Interface]
* [http://vis.berkeley.edu/papers/infovis_design_patterns/ Information Visualization]
* [http://simson.net/thesis/ Computer Security]
* [http://developer.yahoo.com/ypatterns/ Web Applications]
* [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification]
* [http://pattron.net/default.aspx A pattern catalog]
* [http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm Classification of Object Oriented Design Patterns]
* [http://www.patternforge.net/wiki/images/0/0c/Kudelka.pdf New Pattern Classification Approach]
* [http://java.sun.com/blueprints/patterns/catalog.html J2EE Patterns]

= References =
[1] [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]

[2] [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification] by Imed Hammouda & Jakub Rudzki

[3] S. Antoy and M. Hanus. “Functional Logic Design Patterns”. In Proc. Of the 6thInternational Symposium on Functional and Logic Programming (FLOPS 2002), Aizu (Japan), Springer LNCS 2441, pp. 67-87, 2002.

[4] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerland and M. Stal. ”Pattern-Oriented Software Architecture: A System of Patterns”. Wiley , (1996).

[5] B. P. Douglass. “Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns”, Addison-Wesley, 19.

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-15T01:52:54Z

Cybo: /* Problem */

= Introduction =
Patterns are often classified into creational, structural, and behavioral categories. However, this leaves a large number of patterns in each group, with no easy way of remembering all of them. What classifications and strategies have been developed to help programmers remember patterns, so that they can apply them at opportune moments?

This article is intended for experienced programmers who are well in versatile patterns. It is not intended to familiarize the reader with the concept of a design pattern. If interested in learning what design patterns are please refer to [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]. The intent of the article is not to describe existing patterns and their usage but rather introduce a other ways of categorizing and cataloging of patterns.

This article relies heavily on the [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation by Imed Hammouda and Jakub Rudzki]. We would like to thank them for their contribution to the field of design patterns and helping us to better understand pattern classification.

= Definition =

A pattern is a solution to a problem in its context. A context is specific to the domain in which the problem is being solved. For example, in computer science software engineers often are surrounded by problems in similar contexts such as web and database infrastructure. Within these contexts there are repeatable solutions. Those solutions when described abstractly are are what we call patterns. A pattern in itself is not a finished solution to a problem but rather a template on how to solve a given problem which can arise in a variety of different situations (contexts)[1]

The goal of patterns is to recognize and make use of a library of knowledge that can be used to solve problems. Often times, the same problems are 're-solved' without learning from the past experiences. As long as we have similar contexts we will have patterns or knowledge that develop from those solved problems.

== Example ==
The company you work for decides to switch a different database vendor which in turn requires you to change the interface for a set of objects in the software you designed.
It turns out that the change of interface is a common problem not just for the databases but in general in software development. In this case you would use a Adapter pattern in the context of database development.

= Problem =

The problem with patterns is classification and recognition or usage, i.e. what type of patterns to use for each given case. For example, a pattern that is not classified correctly will not be remembered and used. Several attempts to classify patterns has been made. The existing software classification of patterns uses the categories of:

* Structural
* Behavioral
* Creational

While these are good starting points for patterns, it is very hard to make use of this information in different contexts.

= Existing Work =

[http://c2.com/cgi/wiki?GangOfFour The Gang of Four] patterns are the most famous. They are classified according to creational, structural and behavioral groups. There is also a J2EE catalog of patterns by SUN. These are all classified as J2EE patterns but they can be split into presentation, business, and integration tier patterns.

There is a good [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation] regarding pattern classification by Imed Hammouda and Jakub Rudzki. In the presentation they suggest that patterns can be classifed by:

* Domain
* Paradigm
* Granularity
* Purpose
* Scope
* Discipline

== Domain ==

Domain specific classification may help make patterns more useful in various contexts. This is because the solution to the problem will be more specific to the context. Below are some examples of domain specific classification.

'''[http://en.wikipedia.org/wiki/Factory_method_pattern Factory method]''' - Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.[1]
'''[http://en.wikipedia.org/wiki/Object_pool Object pool]''' - Avoid expensive acquisition and release of resources by recycling objects that are no longer in use.[1]

'''[http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]''' - Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.[1]

'''[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]''' - Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.[1]

== Paradigm ==
Paradigm classification is a categorization of a pattern according a programming paradigm. In [http://en.wikipedia.org/wiki/Object-oriented_programming OOP] patterns take forms of classes, objects and inheritance while in [http://en.wikipedia.org/wiki/Imperative_programming imperative programming] patterns take form of procedures and functions.

Below are examples of patterns for functional logic languages taken from [2] and [3]

'''Opaque Type''' - Ensure that values of a datatype are hidden.

'''Locally Defined Global Identifier''' - Ensure that a local name is globally unique.

'''Incremental Solution''' - Compute solutions in an incremental manner.

'''Concurrent Distinct Choices''' - Ensure that a mapping from indexes to values is injective.

'''Constrained Constructor''' - Prevent invoking a constructor that might create invalid data.

== Granularity ==
This kind of categorization refers to the system level where the patterns are used at. For this category it is sometimes hard to draw a border between levels and the pattern might be used at different granularity categories. Below are the examples of pattern classification based on granularity classification. These examples were taken from [2] and [4]

'''Architectural patterns''' - refer to a software system at high level. Examples of these patterns would be [http://en.wikipedia.org/wiki/Layer_%28object-oriented_design%29 Layer], [http://en.wikipedia.org/wiki/Model-View-Controller Model-View-Controller] and [http://en.wikipedia.org/wiki/Multitier_architecture Multitier architecture]

'''Design patterns''' - focus on subsystems and components. Examples of these patters would be [http://en.wikipedia.org/wiki/Factory_method_pattern Factory method], [http://en.wikipedia.org/wiki/Object_pool Object pool] and [http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]

'''Idioms''' - address the lowest level of a software system. A good example of these would be [http://c2.com/cgi/wiki?JavaIdioms Java Idioms]

== Purpose ==
Purpose represents a specific type of a problem a pattern is trying to solve. It is the most useful criterion since it describes the exact situation where the pattern is used.

Below are examples which were taken from [2] and [5]

'''Architectural support patterns''' - represent the strategic decisions for the organization of real-time applications.

'''Collaboration and distribution''' - patterns provide solutions to common application domain problems in real-time systems.

'''Safety and reliability patterns''' - deal with common problems of safety and reliability.

'''Behavioral patterns''' - provide different implementation solutions involving multiple objects.

== Scope ==
Scope classification is categorization of patterns according to features implemented in a given pattern. As an example in [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented design] patterns can be classified using either class inheritance or object composition

== Discipline ==

= Article Definitions =
'''Gang of Four''' - also known as GoF. The authors of the Design Patterns book.

'''''M''odel-''V''iew-''C''ontroller''' - MVC for short, Architectural design pattern.

= Links =

* [http://www.cs.helsinki.fi/u/salaakso/patterns/index.html User Interface]
* [http://vis.berkeley.edu/papers/infovis_design_patterns/ Information Visualization]
* [http://simson.net/thesis/ Computer Security]
* [http://developer.yahoo.com/ypatterns/ Web Applications]
* [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification]
* [http://pattron.net/default.aspx A pattern catalog]
* [http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm Classification of Object Oriented Design Patterns]
* [http://www.patternforge.net/wiki/images/0/0c/Kudelka.pdf New Pattern Classification Approach]
* [http://java.sun.com/blueprints/patterns/catalog.html J2EE Patterns]

= References =
[1] [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]

[2] [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification] by Imed Hammouda & Jakub Rudzki

[3] S. Antoy and M. Hanus. “Functional Logic Design Patterns”. In Proc. Of the 6thInternational Symposium on Functional and Logic Programming (FLOPS 2002), Aizu (Japan), Springer LNCS 2441, pp. 67-87, 2002.

[4] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerland and M. Stal. ”Pattern-Oriented Software Architecture: A System of Patterns”. Wiley , (1996).

[5] B. P. Douglass. “Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns”, Addison-Wesley, 19.

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-15T01:51:33Z

Cybo: /* Scope */

= Introduction =
Patterns are often classified into creational, structural, and behavioral categories. However, this leaves a large number of patterns in each group, with no easy way of remembering all of them. What classifications and strategies have been developed to help programmers remember patterns, so that they can apply them at opportune moments?

This article is intended for experienced programmers who are well in versatile patterns. It is not intended to familiarize the reader with the concept of a design pattern. If interested in learning what design patterns are please refer to [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]. The intent of the article is not to describe existing patterns and their usage but rather introduce a other ways of categorizing and cataloging of patterns.

This article relies heavily on the [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation by Imed Hammouda and Jakub Rudzki]. We would like to thank them for their contribution to the field of design patterns and helping us to better understand pattern classification.

= Definition =

A pattern is a solution to a problem in its context. A context is specific to the domain in which the problem is being solved. For example, in computer science software engineers often are surrounded by problems in similar contexts such as web and database infrastructure. Within these contexts there are repeatable solutions. Those solutions when described abstractly are are what we call patterns. A pattern in itself is not a finished solution to a problem but rather a template on how to solve a given problem which can arise in a variety of different situations (contexts)[1]

The goal of patterns is to recognize and make use of a library of knowledge that can be used to solve problems. Often times, the same problems are 're-solved' without learning from the past experiences. As long as we have similar contexts we will have patterns or knowledge that develop from those solved problems.

== Example ==
The company you work for decides to switch a different database vendor which in turn requires you to change the interface for a set of objects in the software you designed.
It turns out that the change of interface is a common problem not just for the databases but in general in software development. In this case you would use a Adapter pattern in the context of database development.

= Problem =

The problem with patterns is classification and recognition or usage, i.e. what type of patterns to use for each given case. For example, a pattern that is not classified correctly will not be remembered and used. Several attempts to classify patterns has been made. The existing software classification of patterns uses the categories of:

# Structural
# Behavioral
# Creational

While these are good starting points for patterns, it is very hard to make use of this information in different contexts.

= Existing Work =

[http://c2.com/cgi/wiki?GangOfFour The Gang of Four] patterns are the most famous. They are classified according to creational, structural and behavioral groups. There is also a J2EE catalog of patterns by SUN. These are all classified as J2EE patterns but they can be split into presentation, business, and integration tier patterns.

There is a good [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation] regarding pattern classification by Imed Hammouda and Jakub Rudzki. In the presentation they suggest that patterns can be classifed by:

* Domain
* Paradigm
* Granularity
* Purpose
* Scope
* Discipline

== Domain ==

Domain specific classification may help make patterns more useful in various contexts. This is because the solution to the problem will be more specific to the context. Below are some examples of domain specific classification.

'''[http://en.wikipedia.org/wiki/Factory_method_pattern Factory method]''' - Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.[1]
'''[http://en.wikipedia.org/wiki/Object_pool Object pool]''' - Avoid expensive acquisition and release of resources by recycling objects that are no longer in use.[1]

'''[http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]''' - Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.[1]

'''[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]''' - Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.[1]

== Paradigm ==
Paradigm classification is a categorization of a pattern according a programming paradigm. In [http://en.wikipedia.org/wiki/Object-oriented_programming OOP] patterns take forms of classes, objects and inheritance while in [http://en.wikipedia.org/wiki/Imperative_programming imperative programming] patterns take form of procedures and functions.

Below are examples of patterns for functional logic languages taken from [2] and [3]

'''Opaque Type''' - Ensure that values of a datatype are hidden.

'''Locally Defined Global Identifier''' - Ensure that a local name is globally unique.

'''Incremental Solution''' - Compute solutions in an incremental manner.

'''Concurrent Distinct Choices''' - Ensure that a mapping from indexes to values is injective.

'''Constrained Constructor''' - Prevent invoking a constructor that might create invalid data.

== Granularity ==
This kind of categorization refers to the system level where the patterns are used at. For this category it is sometimes hard to draw a border between levels and the pattern might be used at different granularity categories. Below are the examples of pattern classification based on granularity classification. These examples were taken from [2] and [4]

'''Architectural patterns''' - refer to a software system at high level. Examples of these patterns would be [http://en.wikipedia.org/wiki/Layer_%28object-oriented_design%29 Layer], [http://en.wikipedia.org/wiki/Model-View-Controller Model-View-Controller] and [http://en.wikipedia.org/wiki/Multitier_architecture Multitier architecture]

'''Design patterns''' - focus on subsystems and components. Examples of these patters would be [http://en.wikipedia.org/wiki/Factory_method_pattern Factory method], [http://en.wikipedia.org/wiki/Object_pool Object pool] and [http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]

'''Idioms''' - address the lowest level of a software system. A good example of these would be [http://c2.com/cgi/wiki?JavaIdioms Java Idioms]

== Purpose ==
Purpose represents a specific type of a problem a pattern is trying to solve. It is the most useful criterion since it describes the exact situation where the pattern is used.

Below are examples which were taken from [2] and [5]

'''Architectural support patterns''' - represent the strategic decisions for the organization of real-time applications.

'''Collaboration and distribution''' - patterns provide solutions to common application domain problems in real-time systems.

'''Safety and reliability patterns''' - deal with common problems of safety and reliability.

'''Behavioral patterns''' - provide different implementation solutions involving multiple objects.

== Scope ==
Scope classification is categorization of patterns according to features implemented in a given pattern. As an example in [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented design] patterns can be classified using either class inheritance or object composition

== Discipline ==

= Article Definitions =
'''Gang of Four''' - also known as GoF. The authors of the Design Patterns book.

'''''M''odel-''V''iew-''C''ontroller''' - MVC for short, Architectural design pattern.

= Links =

* [http://www.cs.helsinki.fi/u/salaakso/patterns/index.html User Interface]
* [http://vis.berkeley.edu/papers/infovis_design_patterns/ Information Visualization]
* [http://simson.net/thesis/ Computer Security]
* [http://developer.yahoo.com/ypatterns/ Web Applications]
* [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification]
* [http://pattron.net/default.aspx A pattern catalog]
* [http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm Classification of Object Oriented Design Patterns]
* [http://www.patternforge.net/wiki/images/0/0c/Kudelka.pdf New Pattern Classification Approach]
* [http://java.sun.com/blueprints/patterns/catalog.html J2EE Patterns]

= References =
[1] [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]

[2] [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification] by Imed Hammouda & Jakub Rudzki

[3] S. Antoy and M. Hanus. “Functional Logic Design Patterns”. In Proc. Of the 6thInternational Symposium on Functional and Logic Programming (FLOPS 2002), Aizu (Japan), Springer LNCS 2441, pp. 67-87, 2002.

[4] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerland and M. Stal. ”Pattern-Oriented Software Architecture: A System of Patterns”. Wiley , (1996).

[5] B. P. Douglass. “Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns”, Addison-Wesley, 19.

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-15T01:46:02Z

Cybo: /* Purpose */

= Introduction =
Patterns are often classified into creational, structural, and behavioral categories. However, this leaves a large number of patterns in each group, with no easy way of remembering all of them. What classifications and strategies have been developed to help programmers remember patterns, so that they can apply them at opportune moments?

This article is intended for experienced programmers who are well in versatile patterns. It is not intended to familiarize the reader with the concept of a design pattern. If interested in learning what design patterns are please refer to [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]. The intent of the article is not to describe existing patterns and their usage but rather introduce a other ways of categorizing and cataloging of patterns.

This article relies heavily on the [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation by Imed Hammouda and Jakub Rudzki]. We would like to thank them for their contribution to the field of design patterns and helping us to better understand pattern classification.

= Definition =

A pattern is a solution to a problem in its context. A context is specific to the domain in which the problem is being solved. For example, in computer science software engineers often are surrounded by problems in similar contexts such as web and database infrastructure. Within these contexts there are repeatable solutions. Those solutions when described abstractly are are what we call patterns. A pattern in itself is not a finished solution to a problem but rather a template on how to solve a given problem which can arise in a variety of different situations (contexts)[1]

The goal of patterns is to recognize and make use of a library of knowledge that can be used to solve problems. Often times, the same problems are 're-solved' without learning from the past experiences. As long as we have similar contexts we will have patterns or knowledge that develop from those solved problems.

== Example ==
The company you work for decides to switch a different database vendor which in turn requires you to change the interface for a set of objects in the software you designed.
It turns out that the change of interface is a common problem not just for the databases but in general in software development. In this case you would use a Adapter pattern in the context of database development.

= Problem =

The problem with patterns is classification and recognition or usage, i.e. what type of patterns to use for each given case. For example, a pattern that is not classified correctly will not be remembered and used. Several attempts to classify patterns has been made. The existing software classification of patterns uses the categories of:

# Structural
# Behavioral
# Creational

While these are good starting points for patterns, it is very hard to make use of this information in different contexts.

= Existing Work =

[http://c2.com/cgi/wiki?GangOfFour The Gang of Four] patterns are the most famous. They are classified according to creational, structural and behavioral groups. There is also a J2EE catalog of patterns by SUN. These are all classified as J2EE patterns but they can be split into presentation, business, and integration tier patterns.

There is a good [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation] regarding pattern classification by Imed Hammouda and Jakub Rudzki. In the presentation they suggest that patterns can be classifed by:

* Domain
* Paradigm
* Granularity
* Purpose
* Scope
* Discipline

== Domain ==

Domain specific classification may help make patterns more useful in various contexts. This is because the solution to the problem will be more specific to the context. Below are some examples of domain specific classification.

'''[http://en.wikipedia.org/wiki/Factory_method_pattern Factory method]''' - Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.[1]
'''[http://en.wikipedia.org/wiki/Object_pool Object pool]''' - Avoid expensive acquisition and release of resources by recycling objects that are no longer in use.[1]

'''[http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]''' - Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.[1]

'''[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]''' - Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.[1]

== Paradigm ==
Paradigm classification is a categorization of a pattern according a programming paradigm. In [http://en.wikipedia.org/wiki/Object-oriented_programming OOP] patterns take forms of classes, objects and inheritance while in [http://en.wikipedia.org/wiki/Imperative_programming imperative programming] patterns take form of procedures and functions.

Below are examples of patterns for functional logic languages taken from [2] and [3]

'''Opaque Type''' - Ensure that values of a datatype are hidden.

'''Locally Defined Global Identifier''' - Ensure that a local name is globally unique.

'''Incremental Solution''' - Compute solutions in an incremental manner.

'''Concurrent Distinct Choices''' - Ensure that a mapping from indexes to values is injective.

'''Constrained Constructor''' - Prevent invoking a constructor that might create invalid data.

== Granularity ==
This kind of categorization refers to the system level where the patterns are used at. For this category it is sometimes hard to draw a border between levels and the pattern might be used at different granularity categories. Below are the examples of pattern classification based on granularity classification. These examples were taken from [2] and [4]

'''Architectural patterns''' - refer to a software system at high level. Examples of these patterns would be [http://en.wikipedia.org/wiki/Layer_%28object-oriented_design%29 Layer], [http://en.wikipedia.org/wiki/Model-View-Controller Model-View-Controller] and [http://en.wikipedia.org/wiki/Multitier_architecture Multitier architecture]

'''Design patterns''' - focus on subsystems and components. Examples of these patters would be [http://en.wikipedia.org/wiki/Factory_method_pattern Factory method], [http://en.wikipedia.org/wiki/Object_pool Object pool] and [http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]

'''Idioms''' - address the lowest level of a software system. A good example of these would be [http://c2.com/cgi/wiki?JavaIdioms Java Idioms]

== Purpose ==
Purpose represents a specific type of a problem a pattern is trying to solve. It is the most useful criterion since it describes the exact situation where the pattern is used.

Below are examples which were taken from [2] and [5]

'''Architectural support patterns''' - represent the strategic decisions for the organization of real-time applications.

'''Collaboration and distribution''' - patterns provide solutions to common application domain problems in real-time systems.

'''Safety and reliability patterns''' - deal with common problems of safety and reliability.

'''Behavioral patterns''' - provide different implementation solutions involving multiple objects.

== Scope ==
== Discipline ==

= Article Definitions =
'''Gang of Four''' - also known as GoF. The authors of the Design Patterns book.

'''''M''odel-''V''iew-''C''ontroller''' - MVC for short, Architectural design pattern.

= Links =

* [http://www.cs.helsinki.fi/u/salaakso/patterns/index.html User Interface]
* [http://vis.berkeley.edu/papers/infovis_design_patterns/ Information Visualization]
* [http://simson.net/thesis/ Computer Security]
* [http://developer.yahoo.com/ypatterns/ Web Applications]
* [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification]
* [http://pattron.net/default.aspx A pattern catalog]
* [http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm Classification of Object Oriented Design Patterns]
* [http://www.patternforge.net/wiki/images/0/0c/Kudelka.pdf New Pattern Classification Approach]
* [http://java.sun.com/blueprints/patterns/catalog.html J2EE Patterns]

= References =
[1] [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]

[2] [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification] by Imed Hammouda & Jakub Rudzki

[3] S. Antoy and M. Hanus. “Functional Logic Design Patterns”. In Proc. Of the 6thInternational Symposium on Functional and Logic Programming (FLOPS 2002), Aizu (Japan), Springer LNCS 2441, pp. 67-87, 2002.

[4] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerland and M. Stal. ”Pattern-Oriented Software Architecture: A System of Patterns”. Wiley , (1996).

[5] B. P. Douglass. “Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns”, Addison-Wesley, 19.

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-15T01:44:57Z

Cybo: /* Purpose */

= Introduction =
Patterns are often classified into creational, structural, and behavioral categories. However, this leaves a large number of patterns in each group, with no easy way of remembering all of them. What classifications and strategies have been developed to help programmers remember patterns, so that they can apply them at opportune moments?

This article is intended for experienced programmers who are well in versatile patterns. It is not intended to familiarize the reader with the concept of a design pattern. If interested in learning what design patterns are please refer to [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]. The intent of the article is not to describe existing patterns and their usage but rather introduce a other ways of categorizing and cataloging of patterns.

This article relies heavily on the [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation by Imed Hammouda and Jakub Rudzki]. We would like to thank them for their contribution to the field of design patterns and helping us to better understand pattern classification.

= Definition =

A pattern is a solution to a problem in its context. A context is specific to the domain in which the problem is being solved. For example, in computer science software engineers often are surrounded by problems in similar contexts such as web and database infrastructure. Within these contexts there are repeatable solutions. Those solutions when described abstractly are are what we call patterns. A pattern in itself is not a finished solution to a problem but rather a template on how to solve a given problem which can arise in a variety of different situations (contexts)[1]

The goal of patterns is to recognize and make use of a library of knowledge that can be used to solve problems. Often times, the same problems are 're-solved' without learning from the past experiences. As long as we have similar contexts we will have patterns or knowledge that develop from those solved problems.

== Example ==
The company you work for decides to switch a different database vendor which in turn requires you to change the interface for a set of objects in the software you designed.
It turns out that the change of interface is a common problem not just for the databases but in general in software development. In this case you would use a Adapter pattern in the context of database development.

= Problem =

The problem with patterns is classification and recognition or usage, i.e. what type of patterns to use for each given case. For example, a pattern that is not classified correctly will not be remembered and used. Several attempts to classify patterns has been made. The existing software classification of patterns uses the categories of:

# Structural
# Behavioral
# Creational

While these are good starting points for patterns, it is very hard to make use of this information in different contexts.

= Existing Work =

[http://c2.com/cgi/wiki?GangOfFour The Gang of Four] patterns are the most famous. They are classified according to creational, structural and behavioral groups. There is also a J2EE catalog of patterns by SUN. These are all classified as J2EE patterns but they can be split into presentation, business, and integration tier patterns.

There is a good [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation] regarding pattern classification by Imed Hammouda and Jakub Rudzki. In the presentation they suggest that patterns can be classifed by:

* Domain
* Paradigm
* Granularity
* Purpose
* Scope
* Discipline

== Domain ==

Domain specific classification may help make patterns more useful in various contexts. This is because the solution to the problem will be more specific to the context. Below are some examples of domain specific classification.

'''[http://en.wikipedia.org/wiki/Factory_method_pattern Factory method]''' - Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.[1]
'''[http://en.wikipedia.org/wiki/Object_pool Object pool]''' - Avoid expensive acquisition and release of resources by recycling objects that are no longer in use.[1]

'''[http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]''' - Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.[1]

'''[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]''' - Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.[1]

== Paradigm ==
Paradigm classification is a categorization of a pattern according a programming paradigm. In [http://en.wikipedia.org/wiki/Object-oriented_programming OOP] patterns take forms of classes, objects and inheritance while in [http://en.wikipedia.org/wiki/Imperative_programming imperative programming] patterns take form of procedures and functions.

Below are examples of patterns for functional logic languages taken from [2] and [3]

'''Opaque Type''' - Ensure that values of a datatype are hidden.

'''Locally Defined Global Identifier''' - Ensure that a local name is globally unique.

'''Incremental Solution''' - Compute solutions in an incremental manner.

'''Concurrent Distinct Choices''' - Ensure that a mapping from indexes to values is injective.

'''Constrained Constructor''' - Prevent invoking a constructor that might create invalid data.

== Granularity ==
This kind of categorization refers to the system level where the patterns are used at. For this category it is sometimes hard to draw a border between levels and the pattern might be used at different granularity categories. Below are the examples of pattern classification based on granularity classification. These examples were taken from [2] and [4]

'''Architectural patterns''' - refer to a software system at high level. Examples of these patterns would be [http://en.wikipedia.org/wiki/Layer_%28object-oriented_design%29 Layer], [http://en.wikipedia.org/wiki/Model-View-Controller Model-View-Controller] and [http://en.wikipedia.org/wiki/Multitier_architecture Multitier architecture]

'''Design patterns''' - focus on subsystems and components. Examples of these patters would be [http://en.wikipedia.org/wiki/Factory_method_pattern Factory method], [http://en.wikipedia.org/wiki/Object_pool Object pool] and [http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]

'''Idioms''' - address the lowest level of a software system. A good example of these would be [http://c2.com/cgi/wiki?JavaIdioms Java Idioms]

== Purpose ==
Purpose represents a specific type of a problem a pattern is trying to solve. It is the most useful criterion since it describes the exact situation where the pattern is used.

Below are examples which were taken from [2] and [5]

'''Architectural support patterns''' - represent the strategic decisions for the organization of real-time applications.
'''Collaboration and distribution''' - patterns provide solutions to common application domain problems in real-time systems.
'''Safety and reliability patterns''' - deal with common problems of safety and reliability.
'''Behavioral patterns''' - provide different implementation solutions involving multiple objects.

== Scope ==
== Discipline ==

= Article Definitions =
'''Gang of Four''' - also known as GoF. The authors of the Design Patterns book.

'''''M''odel-''V''iew-''C''ontroller''' - MVC for short, Architectural design pattern.

= Links =

* [http://www.cs.helsinki.fi/u/salaakso/patterns/index.html User Interface]
* [http://vis.berkeley.edu/papers/infovis_design_patterns/ Information Visualization]
* [http://simson.net/thesis/ Computer Security]
* [http://developer.yahoo.com/ypatterns/ Web Applications]
* [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification]
* [http://pattron.net/default.aspx A pattern catalog]
* [http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm Classification of Object Oriented Design Patterns]
* [http://www.patternforge.net/wiki/images/0/0c/Kudelka.pdf New Pattern Classification Approach]
* [http://java.sun.com/blueprints/patterns/catalog.html J2EE Patterns]

= References =
[1] [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]

[2] [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification] by Imed Hammouda & Jakub Rudzki

[3] S. Antoy and M. Hanus. “Functional Logic Design Patterns”. In Proc. Of the 6thInternational Symposium on Functional and Logic Programming (FLOPS 2002), Aizu (Japan), Springer LNCS 2441, pp. 67-87, 2002.

[4] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerland and M. Stal. ”Pattern-Oriented Software Architecture: A System of Patterns”. Wiley , (1996).

[5] B. P. Douglass. “Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns”, Addison-Wesley, 19.

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-15T01:43:01Z

Cybo: /* References */

= Introduction =
Patterns are often classified into creational, structural, and behavioral categories. However, this leaves a large number of patterns in each group, with no easy way of remembering all of them. What classifications and strategies have been developed to help programmers remember patterns, so that they can apply them at opportune moments?

This article is intended for experienced programmers who are well in versatile patterns. It is not intended to familiarize the reader with the concept of a design pattern. If interested in learning what design patterns are please refer to [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]. The intent of the article is not to describe existing patterns and their usage but rather introduce a other ways of categorizing and cataloging of patterns.

This article relies heavily on the [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation by Imed Hammouda and Jakub Rudzki]. We would like to thank them for their contribution to the field of design patterns and helping us to better understand pattern classification.

= Definition =

A pattern is a solution to a problem in its context. A context is specific to the domain in which the problem is being solved. For example, in computer science software engineers often are surrounded by problems in similar contexts such as web and database infrastructure. Within these contexts there are repeatable solutions. Those solutions when described abstractly are are what we call patterns. A pattern in itself is not a finished solution to a problem but rather a template on how to solve a given problem which can arise in a variety of different situations (contexts)[1]

The goal of patterns is to recognize and make use of a library of knowledge that can be used to solve problems. Often times, the same problems are 're-solved' without learning from the past experiences. As long as we have similar contexts we will have patterns or knowledge that develop from those solved problems.

== Example ==
The company you work for decides to switch a different database vendor which in turn requires you to change the interface for a set of objects in the software you designed.
It turns out that the change of interface is a common problem not just for the databases but in general in software development. In this case you would use a Adapter pattern in the context of database development.

= Problem =

The problem with patterns is classification and recognition or usage, i.e. what type of patterns to use for each given case. For example, a pattern that is not classified correctly will not be remembered and used. Several attempts to classify patterns has been made. The existing software classification of patterns uses the categories of:

# Structural
# Behavioral
# Creational

While these are good starting points for patterns, it is very hard to make use of this information in different contexts.

= Existing Work =

[http://c2.com/cgi/wiki?GangOfFour The Gang of Four] patterns are the most famous. They are classified according to creational, structural and behavioral groups. There is also a J2EE catalog of patterns by SUN. These are all classified as J2EE patterns but they can be split into presentation, business, and integration tier patterns.

There is a good [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation] regarding pattern classification by Imed Hammouda and Jakub Rudzki. In the presentation they suggest that patterns can be classifed by:

* Domain
* Paradigm
* Granularity
* Purpose
* Scope
* Discipline

== Domain ==

Domain specific classification may help make patterns more useful in various contexts. This is because the solution to the problem will be more specific to the context. Below are some examples of domain specific classification.

'''[http://en.wikipedia.org/wiki/Factory_method_pattern Factory method]''' - Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.[1]
'''[http://en.wikipedia.org/wiki/Object_pool Object pool]''' - Avoid expensive acquisition and release of resources by recycling objects that are no longer in use.[1]

'''[http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]''' - Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.[1]

'''[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]''' - Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.[1]

== Paradigm ==
Paradigm classification is a categorization of a pattern according a programming paradigm. In [http://en.wikipedia.org/wiki/Object-oriented_programming OOP] patterns take forms of classes, objects and inheritance while in [http://en.wikipedia.org/wiki/Imperative_programming imperative programming] patterns take form of procedures and functions.

Below are examples of patterns for functional logic languages taken from [2] and [3]

'''Opaque Type''' - Ensure that values of a datatype are hidden.

'''Locally Defined Global Identifier''' - Ensure that a local name is globally unique.

'''Incremental Solution''' - Compute solutions in an incremental manner.

'''Concurrent Distinct Choices''' - Ensure that a mapping from indexes to values is injective.

'''Constrained Constructor''' - Prevent invoking a constructor that might create invalid data.

== Granularity ==
This kind of categorization refers to the system level where the patterns are used at. For this category it is sometimes hard to draw a border between levels and the pattern might be used at different granularity categories. Below are the examples of pattern classification based on granularity classification. These examples were taken from [2] and [4]

'''Architectural patterns''' - refer to a software system at high level. Examples of these patterns would be [http://en.wikipedia.org/wiki/Layer_%28object-oriented_design%29 Layer], [http://en.wikipedia.org/wiki/Model-View-Controller Model-View-Controller] and [http://en.wikipedia.org/wiki/Multitier_architecture Multitier architecture]

'''Design patterns''' - focus on subsystems and components. Examples of these patters would be [http://en.wikipedia.org/wiki/Factory_method_pattern Factory method], [http://en.wikipedia.org/wiki/Object_pool Object pool] and [http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]

'''Idioms''' - address the lowest level of a software system. A good example of these would be [http://c2.com/cgi/wiki?JavaIdioms Java Idioms]

== Purpose ==
Purpose represents a specific type of a problem a pattern is trying to solve. It is the most useful criterion since it describes the exact situation where the pattern is used.

Examples

== Scope ==
== Discipline ==

= Article Definitions =
'''Gang of Four''' - also known as GoF. The authors of the Design Patterns book.

'''''M''odel-''V''iew-''C''ontroller''' - MVC for short, Architectural design pattern.

= Links =

* [http://www.cs.helsinki.fi/u/salaakso/patterns/index.html User Interface]
* [http://vis.berkeley.edu/papers/infovis_design_patterns/ Information Visualization]
* [http://simson.net/thesis/ Computer Security]
* [http://developer.yahoo.com/ypatterns/ Web Applications]
* [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification]
* [http://pattron.net/default.aspx A pattern catalog]
* [http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm Classification of Object Oriented Design Patterns]
* [http://www.patternforge.net/wiki/images/0/0c/Kudelka.pdf New Pattern Classification Approach]
* [http://java.sun.com/blueprints/patterns/catalog.html J2EE Patterns]

= References =
[1] [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]

[2] [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification] by Imed Hammouda & Jakub Rudzki

[3] S. Antoy and M. Hanus. “Functional Logic Design Patterns”. In Proc. Of the 6thInternational Symposium on Functional and Logic Programming (FLOPS 2002), Aizu (Japan), Springer LNCS 2441, pp. 67-87, 2002.

[4] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerland and M. Stal. ”Pattern-Oriented Software Architecture: A System of Patterns”. Wiley , (1996).

[5] B. P. Douglass. “Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns”, Addison-Wesley, 19.

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-15T01:41:58Z

Cybo: /* Purpose */

= Introduction =
Patterns are often classified into creational, structural, and behavioral categories. However, this leaves a large number of patterns in each group, with no easy way of remembering all of them. What classifications and strategies have been developed to help programmers remember patterns, so that they can apply them at opportune moments?

This article is intended for experienced programmers who are well in versatile patterns. It is not intended to familiarize the reader with the concept of a design pattern. If interested in learning what design patterns are please refer to [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]. The intent of the article is not to describe existing patterns and their usage but rather introduce a other ways of categorizing and cataloging of patterns.

This article relies heavily on the [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation by Imed Hammouda and Jakub Rudzki]. We would like to thank them for their contribution to the field of design patterns and helping us to better understand pattern classification.

= Definition =

A pattern is a solution to a problem in its context. A context is specific to the domain in which the problem is being solved. For example, in computer science software engineers often are surrounded by problems in similar contexts such as web and database infrastructure. Within these contexts there are repeatable solutions. Those solutions when described abstractly are are what we call patterns. A pattern in itself is not a finished solution to a problem but rather a template on how to solve a given problem which can arise in a variety of different situations (contexts)[1]

The goal of patterns is to recognize and make use of a library of knowledge that can be used to solve problems. Often times, the same problems are 're-solved' without learning from the past experiences. As long as we have similar contexts we will have patterns or knowledge that develop from those solved problems.

== Example ==
The company you work for decides to switch a different database vendor which in turn requires you to change the interface for a set of objects in the software you designed.
It turns out that the change of interface is a common problem not just for the databases but in general in software development. In this case you would use a Adapter pattern in the context of database development.

= Problem =

The problem with patterns is classification and recognition or usage, i.e. what type of patterns to use for each given case. For example, a pattern that is not classified correctly will not be remembered and used. Several attempts to classify patterns has been made. The existing software classification of patterns uses the categories of:

# Structural
# Behavioral
# Creational

While these are good starting points for patterns, it is very hard to make use of this information in different contexts.

= Existing Work =

[http://c2.com/cgi/wiki?GangOfFour The Gang of Four] patterns are the most famous. They are classified according to creational, structural and behavioral groups. There is also a J2EE catalog of patterns by SUN. These are all classified as J2EE patterns but they can be split into presentation, business, and integration tier patterns.

There is a good [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation] regarding pattern classification by Imed Hammouda and Jakub Rudzki. In the presentation they suggest that patterns can be classifed by:

* Domain
* Paradigm
* Granularity
* Purpose
* Scope
* Discipline

== Domain ==

Domain specific classification may help make patterns more useful in various contexts. This is because the solution to the problem will be more specific to the context. Below are some examples of domain specific classification.

'''[http://en.wikipedia.org/wiki/Factory_method_pattern Factory method]''' - Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.[1]
'''[http://en.wikipedia.org/wiki/Object_pool Object pool]''' - Avoid expensive acquisition and release of resources by recycling objects that are no longer in use.[1]

'''[http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]''' - Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.[1]

'''[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]''' - Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.[1]

== Paradigm ==
Paradigm classification is a categorization of a pattern according a programming paradigm. In [http://en.wikipedia.org/wiki/Object-oriented_programming OOP] patterns take forms of classes, objects and inheritance while in [http://en.wikipedia.org/wiki/Imperative_programming imperative programming] patterns take form of procedures and functions.

Below are examples of patterns for functional logic languages taken from [2] and [3]

'''Opaque Type''' - Ensure that values of a datatype are hidden.

'''Locally Defined Global Identifier''' - Ensure that a local name is globally unique.

'''Incremental Solution''' - Compute solutions in an incremental manner.

'''Concurrent Distinct Choices''' - Ensure that a mapping from indexes to values is injective.

'''Constrained Constructor''' - Prevent invoking a constructor that might create invalid data.

== Granularity ==
This kind of categorization refers to the system level where the patterns are used at. For this category it is sometimes hard to draw a border between levels and the pattern might be used at different granularity categories. Below are the examples of pattern classification based on granularity classification. These examples were taken from [2] and [4]

'''Architectural patterns''' - refer to a software system at high level. Examples of these patterns would be [http://en.wikipedia.org/wiki/Layer_%28object-oriented_design%29 Layer], [http://en.wikipedia.org/wiki/Model-View-Controller Model-View-Controller] and [http://en.wikipedia.org/wiki/Multitier_architecture Multitier architecture]

'''Design patterns''' - focus on subsystems and components. Examples of these patters would be [http://en.wikipedia.org/wiki/Factory_method_pattern Factory method], [http://en.wikipedia.org/wiki/Object_pool Object pool] and [http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]

'''Idioms''' - address the lowest level of a software system. A good example of these would be [http://c2.com/cgi/wiki?JavaIdioms Java Idioms]

== Purpose ==
Purpose represents a specific type of a problem a pattern is trying to solve. It is the most useful criterion since it describes the exact situation where the pattern is used.

Examples

== Scope ==
== Discipline ==

= Article Definitions =
'''Gang of Four''' - also known as GoF. The authors of the Design Patterns book.

'''''M''odel-''V''iew-''C''ontroller''' - MVC for short, Architectural design pattern.

= Links =

* [http://www.cs.helsinki.fi/u/salaakso/patterns/index.html User Interface]
* [http://vis.berkeley.edu/papers/infovis_design_patterns/ Information Visualization]
* [http://simson.net/thesis/ Computer Security]
* [http://developer.yahoo.com/ypatterns/ Web Applications]
* [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification]
* [http://pattron.net/default.aspx A pattern catalog]
* [http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm Classification of Object Oriented Design Patterns]
* [http://www.patternforge.net/wiki/images/0/0c/Kudelka.pdf New Pattern Classification Approach]
* [http://java.sun.com/blueprints/patterns/catalog.html J2EE Patterns]

= References =
[1] [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]

[2] [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification] by Imed Hammouda & Jakub Rudzki

[3] S. Antoy and M. Hanus. “Functional Logic Design Patterns”. In Proc. Of the 6thInternational Symposium on Functional and Logic Programming (FLOPS 2002), Aizu (Japan), Springer LNCS 2441, pp. 67-87, 2002.

[4] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerland and M. Stal. ”Pattern-Oriented Software Architecture: A System of Patterns”. Wiley , (1996).

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-14T23:14:15Z

Cybo: /* Paradigm */

= Introduction =
Patterns are often classified into creational, structural, and behavioral categories. However, this leaves a large number of patterns in each group, with no easy way of remembering all of them. What classifications and strategies have been developed to help programmers remember patterns, so that they can apply them at opportune moments?

This article is intended for experienced programmers who are well in versatile patterns. It is not intended to familiarize the reader with the concept of a design pattern. If interested in learning what design patterns are please refer to [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]. The intent of the article is not to describe existing patterns and their usage but rather introduce a other ways of categorizing and cataloging of patterns.

This article relies heavily on the [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation by Imed Hammouda and Jakub Rudzki]. We would like to thank them for their contribution to the field of design patterns and helping us to better understand pattern classification.

= Definition =

A pattern is a solution to a problem in its context. A context is specific to the domain in which the problem is being solved. For example, in computer science software engineers often are surrounded by problems in similar contexts such as web and database infrastructure. Within these contexts there are repeatable solutions. Those solutions when described abstractly are are what we call patterns. A pattern in itself is not a finished solution to a problem but rather a template on how to solve a given problem which can arise in a variety of different situations (contexts)[1]

The goal of patterns is to recognize and make use of a library of knowledge that can be used to solve problems. Often times, the same problems are 're-solved' without learning from the past experiences. As long as we have similar contexts we will have patterns or knowledge that develop from those solved problems.

== Example ==
The company you work for decides to switch a different database vendor which in turn requires you to change the interface for a set of objects in the software you designed.
It turns out that the change of interface is a common problem not just for the databases but in general in software development. In this case you would use a Adapter pattern in the context of database development.

= Problem =

The problem with patterns is classification and recognition or usage, i.e. what type of patterns to use for each given case. For example, a pattern that is not classified correctly will not be remembered and used. Several attempts to classify patterns has been made. The existing software classification of patterns uses the categories of:

# Structural
# Behavioral
# Creational

While these are good starting points for patterns, it is very hard to make use of this information in different contexts.

= Existing Work =

[http://c2.com/cgi/wiki?GangOfFour The Gang of Four] patterns are the most famous. They are classified according to creational, structural and behavioral groups. There is also a J2EE catalog of patterns by SUN. These are all classified as J2EE patterns but they can be split into presentation, business, and integration tier patterns.

There is a good [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation] regarding pattern classification by Imed Hammouda and Jakub Rudzki. In the presentation they suggest that patterns can be classifed by:

* Domain
* Paradigm
* Granularity
* Purpose
* Scope
* Discipline

== Domain ==

Domain specific classification may help make patterns more useful in various contexts. This is because the solution to the problem will be more specific to the context. Below are some examples of domain specific classification.

'''[http://en.wikipedia.org/wiki/Factory_method_pattern Factory method]''' - Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.[1]
'''[http://en.wikipedia.org/wiki/Object_pool Object pool]''' - Avoid expensive acquisition and release of resources by recycling objects that are no longer in use.[1]

'''[http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]''' - Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.[1]

'''[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]''' - Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.[1]

== Paradigm ==
Paradigm classification is a categorization of a pattern according a programming paradigm. In [http://en.wikipedia.org/wiki/Object-oriented_programming OOP] patterns take forms of classes, objects and inheritance while in [http://en.wikipedia.org/wiki/Imperative_programming imperative programming] patterns take form of procedures and functions.

Below are examples of patterns for functional logic languages taken from [2] and [3]

'''Opaque Type''' - Ensure that values of a datatype are hidden.

'''Locally Defined Global Identifier''' - Ensure that a local name is globally unique.

'''Incremental Solution''' - Compute solutions in an incremental manner.

'''Concurrent Distinct Choices''' - Ensure that a mapping from indexes to values is injective.

'''Constrained Constructor''' - Prevent invoking a constructor that might create invalid data.

== Granularity ==
This kind of categorization refers to the system level where the patterns are used at. For this category it is sometimes hard to draw a border between levels and the pattern might be used at different granularity categories. Below are the examples of pattern classification based on granularity classification. These examples were taken from [2] and [4]

'''Architectural patterns''' - refer to a software system at high level. Examples of these patterns would be [http://en.wikipedia.org/wiki/Layer_%28object-oriented_design%29 Layer], [http://en.wikipedia.org/wiki/Model-View-Controller Model-View-Controller] and [http://en.wikipedia.org/wiki/Multitier_architecture Multitier architecture]

'''Design patterns''' - focus on subsystems and components. Examples of these patters would be [http://en.wikipedia.org/wiki/Factory_method_pattern Factory method], [http://en.wikipedia.org/wiki/Object_pool Object pool] and [http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]

'''Idioms''' - address the lowest level of a software system. A good example of these would be [http://c2.com/cgi/wiki?JavaIdioms Java Idioms]

== Purpose ==
== Scope ==
== Discipline ==

= Article Definitions =
'''Gang of Four''' - also known as GoF. The authors of the Design Patterns book.

'''''M''odel-''V''iew-''C''ontroller''' - MVC for short, Architectural design pattern.

= Links =

* [http://www.cs.helsinki.fi/u/salaakso/patterns/index.html User Interface]
* [http://vis.berkeley.edu/papers/infovis_design_patterns/ Information Visualization]
* [http://simson.net/thesis/ Computer Security]
* [http://developer.yahoo.com/ypatterns/ Web Applications]
* [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification]
* [http://pattron.net/default.aspx A pattern catalog]
* [http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm Classification of Object Oriented Design Patterns]
* [http://www.patternforge.net/wiki/images/0/0c/Kudelka.pdf New Pattern Classification Approach]
* [http://java.sun.com/blueprints/patterns/catalog.html J2EE Patterns]

= References =
[1] [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]

[2] [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification] by Imed Hammouda & Jakub Rudzki

[3] S. Antoy and M. Hanus. “Functional Logic Design Patterns”. In Proc. Of the 6thInternational Symposium on Functional and Logic Programming (FLOPS 2002), Aizu (Japan), Springer LNCS 2441, pp. 67-87, 2002.

[4] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerland and M. Stal. ”Pattern-Oriented Software Architecture: A System of Patterns”. Wiley , (1996).

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-14T17:48:03Z

Cybo: /* Introduction */

= Introduction =
Patterns are often classified into creational, structural, and behavioral categories. However, this leaves a large number of patterns in each group, with no easy way of remembering all of them. What classifications and strategies have been developed to help programmers remember patterns, so that they can apply them at opportune moments?

This article is intended for experienced programmers who are well in versatile patterns. It is not intended to familiarize the reader with the concept of a design pattern. If interested in learning what design patterns are please refer to [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]. The intent of the article is not to describe existing patterns and their usage but rather introduce a other ways of categorizing and cataloging of patterns.

This article relies heavily on the [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation by Imed Hammouda and Jakub Rudzki]. We would like to thank them for their contribution to the field of design patterns and helping us to better understand pattern classification.

= Definition =

A pattern is a solution to a problem in its context. A context is specific to the domain in which the problem is being solved. For example, in computer science software engineers often are surrounded by problems in similar contexts such as web and database infrastructure. Within these contexts there are repeatable solutions. Those solutions when described abstractly are are what we call patterns. A pattern in itself is not a finished solution to a problem but rather a template on how to solve a given problem which can arise in a variety of different situations (contexts)[1]

The goal of patterns is to recognize and make use of a library of knowledge that can be used to solve problems. Often times, the same problems are 're-solved' without learning from the past experiences. As long as we have similar contexts we will have patterns or knowledge that develop from those solved problems.

== Example ==
The company you work for decides to switch a different database vendor which in turn requires you to change the interface for a set of objects in the software you designed.
It turns out that the change of interface is a common problem not just for the databases but in general in software development. In this case you would use a Adapter pattern in the context of database development.

= Problem =

The problem with patterns is classification and recognition or usage, i.e. what type of patterns to use for each given case. For example, a pattern that is not classified correctly will not be remembered and used. Several attempts to classify patterns has been made. The existing software classification of patterns uses the categories of:

# Structural
# Behavioral
# Creational

While these are good starting points for patterns, it is very hard to make use of this information in different contexts.

= Existing Work =

[http://c2.com/cgi/wiki?GangOfFour The Gang of Four] patterns are the most famous. They are classified according to creational, structural and behavioral groups. There is also a J2EE catalog of patterns by SUN. These are all classified as J2EE patterns but they can be split into presentation, business, and integration tier patterns.

There is a good [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation] regarding pattern classification by Imed Hammouda and Jakub Rudzki. In the presentation they suggest that patterns can be classifed by:

* Domain
* Paradigm
* Granularity
* Purpose
* Scope
* Discipline

== Domain ==

Domain specific classification may help make patterns more useful in various contexts. This is because the solution to the problem will be more specific to the context. Below are some examples of domain specific classification.

'''[http://en.wikipedia.org/wiki/Factory_method_pattern Factory method]''' - Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.[1]
'''[http://en.wikipedia.org/wiki/Object_pool Object pool]''' - Avoid expensive acquisition and release of resources by recycling objects that are no longer in use.[1]

'''[http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]''' - Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.[1]

'''[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]''' - Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.[1]

== Paradigm ==
Paradigm classification is a categorization of a pattern according a programming paradigm. In [http://en.wikipedia.org/wiki/Object-oriented_programming OOP] patterns take forms of classes, objects and inheritance while in [http://en.wikipedia.org/wiki/Imperative_programming imperative programming] patterns take form of procedures and functions.

Below are examples of patterns for functional logic languages taken from [2] and [3]

'''Opaque Type''' - Ensure that values of a datatype are hidden.

'''Locally Defined''' Global Identifier - Ensure that a local name is globally unique.

'''Incremental Solution''' - Compute solutions in an incremental manner.

'''Concurrent Distinct Choices''' - Ensure that a mapping from indexes to values is injective.

'''Constrained Constructor''' - Prevent invoking a constructor that might create invalid data.

== Granularity ==
This kind of categorization refers to the system level where the patterns are used at. For this category it is sometimes hard to draw a border between levels and the pattern might be used at different granularity categories. Below are the examples of pattern classification based on granularity classification. These examples were taken from [2] and [4]

'''Architectural patterns''' - refer to a software system at high level. Examples of these patterns would be [http://en.wikipedia.org/wiki/Layer_%28object-oriented_design%29 Layer], [http://en.wikipedia.org/wiki/Model-View-Controller Model-View-Controller] and [http://en.wikipedia.org/wiki/Multitier_architecture Multitier architecture]

'''Design patterns''' - focus on subsystems and components. Examples of these patters would be [http://en.wikipedia.org/wiki/Factory_method_pattern Factory method], [http://en.wikipedia.org/wiki/Object_pool Object pool] and [http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]

'''Idioms''' - address the lowest level of a software system. A good example of these would be [http://c2.com/cgi/wiki?JavaIdioms Java Idioms]

== Purpose ==
== Scope ==
== Discipline ==

= Article Definitions =
'''Gang of Four''' - also known as GoF. The authors of the Design Patterns book.

'''''M''odel-''V''iew-''C''ontroller''' - MVC for short, Architectural design pattern.

= Links =

* [http://www.cs.helsinki.fi/u/salaakso/patterns/index.html User Interface]
* [http://vis.berkeley.edu/papers/infovis_design_patterns/ Information Visualization]
* [http://simson.net/thesis/ Computer Security]
* [http://developer.yahoo.com/ypatterns/ Web Applications]
* [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification]
* [http://pattron.net/default.aspx A pattern catalog]
* [http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm Classification of Object Oriented Design Patterns]
* [http://www.patternforge.net/wiki/images/0/0c/Kudelka.pdf New Pattern Classification Approach]
* [http://java.sun.com/blueprints/patterns/catalog.html J2EE Patterns]

= References =
[1] [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]

[2] [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification] by Imed Hammouda & Jakub Rudzki

[3] S. Antoy and M. Hanus. “Functional Logic Design Patterns”. In Proc. Of the 6thInternational Symposium on Functional and Logic Programming (FLOPS 2002), Aizu (Japan), Springer LNCS 2441, pp. 67-87, 2002.

[4] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerland and M. Stal. ”Pattern-Oriented Software Architecture: A System of Patterns”. Wiley , (1996).

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-14T17:46:36Z

Cybo: /* Granularity */

= Introduction =
Patterns are often classified into creational, structural, and behavioral categories. However, this leaves a large number of patterns in each group, with no easy way of remembering all of them. What classifications and strategies have been developed to help programmers remember patterns, so that they can apply them at opportune moments?

This article is intended for experienced programmers who are well in versatile patterns. It is not intended to familiarize the reader with the concept of a design pattern. If interested in learning what design patterns are please refer to [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]. The intent of the article is not to describe existing patterns and their usage but rather introduce a other ways of categorizing and cataloging of patterns.

This article relies heavily on the [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation by Imed Hammouda & Jakub Rudzki]. We would like to thank them for their contribution to the field of design patterns and helping us to better understand pattern classification.

= Definition =

A pattern is a solution to a problem in its context. A context is specific to the domain in which the problem is being solved. For example, in computer science software engineers often are surrounded by problems in similar contexts such as web and database infrastructure. Within these contexts there are repeatable solutions. Those solutions when described abstractly are are what we call patterns. A pattern in itself is not a finished solution to a problem but rather a template on how to solve a given problem which can arise in a variety of different situations (contexts)[1]

The goal of patterns is to recognize and make use of a library of knowledge that can be used to solve problems. Often times, the same problems are 're-solved' without learning from the past experiences. As long as we have similar contexts we will have patterns or knowledge that develop from those solved problems.

== Example ==
The company you work for decides to switch a different database vendor which in turn requires you to change the interface for a set of objects in the software you designed.
It turns out that the change of interface is a common problem not just for the databases but in general in software development. In this case you would use a Adapter pattern in the context of database development.

= Problem =

The problem with patterns is classification and recognition or usage, i.e. what type of patterns to use for each given case. For example, a pattern that is not classified correctly will not be remembered and used. Several attempts to classify patterns has been made. The existing software classification of patterns uses the categories of:

# Structural
# Behavioral
# Creational

While these are good starting points for patterns, it is very hard to make use of this information in different contexts.

= Existing Work =

[http://c2.com/cgi/wiki?GangOfFour The Gang of Four] patterns are the most famous. They are classified according to creational, structural and behavioral groups. There is also a J2EE catalog of patterns by SUN. These are all classified as J2EE patterns but they can be split into presentation, business, and integration tier patterns.

There is a good [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation] regarding pattern classification by Imed Hammouda and Jakub Rudzki. In the presentation they suggest that patterns can be classifed by:

* Domain
* Paradigm
* Granularity
* Purpose
* Scope
* Discipline

== Domain ==

Domain specific classification may help make patterns more useful in various contexts. This is because the solution to the problem will be more specific to the context. Below are some examples of domain specific classification.

'''[http://en.wikipedia.org/wiki/Factory_method_pattern Factory method]''' - Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.[1]
'''[http://en.wikipedia.org/wiki/Object_pool Object pool]''' - Avoid expensive acquisition and release of resources by recycling objects that are no longer in use.[1]

'''[http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]''' - Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.[1]

'''[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]''' - Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.[1]

== Paradigm ==
Paradigm classification is a categorization of a pattern according a programming paradigm. In [http://en.wikipedia.org/wiki/Object-oriented_programming OOP] patterns take forms of classes, objects and inheritance while in [http://en.wikipedia.org/wiki/Imperative_programming imperative programming] patterns take form of procedures and functions.

Below are examples of patterns for functional logic languages taken from [2] and [3]

'''Opaque Type''' - Ensure that values of a datatype are hidden.

'''Locally Defined''' Global Identifier - Ensure that a local name is globally unique.

'''Incremental Solution''' - Compute solutions in an incremental manner.

'''Concurrent Distinct Choices''' - Ensure that a mapping from indexes to values is injective.

'''Constrained Constructor''' - Prevent invoking a constructor that might create invalid data.

== Granularity ==
This kind of categorization refers to the system level where the patterns are used at. For this category it is sometimes hard to draw a border between levels and the pattern might be used at different granularity categories. Below are the examples of pattern classification based on granularity classification. These examples were taken from [2] and [4]

'''Architectural patterns''' - refer to a software system at high level. Examples of these patterns would be [http://en.wikipedia.org/wiki/Layer_%28object-oriented_design%29 Layer], [http://en.wikipedia.org/wiki/Model-View-Controller Model-View-Controller] and [http://en.wikipedia.org/wiki/Multitier_architecture Multitier architecture]

'''Design patterns''' - focus on subsystems and components. Examples of these patters would be [http://en.wikipedia.org/wiki/Factory_method_pattern Factory method], [http://en.wikipedia.org/wiki/Object_pool Object pool] and [http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]

'''Idioms''' - address the lowest level of a software system. A good example of these would be [http://c2.com/cgi/wiki?JavaIdioms Java Idioms]

== Purpose ==
== Scope ==
== Discipline ==

= Article Definitions =
'''Gang of Four''' - also known as GoF. The authors of the Design Patterns book.

'''''M''odel-''V''iew-''C''ontroller''' - MVC for short, Architectural design pattern.

= Links =

* [http://www.cs.helsinki.fi/u/salaakso/patterns/index.html User Interface]
* [http://vis.berkeley.edu/papers/infovis_design_patterns/ Information Visualization]
* [http://simson.net/thesis/ Computer Security]
* [http://developer.yahoo.com/ypatterns/ Web Applications]
* [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification]
* [http://pattron.net/default.aspx A pattern catalog]
* [http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm Classification of Object Oriented Design Patterns]
* [http://www.patternforge.net/wiki/images/0/0c/Kudelka.pdf New Pattern Classification Approach]
* [http://java.sun.com/blueprints/patterns/catalog.html J2EE Patterns]

= References =
[1] [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]

[2] [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification] by Imed Hammouda & Jakub Rudzki

[3] S. Antoy and M. Hanus. “Functional Logic Design Patterns”. In Proc. Of the 6thInternational Symposium on Functional and Logic Programming (FLOPS 2002), Aizu (Japan), Springer LNCS 2441, pp. 67-87, 2002.

[4] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerland and M. Stal. ”Pattern-Oriented Software Architecture: A System of Patterns”. Wiley , (1996).

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-14T17:45:28Z

Cybo:

= Introduction =
Patterns are often classified into creational, structural, and behavioral categories. However, this leaves a large number of patterns in each group, with no easy way of remembering all of them. What classifications and strategies have been developed to help programmers remember patterns, so that they can apply them at opportune moments?

This article is intended for experienced programmers who are well in versatile patterns. It is not intended to familiarize the reader with the concept of a design pattern. If interested in learning what design patterns are please refer to [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]. The intent of the article is not to describe existing patterns and their usage but rather introduce a other ways of categorizing and cataloging of patterns.

This article relies heavily on the [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation by Imed Hammouda & Jakub Rudzki]. We would like to thank them for their contribution to the field of design patterns and helping us to better understand pattern classification.

= Definition =

A pattern is a solution to a problem in its context. A context is specific to the domain in which the problem is being solved. For example, in computer science software engineers often are surrounded by problems in similar contexts such as web and database infrastructure. Within these contexts there are repeatable solutions. Those solutions when described abstractly are are what we call patterns. A pattern in itself is not a finished solution to a problem but rather a template on how to solve a given problem which can arise in a variety of different situations (contexts)[1]

The goal of patterns is to recognize and make use of a library of knowledge that can be used to solve problems. Often times, the same problems are 're-solved' without learning from the past experiences. As long as we have similar contexts we will have patterns or knowledge that develop from those solved problems.

== Example ==
The company you work for decides to switch a different database vendor which in turn requires you to change the interface for a set of objects in the software you designed.
It turns out that the change of interface is a common problem not just for the databases but in general in software development. In this case you would use a Adapter pattern in the context of database development.

= Problem =

The problem with patterns is classification and recognition or usage, i.e. what type of patterns to use for each given case. For example, a pattern that is not classified correctly will not be remembered and used. Several attempts to classify patterns has been made. The existing software classification of patterns uses the categories of:

# Structural
# Behavioral
# Creational

While these are good starting points for patterns, it is very hard to make use of this information in different contexts.

= Existing Work =

[http://c2.com/cgi/wiki?GangOfFour The Gang of Four] patterns are the most famous. They are classified according to creational, structural and behavioral groups. There is also a J2EE catalog of patterns by SUN. These are all classified as J2EE patterns but they can be split into presentation, business, and integration tier patterns.

There is a good [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation] regarding pattern classification by Imed Hammouda and Jakub Rudzki. In the presentation they suggest that patterns can be classifed by:

* Domain
* Paradigm
* Granularity
* Purpose
* Scope
* Discipline

== Domain ==

Domain specific classification may help make patterns more useful in various contexts. This is because the solution to the problem will be more specific to the context. Below are some examples of domain specific classification.

'''[http://en.wikipedia.org/wiki/Factory_method_pattern Factory method]''' - Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.[1]
'''[http://en.wikipedia.org/wiki/Object_pool Object pool]''' - Avoid expensive acquisition and release of resources by recycling objects that are no longer in use.[1]

'''[http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]''' - Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.[1]

'''[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]''' - Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.[1]

== Paradigm ==
Paradigm classification is a categorization of a pattern according a programming paradigm. In [http://en.wikipedia.org/wiki/Object-oriented_programming OOP] patterns take forms of classes, objects and inheritance while in [http://en.wikipedia.org/wiki/Imperative_programming imperative programming] patterns take form of procedures and functions.

Below are examples of patterns for functional logic languages taken from [2] and [3]

'''Opaque Type''' - Ensure that values of a datatype are hidden.

'''Locally Defined''' Global Identifier - Ensure that a local name is globally unique.

'''Incremental Solution''' - Compute solutions in an incremental manner.

'''Concurrent Distinct Choices''' - Ensure that a mapping from indexes to values is injective.

'''Constrained Constructor''' - Prevent invoking a constructor that might create invalid data.

== Granularity ==
This kind of categorization refers to the system level where the patterns are used at. For this category it is sometimes hard to draw a border between levels and the pattern might be used at different granularity categories. Below are the examples of pattern classification based on granularity classification. These examples were taken from [2] and [4]

'''Architectural patterns''' - refer to a software system at high level. Examples of these patterns would be [http://en.wikipedia.org/wiki/Layer_%28object-oriented_design%29 Layer], [http://en.wikipedia.org/wiki/Model-View-Controller Model-View-Controller] and [http://en.wikipedia.org/wiki/Multitier_architecture Multitier architecture]

'''Design patterns''' - focus on subsystems and components. Examples of these patters would be [http://en.wikipedia.org/wiki/Factory_method_pattern Factory method], [http://en.wikipedia.org/wiki/Object_pool Object pool] and [http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]

'''Idioms (coding patterns)''' - address the lowest level of a software system. A good example of these would be [http://c2.com/cgi/wiki?JavaIdioms Java Idioms]

== Purpose ==
== Scope ==
== Discipline ==

= Article Definitions =
'''Gang of Four''' - also known as GoF. The authors of the Design Patterns book.

'''''M''odel-''V''iew-''C''ontroller''' - MVC for short, Architectural design pattern.

= Links =

* [http://www.cs.helsinki.fi/u/salaakso/patterns/index.html User Interface]
* [http://vis.berkeley.edu/papers/infovis_design_patterns/ Information Visualization]
* [http://simson.net/thesis/ Computer Security]
* [http://developer.yahoo.com/ypatterns/ Web Applications]
* [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification]
* [http://pattron.net/default.aspx A pattern catalog]
* [http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm Classification of Object Oriented Design Patterns]
* [http://www.patternforge.net/wiki/images/0/0c/Kudelka.pdf New Pattern Classification Approach]
* [http://java.sun.com/blueprints/patterns/catalog.html J2EE Patterns]

= References =
[1] [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]

[2] [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification] by Imed Hammouda & Jakub Rudzki

[3] S. Antoy and M. Hanus. “Functional Logic Design Patterns”. In Proc. Of the 6thInternational Symposium on Functional and Logic Programming (FLOPS 2002), Aizu (Japan), Springer LNCS 2441, pp. 67-87, 2002.

[4] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerland and M. Stal. ”Pattern-Oriented Software Architecture: A System of Patterns”. Wiley , (1996).

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-14T17:40:16Z

Cybo: /* Granularity */

= Introduction =
Patterns are often classified into creational, structural, and behavioral categories. However, this leaves a large number of patterns in each group, with no easy way of remembering all of them. What classifications and strategies have been developed to help programmers remember patterns, so that they can apply them at opportune moments?

This article is intended for experienced programmers who are well in versatile patterns. It is not intended to familiarize the reader with the concept of a design pattern. If interested in learning what design patterns are please refer to [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]. The intent of the article is not to describe existing patterns and their usage but rather introduce a other ways of categorizing and cataloging of patterns.

This article relies heavily on the [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation by Imed Hammouda & Jakub Rudzki]. We would like to thank them for their contribution to the field of design patterns and helping us to better understand pattern classification.

= Definition =

A pattern is a solution to a problem in its context. A context is specific to the domain in which the problem is being solved. For example, in computer science software engineers often are surrounded by problems in similar contexts such as web and database infrastructure. Within these contexts there are repeatable solutions. Those solutions when described abstractly are are what we call patterns. A pattern in itself is not a finished solution to a problem but rather a template on how to solve a given problem which can arise in a variety of different situations (contexts)[1]

The goal of patterns is to recognize and make use of a library of knowledge that can be used to solve problems. Often times, the same problems are 're-solved' without learning from the past experiences. As long as we have similar contexts we will have patterns or knowledge that develop from those solved problems.

== Example ==
The company you work for decides to switch a different database vendor which in turn requires you to change the interface for a set of objects in the software you designed.
It turns out that the change of interface is a common problem not just for the databases but in general in software development. In this case you would use a Adapter pattern in the context of database development.

= Problem =

The problem with patterns is classification and recognition or usage, i.e. what type of patterns to use for each given case. For example, a pattern that is not classified correctly will not be remembered and used. Several attempts to classify patterns has been made. The existing software classification of patterns uses the categories of:

# Structural
# Behavioral
# Creational

While these are good starting points for patterns, it is very hard to make use of this information in different contexts.

= Existing Work =

[http://c2.com/cgi/wiki?GangOfFour The Gang of Four] patterns are the most famous. They are classified according to creational, structural and behavioral groups. There is also a J2EE catalog of patterns by SUN. These are all classified as J2EE patterns but they can be split into presentation, business, and integration tier patterns.

There is a good [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation] regarding pattern classification by Imed Hammouda and Jakub Rudzki. In the presentation they suggest that patterns can be classifed by:

* Domain
* Paradigm
* Granularity
* Purpose
* Scope
* Discipline

== Domain ==

Domain specific classification may help make patterns more useful in various contexts. This is because the solution to the problem will be more specific to the context. Below are some examples of domain specific classification.

'''[http://en.wikipedia.org/wiki/Factory_method_pattern Factory method]''' - Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.[1]
'''[http://en.wikipedia.org/wiki/Object_pool Object pool]''' - Avoid expensive acquisition and release of resources by recycling objects that are no longer in use.[1]

'''[http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]''' - Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.[1]

'''[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]''' - Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.[1]

== Paradigm ==
Paradigm classification is a categorization of a pattern according a programming paradigm. In [http://en.wikipedia.org/wiki/Object-oriented_programming OOP] patterns take forms of classes, objects and inheritance while in [http://en.wikipedia.org/wiki/Imperative_programming imperative programming] patterns take form of procedures and functions.

Below are examples of patterns for functional logic languages taken from [2] and [3]

'''Opaque Type''' - Ensure that values of a datatype are hidden.

'''Locally Defined''' Global Identifier - Ensure that a local name is globally unique.

'''Incremental Solution''' - Compute solutions in an incremental manner.

'''Concurrent Distinct Choices''' - Ensure that a mapping from indexes to values is injective.

'''Constrained Constructor''' - Prevent invoking a constructor that might create invalid data.

== Granularity ==
This kind of categorization refers to the system level where the patterns are used at. For this category it is sometimes hard to draw a border between levels and the pattern might be used at different granularity categories. Below are the examples of pattern classification based on granularity classification. These examples were taken from [2] and [4]

'''Architectural patterns''' - refer to a software system at high level. Examples of these patterns would be [http://en.wikipedia.org/wiki/Layer_%28object-oriented_design%29 Layer], [http://en.wikipedia.org/wiki/Model-View-Controller Model-View-Controller] and [http://en.wikipedia.org/wiki/Multitier_architecture Multitier architecture]

'''Design patterns''' - focus on subsystems and components. Examples of these patters would be [http://en.wikipedia.org/wiki/Factory_method_pattern Factory method], [http://en.wikipedia.org/wiki/Object_pool Object pool] and [http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]

'''Idioms (coding patterns)''' - address the lowest level of a software system. A good example of these would be [http://c2.com/cgi/wiki?JavaIdioms Java Idioms]

== Purpose ==
== Scope ==
== Discipline ==

= Article Definitions =
'''Gang of Four''' - also known as GoF. The authors of the Design Patterns book.

'''''M''odel-''V''iew-''C''ontroller''' - MVC for short, Architectural design pattern.

= Links =

* [http://www.cs.helsinki.fi/u/salaakso/patterns/index.html User Interface]
* [http://vis.berkeley.edu/papers/infovis_design_patterns/ Information Visualization]
* [http://simson.net/thesis/ Computer Security]
* [http://developer.yahoo.com/ypatterns/ Web Applications]
* [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification]
* [http://pattron.net/default.aspx A pattern catalog]
* [http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm Classification of Object Oriented Design Patterns]
* [http://www.patternforge.net/wiki/images/0/0c/Kudelka.pdf New Pattern Classification Approach]
* [http://java.sun.com/blueprints/patterns/catalog.html J2EE Patterns]

= References =
[1][http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]

[2][http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification] by Imed Hammouda & Jakub Rudzki

[3]S. Antoy and M. Hanus. “Functional Logic Design Patterns”. In Proc. Of the 6thInternational Symposium on Functional and Logic Programming (FLOPS 2002), Aizu (Japan), Springer LNCS 2441, pp. 67-87, 2002.

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-14T17:38:50Z

Cybo: /* Introduction */

= Introduction =
Patterns are often classified into creational, structural, and behavioral categories. However, this leaves a large number of patterns in each group, with no easy way of remembering all of them. What classifications and strategies have been developed to help programmers remember patterns, so that they can apply them at opportune moments?

This article is intended for experienced programmers who are well in versatile patterns. It is not intended to familiarize the reader with the concept of a design pattern. If interested in learning what design patterns are please refer to [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]. The intent of the article is not to describe existing patterns and their usage but rather introduce a other ways of categorizing and cataloging of patterns.

This article relies heavily on the [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation by Imed Hammouda & Jakub Rudzki]. We would like to thank them for their contribution to the field of design patterns and helping us to better understand pattern classification.

= Definition =

A pattern is a solution to a problem in its context. A context is specific to the domain in which the problem is being solved. For example, in computer science software engineers often are surrounded by problems in similar contexts such as web and database infrastructure. Within these contexts there are repeatable solutions. Those solutions when described abstractly are are what we call patterns. A pattern in itself is not a finished solution to a problem but rather a template on how to solve a given problem which can arise in a variety of different situations (contexts)[1]

The goal of patterns is to recognize and make use of a library of knowledge that can be used to solve problems. Often times, the same problems are 're-solved' without learning from the past experiences. As long as we have similar contexts we will have patterns or knowledge that develop from those solved problems.

== Example ==
The company you work for decides to switch a different database vendor which in turn requires you to change the interface for a set of objects in the software you designed.
It turns out that the change of interface is a common problem not just for the databases but in general in software development. In this case you would use a Adapter pattern in the context of database development.

= Problem =

The problem with patterns is classification and recognition or usage, i.e. what type of patterns to use for each given case. For example, a pattern that is not classified correctly will not be remembered and used. Several attempts to classify patterns has been made. The existing software classification of patterns uses the categories of:

# Structural
# Behavioral
# Creational

While these are good starting points for patterns, it is very hard to make use of this information in different contexts.

= Existing Work =

[http://c2.com/cgi/wiki?GangOfFour The Gang of Four] patterns are the most famous. They are classified according to creational, structural and behavioral groups. There is also a J2EE catalog of patterns by SUN. These are all classified as J2EE patterns but they can be split into presentation, business, and integration tier patterns.

There is a good [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation] regarding pattern classification by Imed Hammouda and Jakub Rudzki. In the presentation they suggest that patterns can be classifed by:

* Domain
* Paradigm
* Granularity
* Purpose
* Scope
* Discipline

== Domain ==

Domain specific classification may help make patterns more useful in various contexts. This is because the solution to the problem will be more specific to the context. Below are some examples of domain specific classification.

'''[http://en.wikipedia.org/wiki/Factory_method_pattern Factory method]''' - Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.[1]
'''[http://en.wikipedia.org/wiki/Object_pool Object pool]''' - Avoid expensive acquisition and release of resources by recycling objects that are no longer in use.[1]

'''[http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]''' - Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.[1]

'''[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]''' - Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.[1]

== Paradigm ==
Paradigm classification is a categorization of a pattern according a programming paradigm. In [http://en.wikipedia.org/wiki/Object-oriented_programming OOP] patterns take forms of classes, objects and inheritance while in [http://en.wikipedia.org/wiki/Imperative_programming imperative programming] patterns take form of procedures and functions.

Below are examples of patterns for functional logic languages taken from [2] and [3]

'''Opaque Type''' - Ensure that values of a datatype are hidden.

'''Locally Defined''' Global Identifier - Ensure that a local name is globally unique.

'''Incremental Solution''' - Compute solutions in an incremental manner.

'''Concurrent Distinct Choices''' - Ensure that a mapping from indexes to values is injective.

'''Constrained Constructor''' - Prevent invoking a constructor that might create invalid data.

== Granularity ==
This kind of categorization refers to the system level where the patterns are used at. For this category it is sometimes hard to draw a border between levels and the pattern might be used at different granularity categories. Below are the examples of pattern classification based on granularity classification. These examples were taken from [2] and [4]

'''Architectural patterns''' - refer to a software system at high level. Examples of these patterns would be [http://en.wikipedia.org/wiki/Layer_%28object-oriented_design%29 Layer], [http://en.wikipedia.org/wiki/Model-View-Controller Model-View-Controller] and [http://en.wikipedia.org/wiki/Multitier_architecture Multitier architecture]

'''Design patterns''' - focus on subsystems and components. Examples of these patters would be [http://en.wikipedia.org/wiki/Factory_method_pattern Factory method], [http://en.wikipedia.org/wiki/Object_pool Object pool] and [http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]

'''Idioms (coding patterns)''' - address the lowest level of a software system.

== Purpose ==
== Scope ==
== Discipline ==

= Article Definitions =
'''Gang of Four''' - also known as GoF. The authors of the Design Patterns book.

'''''M''odel-''V''iew-''C''ontroller''' - MVC for short, Architectural design pattern.

= Links =

* [http://www.cs.helsinki.fi/u/salaakso/patterns/index.html User Interface]
* [http://vis.berkeley.edu/papers/infovis_design_patterns/ Information Visualization]
* [http://simson.net/thesis/ Computer Security]
* [http://developer.yahoo.com/ypatterns/ Web Applications]
* [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification]
* [http://pattron.net/default.aspx A pattern catalog]
* [http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm Classification of Object Oriented Design Patterns]
* [http://www.patternforge.net/wiki/images/0/0c/Kudelka.pdf New Pattern Classification Approach]
* [http://java.sun.com/blueprints/patterns/catalog.html J2EE Patterns]

= References =
[1][http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]

[2][http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification] by Imed Hammouda & Jakub Rudzki

[3]S. Antoy and M. Hanus. “Functional Logic Design Patterns”. In Proc. Of the 6thInternational Symposium on Functional and Logic Programming (FLOPS 2002), Aizu (Japan), Springer LNCS 2441, pp. 67-87, 2002.

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-14T17:38:18Z

Cybo:

= Introduction =
Patterns are often classified into creational, structural, and behavioral categories. However, this leaves a large number of patterns in each group, with no easy way of remembering all of them. What classifications and strategies have been developed to help programmers remember patterns, so that they can apply them at opportune moments?

This article is intended for experienced programmers who are well versatile patterns. It is not intended to familiarize the reader with the concept of a design pattern. If interested in learning what design patterns are please refer to [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]. The intent of the article is not to describe existing patterns and their usage but rather introduce a other ways of categorizing and cataloging of patterns.

This article relies heavily on the [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation by Imed Hammouda & Jakub Rudzki]. We would like to thank them for their contribution to the field of design patterns and helping us to better understand pattern classification.

= Definition =

A pattern is a solution to a problem in its context. A context is specific to the domain in which the problem is being solved. For example, in computer science software engineers often are surrounded by problems in similar contexts such as web and database infrastructure. Within these contexts there are repeatable solutions. Those solutions when described abstractly are are what we call patterns. A pattern in itself is not a finished solution to a problem but rather a template on how to solve a given problem which can arise in a variety of different situations (contexts)[1]

The goal of patterns is to recognize and make use of a library of knowledge that can be used to solve problems. Often times, the same problems are 're-solved' without learning from the past experiences. As long as we have similar contexts we will have patterns or knowledge that develop from those solved problems.

== Example ==
The company you work for decides to switch a different database vendor which in turn requires you to change the interface for a set of objects in the software you designed.
It turns out that the change of interface is a common problem not just for the databases but in general in software development. In this case you would use a Adapter pattern in the context of database development.

= Problem =

The problem with patterns is classification and recognition or usage, i.e. what type of patterns to use for each given case. For example, a pattern that is not classified correctly will not be remembered and used. Several attempts to classify patterns has been made. The existing software classification of patterns uses the categories of:

# Structural
# Behavioral
# Creational

While these are good starting points for patterns, it is very hard to make use of this information in different contexts.

= Existing Work =

[http://c2.com/cgi/wiki?GangOfFour The Gang of Four] patterns are the most famous. They are classified according to creational, structural and behavioral groups. There is also a J2EE catalog of patterns by SUN. These are all classified as J2EE patterns but they can be split into presentation, business, and integration tier patterns.

There is a good [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation] regarding pattern classification by Imed Hammouda and Jakub Rudzki. In the presentation they suggest that patterns can be classifed by:

* Domain
* Paradigm
* Granularity
* Purpose
* Scope
* Discipline

== Domain ==

Domain specific classification may help make patterns more useful in various contexts. This is because the solution to the problem will be more specific to the context. Below are some examples of domain specific classification.

'''[http://en.wikipedia.org/wiki/Factory_method_pattern Factory method]''' - Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.[1]
'''[http://en.wikipedia.org/wiki/Object_pool Object pool]''' - Avoid expensive acquisition and release of resources by recycling objects that are no longer in use.[1]

'''[http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]''' - Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.[1]

'''[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]''' - Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.[1]

== Paradigm ==
Paradigm classification is a categorization of a pattern according a programming paradigm. In [http://en.wikipedia.org/wiki/Object-oriented_programming OOP] patterns take forms of classes, objects and inheritance while in [http://en.wikipedia.org/wiki/Imperative_programming imperative programming] patterns take form of procedures and functions.

Below are examples of patterns for functional logic languages taken from [2] and [3]

'''Opaque Type''' - Ensure that values of a datatype are hidden.

'''Locally Defined''' Global Identifier - Ensure that a local name is globally unique.

'''Incremental Solution''' - Compute solutions in an incremental manner.

'''Concurrent Distinct Choices''' - Ensure that a mapping from indexes to values is injective.

'''Constrained Constructor''' - Prevent invoking a constructor that might create invalid data.

== Granularity ==
This kind of categorization refers to the system level where the patterns are used at. For this category it is sometimes hard to draw a border between levels and the pattern might be used at different granularity categories. Below are the examples of pattern classification based on granularity classification. These examples were taken from [2] and [4]

'''Architectural patterns''' - refer to a software system at high level. Examples of these patterns would be [http://en.wikipedia.org/wiki/Layer_%28object-oriented_design%29 Layer], [http://en.wikipedia.org/wiki/Model-View-Controller Model-View-Controller] and [http://en.wikipedia.org/wiki/Multitier_architecture Multitier architecture]

'''Design patterns''' - focus on subsystems and components. Examples of these patters would be [http://en.wikipedia.org/wiki/Factory_method_pattern Factory method], [http://en.wikipedia.org/wiki/Object_pool Object pool] and [http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]

'''Idioms (coding patterns)''' - address the lowest level of a software system.

== Purpose ==
== Scope ==
== Discipline ==

= Article Definitions =
'''Gang of Four''' - also known as GoF. The authors of the Design Patterns book.

'''''M''odel-''V''iew-''C''ontroller''' - MVC for short, Architectural design pattern.

= Links =

* [http://www.cs.helsinki.fi/u/salaakso/patterns/index.html User Interface]
* [http://vis.berkeley.edu/papers/infovis_design_patterns/ Information Visualization]
* [http://simson.net/thesis/ Computer Security]
* [http://developer.yahoo.com/ypatterns/ Web Applications]
* [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification]
* [http://pattron.net/default.aspx A pattern catalog]
* [http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm Classification of Object Oriented Design Patterns]
* [http://www.patternforge.net/wiki/images/0/0c/Kudelka.pdf New Pattern Classification Approach]
* [http://java.sun.com/blueprints/patterns/catalog.html J2EE Patterns]

= References =
[1][http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]

[2][http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification] by Imed Hammouda & Jakub Rudzki

[3]S. Antoy and M. Hanus. “Functional Logic Design Patterns”. In Proc. Of the 6thInternational Symposium on Functional and Logic Programming (FLOPS 2002), Aizu (Japan), Springer LNCS 2441, pp. 67-87, 2002.

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-14T17:26:30Z

Cybo:

= Introduction =
Patterns are often classified into creational, structural, and behavioral categories. However, this leaves a large number of patterns in each group, with no easy way of remembering all of them. What classifications and strategies have been developed to help programmers remember patterns, so that they can apply them at opportune moments?

This article is intended for experienced programmer who are familiar with patterns and have used them before. It is not intended to familiarize the reader with the concept of a design pattern. If interested in learning what design patterns are please refer to [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]. The intent of the article is not to describe existing patterns and their usage but rather introduce a other ways of categorizing and cataloging of patterns.

This article relies heavily on the [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation by Imed Hammouda & Jakub Rudzki]. We would like to thank them for their contribution to the field of design patterns and helping us to better understand pattern classification.

= Definition =

A pattern is a solution to a problem in its context. A context is specific to the domain in which the problem is being solved. For example, in computer science software engineers often are surrounded by problems in similar contexts such as web and database infrastructure. Within these contexts there are repeatable solutions. Those solutions when described abstractly are are what we call patterns. A pattern in itself is not a finished solution to a problem but rather a template on how to solve a given problem which can arise in a variety of different situations (contexts)[1]

The goal of patterns is to recognize and make use of a library of knowledge that can be used to solve problems. Often times, the same problems are 're-solved' without learning from the past experiences. As long as we have similar contexts we will have patterns or knowledge that develop from those solved problems.

== Example ==
The company you work for decides to switch a different database vendor which in turn requires you to change the interface for a set of objects in the software you designed.
It turns out that the change of interface is a common problem not just for the databases but in general in software development. In this case you would use a Adapter pattern in the context of database development.

= Problem =

The problem with patterns is classification and recognition or usage, i.e. what type of patterns to use for each given case. For example, a pattern that is not classified correctly will not be remembered and used. Several attempts to classify patterns has been made. The existing software classification of patterns uses the categories of:

# Structural
# Behavioral
# Creational

While these are good starting points for patterns, it is very hard to make use of this information in different contexts.

= Existing Work =

[http://c2.com/cgi/wiki?GangOfFour The Gang of Four] patterns are the most famous. They are classified according to creational, structural and behavioral groups. There is also a J2EE catalog of patterns by SUN. These are all classified as J2EE patterns but they can be split into presentation, business, and integration tier patterns.

There is a good [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation] regarding pattern classification by Imed Hammouda and Jakub Rudzki. In the presentation they suggest that patterns can be classifed by:

* Domain
* Paradigm
* Granularity
* Purpose
* Scope
* Discipline

== Domain ==

Domain specific classification may help make patterns more useful in various contexts. This is because the solution to the problem will be more specific to the context. Below are some examples of domain specific classification.

'''[http://en.wikipedia.org/wiki/Factory_method_pattern Factory method]''' - Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.[1]
'''[http://en.wikipedia.org/wiki/Object_pool Object pool]''' - Avoid expensive acquisition and release of resources by recycling objects that are no longer in use.[1]

'''[http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]''' - Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.[1]

'''[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]''' - Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.[1]

== Paradigm ==
Paradigm classification is a categorization of a pattern according a programming paradigm. In [http://en.wikipedia.org/wiki/Object-oriented_programming OOP] patterns take forms of classes, objects and inheritance while in [http://en.wikipedia.org/wiki/Imperative_programming imperative programming] patterns take form of procedures and functions.

Below are examples of patterns for functional logic languages taken from [2] and [3]

'''Opaque Type''' - Ensure that values of a datatype are hidden.

'''Locally Defined''' Global Identifier - Ensure that a local name is globally unique.

'''Incremental Solution''' - Compute solutions in an incremental manner.

'''Concurrent Distinct Choices''' - Ensure that a mapping from indexes to values is injective.

'''Constrained Constructor''' - Prevent invoking a constructor that might create invalid data.

= Article Definitions =
'''Gang of Four''' - also known as GoF. The authors of the Design Patterns book.

'''''M''odel-''V''iew-''C''ontroller''' - MVC for short, Architectural design pattern.

== Granularity ==
This kind of categorization refers to the system level where the patterns are used at. For this category it is sometimes hard to draw a border between levels and the pattern might be used at different granularity categories. Below are the examples of pattern classification based on granularity classification

== Purpose ==
== Scope ==
== Discipline ==

= Links =

* [http://www.cs.helsinki.fi/u/salaakso/patterns/index.html User Interface]
* [http://vis.berkeley.edu/papers/infovis_design_patterns/ Information Visualization]
* [http://simson.net/thesis/ Computer Security]
* [http://developer.yahoo.com/ypatterns/ Web Applications]
* [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification]
* [http://pattron.net/default.aspx A pattern catalog]
* [http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm Classification of Object Oriented Design Patterns]
* [http://www.patternforge.net/wiki/images/0/0c/Kudelka.pdf New Pattern Classification Approach]
* [http://java.sun.com/blueprints/patterns/catalog.html J2EE Patterns]

= References =
[1][http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]

[2][http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification] by Imed Hammouda & Jakub Rudzki

[3]S. Antoy and M. Hanus. “Functional Logic Design Patterns”. In Proc. Of the 6thInternational Symposium on Functional and Logic Programming (FLOPS 2002), Aizu (Japan), Springer LNCS 2441, pp. 67-87, 2002.

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-14T17:15:53Z

Cybo: /* Paradigm */

= Introduction =
Patterns are often classified into creational, structural, and behavioral categories. However, this leaves a large number of patterns in each group, with no easy way of remembering all of them. What classifications and strategies have been developed to help programmers remember patterns, so that they can apply them at opportune moments?

This article is intended for users who are familiar with patterns and have used them before. It is not intended to familiarize the reader with the concept of a design pattern. If interested in learning what design patterns are please refer to [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]. The intent of the article is not to describe existing patterns and their usage but rather introduce a other ways of categorizing and cataloging of patterns.

This article relies heavily on the [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation by Imed Hammouda & Jakub Rudzki]. We would like to thank them for their contribution to the field of design patterns and helping us to better understand pattern classification.

= Definition =

A pattern is a solution to a problem in its context. A context is specific to the domain in which the problem is being solved. For example, in computer science software engineers often are surrounded by problems in similar contexts such as web and database infrastructure. Within these contexts there are repeatable solutions. Those solutions when described abstractly are are what we call patterns. A pattern in itself is not a finished solution to a problem but rather a template on how to solve a given problem which can arise in a variety of different situations (contexts)[1]

The goal of patterns is to recognize and make use of a library of knowledge that can be used to solve problems. Often times, the same problems are 're-solved' without learning from the past experiences. As long as we have similar contexts we will have patterns or knowledge that develop from those solved problems.

== Example ==
The company you work for decides to switch a different database vendor which in turn requires you to change the interface for a set of objects in the software you designed.
It turns out that the change of interface is a common problem not just for the databases but in general in software development. In this case you would use a Adapter pattern in the context of database development.

= Problem =

The problem with patterns is classification and recognition or usage, i.e. what type of patterns to use for each given case. For example, a pattern that is not classified correctly will not be remembered and used. Several attempts to classify patterns has been made. The existing software classification of patterns uses the categories of:

# Structural
# Behavioral
# Creational

While these are good starting points for patterns, it is very hard to make use of this information in different contexts.

= Existing Work =

[http://c2.com/cgi/wiki?GangOfFour The Gang of Four] patterns are the most famous. They are classified according to creational, structural and behavioral groups. There is also a J2EE catalog of patterns by SUN. These are all classified as J2EE patterns but they can be split into presentation, business, and integration tier patterns.

There is a good [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation] regarding pattern classification by Imed Hammouda and Jakub Rudzki. In the presentation they suggest that patterns can be classifed by:

* Domain
* Paradigm
* Granularity
* Purpose
* Scope
* Discipline

== Domain ==

Domain specific classification may help make patterns more useful in various contexts. This is because the solution to the problem will be more specific to the context. Below are some examples of domain specific classification.

'''[http://en.wikipedia.org/wiki/Factory_method_pattern Factory method]''' - Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.[1]
'''[http://en.wikipedia.org/wiki/Object_pool Object pool]''' - Avoid expensive acquisition and release of resources by recycling objects that are no longer in use.[1]

'''[http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]''' - Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.[1]

'''[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]''' - Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.[1]

== Paradigm ==
Paradigm classification is a categorization of a pattern according a programming paradigm. In [http://en.wikipedia.org/wiki/Object-oriented_programming OOP] patterns take forms of classes, objects and inheritance while in [http://en.wikipedia.org/wiki/Imperative_programming imperative programming] patterns take form of procedures and functions.

Below are examples of patterns for functional logic languages taken from [2] and [3]

'''Opaque Type''' - Ensure that values of a datatype are hidden.

'''Locally Defined''' Global Identifier - Ensure that a local name is globally unique.

'''Incremental Solution''' - Compute solutions in an incremental manner.

'''Concurrent Distinct Choices''' - Ensure that a mapping from indexes to values is injective.

'''Constrained Constructor''' - Prevent invoking a constructor that might create invalid data.

= Article Definitions =
'''Gang of Four''' - also known as GoF. The authors of the Design Patterns book.

'''''M''odel-''V''iew-''C''ontroller''' - MVC for short, Architectural design pattern.

= Links =

* [http://www.cs.helsinki.fi/u/salaakso/patterns/index.html User Interface]
* [http://vis.berkeley.edu/papers/infovis_design_patterns/ Information Visualization]
* [http://simson.net/thesis/ Computer Security]
* [http://developer.yahoo.com/ypatterns/ Web Applications]
* [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification]
* [http://pattron.net/default.aspx A pattern catalog]
* [http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm Classification of Object Oriented Design Patterns]
* [http://www.patternforge.net/wiki/images/0/0c/Kudelka.pdf New Pattern Classification Approach]
* [http://java.sun.com/blueprints/patterns/catalog.html J2EE Patterns]

= References =
[1][http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]
[2][http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification] by Imed Hammouda & Jakub Rudzki
[3]S. Antoy and M. Hanus. “Functional Logic Design Patterns”. In Proc. Of the 6thInternational Symposium on Functional and Logic Programming (FLOPS 2002), Aizu (Japan), Springer LNCS 2441, pp. 67-87, 2002.

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-14T17:14:58Z

Cybo:

= Introduction =
Patterns are often classified into creational, structural, and behavioral categories. However, this leaves a large number of patterns in each group, with no easy way of remembering all of them. What classifications and strategies have been developed to help programmers remember patterns, so that they can apply them at opportune moments?

This article is intended for users who are familiar with patterns and have used them before. It is not intended to familiarize the reader with the concept of a design pattern. If interested in learning what design patterns are please refer to [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]. The intent of the article is not to describe existing patterns and their usage but rather introduce a other ways of categorizing and cataloging of patterns.

This article relies heavily on the [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation by Imed Hammouda & Jakub Rudzki]. We would like to thank them for their contribution to the field of design patterns and helping us to better understand pattern classification.

= Definition =

A pattern is a solution to a problem in its context. A context is specific to the domain in which the problem is being solved. For example, in computer science software engineers often are surrounded by problems in similar contexts such as web and database infrastructure. Within these contexts there are repeatable solutions. Those solutions when described abstractly are are what we call patterns. A pattern in itself is not a finished solution to a problem but rather a template on how to solve a given problem which can arise in a variety of different situations (contexts)[1]

The goal of patterns is to recognize and make use of a library of knowledge that can be used to solve problems. Often times, the same problems are 're-solved' without learning from the past experiences. As long as we have similar contexts we will have patterns or knowledge that develop from those solved problems.

== Example ==
The company you work for decides to switch a different database vendor which in turn requires you to change the interface for a set of objects in the software you designed.
It turns out that the change of interface is a common problem not just for the databases but in general in software development. In this case you would use a Adapter pattern in the context of database development.

= Problem =

The problem with patterns is classification and recognition or usage, i.e. what type of patterns to use for each given case. For example, a pattern that is not classified correctly will not be remembered and used. Several attempts to classify patterns has been made. The existing software classification of patterns uses the categories of:

# Structural
# Behavioral
# Creational

While these are good starting points for patterns, it is very hard to make use of this information in different contexts.

= Existing Work =

[http://c2.com/cgi/wiki?GangOfFour The Gang of Four] patterns are the most famous. They are classified according to creational, structural and behavioral groups. There is also a J2EE catalog of patterns by SUN. These are all classified as J2EE patterns but they can be split into presentation, business, and integration tier patterns.

There is a good [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf presentation] regarding pattern classification by Imed Hammouda and Jakub Rudzki. In the presentation they suggest that patterns can be classifed by:

* Domain
* Paradigm
* Granularity
* Purpose
* Scope
* Discipline

== Domain ==

Domain specific classification may help make patterns more useful in various contexts. This is because the solution to the problem will be more specific to the context. Below are some examples of domain specific classification.

'''[http://en.wikipedia.org/wiki/Factory_method_pattern Factory method]''' - Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.[1]
'''[http://en.wikipedia.org/wiki/Object_pool Object pool]''' - Avoid expensive acquisition and release of resources by recycling objects that are no longer in use.[1]

'''[http://en.wikipedia.org/wiki/Adapter_pattern Adapter or Wrapper]''' - Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.[1]

'''[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]''' - Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.[1]

== Paradigm ==
Paradigm classification is a categorization of a pattern according a programming paradigm. In [http://en.wikipedia.org/wiki/Object-oriented_programming OOP] patterns take forms of classes, objects and inheritance while in [http://en.wikipedia.org/wiki/Imperative_programming imperative programming] patterns take form of procedures and functions.

Below are examples of patterns for functional logic languages taken from [2] and [3]

'''Opaque Type''' - Ensure that values of a datatype are hidden.
'''Locally Defined''' Global Identifier - Ensure that a local name is globally unique.
'''Incremental Solution''' - Compute solutions in an incremental manner.
'''Concurrent Distinct Choices''' - Ensure that a mapping from indexes to values is injective.
'''Constrained Constructor''' - Prevent invoking a constructor that might create invalid data.

= Article Definitions =
'''Gang of Four''' - also known as GoF. The authors of the Design Patterns book.

'''''M''odel-''V''iew-''C''ontroller''' - MVC for short, Architectural design pattern.

= Links =

* [http://www.cs.helsinki.fi/u/salaakso/patterns/index.html User Interface]
* [http://vis.berkeley.edu/papers/infovis_design_patterns/ Information Visualization]
* [http://simson.net/thesis/ Computer Security]
* [http://developer.yahoo.com/ypatterns/ Web Applications]
* [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification]
* [http://pattron.net/default.aspx A pattern catalog]
* [http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm Classification of Object Oriented Design Patterns]
* [http://www.patternforge.net/wiki/images/0/0c/Kudelka.pdf New Pattern Classification Approach]
* [http://java.sun.com/blueprints/patterns/catalog.html J2EE Patterns]

= References =
[1][http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design Pattern]
[2][http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Pattern Classification] by Imed Hammouda & Jakub Rudzki
[3]S. Antoy and M. Hanus. “Functional Logic Design Patterns”. In Proc. Of the 6thInternational Symposium on Functional and Logic Programming (FLOPS 2002), Aizu (Japan), Springer LNCS 2441, pp. 67-87, 2002.

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-14T17:04:28Z

Cybo: /* Paradigm */

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-14T17:03:25Z

Cybo: /* Existing Work */

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-14T16:53:00Z

Cybo: /* Domain */

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-14T16:52:00Z

Cybo: /* Domain */

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-14T16:50:37Z

Cybo: /* Domain */

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-14T16:44:43Z

Cybo: /* Domain */

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-14T16:41:09Z

Cybo: /* Article Definitions */

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-14T16:40:45Z

Cybo:

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-14T16:34:52Z

Cybo: /* Introduction */

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-14T16:32:34Z

Cybo: /* Existing Work */

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-14T16:22:59Z

Cybo: /* Existing Work */

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-14T16:13:03Z

Cybo:

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-14T16:12:20Z

Cybo: /* Definition */

CSC/ECE 517 Fall 2009/wiki2 12 PatternClassification

2009-10-14T16:10:48Z

Cybo: /* Definition */