Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-19T20:16:37Z

Tinydancer: /* CRC Cards */

Topic : CRC cards are useful, but have some limitations. For example, they require that a group be present; it is sometimes hard to get a group together. One alternative technique is "Object Think." Compare CRC cards with Object Think and any other alternatives for the first stages of analysis and design.

= CRC Cards =

CRC (Class-Responsibility-Collaborator) Card Modeling was first introduced by Kent Beck and Ward Cunningham. It is a simple yet powerful object-oriented analysis technique where users, analysts, and developers can work together in a modeling and design process.

CRC Cards are usually created from index cards which contain the following information:
* Class name - the name of the class
* Responsibilities - anything that the class knows or does
* Collaborators - names of other classes with which the class will collaborate to fulfill its responsibilities

The size of the index card forces the designers or participants to limit the class from having too many responsibilities or collaborations with other classes. The designers should consider breaking a class that has too many responsibilities into multiple classes. Class that has too many collaborations with other classes will create high coupling, which does not adhere with the object oriented methodology.

= Object Think =

Simon Horwith defines “Object Think” as an approach to Object Oriented Programming based on the practice of object personification.

Object Think represents a way to think of the domain model in terms of objects, which further helps in developing or designing classes. Object Think was suggested as a practical alternative to CRC cards in 1993 by Coad and Nicola. The primary benefit of Object Think is that unlike CRC cards, it can be done individually and no group is required.

In Object Think perspective, objects are modeled to carry out real world functions. Then the responsibilities are distributed across objects as part of the design. Object Think therefore helps to create an accurate domain model where every object in the domain model handles all of its own responsibilities. The advantage of this approach is that as the software system is initially designed, the designers might start with fewer objects carrying out many functionality. As the system grows over time, Object Think will lead to design a community of objects sharing those responsibilities.

Object Think also bridges the traditional process-oriented thinking with the object mindsets. For example, the real world scenario of communication translates to Messaging in the Object Oriented paradigm.

Object Think perceives Objects as independent entity performing actions and making decisions on its own. Mike Abney, in the article -"Object Think: A Perspective on Objects" suggests that an object's capability to act is one of its three categories of responsibilities: "whom I know," "what I do," and "what I know." Peter Coad and Edward Youdon (in Object-Oriented Analysis, 2nd ed., Prentice Hall, 1990) refers this to object's services. Although technically services refer to an operation or procedure, when an object performs the services they are viewed as actions on the objects. As an example, an account object provides a debit method. So, when the debit method is acted on the object, it is viewed as debit action being carried upon the object. This means the state of the object changes based on the action that is being performed on the object.

== Guidelines for Design Using Object Think ==

1. Everything in the domain model is an object. This means that a class technically cannot have free-floating functions that are not related to an object of the class. Functions generally represent the actions on an object or a concept in the domain model. So, they have to be associated with an object that represent the concept

2. Think like an Object

3. Model the objects of a system using the language of the domain model. This helps designers to focus on the domain model and design a system with a high level perspective instead of bogged down with low level implementation details.The purpose and capabilities of an object has to be designed and stated clearly. Also, the implementation should statisfy the stated goal.

4. Objects should have context free behavior - This really means that Objects should be designed with the object oriented principles like encapsulation, cohesion, coupling, reuse etc. and Objects should be modeled as autonomous agents that perform the operations in isolation.

5. Design using simulation - Simulating a domain model by representing it in terms of various objects will help to identify the details of the design.

6. Design to keep functions and data together - Domain model's operations can be represented as actions on objects. Since these operations affect the state of the object, it is a good practice to tie objects and their operations together.

== Benefits of Object Thinking ==

1. Unlike CRC, Object thinking can be carried out by individuals

2. Design using Object think provides a maintainable code as in a long run, a system will have objects sharing ther responsibilities and collaborating to complete a domain operation

3. Design using object think also results in a reusable code

4. Since Object Think insists on stating the purpose and capabilities of the objects, this will result in a better definition of data and the responsibility on the objects

5. Also, Object Think can be used as a platform to educate developers to become object oriented thinkers

= Alternatives to CRC Cards =
== Unified Modeling Language (UML) ==

UML is a visual language for specifying, constructing, and documenting the artifacts of systems.

Advantages of UML Diagram compared to CRC cards:
# You can use UML with all processes, throughout the development lifecycle, and across different implementation technologies.
# You can easily visualize the relationship between classes or objects.
# The complete structure of the system can be captured in one UML diagram, instead of several CRC cards.

== OMT ==
The Object Modeling technique combines three views of a system and hence three models are used for representing the views.

# Object Model – describes the static structure of the objects and their relationships in the system. This represents the concepts like attribute, operation, inheritance, association, aggregation etc.
# Dynamic Model – describes the aspects of the system that changes over time. This model explains the concepts like states, event, activity, etc.
# Functional Model – describes the data value transformations in a system. This model explains the concepts like process, data flow, and control flow, actor, etc.

During the analysis phase of the design, all these models are developed and delivered. Object Model Diagram provides a formal graphic notation for modeling objects, classes and their relationships with one another. State diagrams and Event flow diagrams will represent the dynamic model of the system. Data flow diagram represents the data transformation within the system due to the events or actions of the actors.
OMT differs from CRCs in the way the system is viewed. Apart from viewing the systems as classes and responsibilities, OMT provides a richer way to view and design the system using the 3 models as described above.

== Booch Method of OOAD ==

Booch Method is a process and notation for developing and communicating the design of an object-oriented software system. Booch method contains proven heuristics for developing quality software that provides effective design and support for development of future systems.
Booch method is a broad methodology that addresses OOAD using object modeling, analysis modeling, application design, implementation design etc.

Booch method uses following types of diagrams to describe the design decisions that must be made when creating an Object-Oriented system.

Class Diagrams: Represents set of classes and class relationships

Class Specification is used to capture all the information about a class in text format. A class specification contains set of fields that define a class

Category Diagrams are used to group logically related classes in to meaningful collection.

State Transition Diagrams represents the dynamic behavior associated of the classes in the system

Object Diagrams show the existence of objects and their relationships in the logical model of the system.

Timing Diagram is a graph that augments an on object diagram to capture information about external events and timing of operations in the object diagram

Module Diagram is used to show the allocation of classes and objects to module in the physical design of the system.

Process Diagrams represents various process flows and their allocation to processors of the system

Subsystems represent the clusters of logically related modules

The analysis and design steps in Booch method will result in class diagrams, class specifications, object specifications, inheritance views, class category diagrams, architectural descriptions.

== Coad, Yourdon and Nicola OOAD ==

In Coad, Yourdon and Nicola method, OOA works with problem domain classes and objects and OOD focuses on human interaction, task management, and data management classes and objects. In this method, each class and its objects fit into one of the four components: human interaction component, problem domain component, task management component, data management component. They differ from traditional CRCs in a way that the approach revolves around the principles of managing complexity. Three most important principles to manage complexity are:

1. Pervading methods of organization – This is similar to how real world people organize the objects via differentiating objects based on attributes, forming a class of objects based on the features.

2. Categories of behavior – This concept is the basis for identifying the actions of an object

3. Personification – This gives a human characteristic to inanimate objects

== FUSION ==

Fusion method was developed by Object Oriented Design Group at Hewlett-Packard Laboratories, Bristol. The method builds on existing Booch, OMT, CRC and provides a direct route from requirements definition through to a programming language implementation.
The analysis phase of this method provides a declarative description of system behavior. The Object model describes the static structure of the objects in the problem domain and their interrelation. The Interface model describes the interface of a system and how the system interacts with the environment.

The design stage realizes the system behavior using various outputs as given below.

1. Object Interaction Graph and visibility graph shows how objects interact with each other to complete an operation that is defined in the interface model. Algorithms, classes and their attributes, method signatures are specified accompanying each object interaction graph. Visibility graph complements the Object Interaction graph as it shows how the references among various objects are implemented.

2. Class description captures the class interfaces, attributes, object reference attributes and method signatures

3. Inheritance Graphs are specified to capture the relationships between the objects that are working together.

= References =

* Object Think - Common Sense Software Architecture by Simon Horwith on cfunited conference 2006

* [http://www.informit.com/articles/article.aspx?p=25184&seqNum=4 Object Think: A Perspective on Objects by Mike Abney]

* [http://net.educause.edu/ir/library/text/c95/c95-ps04.txt "OBJECT THINK" A Step toward Object Oriented Implementation]

* [http://corfield.org/blog/index.cfm/do/blog.entry/entry/Object_Think Object Think]

* Designing Object Oriented Software by Wirfs-Brock et al.

* Object Analysis and Design : Description of Methods by Andrew T.F. Hutt

* [http://students.cs.byu.edu/~pbiggs/survey.html A Survey of Object-Oriented Methods by Peter Biggs]

* [http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf Introduction to CRC Cards by David M. Rubin]

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-19T20:05:55Z

Tinydancer: /* References */

Topic : CRC cards are useful, but have some limitations. For example, they require that a group be present; it is sometimes hard to get a group together. One alternative technique is "Object Think." Compare CRC cards with Object Think and any other alternatives for the first stages of analysis and design.

= CRC Cards =

CRC (Class-Responsibility-Collaborator) Card Modeling was first introduced by Kent Beck and Ward Cunningham. It is a simple yet powerful object-oriented analysis technique where users, analysts, and developers can work together in a modeling and design process.

= Object Think =

Simon Horwith defines “Object Think” as an approach to Object Oriented Programming based on the practice of object personification.

Object Think represents a way to think of the domain model in terms of objects, which further helps in developing or designing classes. Object Think was suggested as a practical alternative to CRC cards in 1993 by Coad and Nicola. The primary benefit of Object Think is that unlike CRC cards, it can be done individually and no group is required.

In Object Think perspective, objects are modeled to carry out real world functions. Then the responsibilities are distributed across objects as part of the design. Object Think therefore helps to create an accurate domain model where every object in the domain model handles all of its own responsibilities. The advantage of this approach is that as the software system is initially designed, the designers might start with fewer objects carrying out many functionality. As the system grows over time, Object Think will lead to design a community of objects sharing those responsibilities.

Object Think also bridges the traditional process-oriented thinking with the object mindsets. For example, the real world scenario of communication translates to Messaging in the Object Oriented paradigm.

Object Think perceives Objects as independent entity performing actions and making decisions on its own. Mike Abney, in the article -"Object Think: A Perspective on Objects" suggests that an object's capability to act is one of its three categories of responsibilities: "whom I know," "what I do," and "what I know." Peter Coad and Edward Youdon (in Object-Oriented Analysis, 2nd ed., Prentice Hall, 1990) refers this to object's services. Although technically services refer to an operation or procedure, when an object performs the services they are viewed as actions on the objects. As an example, an account object provides a debit method. So, when the debit method is acted on the object, it is viewed as debit action being carried upon the object. This means the state of the object changes based on the action that is being performed on the object.

== Guidelines for Design Using Object Think ==

1. Everything in the domain model is an object. This means that a class technically cannot have free-floating functions that are not related to an object of the class. Functions generally represent the actions on an object or a concept in the domain model. So, they have to be associated with an object that represent the concept

2. Think like an Object

3. Model the objects of a system using the language of the domain model. This helps designers to focus on the domain model and design a system with a high level perspective instead of bogged down with low level implementation details.The purpose and capabilities of an object has to be designed and stated clearly. Also, the implementation should statisfy the stated goal.

4. Objects should have context free behavior - This really means that Objects should be designed with the object oriented principles like encapsulation, cohesion, coupling, reuse etc. and Objects should be modeled as autonomous agents that perform the operations in isolation.

5. Design using simulation - Simulating a domain model by representing it in terms of various objects will help to identify the details of the design.

6. Design to keep functions and data together - Domain model's operations can be represented as actions on objects. Since these operations affect the state of the object, it is a good practice to tie objects and their operations together.

== Benefits of Object Thinking ==

1. Unlike CRC, Object thinking can be carried out by individuals

2. Design using Object think provides a maintainable code as in a long run, a system will have objects sharing ther responsibilities and collaborating to complete a domain operation

3. Design using object think also results in a reusable code

4. Since Object Think insists on stating the purpose and capabilities of the objects, this will result in a better definition of data and the responsibility on the objects

5. Also, Object Think can be used as a platform to educate developers to become object oriented thinkers

= Alternatives to CRC Cards =
== Unified Modeling Language (UML) ==

UML is a visual language for specifying, constructing, and documenting the artifacts of systems.

Advantages of UML Diagram compared to CRC cards:
# You can use UML with all processes, throughout the development lifecycle, and across different implementation technologies.
# You can easily visualize the relationship between classes or objects.
# The complete structure of the system can be captured in one UML diagram, instead of several CRC cards.

== OMT ==
The Object Modeling technique combines three views of a system and hence three models are used for representing the views.

# Object Model – describes the static structure of the objects and their relationships in the system. This represents the concepts like attribute, operation, inheritance, association, aggregation etc.
# Dynamic Model – describes the aspects of the system that changes over time. This model explains the concepts like states, event, activity, etc.
# Functional Model – describes the data value transformations in a system. This model explains the concepts like process, data flow, and control flow, actor, etc.

During the analysis phase of the design, all these models are developed and delivered. Object Model Diagram provides a formal graphic notation for modeling objects, classes and their relationships with one another. State diagrams and Event flow diagrams will represent the dynamic model of the system. Data flow diagram represents the data transformation within the system due to the events or actions of the actors.
OMT differs from CRCs in the way the system is viewed. Apart from viewing the systems as classes and responsibilities, OMT provides a richer way to view and design the system using the 3 models as described above.

== Booch Method of OOAD ==

Booch Method is a process and notation for developing and communicating the design of an object-oriented software system. Booch method contains proven heuristics for developing quality software that provides effective design and support for development of future systems.
Booch method is a broad methodology that addresses OOAD using object modeling, analysis modeling, application design, implementation design etc.

Booch method uses following types of diagrams to describe the design decisions that must be made when creating an Object-Oriented system.

Class Diagrams: Represents set of classes and class relationships

Class Specification is used to capture all the information about a class in text format. A class specification contains set of fields that define a class

Category Diagrams are used to group logically related classes in to meaningful collection.

State Transition Diagrams represents the dynamic behavior associated of the classes in the system

Object Diagrams show the existence of objects and their relationships in the logical model of the system.

Timing Diagram is a graph that augments an on object diagram to capture information about external events and timing of operations in the object diagram

Module Diagram is used to show the allocation of classes and objects to module in the physical design of the system.

Process Diagrams represents various process flows and their allocation to processors of the system

Subsystems represent the clusters of logically related modules

The analysis and design steps in Booch method will result in class diagrams, class specifications, object specifications, inheritance views, class category diagrams, architectural descriptions.

== Coad, Yourdon and Nicola OOAD ==

In Coad, Yourdon and Nicola method, OOA works with problem domain classes and objects and OOD focuses on human interaction, task management, and data management classes and objects. In this method, each class and its objects fit into one of the four components: human interaction component, problem domain component, task management component, data management component. They differ from traditional CRCs in a way that the approach revolves around the principles of managing complexity. Three most important principles to manage complexity are:

1. Pervading methods of organization – This is similar to how real world people organize the objects via differentiating objects based on attributes, forming a class of objects based on the features.

2. Categories of behavior – This concept is the basis for identifying the actions of an object

3. Personification – This gives a human characteristic to inanimate objects

== FUSION ==

Fusion method was developed by Object Oriented Design Group at Hewlett-Packard Laboratories, Bristol. The method builds on existing Booch, OMT, CRC and provides a direct route from requirements definition through to a programming language implementation.
The analysis phase of this method provides a declarative description of system behavior. The Object model describes the static structure of the objects in the problem domain and their interrelation. The Interface model describes the interface of a system and how the system interacts with the environment.

The design stage realizes the system behavior using various outputs as given below.

1. Object Interaction Graph and visibility graph shows how objects interact with each other to complete an operation that is defined in the interface model. Algorithms, classes and their attributes, method signatures are specified accompanying each object interaction graph. Visibility graph complements the Object Interaction graph as it shows how the references among various objects are implemented.

2. Class description captures the class interfaces, attributes, object reference attributes and method signatures

3. Inheritance Graphs are specified to capture the relationships between the objects that are working together.

= References =

* Object Think - Common Sense Software Architecture by Simon Horwith on cfunited conference 2006

* [http://www.informit.com/articles/article.aspx?p=25184&seqNum=4 Object Think: A Perspective on Objects by Mike Abney]

* [http://net.educause.edu/ir/library/text/c95/c95-ps04.txt "OBJECT THINK" A Step toward Object Oriented Implementation]

* [http://corfield.org/blog/index.cfm/do/blog.entry/entry/Object_Think Object Think]

* Designing Object Oriented Software by Wirfs-Brock et al.

* Object Analysis and Design : Description of Methods by Andrew T.F. Hutt

* [http://students.cs.byu.edu/~pbiggs/survey.html A Survey of Object-Oriented Methods by Peter Biggs]

* [http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf Introduction to CRC Cards by David M. Rubin]

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-19T20:05:17Z

Tinydancer: /* References */

Topic : CRC cards are useful, but have some limitations. For example, they require that a group be present; it is sometimes hard to get a group together. One alternative technique is "Object Think." Compare CRC cards with Object Think and any other alternatives for the first stages of analysis and design.

= CRC Cards =

CRC (Class-Responsibility-Collaborator) Card Modeling was first introduced by Kent Beck and Ward Cunningham. It is a simple yet powerful object-oriented analysis technique where users, analysts, and developers can work together in a modeling and design process.

= Object Think =

Simon Horwith defines “Object Think” as an approach to Object Oriented Programming based on the practice of object personification.

Object Think represents a way to think of the domain model in terms of objects, which further helps in developing or designing classes. Object Think was suggested as a practical alternative to CRC cards in 1993 by Coad and Nicola. The primary benefit of Object Think is that unlike CRC cards, it can be done individually and no group is required.

In Object Think perspective, objects are modeled to carry out real world functions. Then the responsibilities are distributed across objects as part of the design. Object Think therefore helps to create an accurate domain model where every object in the domain model handles all of its own responsibilities. The advantage of this approach is that as the software system is initially designed, the designers might start with fewer objects carrying out many functionality. As the system grows over time, Object Think will lead to design a community of objects sharing those responsibilities.

Object Think also bridges the traditional process-oriented thinking with the object mindsets. For example, the real world scenario of communication translates to Messaging in the Object Oriented paradigm.

Object Think perceives Objects as independent entity performing actions and making decisions on its own. Mike Abney, in the article -"Object Think: A Perspective on Objects" suggests that an object's capability to act is one of its three categories of responsibilities: "whom I know," "what I do," and "what I know." Peter Coad and Edward Youdon (in Object-Oriented Analysis, 2nd ed., Prentice Hall, 1990) refers this to object's services. Although technically services refer to an operation or procedure, when an object performs the services they are viewed as actions on the objects. As an example, an account object provides a debit method. So, when the debit method is acted on the object, it is viewed as debit action being carried upon the object. This means the state of the object changes based on the action that is being performed on the object.

== Guidelines for Design Using Object Think ==

1. Everything in the domain model is an object. This means that a class technically cannot have free-floating functions that are not related to an object of the class. Functions generally represent the actions on an object or a concept in the domain model. So, they have to be associated with an object that represent the concept

2. Think like an Object

3. Model the objects of a system using the language of the domain model. This helps designers to focus on the domain model and design a system with a high level perspective instead of bogged down with low level implementation details.The purpose and capabilities of an object has to be designed and stated clearly. Also, the implementation should statisfy the stated goal.

4. Objects should have context free behavior - This really means that Objects should be designed with the object oriented principles like encapsulation, cohesion, coupling, reuse etc. and Objects should be modeled as autonomous agents that perform the operations in isolation.

5. Design using simulation - Simulating a domain model by representing it in terms of various objects will help to identify the details of the design.

6. Design to keep functions and data together - Domain model's operations can be represented as actions on objects. Since these operations affect the state of the object, it is a good practice to tie objects and their operations together.

== Benefits of Object Thinking ==

1. Unlike CRC, Object thinking can be carried out by individuals

2. Design using Object think provides a maintainable code as in a long run, a system will have objects sharing ther responsibilities and collaborating to complete a domain operation

3. Design using object think also results in a reusable code

4. Since Object Think insists on stating the purpose and capabilities of the objects, this will result in a better definition of data and the responsibility on the objects

5. Also, Object Think can be used as a platform to educate developers to become object oriented thinkers

= Alternatives to CRC Cards =
== Unified Modeling Language (UML) ==

UML is a visual language for specifying, constructing, and documenting the artifacts of systems.

Advantages of UML Diagram compared to CRC cards:
# You can use UML with all processes, throughout the development lifecycle, and across different implementation technologies.
# You can easily visualize the relationship between classes or objects.
# The complete structure of the system can be captured in one UML diagram, instead of several CRC cards.

== OMT ==
The Object Modeling technique combines three views of a system and hence three models are used for representing the views.

# Object Model – describes the static structure of the objects and their relationships in the system. This represents the concepts like attribute, operation, inheritance, association, aggregation etc.
# Dynamic Model – describes the aspects of the system that changes over time. This model explains the concepts like states, event, activity, etc.
# Functional Model – describes the data value transformations in a system. This model explains the concepts like process, data flow, and control flow, actor, etc.

During the analysis phase of the design, all these models are developed and delivered. Object Model Diagram provides a formal graphic notation for modeling objects, classes and their relationships with one another. State diagrams and Event flow diagrams will represent the dynamic model of the system. Data flow diagram represents the data transformation within the system due to the events or actions of the actors.
OMT differs from CRCs in the way the system is viewed. Apart from viewing the systems as classes and responsibilities, OMT provides a richer way to view and design the system using the 3 models as described above.

== Booch Method of OOAD ==

Booch Method is a process and notation for developing and communicating the design of an object-oriented software system. Booch method contains proven heuristics for developing quality software that provides effective design and support for development of future systems.
Booch method is a broad methodology that addresses OOAD using object modeling, analysis modeling, application design, implementation design etc.

Booch method uses following types of diagrams to describe the design decisions that must be made when creating an Object-Oriented system.

Class Diagrams: Represents set of classes and class relationships

Class Specification is used to capture all the information about a class in text format. A class specification contains set of fields that define a class

Category Diagrams are used to group logically related classes in to meaningful collection.

State Transition Diagrams represents the dynamic behavior associated of the classes in the system

Object Diagrams show the existence of objects and their relationships in the logical model of the system.

Timing Diagram is a graph that augments an on object diagram to capture information about external events and timing of operations in the object diagram

Module Diagram is used to show the allocation of classes and objects to module in the physical design of the system.

Process Diagrams represents various process flows and their allocation to processors of the system

Subsystems represent the clusters of logically related modules

The analysis and design steps in Booch method will result in class diagrams, class specifications, object specifications, inheritance views, class category diagrams, architectural descriptions.

== Coad, Yourdon and Nicola OOAD ==

In Coad, Yourdon and Nicola method, OOA works with problem domain classes and objects and OOD focuses on human interaction, task management, and data management classes and objects. In this method, each class and its objects fit into one of the four components: human interaction component, problem domain component, task management component, data management component. They differ from traditional CRCs in a way that the approach revolves around the principles of managing complexity. Three most important principles to manage complexity are:

1. Pervading methods of organization – This is similar to how real world people organize the objects via differentiating objects based on attributes, forming a class of objects based on the features.

2. Categories of behavior – This concept is the basis for identifying the actions of an object

3. Personification – This gives a human characteristic to inanimate objects

== FUSION ==

Fusion method was developed by Object Oriented Design Group at Hewlett-Packard Laboratories, Bristol. The method builds on existing Booch, OMT, CRC and provides a direct route from requirements definition through to a programming language implementation.
The analysis phase of this method provides a declarative description of system behavior. The Object model describes the static structure of the objects in the problem domain and their interrelation. The Interface model describes the interface of a system and how the system interacts with the environment.

The design stage realizes the system behavior using various outputs as given below.

1. Object Interaction Graph and visibility graph shows how objects interact with each other to complete an operation that is defined in the interface model. Algorithms, classes and their attributes, method signatures are specified accompanying each object interaction graph. Visibility graph complements the Object Interaction graph as it shows how the references among various objects are implemented.

2. Class description captures the class interfaces, attributes, object reference attributes and method signatures

3. Inheritance Graphs are specified to capture the relationships between the objects that are working together.

= References =

* Object Think - Common Sense Software Architecture by Simon Horwith on cfunited conference 2006

* [http://www.informit.com/articles/article.aspx?p=25184&seqNum=4 Object Think: A Perspective on Objects by Mike Abney]

* [http://net.educause.edu/ir/library/text/c95/c95-ps04.txt "OBJECT THINK" A Step toward Object Oriented Implementation]

* [http://corfield.org/blog/index.cfm/do/blog.entry/entry/Object_Think Object Think]

* Designing Object Oriented Software by Wirfs-Brock et al.

* Object Analysis and Design : Description of Methods by Andrew T.F. Hutt

* [http://students.cs.byu.edu/~pbiggs/survey.html A Survey of Object-Oriented Methods by Peter Biggs]

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-19T20:04:44Z

Tinydancer: /* CRC Cards */

Topic : CRC cards are useful, but have some limitations. For example, they require that a group be present; it is sometimes hard to get a group together. One alternative technique is "Object Think." Compare CRC cards with Object Think and any other alternatives for the first stages of analysis and design.

= CRC Cards =

CRC (Class-Responsibility-Collaborator) Card Modeling was first introduced by Kent Beck and Ward Cunningham. It is a simple yet powerful object-oriented analysis technique where users, analysts, and developers can work together in a modeling and design process.

= Object Think =

Simon Horwith defines “Object Think” as an approach to Object Oriented Programming based on the practice of object personification.

Object Think represents a way to think of the domain model in terms of objects, which further helps in developing or designing classes. Object Think was suggested as a practical alternative to CRC cards in 1993 by Coad and Nicola. The primary benefit of Object Think is that unlike CRC cards, it can be done individually and no group is required.

In Object Think perspective, objects are modeled to carry out real world functions. Then the responsibilities are distributed across objects as part of the design. Object Think therefore helps to create an accurate domain model where every object in the domain model handles all of its own responsibilities. The advantage of this approach is that as the software system is initially designed, the designers might start with fewer objects carrying out many functionality. As the system grows over time, Object Think will lead to design a community of objects sharing those responsibilities.

Object Think also bridges the traditional process-oriented thinking with the object mindsets. For example, the real world scenario of communication translates to Messaging in the Object Oriented paradigm.

Object Think perceives Objects as independent entity performing actions and making decisions on its own. Mike Abney, in the article -"Object Think: A Perspective on Objects" suggests that an object's capability to act is one of its three categories of responsibilities: "whom I know," "what I do," and "what I know." Peter Coad and Edward Youdon (in Object-Oriented Analysis, 2nd ed., Prentice Hall, 1990) refers this to object's services. Although technically services refer to an operation or procedure, when an object performs the services they are viewed as actions on the objects. As an example, an account object provides a debit method. So, when the debit method is acted on the object, it is viewed as debit action being carried upon the object. This means the state of the object changes based on the action that is being performed on the object.

== Guidelines for Design Using Object Think ==

1. Everything in the domain model is an object. This means that a class technically cannot have free-floating functions that are not related to an object of the class. Functions generally represent the actions on an object or a concept in the domain model. So, they have to be associated with an object that represent the concept

2. Think like an Object

3. Model the objects of a system using the language of the domain model. This helps designers to focus on the domain model and design a system with a high level perspective instead of bogged down with low level implementation details.The purpose and capabilities of an object has to be designed and stated clearly. Also, the implementation should statisfy the stated goal.

4. Objects should have context free behavior - This really means that Objects should be designed with the object oriented principles like encapsulation, cohesion, coupling, reuse etc. and Objects should be modeled as autonomous agents that perform the operations in isolation.

5. Design using simulation - Simulating a domain model by representing it in terms of various objects will help to identify the details of the design.

6. Design to keep functions and data together - Domain model's operations can be represented as actions on objects. Since these operations affect the state of the object, it is a good practice to tie objects and their operations together.

== Benefits of Object Thinking ==

1. Unlike CRC, Object thinking can be carried out by individuals

2. Design using Object think provides a maintainable code as in a long run, a system will have objects sharing ther responsibilities and collaborating to complete a domain operation

3. Design using object think also results in a reusable code

4. Since Object Think insists on stating the purpose and capabilities of the objects, this will result in a better definition of data and the responsibility on the objects

5. Also, Object Think can be used as a platform to educate developers to become object oriented thinkers

= Alternatives to CRC Cards =
== Unified Modeling Language (UML) ==

UML is a visual language for specifying, constructing, and documenting the artifacts of systems.

Advantages of UML Diagram compared to CRC cards:
# You can use UML with all processes, throughout the development lifecycle, and across different implementation technologies.
# You can easily visualize the relationship between classes or objects.
# The complete structure of the system can be captured in one UML diagram, instead of several CRC cards.

== OMT ==
The Object Modeling technique combines three views of a system and hence three models are used for representing the views.

# Object Model – describes the static structure of the objects and their relationships in the system. This represents the concepts like attribute, operation, inheritance, association, aggregation etc.
# Dynamic Model – describes the aspects of the system that changes over time. This model explains the concepts like states, event, activity, etc.
# Functional Model – describes the data value transformations in a system. This model explains the concepts like process, data flow, and control flow, actor, etc.

During the analysis phase of the design, all these models are developed and delivered. Object Model Diagram provides a formal graphic notation for modeling objects, classes and their relationships with one another. State diagrams and Event flow diagrams will represent the dynamic model of the system. Data flow diagram represents the data transformation within the system due to the events or actions of the actors.
OMT differs from CRCs in the way the system is viewed. Apart from viewing the systems as classes and responsibilities, OMT provides a richer way to view and design the system using the 3 models as described above.

== Booch Method of OOAD ==

Booch Method is a process and notation for developing and communicating the design of an object-oriented software system. Booch method contains proven heuristics for developing quality software that provides effective design and support for development of future systems.
Booch method is a broad methodology that addresses OOAD using object modeling, analysis modeling, application design, implementation design etc.

Booch method uses following types of diagrams to describe the design decisions that must be made when creating an Object-Oriented system.

Class Diagrams: Represents set of classes and class relationships

Class Specification is used to capture all the information about a class in text format. A class specification contains set of fields that define a class

Category Diagrams are used to group logically related classes in to meaningful collection.

State Transition Diagrams represents the dynamic behavior associated of the classes in the system

Object Diagrams show the existence of objects and their relationships in the logical model of the system.

Timing Diagram is a graph that augments an on object diagram to capture information about external events and timing of operations in the object diagram

Module Diagram is used to show the allocation of classes and objects to module in the physical design of the system.

Process Diagrams represents various process flows and their allocation to processors of the system

Subsystems represent the clusters of logically related modules

The analysis and design steps in Booch method will result in class diagrams, class specifications, object specifications, inheritance views, class category diagrams, architectural descriptions.

== Coad, Yourdon and Nicola OOAD ==

In Coad, Yourdon and Nicola method, OOA works with problem domain classes and objects and OOD focuses on human interaction, task management, and data management classes and objects. In this method, each class and its objects fit into one of the four components: human interaction component, problem domain component, task management component, data management component. They differ from traditional CRCs in a way that the approach revolves around the principles of managing complexity. Three most important principles to manage complexity are:

1. Pervading methods of organization – This is similar to how real world people organize the objects via differentiating objects based on attributes, forming a class of objects based on the features.

2. Categories of behavior – This concept is the basis for identifying the actions of an object

3. Personification – This gives a human characteristic to inanimate objects

== FUSION ==

Fusion method was developed by Object Oriented Design Group at Hewlett-Packard Laboratories, Bristol. The method builds on existing Booch, OMT, CRC and provides a direct route from requirements definition through to a programming language implementation.
The analysis phase of this method provides a declarative description of system behavior. The Object model describes the static structure of the objects in the problem domain and their interrelation. The Interface model describes the interface of a system and how the system interacts with the environment.

The design stage realizes the system behavior using various outputs as given below.

1. Object Interaction Graph and visibility graph shows how objects interact with each other to complete an operation that is defined in the interface model. Algorithms, classes and their attributes, method signatures are specified accompanying each object interaction graph. Visibility graph complements the Object Interaction graph as it shows how the references among various objects are implemented.

2. Class description captures the class interfaces, attributes, object reference attributes and method signatures

3. Inheritance Graphs are specified to capture the relationships between the objects that are working together.

= References =

Object Think - Common Sense Software Architecture by Simon Horwith on cfunited conference 2006

[http://www.informit.com/articles/article.aspx?p=25184&seqNum=4 Object Think: A Perspective on Objects by Mike Abney]

[http://net.educause.edu/ir/library/text/c95/c95-ps04.txt "OBJECT THINK" A Step toward Object Oriented Implementation]

[http://corfield.org/blog/index.cfm/do/blog.entry/entry/Object_Think Object Think]

Designing Object Oriented Software by Wirfs-Brock et al.

Object Analysis and Design : Description of Methods by Andrew T.F. Hutt

[http://students.cs.byu.edu/~pbiggs/survey.html A Survey of Object-Oriented Methods by Peter Biggs]

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-19T19:27:31Z

Tinydancer: /* OMT */

Topic : CRC cards are useful, but have some limitations. For example, they require that a group be present; it is sometimes hard to get a group together. One alternative technique is "Object Think." Compare CRC cards with Object Think and any other alternatives for the first stages of analysis and design.

= CRC Cards =

= Object Think =

Simon Horwith defines “Object Think” as an approach to Object Oriented Programming based on the practice of object personification.

Object Think represents a way to think of the domain model in terms of objects, which further helps in developing or designing classes. Object Think was suggested as a practical alternative to CRC cards in 1993 by Coad and Nicola. The primary benefit of Object Think is that unlike CRC cards, it can be done individually and no group is required.

In Object Think perspective, objects are modeled to carry out real world functions. Then the responsibilities are distributed across objects as part of the design. Object Think therefore helps to create an accurate domain model where every object in the domain model handles all of its own responsibilities. The advantage of this approach is that as the software system is initially designed, the designers might start with fewer objects carrying out many functionality. As the system grows over time, Object Think will lead to design a community of objects sharing those responsibilities.

Object Think also bridges the traditional process-oriented thinking with the object mindsets. For example, the real world scenario of communication translates to Messaging in the Object Oriented paradigm.

Object Think perceives Objects as independent entity performing actions and making decisions on its own. Mike Abney, in the article -"Object Think: A Perspective on Objects" suggests that an object's capability to act is one of its three categories of responsibilities: "whom I know," "what I do," and "what I know." Peter Coad and Edward Youdon (in Object-Oriented Analysis, 2nd ed., Prentice Hall, 1990) refers this to object's services. Although technically services refer to an operation or procedure, when an object performs the services they are viewed as actions on the objects. As an example, an account object provides a debit method. So, when the debit method is acted on the object, it is viewed as debit action being carried upon the object. This means the state of the object changes based on the action that is being performed on the object.

== Guidelines for Design Using Object Think ==

1. Everything in the domain model is an object. This means that a class technically cannot have free-floating functions that are not related to an object of the class. Functions generally represent the actions on an object or a concept in the domain model. So, they have to be associated with an object that represent the concept

2. Think like an Object

3. Model the objects of a system using the language of the domain model. This helps designers to focus on the domain model and design a system with a high level perspective instead of bogged down with low level implementation details.The purpose and capabilities of an object has to be designed and stated clearly. Also, the implementation should statisfy the stated goal.

4. Objects should have context free behavior - This really means that Objects should be designed with the object oriented principles like encapsulation, cohesion, coupling, reuse etc. and Objects should be modeled as autonomous agents that perform the operations in isolation.

5. Design using simulation - Simulating a domain model by representing it in terms of various objects will help to identify the details of the design.

6. Design to keep functions and data together - Domain model's operations can be represented as actions on objects. Since these operations affect the state of the object, it is a good practice to tie objects and their operations together.

== Benefits of Object Thinking ==

1. Unlike CRC, Object thinking can be carried out by individuals

2. Design using Object think provides a maintainable code as in a long run, a system will have objects sharing ther responsibilities and collaborating to complete a domain operation

3. Design using object think also results in a reusable code

4. Since Object Think insists on stating the purpose and capabilities of the objects, this will result in a better definition of data and the responsibility on the objects

5. Also, Object Think can be used as a platform to educate developers to become object oriented thinkers

= Alternatives to CRC Cards =
== Unified Modeling Language (UML) ==

UML is a visual language for specifying, constructing, and documenting the artifacts of systems.

Advantages of UML Diagram compared to CRC cards:
# You can use UML with all processes, throughout the development lifecycle, and across different implementation technologies.
# You can easily visualize the relationship between classes or objects.
# The complete structure of the system can be captured in one UML diagram, instead of several CRC cards.

== OMT ==
The Object Modeling technique combines three views of a system and hence three models are used for representing the views.

# Object Model – describes the static structure of the objects and their relationships in the system. This represents the concepts like attribute, operation, inheritance, association, aggregation etc.
# Dynamic Model – describes the aspects of the system that changes over time. This model explains the concepts like states, event, activity, etc.
# Functional Model – describes the data value transformations in a system. This model explains the concepts like process, data flow, and control flow, actor, etc.

During the analysis phase of the design, all these models are developed and delivered. Object Model Diagram provides a formal graphic notation for modeling objects, classes and their relationships with one another. State diagrams and Event flow diagrams will represent the dynamic model of the system. Data flow diagram represents the data transformation within the system due to the events or actions of the actors.
OMT differs from CRCs in the way the system is viewed. Apart from viewing the systems as classes and responsibilities, OMT provides a richer way to view and design the system using the 3 models as described above.

== Booch Method of OOAD ==

Booch Method is a process and notation for developing and communicating the design of an object-oriented software system. Booch method contains proven heuristics for developing quality software that provides effective design and support for development of future systems.
Booch method is a broad methodology that addresses OOAD using object modeling, analysis modeling, application design, implementation design etc.

Booch method uses following types of diagrams to describe the design decisions that must be made when creating an Object-Oriented system.

Class Diagrams: Represents set of classes and class relationships

Class Specification is used to capture all the information about a class in text format. A class specification contains set of fields that define a class

Category Diagrams are used to group logically related classes in to meaningful collection.

State Transition Diagrams represents the dynamic behavior associated of the classes in the system

Object Diagrams show the existence of objects and their relationships in the logical model of the system.

Timing Diagram is a graph that augments an on object diagram to capture information about external events and timing of operations in the object diagram

Module Diagram is used to show the allocation of classes and objects to module in the physical design of the system.

Process Diagrams represents various process flows and their allocation to processors of the system

Subsystems represent the clusters of logically related modules

The analysis and design steps in Booch method will result in class diagrams, class specifications, object specifications, inheritance views, class category diagrams, architectural descriptions.

== Coad, Yourdon and Nicola OOAD ==

In Coad, Yourdon and Nicola method, OOA works with problem domain classes and objects and OOD focuses on human interaction, task management, and data management classes and objects. In this method, each class and its objects fit into one of the four components: human interaction component, problem domain component, task management component, data management component. They differ from traditional CRCs in a way that the approach revolves around the principles of managing complexity. Three most important principles to manage complexity are:

1. Pervading methods of organization – This is similar to how real world people organize the objects via differentiating objects based on attributes, forming a class of objects based on the features.

2. Categories of behavior – This concept is the basis for identifying the actions of an object

3. Personification – This gives a human characteristic to inanimate objects

== FUSION ==

Fusion method was developed by Object Oriented Design Group at Hewlett-Packard Laboratories, Bristol. The method builds on existing Booch, OMT, CRC and provides a direct route from requirements definition through to a programming language implementation.
The analysis phase of this method provides a declarative description of system behavior. The Object model describes the static structure of the objects in the problem domain and their interrelation. The Interface model describes the interface of a system and how the system interacts with the environment.

The design stage realizes the system behavior using various outputs as given below.

1. Object Interaction Graph and visibility graph shows how objects interact with each other to complete an operation that is defined in the interface model. Algorithms, classes and their attributes, method signatures are specified accompanying each object interaction graph. Visibility graph complements the Object Interaction graph as it shows how the references among various objects are implemented.

2. Class description captures the class interfaces, attributes, object reference attributes and method signatures

3. Inheritance Graphs are specified to capture the relationships between the objects that are working together.

= References =

Object Think - Common Sense Software Architecture by Simon Horwith on cfunited conference 2006

[http://www.informit.com/articles/article.aspx?p=25184&seqNum=4 Object Think: A Perspective on Objects by Mike Abney]

[http://net.educause.edu/ir/library/text/c95/c95-ps04.txt "OBJECT THINK" A Step toward Object Oriented Implementation]

[http://corfield.org/blog/index.cfm/do/blog.entry/entry/Object_Think Object Think]

Designing Object Oriented Software by Wirfs-Brock et al.

Object Analysis and Design : Description of Methods by Andrew T.F. Hutt

[http://students.cs.byu.edu/~pbiggs/survey.html A Survey of Object-Oriented Methods by Peter Biggs]

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-19T19:27:16Z

Tinydancer: /* OMT */

Topic : CRC cards are useful, but have some limitations. For example, they require that a group be present; it is sometimes hard to get a group together. One alternative technique is "Object Think." Compare CRC cards with Object Think and any other alternatives for the first stages of analysis and design.

= CRC Cards =

= Object Think =

Simon Horwith defines “Object Think” as an approach to Object Oriented Programming based on the practice of object personification.

Object Think represents a way to think of the domain model in terms of objects, which further helps in developing or designing classes. Object Think was suggested as a practical alternative to CRC cards in 1993 by Coad and Nicola. The primary benefit of Object Think is that unlike CRC cards, it can be done individually and no group is required.

In Object Think perspective, objects are modeled to carry out real world functions. Then the responsibilities are distributed across objects as part of the design. Object Think therefore helps to create an accurate domain model where every object in the domain model handles all of its own responsibilities. The advantage of this approach is that as the software system is initially designed, the designers might start with fewer objects carrying out many functionality. As the system grows over time, Object Think will lead to design a community of objects sharing those responsibilities.

Object Think also bridges the traditional process-oriented thinking with the object mindsets. For example, the real world scenario of communication translates to Messaging in the Object Oriented paradigm.

Object Think perceives Objects as independent entity performing actions and making decisions on its own. Mike Abney, in the article -"Object Think: A Perspective on Objects" suggests that an object's capability to act is one of its three categories of responsibilities: "whom I know," "what I do," and "what I know." Peter Coad and Edward Youdon (in Object-Oriented Analysis, 2nd ed., Prentice Hall, 1990) refers this to object's services. Although technically services refer to an operation or procedure, when an object performs the services they are viewed as actions on the objects. As an example, an account object provides a debit method. So, when the debit method is acted on the object, it is viewed as debit action being carried upon the object. This means the state of the object changes based on the action that is being performed on the object.

== Guidelines for Design Using Object Think ==

1. Everything in the domain model is an object. This means that a class technically cannot have free-floating functions that are not related to an object of the class. Functions generally represent the actions on an object or a concept in the domain model. So, they have to be associated with an object that represent the concept

2. Think like an Object

3. Model the objects of a system using the language of the domain model. This helps designers to focus on the domain model and design a system with a high level perspective instead of bogged down with low level implementation details.The purpose and capabilities of an object has to be designed and stated clearly. Also, the implementation should statisfy the stated goal.

4. Objects should have context free behavior - This really means that Objects should be designed with the object oriented principles like encapsulation, cohesion, coupling, reuse etc. and Objects should be modeled as autonomous agents that perform the operations in isolation.

5. Design using simulation - Simulating a domain model by representing it in terms of various objects will help to identify the details of the design.

6. Design to keep functions and data together - Domain model's operations can be represented as actions on objects. Since these operations affect the state of the object, it is a good practice to tie objects and their operations together.

== Benefits of Object Thinking ==

1. Unlike CRC, Object thinking can be carried out by individuals

2. Design using Object think provides a maintainable code as in a long run, a system will have objects sharing ther responsibilities and collaborating to complete a domain operation

3. Design using object think also results in a reusable code

4. Since Object Think insists on stating the purpose and capabilities of the objects, this will result in a better definition of data and the responsibility on the objects

5. Also, Object Think can be used as a platform to educate developers to become object oriented thinkers

= Alternatives to CRC Cards =
== Unified Modeling Language (UML) ==

UML is a visual language for specifying, constructing, and documenting the artifacts of systems.

Advantages of UML Diagram compared to CRC cards:
# You can use UML with all processes, throughout the development lifecycle, and across different implementation technologies.
# You can easily visualize the relationship between classes or objects.
# The complete structure of the system can be captured in one UML diagram, instead of several CRC cards.

== OMT ==
The Object Modeling technique combines three views of a system and hence three models are used for representing the views.

# Object Model – describes the static structure of the objects and their relationships in the system. This represents the concepts like attribute, operation, inheritance, association, aggregation etc.

# Dynamic Model – describes the aspects of the system that changes over time. This model explains the concepts like states, event, activity etc

# Functional Model – describes the data value transformations in a system. This model explains the concepts like process, data flow, and control flow, actor etc.

During the analysis phase of the design, all these models are developed and delivered. Object Model Diagram provides a formal graphic notation for modeling objects, classes and their relationships with one another. State diagrams and Event flow diagrams will represent the dynamic model of the system. Data flow diagram represents the data transformation within the system due to the events or actions of the actors.
OMT differs from CRCs in the way the system is viewed. Apart from viewing the systems as classes and responsibilities, OMT provides a richer way to view and design the system using the 3 models as described above.

== Booch Method of OOAD ==

Booch Method is a process and notation for developing and communicating the design of an object-oriented software system. Booch method contains proven heuristics for developing quality software that provides effective design and support for development of future systems.
Booch method is a broad methodology that addresses OOAD using object modeling, analysis modeling, application design, implementation design etc.

Booch method uses following types of diagrams to describe the design decisions that must be made when creating an Object-Oriented system.

Class Diagrams: Represents set of classes and class relationships

Class Specification is used to capture all the information about a class in text format. A class specification contains set of fields that define a class

Category Diagrams are used to group logically related classes in to meaningful collection.

State Transition Diagrams represents the dynamic behavior associated of the classes in the system

Object Diagrams show the existence of objects and their relationships in the logical model of the system.

Timing Diagram is a graph that augments an on object diagram to capture information about external events and timing of operations in the object diagram

Module Diagram is used to show the allocation of classes and objects to module in the physical design of the system.

Process Diagrams represents various process flows and their allocation to processors of the system

Subsystems represent the clusters of logically related modules

The analysis and design steps in Booch method will result in class diagrams, class specifications, object specifications, inheritance views, class category diagrams, architectural descriptions.

== Coad, Yourdon and Nicola OOAD ==

In Coad, Yourdon and Nicola method, OOA works with problem domain classes and objects and OOD focuses on human interaction, task management, and data management classes and objects. In this method, each class and its objects fit into one of the four components: human interaction component, problem domain component, task management component, data management component. They differ from traditional CRCs in a way that the approach revolves around the principles of managing complexity. Three most important principles to manage complexity are:

1. Pervading methods of organization – This is similar to how real world people organize the objects via differentiating objects based on attributes, forming a class of objects based on the features.

2. Categories of behavior – This concept is the basis for identifying the actions of an object

3. Personification – This gives a human characteristic to inanimate objects

== FUSION ==

Fusion method was developed by Object Oriented Design Group at Hewlett-Packard Laboratories, Bristol. The method builds on existing Booch, OMT, CRC and provides a direct route from requirements definition through to a programming language implementation.
The analysis phase of this method provides a declarative description of system behavior. The Object model describes the static structure of the objects in the problem domain and their interrelation. The Interface model describes the interface of a system and how the system interacts with the environment.

The design stage realizes the system behavior using various outputs as given below.

1. Object Interaction Graph and visibility graph shows how objects interact with each other to complete an operation that is defined in the interface model. Algorithms, classes and their attributes, method signatures are specified accompanying each object interaction graph. Visibility graph complements the Object Interaction graph as it shows how the references among various objects are implemented.

2. Class description captures the class interfaces, attributes, object reference attributes and method signatures

3. Inheritance Graphs are specified to capture the relationships between the objects that are working together.

= References =

Object Think - Common Sense Software Architecture by Simon Horwith on cfunited conference 2006

[http://www.informit.com/articles/article.aspx?p=25184&seqNum=4 Object Think: A Perspective on Objects by Mike Abney]

[http://net.educause.edu/ir/library/text/c95/c95-ps04.txt "OBJECT THINK" A Step toward Object Oriented Implementation]

[http://corfield.org/blog/index.cfm/do/blog.entry/entry/Object_Think Object Think]

Designing Object Oriented Software by Wirfs-Brock et al.

Object Analysis and Design : Description of Methods by Andrew T.F. Hutt

[http://students.cs.byu.edu/~pbiggs/survey.html A Survey of Object-Oriented Methods by Peter Biggs]

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-19T15:47:45Z

Tinydancer: /* Unified Modeling Language (UML) */

Topic : CRC cards are useful, but have some limitations. For example, they require that a group be present; it is sometimes hard to get a group together. One alternative technique is "Object Think." Compare CRC cards with Object Think and any other alternatives for the first stages of analysis and design.

= CRC Cards =

= Object Think =

Simon Horwith defines “Object Think” as an approach to Object Oriented Programming based on the practice of object personification.

Object Think represents a way to think of the domain model in terms of objects, which further helps in developing or designing classes. Object Think was suggested as a practical alternative to CRC cards in 1993 by Coad and Nicola. The primary benefit of Object Think is that unlike CRC cards, it can be done individually and no group is required.

In Object Think perspective, objects are modeled to carry out real world functions. Then the responsibilities are distributed across objects as part of the design. Object Think therefore helps to create an accurate domain model where every object in the domain model handles all of its own responsibilities. The advantage of this approach is that as the software system is initially designed, the designers might start with fewer objects carrying out many functionality. As the system grows over time, Object Think will lead to design a community of objects sharing those responsibilities.

Object Think also bridges the traditional process-oriented thinking with the object mindsets. For example, the real world scenario of communication translates to Messaging in the Object Oriented paradigm.

Object Think perceives Objects as independent entity performing actions and making decisions on its own. Mike Abney, in the article -"Object Think: A Perspective on Objects" suggests that an object's capability to act is one of its three categories of responsibilities: "whom I know," "what I do," and "what I know." Peter Coad and Edward Youdon (in Object-Oriented Analysis, 2nd ed., Prentice Hall, 1990) refers this to object's services. Although technically services refer to an operation or procedure, when an object performs the services they are viewed as actions on the objects. As an example, an account object provides a debit method. So, when the debit method is acted on the object, it is viewed as debit action being carried upon the object. This means the state of the object changes based on the action that is being performed on the object.

== Guidelines for Design Using Object Think ==

1. Everything in the domain model is an object. This means that a class technically cannot have free-floating functions that are not related to an object of the class. Functions generally represent the actions on an object or a concept in the domain model. So, they have to be associated with an object that represent the concept

2. Think like an Object

3. Model the objects of a system using the language of the domain model. This helps designers to focus on the domain model and design a system with a high level perspective instead of bogged down with low level implementation details.The purpose and capabilities of an object has to be designed and stated clearly. Also, the implementation should statisfy the stated goal.

4. Objects should have context free behavior - This really means that Objects should be designed with the object oriented principles like encapsulation, cohesion, coupling, reuse etc. and Objects should be modeled as autonomous agents that perform the operations in isolation.

5. Design using simulation - Simulating a domain model by representing it in terms of various objects will help to identify the details of the design.

6. Design to keep functions and data together - Domain model's operations can be represented as actions on objects. Since these operations affect the state of the object, it is a good practice to tie objects and their operations together.

== Benefits of Object Thinking ==

1. Unlike CRC, Object thinking can be carried out by individuals

2. Design using Object think provides a maintainable code as in a long run, a system will have objects sharing ther responsibilities and collaborating to complete a domain operation

3. Design using object think also results in a reusable code

4. Since Object Think insists on stating the purpose and capabilities of the objects, this will result in a better definition of data and the responsibility on the objects

5. Also, Object Think can be used as a platform to educate developers to become object oriented thinkers

= Alternatives to CRC Cards =
== Unified Modeling Language (UML) ==

UML is a visual language for specifying, constructing, and documenting the artifacts of systems.

Advantages of UML Diagram compared to CRC cards:
# You can use UML with all processes, throughout the development lifecycle, and across different implementation technologies.
# You can easily visualize the relationship between classes or objects.
# The complete structure of the system can be captured in one UML diagram, instead of several CRC cards.

== OMT ==
The Object Modeling technique combines three views of a system and hence three models are used for representing the views.

1. Object Model – describes the static structure of the objects and their relationships in the system. This represents the concepts like attribute, operation, inheritance, association, aggregation etc.

2. Dynamic Model – describes the aspects of the system that changes over time. This model explains the concepts like states, event, activity etc

3. Functional Model – describes the data value transformations in a system. This model explains the concepts like process, data flow, and control flow, actor etc.

During the analysis phase of the design, all these models are developed and delivered. Object Model Diagram provides a formal graphic notation for modeling objects, classes and their relationships with one another. State diagrams and Event flow diagrams will represent the dynamic model of the system. Data flow diagram represents the data transformation within the system due to the events or actions of the actors.
OMT differs from CRCs in the way the system is viewed. Apart from viewing the systems as classes and responsibilities, OMT provides a richer way to view and design the system using the 3 models as described above.

== Booch Method of OOAD ==

Booch Method is a process and notation for developing and communicating the design of an object-oriented software system. Booch method contains proven heuristics for developing quality software that provides effective design and support for development of future systems.
Booch method is a broad methodology that addresses OOAD using object modeling, analysis modeling, application design, implementation design etc.

Booch method uses following types of diagrams to describe the design decisions that must be made when creating an Object-Oriented system.

Class Diagrams: Represents set of classes and class relationships

Class Specification is used to capture all the information about a class in text format. A class specification contains set of fields that define a class

Category Diagrams are used to group logically related classes in to meaningful collection.

State Transition Diagrams represents the dynamic behavior associated of the classes in the system

Object Diagrams show the existence of objects and their relationships in the logical model of the system.

Timing Diagram is a graph that augments an on object diagram to capture information about external events and timing of operations in the object diagram

Module Diagram is used to show the allocation of classes and objects to module in the physical design of the system.

Process Diagrams represents various process flows and their allocation to processors of the system

Subsystems represent the clusters of logically related modules

The analysis and design steps in Booch method will result in class diagrams, class specifications, object specifications, inheritance views, class category diagrams, architectural descriptions.

== Coad, Yourdon and Nicola OOAD ==

In Coad, Yourdon and Nicola method, OOA works with problem domain classes and objects and OOD focuses on human interaction, task management, and data management classes and objects. In this method, each class and its objects fit into one of the four components: human interaction component, problem domain component, task management component, data management component. They differ from traditional CRCs in a way that the approach revolves around the principles of managing complexity. Three most important principles to manage complexity are:

1. Pervading methods of organization – This is similar to how real world people organize the objects via differentiating objects based on attributes, forming a class of objects based on the features.

2. Categories of behavior – This concept is the basis for identifying the actions of an object

3. Personification – This gives a human characteristic to inanimate objects

== FUSION ==

Fusion method was developed by Object Oriented Design Group at Hewlett-Packard Laboratories, Bristol. The method builds on existing Booch, OMT, CRC and provides a direct route from requirements definition through to a programming language implementation.
The analysis phase of this method provides a declarative description of system behavior. The Object model describes the static structure of the objects in the problem domain and their interrelation. The Interface model describes the interface of a system and how the system interacts with the environment.

The design stage realizes the system behavior using various outputs as given below.

1. Object Interaction Graph and visibility graph shows how objects interact with each other to complete an operation that is defined in the interface model. Algorithms, classes and their attributes, method signatures are specified accompanying each object interaction graph. Visibility graph complements the Object Interaction graph as it shows how the references among various objects are implemented.

2. Class description captures the class interfaces, attributes, object reference attributes and method signatures

3. Inheritance Graphs are specified to capture the relationships between the objects that are working together.

= References =

Object Think - Common Sense Software Architecture by Simon Horwith on cfunited conference 2006

[http://www.informit.com/articles/article.aspx?p=25184&seqNum=4 Object Think: A Perspective on Objects by Mike Abney]

[http://net.educause.edu/ir/library/text/c95/c95-ps04.txt "OBJECT THINK" A Step toward Object Oriented Implementation]

[http://corfield.org/blog/index.cfm/do/blog.entry/entry/Object_Think Object Think]

Designing Object Oriented Software by Wirfs-Brock et al.

Object Analysis and Design : Description of Methods by Andrew T.F. Hutt

[http://students.cs.byu.edu/~pbiggs/survey.html A Survey of Object-Oriented Methods by Peter Biggs]

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-19T00:26:54Z

Tinydancer:

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-19T00:25:15Z

Tinydancer: /* Guildelines for design using Object Thinking */

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-19T00:24:33Z

Tinydancer:

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-19T00:20:33Z

Tinydancer:

Report for View (Testing)

2009-10-26T23:04:06Z

Tinydancer: /* No “Semi Year” option under “Budget Period Type” (Should this Model?) */

'''View Analysis and Testing'''

== Testing ==
=== Testing Strategy ===
==== Testing method ====
:*Interactive (manual)
==== Testing Scenario ====
:*Complete Story
:*Split focused
:*Testing matrix

=== Planned Tests ===

=== Tests Done===

== View Analysis (Based on tests) ==

== View Changes ==
=== Planned Changes ===
#Commit Button
#"+", "-" => "Add", "Remove" or icons
#non-purpose? square in transaction dialog
=== Changes Made ===

== Appendix ==
=== Test Cases ===
==== Adding first child to existing category does not create an object tree icon (plus sign)====
Descriptions:
# Under My Budget, highlight one of the existing category.
# Select Edit -> Create new category.
# Create a name for the new category and select one of the existing categories as the parent.
# Select “OK”.

Expected behavior:
The parent category should have an object tree icon (plus sign) to show that it has children categories under it.

Actual behavior:
Notice that the parent category does not have an object tree icon (plus sign) next to it. You will have to either highlight the category or switch view from Buddi and come back.

==== Remaining amount for split is shown on the text box instead of written below the box ====
Descriptions:
# Select split (add details later)

Expected behavior:
Text box for amount is automatically filled with the remaining amount shown below the box.

Actual behavior:
Default amount is set to $0

==== Remaining amount for split transaction is negative ====
Descriptions:
# Select split (add details later)

Expected behavior:
User should be notified that the value inserted is incorrect or that the maximum value should be less than or equal to a certain number.

Actual behavior:
“Save” button is grayed out and user has to figure out what went wrong.

CSC/ECE 517 Fall 2009/program2 buddi wn

2009-10-26T19:45:30Z

Tinydancer: /* Important Information */

'''Buddi Project'''

== Important Information ==
* Submission: October 26 (Monday)
* First Feedback: October 30 (Friday)
* Resubmission: November 6 (Friday)
* Final Review: November 9 (Monday)
* Metareview: November 11 (Wednesday)

E-mail for Buddi questions:
wyatt@digitalcave.ca or wyatt.olson+buddi-ncsu@gmail.com.

=== Required Results ===

This project is more about QA and usability testing, rather than pure
development. While some coding may be required to enhance the view
layer, the vast majority of the code written will be in JUnit tests.
The following is required for your results:
# A '''.zip or .tgz archive''' containing the entire Buddi project (or at a minimum, all files which have changed OR a .diff of your changes, as you desire).
# A '''written report ([[Written Report on Model %28Testing%29|Model]]) on the model testing''', indicating what your unit tests test (paying attention to edge cases where problems are more likely to occur) and the results of these tests. (The actual unit tests themselves will be included in the archive in part a)
# A w'''ritten report ([[Written Report on View %28Testing%29|View]]) on the view testing''', indicating what tests you performed, and what the results were. Screenshots taken throughout the test procedure are optional, but a very good idea to demonstrate what problems (if any) you have found.
# '''A written report on what changes''' you have made to the view (or the model) as a result of your testing. If there were failures or potential improvements discovered in either your tests, this report should include a re-run of the failed tests, showing that they are now working.

== Objectives ==

=== Functionality ===
* Verify that '''splits''' in the data model have been implemented correctly. Ensure that the API wrapper functions allow transparent access to the model. Ensure that there are no edge cases where data corruption occurs.
* Refine and complete the '''view layer''', and verify that it works as desired in all cases.

=== Testing ===
* Verify Model using JUnit.
There are already some model and API tests in the junit source folder - you can use these as a basis for creating more. You should construct some tests to only test the model, others to test the plugin API, and still others to verify that changes written to the API are accessible to the model (and vice-versa).

Be sure to test the edge cases and exceptional input, for instance:
what happens if you try to split a transaction 1000 ways?
What happens if you try to include 0 splits?
What happens when you try to pass null to various setter methods?

* Verify UI
Using your understanding gained from the model tests, you must construct written documents detailing what tests you are planning on doing, and how you plan to go about them. You must then carry out these tests, and document the results. In addition to data integrity, the view tests should include a usability component - is the way which split transactions are expressed intuitive? Are there better ways to do this?

== Bugs or Undesired Behaviors ==

{| class="wikitable" border="1"
|-
! Title
! Details
! Actual Behavior
! Expected Behavior
! Solved
|-valign="top"
| Default Amount for split
| The default amount is not set to the difference automatically for the new split
| Currently, default amount is set to zero
| The remaining split amount represents the remaining balance among the splits
| No
|-valign="top"
| Category drop down
| Category list not filtered
| Some items (credit, cash) are not selectable when selecting a split source.
| If it's not available for selection, then better take them off the list
| No
|-valign="top"
| Split From Source
| Transaction involves split from sources didn't show the split when selected
| It shows <From> in an unselected mode
| Should show "split" entry with "..." button surfaced
| No
|-valign="top"
| Create New menu
| Undesired behavior. Create new options shouldn't be put under ''Edit'' menu. It's not intuitive for new users.
| Under My Accounts tab, Edit -> Create Account.
Under My Budget tab, Edit -> Create Budget Category.
| Several options:
# Move to under File menu
# Create button for "New Account" and "New Budget Category"
| No
|-valign="top"
| Create Budget Category using existing category as parent
| From "My Budget" tab, "Edit" -> "Create Budget Category" -> create new category and choose one of the parents that does not have any children yet -> "OK".
| Parent does not have + sign next to its name. It will only show up when you highlight parent's row or switch view from Buddi and come back.
| Parent's name should have "+" sign next to it right after child creation.
| No
|-valign="top"
|
|
|
|
| No
|}

== References ==

* [[Unit Test for Buddi]]
* [[Buddi Existing Test code]]

== Useful Links ==
# [http://devel.buddi.digitalcave.ca/en/ Buddi docs for Developers]
# [http://buddi.digitalcave.ca/ Buddi docs for Users]

CSC/ECE 517 Fall 2009/program2 buddi wn

2009-10-23T00:09:04Z

Tinydancer: /* Bugs or Undesired Behaviors */

'''Buddi Project'''

== Important Information ==
* Submission: October 23 (Friday)
* First Feedback: October 30 (Friday)
* Resubmission: November 6 (Friday)
* Final Review: November 9 (Monday)
* Metareview: November 11 (Wednesday)

E-mail for Buddi questions:
wyatt@digitalcave.ca or wyatt.olson+buddi-ncsu@gmail.com.

=== Required Results ===

This project is more about QA and usability testing, rather than pure
development. While some coding may be required to enhance the view
layer, the vast majority of the code written will be in JUnit tests.
The following is required for your results:
# A '''.zip or .tgz archive''' containing the entire Buddi project (or at a minimum, all files which have changed OR a .diff of your changes, as you desire).
# A '''written report ([[Written Report on Model %28Testing%29|W]]) on the model testing''', indicating what your unit tests test (paying attention to edge cases where problems are more likely to occur) and the results of these tests. (The actual unit tests themselves will be included in the archive in part a)
# A w'''ritten report ([[Written Report on View %28Testing%29|W]]) on the view testing''', indicating what tests you performed, and what the results were. Screenshots taken throughout the test procedure are optional, but a very good idea to demonstrate what problems (if any) you have found.
# '''A written report on what changes''' you have made to the view (or the model) as a result of your testing. If there were failures or potential improvements discovered in either your tests, this report should include a re-run of the failed tests, showing that they are now working.

== Objectives ==

=== Functionality ===
* Verify that '''splits''' in the data model have been implemented correctly. Ensure that the API wrapper functions allow transparent access to the model. Ensure that there are no edge cases where data corruption occurs.
* Refine and complete the '''view layer''', and verify that it works as desired in all cases.

=== Testing ===
* Verify Model using JUnit.
There are already some model and API tests in the junit source folder - you can use these as a basis for creating more. You should construct some tests to only test the model, others to test the plugin API, and still others to verify that changes written to the API are accessible to the model (and vice-versa).

Be sure to test the edge cases and exceptional input, for instance:
what happens if you try to split a transaction 1000 ways?
What happens if you try to include 0 splits?
What happens when you try to pass null to various setter methods?

* Verify UI
Using your understanding gained from the model tests, you must construct written documents detailing what tests you are planning on doing, and how you plan to go about them. You must then carry out these tests, and document the results. In addition to data integrity, the view tests should include a usability component - is the way which split transactions are expressed intuitive? Are there better ways to do this?

== Bugs or Undesired Behaviors ==

{| class="wikitable" border="1"
|-
! Title
! Details
! Actual Behavior
! Expected Behavior
! Solved
|-valign="top"
| Default Amount for split
| The default amount is not set to the difference automatically for the new split
| Currently, default amount is set to zero
| The remaining split amount represents the remaining balance among the splits
| No
|-valign="top"
| Category drop down
| Category list not filtered
| Some items (credit, cash) are not selectable when selecting a split source.
| If it's not available for selection, then better take them off the list
| No
|-valign="top"
| Split From Source
| Transaction involves split from sources didn't show the split when selected
| It shows <From> in an unselected mode
| Should show "split" entry with "..." button surfaced
| No
|-valign="top"
| Create New menu
| Undesired behavior. Create new options shouldn't be put under ''Edit'' menu. It's not intuitive for new users.
| Under My Accounts tab, Edit -> Create Account.
Under My Budget tab, Edit -> Create Budget Category.
| Several options:
# Move to under File menu
# Create button for "New Account" and "New Budget Category"
| No
|-valign="top"
| Create Budget Category using existing category as parent
| From "My Budget" tab, "Edit" -> "Create Budget Category" -> create new category and choose one of the parents that does not have any children yet -> "OK".
| Parent does not have + sign next to its name. It will only show up when you highlight parent's row or switch view from Buddi and come back.
| Parent's name should have "+" sign next to it right after child creation.
| No
|-valign="top"
|
|
|
|
| No
|}

== References ==

* [[Unit Test for Buddi]]
* [[Buddi Existing Test code]]

== Useful Links ==
# [http://devel.buddi.digitalcave.ca/en/ Buddi docs for Developers]
# [http://buddi.digitalcave.ca/ Buddi docs for Users]

Report for View (Testing)

2009-10-20T18:18:37Z

Tinydancer: /* Appendix */

Report for View (Testing)

2009-10-20T18:16:02Z

Tinydancer:

CSC/ECE 517 Fall 2009/program2 buddi wn

2009-10-19T05:21:32Z

Tinydancer: /* Bugs or Undesired Behaviors */

'''Buddi Project'''

== Important Information ==
* Submission: October 23 (Friday)
* First Feedback: October 30 (Friday)
* Resubmission: November 6 (Friday)
* Final Review: November 9 (Monday)
* Metareview: November 11 (Wednesday)

E-mail for Buddi questions:
wyatt@digitalcave.ca or wyatt.olson+buddi-ncsu@gmail.com.

=== Required Results ===

This project is more about QA and usability testing, rather than pure
development. While some coding may be required to enhance the view
layer, the vast majority of the code written will be in JUnit tests.
The following is required for your results:
# A '''.zip or .tgz archive''' containing the entire Buddi project (or at a minimum, all files which have changed OR a .diff of your changes, as you desire).
# A '''written report on the model testing''', indicating what your unit tests test (paying attention to edge cases where problems are more likely to occur) and the results of these tests. (The actual unit tests themselves will be included in the archive in part a)
# A w'''ritten report on the view testing''', indicating what tests you performed, and what the results were. Screenshots taken throughout the test procedure are optional, but a very good idea to demonstrate what problems (if any) you have found.
# '''A written report on what changes''' you have made to the view (or the model) as a result of your testing. If there were failures or potential improvements discovered in either your tests, this report should include a re-run of the failed tests, showing that they are now working.

== Objectives ==

=== Functionality ===
* Verify that '''splits''' in the data model have been implemented correctly. Ensure that the API wrapper functions allow transparent access to the model. Ensure that there are no edge cases where data corruption occurs.
* Refine and complete the '''view layer''', and verify that it works as desired in all cases.

=== Testing ===
* Verify Model using JUnit.
There are already some model and API tests in the junit source folder - you can use these as a basis for creating more. You should construct some tests to only test the model, others to test the plugin API, and still others to verify that changes written to the API are accessible to the model (and vice-versa).

Be sure to test the edge cases and exceptional input, for instance:
what happens if you try to split a transaction 1000 ways?
What happens if you try to include 0 splits?
What happens when you try to pass null to various setter methods?

* Verify UI
Using your understanding gained from the model tests, you must construct written documents detailing what tests you are planning on doing, and how you plan to go about them. You must then carry out these tests, and document the results. In addition to data integrity, the view tests should include a usability component - is the way which split transactions are expressed intuitive? Are there better ways to do this?

== Bugs or Undesired Behaviors ==

{| class="wikitable" border="1"
|-
! Title
! Details
! Actual Behavior
! Expected Behavior
! Solved
|-valign="top"
| Default Amount for split
| The default amount is not set to the difference automatically for the new split
| Currently, default amount is set to zero
| The remaining split amount represents the remaining balance among the splits
| No
|-valign="top"
| Category drop down
| Category list not filtered
| Some items (credit, cash) are not selectable when selecting a split source.
| If it's not available for selection, then better take them off the list
| No
|-valign="top"
| Split From Source
| Transaction involves split from sources didn't show the split when selected
| It shows <From> in an unselected mode
| Should show "split" entry with "..." button surfaced
| No
|-valign="top"
| ADDITIONAL FEATURE: Add Semi Year (twice a year) "Budget Period Type".
| From "My Budget" tab, "Edit" -> "Modify Budget Category" -> "Budget Period Type".
| No option for Semi Year
| Add the functionality
| No
|-valign="top"
| Create New menu
| Undesired behavior. Create new options shouldn't be put under ''Edit'' menu. It's not intuitive for new users.
| Under My Accounts tab, Edit -> Create Account.
Under My Budget tab, Edit -> Create Budget Category.
| Several options:
# Move to under File menu
# Create button for "New Account" and "New Budget Category"
| No
|-valign="top"
| Create Budget Category using existing category as parent
| From "My Budget" tab, "Edit" -> "Create Budget Category" -> create new category and choose one of the parents that does not have any children yet -> "OK".
| Parent does not have + sign next to its name. It will only show up when you highlight parent's row or switch view from Buddi and come back.
| Parent's name should have "+" sign next to it right after child creation.
| No
|-valign="top"
|
|
|
|
| No
|}

== References ==

* [[Unit Test for Buddi]]

== Useful Links ==
# [http://devel.buddi.digitalcave.ca/en/ Buddi docs for Developers]
# [http://buddi.digitalcave.ca/ Buddi docs for Users]

CSC/ECE 517 Fall 2009/program2 buddi wn

2009-10-19T02:40:11Z

Tinydancer: /* Bugs or Undesired Behaviors */

'''Buddi Project'''

== Important Information ==
* Submission: October 23 (Friday)
* First Feedback: October 30 (Friday)
* Resubmission: November 6 (Friday)
* Final Review: November 9 (Monday)
* Metareview: November 11 (Wednesday)

E-mail for Buddi questions:
wyatt@digitalcave.ca or wyatt.olson+buddi-ncsu@gmail.com.

=== Required Results ===

This project is more about QA and usability testing, rather than pure
development. While some coding may be required to enhance the view
layer, the vast majority of the code written will be in JUnit tests.
The following is required for your results:
# A '''.zip or .tgz archive''' containing the entire Buddi project (or at a minimum, all files which have changed OR a .diff of your changes, as you desire).
# A '''written report on the model testing''', indicating what your unit tests test (paying attention to edge cases where problems are more likely to occur) and the results of these tests. (The actual unit tests themselves will be included in the archive in part a)
# A w'''ritten report on the view testing''', indicating what tests you performed, and what the results were. Screenshots taken throughout the test procedure are optional, but a very good idea to demonstrate what problems (if any) you have found.
# '''A written report on what changes''' you have made to the view (or the model) as a result of your testing. If there were failures or potential improvements discovered in either your tests, this report should include a re-run of the failed tests, showing that they are now working.

== Objectives ==

=== Functionality ===
* Verify that '''splits''' in the data model have been implemented correctly. Ensure that the API wrapper functions allow transparent access to the model. Ensure that there are no edge cases where data corruption occurs.
* Refine and complete the '''view layer''', and verify that it works as desired in all cases.

=== Testing ===
* Verify Model using JUnit.
There are already some model and API tests in the junit source folder - you can use these as a basis for creating more. You should construct some tests to only test the model, others to test the plugin API, and still others to verify that changes written to the API are accessible to the model (and vice-versa).

Be sure to test the edge cases and exceptional input, for instance:
what happens if you try to split a transaction 1000 ways?
What happens if you try to include 0 splits?
What happens when you try to pass null to various setter methods?

* Verify UI
Using your understanding gained from the model tests, you must construct written documents detailing what tests you are planning on doing, and how you plan to go about them. You must then carry out these tests, and document the results. In addition to data integrity, the view tests should include a usability component - is the way which split transactions are expressed intuitive? Are there better ways to do this?

== Bugs or Undesired Behaviors ==

{| class="wikitable" border="1"
|-
! Title
! Details
! Actual Behavior
! Expected Behavior
! Solved
|-valign="top"
| Create New menu
| Undesired behavior. Create new options shouldn't be put under ''Edit'' menu. It's not intuitive for new users.
| Under My Accounts tab, Edit -> Create Account.
Under My Budget tab, Edit -> Create Budget Category.
| Several options:
# Move to under File menu
# Create button for "New Account" and "New Budget Category"
| No
|-valign="top"
| Default Amount for split
| The default amount is not set to the difference automatically for the new split
| Currently default amount is set to zero
| The remaining split amount represents the remaining balance among the splits
| No
|-valign="top"
| Category drop down
| Category list not filtered
| Some items (credit, cash) are not selectable when selecting a split source.
| If it's not available for selection, then better take them off the list
| No
|-valign="top"
| Split From Source
| Transaction involves split from sources didn't show the split when selected
| It shows <From> in an unselected mode
| Should show "split" entry with "..." button surfaced
| No
|-valign="top"
| Create Budget Category using existing category as parent
| From "My Budget" tab, "Edit" -> "Create Budget Category" -> create new category and choose one of the parents that does not have any children yet -> "OK".
| Parent does not have + sign next to its name. It will only show up when you highlight parent's row or switch view from Buddi and come back.
| Parent's name should have "+" sign next to it right after child creation.
| No
|-valign="top"
| ADDITIONAL FEATURE: Add Semi Year (twice a year) "Budget Period Type".
| From "My Budget" tab, "Edit" -> "Modify Budget Category" -> "Budget Period Type".
| No option for Semi Year
| Add the functionality
| No
|-valign="top"
|
|
|
|
| No
|}

== References ==

* [[Unit Test for Buddi]]

== Useful Links ==
# [http://devel.buddi.digitalcave.ca/en/ Buddi docs for Developers]
# [http://buddi.digitalcave.ca/ Buddi docs for Users]

CSC/ECE 517 Fall 2009/program2 buddi wn

2009-10-19T02:40:00Z

Tinydancer: /* Bugs or Undesired Behaviors */

'''Buddi Project'''

== Important Information ==
* Submission: October 23 (Friday)
* First Feedback: October 30 (Friday)
* Resubmission: November 6 (Friday)
* Final Review: November 9 (Monday)
* Metareview: November 11 (Wednesday)

E-mail for Buddi questions:
wyatt@digitalcave.ca or wyatt.olson+buddi-ncsu@gmail.com.

=== Required Results ===

This project is more about QA and usability testing, rather than pure
development. While some coding may be required to enhance the view
layer, the vast majority of the code written will be in JUnit tests.
The following is required for your results:
# A '''.zip or .tgz archive''' containing the entire Buddi project (or at a minimum, all files which have changed OR a .diff of your changes, as you desire).
# A '''written report on the model testing''', indicating what your unit tests test (paying attention to edge cases where problems are more likely to occur) and the results of these tests. (The actual unit tests themselves will be included in the archive in part a)
# A w'''ritten report on the view testing''', indicating what tests you performed, and what the results were. Screenshots taken throughout the test procedure are optional, but a very good idea to demonstrate what problems (if any) you have found.
# '''A written report on what changes''' you have made to the view (or the model) as a result of your testing. If there were failures or potential improvements discovered in either your tests, this report should include a re-run of the failed tests, showing that they are now working.

== Objectives ==

=== Functionality ===
* Verify that '''splits''' in the data model have been implemented correctly. Ensure that the API wrapper functions allow transparent access to the model. Ensure that there are no edge cases where data corruption occurs.
* Refine and complete the '''view layer''', and verify that it works as desired in all cases.

=== Testing ===
* Verify Model using JUnit.
There are already some model and API tests in the junit source folder - you can use these as a basis for creating more. You should construct some tests to only test the model, others to test the plugin API, and still others to verify that changes written to the API are accessible to the model (and vice-versa).

Be sure to test the edge cases and exceptional input, for instance:
what happens if you try to split a transaction 1000 ways?
What happens if you try to include 0 splits?
What happens when you try to pass null to various setter methods?

* Verify UI
Using your understanding gained from the model tests, you must construct written documents detailing what tests you are planning on doing, and how you plan to go about them. You must then carry out these tests, and document the results. In addition to data integrity, the view tests should include a usability component - is the way which split transactions are expressed intuitive? Are there better ways to do this?

== Bugs or Undesired Behaviors ==

{| class="wikitable" border="1"
|-
! Title
! Details
! Actual Behavior
! Expected Behavior
! Solved
|-valign="top"
| Create New menu
| Undesired behavior. Create new options shouldn't be put under ''Edit'' menu. It's not intuitive for new users.
| Under My Accounts tab, Edit -> Create Account.
Under My Budget tab, Edit -> Create Budget Category.
| Several options:
# Move to under File menu
# Create button for "New Account" and "New Budget Category"
| No
|-valign="top"
| Default Amount for split
| The default amount is not set to the difference automatically for the new split
| Currently default amount is set to zero
| The remaining split amount represents the remaining balance among the splits
| No
|-valign="top"
| Category drop down
| Category list not filtered
| Some items (credit, cash) are not selectable when selecting a split source.
| If it's not available for selection, then better take them off the list
| No
|-valign="top"
| Split From Source
| Transaction involves split from sources didn't show the split when selected
| It shows <From> in an unselected mode
| Should show "split" entry with "..." button surfaced
| No
|-valign="top"
| Create Budget Category using existing category as parent
| From "My Budget" tab, "Edit" -> "Create Budget Category" -> create new category and choose one of the parents that does not have any children yet -> "OK".
| Parent does not have + sign next to its name. It will only show up when you highlight parent's row or switch view from Buddi and come back.
| Parent's name should have "+" sign next to it right after child creation.
| No
|-valign="top"
| ADDITIONAL FEATURE: Add Semi Year (twice a year) "Budget Period Type".
| From "My Budget" tab, "Edit" -> "Modify Budget Category" -> "Budget Period Type".
| No option for Semi Year
| Add the funtionality
| No
|-valign="top"
|
|
|
|
| No
|}

== References ==

* [[Unit Test for Buddi]]

== Useful Links ==
# [http://devel.buddi.digitalcave.ca/en/ Buddi docs for Developers]
# [http://buddi.digitalcave.ca/ Buddi docs for Users]

CSC/ECE 517 Fall 2009/program2 buddi wn

2009-10-19T02:30:19Z

Tinydancer: /* Bugs or Undesired Behaviors */

'''Buddi Project'''

== Important Information ==
* Submission: October 23 (Friday)
* First Feedback: October 30 (Friday)
* Resubmission: November 6 (Friday)
* Final Review: November 9 (Monday)
* Metareview: November 11 (Wednesday)

E-mail for Buddi questions:
wyatt@digitalcave.ca or wyatt.olson+buddi-ncsu@gmail.com.

=== Required Results ===

This project is more about QA and usability testing, rather than pure
development. While some coding may be required to enhance the view
layer, the vast majority of the code written will be in JUnit tests.
The following is required for your results:
# A '''.zip or .tgz archive''' containing the entire Buddi project (or at a minimum, all files which have changed OR a .diff of your changes, as you desire).
# A '''written report on the model testing''', indicating what your unit tests test (paying attention to edge cases where problems are more likely to occur) and the results of these tests. (The actual unit tests themselves will be included in the archive in part a)
# A w'''ritten report on the view testing''', indicating what tests you performed, and what the results were. Screenshots taken throughout the test procedure are optional, but a very good idea to demonstrate what problems (if any) you have found.
# '''A written report on what changes''' you have made to the view (or the model) as a result of your testing. If there were failures or potential improvements discovered in either your tests, this report should include a re-run of the failed tests, showing that they are now working.

== Objectives ==

=== Functionality ===
* Verify that '''splits''' in the data model have been implemented correctly. Ensure that the API wrapper functions allow transparent access to the model. Ensure that there are no edge cases where data corruption occurs.
* Refine and complete the '''view layer''', and verify that it works as desired in all cases.

=== Testing ===
* Verify Model using JUnit.
There are already some model and API tests in the junit source folder - you can use these as a basis for creating more. You should construct some tests to only test the model, others to test the plugin API, and still others to verify that changes written to the API are accessible to the model (and vice-versa).

Be sure to test the edge cases and exceptional input, for instance:
what happens if you try to split a transaction 1000 ways?
What happens if you try to include 0 splits?
What happens when you try to pass null to various setter methods?

* Verify UI
Using your understanding gained from the model tests, you must construct written documents detailing what tests you are planning on doing, and how you plan to go about them. You must then carry out these tests, and document the results. In addition to data integrity, the view tests should include a usability component - is the way which split transactions are expressed intuitive? Are there better ways to do this?

== Bugs or Undesired Behaviors ==

{| class="wikitable" border="1"
|-
! Title
! Details
! Actual Behavior
! Expected Behavior
! Solved
|-valign="top"
| Create New menu
| Undesired behavior. Create new options shouldn't be put under ''Edit'' menu. It's not intuitive for new users.
| Under My Accounts tab, Edit -> Create Account.
Under My Budget tab, Edit -> Create Budget Category.
| Several options:
# Move to under File menu
# Create button for "New Account" and "New Budget Category"
| No
|-valign="top"
| Default Amount for split
| The default amount is not set to the difference automatically for the new split
| Currently default amount is set to zero
| The remaining split amount represents the remaining balance among the splits
| No
|-valign="top"
| Category drop down
| Category list not filtered
| Some items (credit, cash) are not selectable when selecting a split source.
| If it's not available for selection, then better take them off the list
| No
|-valign="top"
| Split From Source
| Transaction involves split from sources didn't show the split when selected
| It shows <From> in an unselected mode
| Should show "split" entry with "..." button surfaced
| No
|-valign="top"
| Create Budget Category using existing category as parent
| From "My Budget" tab, "Edit" -> "Create Budget Category" -> create new category and choose one of the parents that does not have any children yet -> "OK".
| Parent does not have + sign next to its name. It will only show up when you highlight parent's row or switch view from Buddi and come back.
| Parent's name should have "+" sign next to it right after child creation.
| No
|-valign="top"
|
|
|
|
| No
|}

== References ==

* [[Unit Test for Buddi]]

== Useful Links ==
# [http://devel.buddi.digitalcave.ca/en/ Buddi docs for Developers]
# [http://buddi.digitalcave.ca/ Buddi docs for Users]

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-15T21:08:07Z

Tinydancer: /* References */

=Introduction=

[http://en.wikipedia.org/wiki/Ruby_language Ruby] offers more concise implementations of certain [http://en.wikipedia.org/wiki/Design_pattern design patterns] than [http://en.wikipedia.org/wiki/Java_language Java] does. We will look at some design patterns and compare the implementation in '''Ruby vs Java''' with the goal to answer the following:
* Is this typical of dynamic object-oriented languages?

* Are there design patterns that any [http://en.wikipedia.org/wiki/Dynamic_language dynamically typed language] can realize better than a [http://en.wikipedia.org/wiki/Type_system statically typed language]?

* Are there instances when a different pattern should be used in a dynamic language than a static language?

=Design Patterns in Java vs Ruby=

==Singleton Pattern==

[http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern] is a design pattern used to restrict the instantiation of the class to one object.

The implementation of the pattern involves:
* making the constructor private
* declare a instance variable
* implement a <code>getInstance</code> method and make the it thread safe.

Below is the comparison between singleton class written in Java and Ruby.

It is clear that Ruby provides a more concise way of implementing the singleton pattern. Ruby uses the singleton module which automatically provides all the functionality that we need to write manually in Java. By writing <code>include singleton</code> in Ruby, we prevent ourselves from having to repeat writing the same code for each class that we wish to make singleton. In contrast, we need to write the Java class below for every singleton objects we create.

'''Java'''

public class SingletonExample {
// declare instance variable
private static SingletonExample singletonEx;

// Make the constructor is private
private SingletonExample() {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonEx == null) {
singletonEx = new SingletonExample();
}
return singletonEx;
}
}

'''Ruby''' (using singleton module)

require singleton
class SingletonExample
include singleton
end

==Factory Pattern==
[http://en.wikipedia.org/wiki/Factory_pattern Factory pattern] is implemented by isolating the code to create an object from the concrete implementation of the class.

In '''Java''', we typically write a similar code as below:

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}

We can implement the same code skeleton in Ruby. However, there is no special classes or class methods in Ruby since it is a dynamic language. Instead, '''Ruby''' allows us to rename our factory method to be called new.

class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end

Our client class now becomes:

class ObjectUser
def doSomething(factory)
...
my_object = factory.new()
...
end
end

Ruby lets us redefine the new method and allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special <code>createObject</code> method.

==Iterator==
[http://en.wikipedia.org/wiki/Iterator_pattern Iterator pattern] is design pattern used to access the elements of an aggregate object sequentially without exposing its underlying representation.

In order to use Iterator pattern, we need:

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential object in the collection.

In Java, we will need to know the type of objects in the collection and cast them to the right type in order to use them. Whereas in Ruby, iterators are built right in.

Here are some examples that show the ease with which we can use iterators in Ruby:
* Iterates a block of code for each element in the <code>Array</code>

a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

* Iterates code for every line in a file

Thread.list.each { |t| print "Thread: #{t}\n" }

* Iterates code for all active threads

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

* Iterates code for each object in the system

open("data.txt").each_line { |line| print "The line is #{line}\n" }

=Conclusion=

Design pattern is a concept that applicable to solve problems regardless of the languages we use to implement the solution. So I cannot think of a case where a specific pattern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support meta-programming and reflection via Modules and Mixins and support extending/reopening classes and redefining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple <code>include Singleton</code> statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on solving the problem at hand rather than spending time implementing the design patterns.

=References=

* Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). [http://en.wikipedia.org/wiki/Design_patterns_book ''Design Patterns: Elements of Reusable Object-Oriented Software'']. Addison-Wesley. ISBN 0-201-63361-2.

* [http://p-cos.net/documents/dynatype.pdf Dynamic vs Static Typing -- A Pattern-based Analysis] by Pascal Costanza, March 13, 2004.

* Olsen, Russ (2007). [http://www.amazon.com/Design-Patterns-Ruby-Russ-Olsen/dp/0321490452 ''Design Patterns in Ruby'']. Addison-Wesley. ISBN 0-321-49045-2.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-15T21:07:50Z

Tinydancer: /* References */

=Introduction=

[http://en.wikipedia.org/wiki/Ruby_language Ruby] offers more concise implementations of certain [http://en.wikipedia.org/wiki/Design_pattern design patterns] than [http://en.wikipedia.org/wiki/Java_language Java] does. We will look at some design patterns and compare the implementation in '''Ruby vs Java''' with the goal to answer the following:
* Is this typical of dynamic object-oriented languages?

* Are there design patterns that any [http://en.wikipedia.org/wiki/Dynamic_language dynamically typed language] can realize better than a [http://en.wikipedia.org/wiki/Type_system statically typed language]?

* Are there instances when a different pattern should be used in a dynamic language than a static language?

=Design Patterns in Java vs Ruby=

==Singleton Pattern==

[http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern] is a design pattern used to restrict the instantiation of the class to one object.

The implementation of the pattern involves:
* making the constructor private
* declare a instance variable
* implement a <code>getInstance</code> method and make the it thread safe.

Below is the comparison between singleton class written in Java and Ruby.

It is clear that Ruby provides a more concise way of implementing the singleton pattern. Ruby uses the singleton module which automatically provides all the functionality that we need to write manually in Java. By writing <code>include singleton</code> in Ruby, we prevent ourselves from having to repeat writing the same code for each class that we wish to make singleton. In contrast, we need to write the Java class below for every singleton objects we create.

'''Java'''

public class SingletonExample {
// declare instance variable
private static SingletonExample singletonEx;

// Make the constructor is private
private SingletonExample() {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonEx == null) {
singletonEx = new SingletonExample();
}
return singletonEx;
}
}

'''Ruby''' (using singleton module)

require singleton
class SingletonExample
include singleton
end

==Factory Pattern==
[http://en.wikipedia.org/wiki/Factory_pattern Factory pattern] is implemented by isolating the code to create an object from the concrete implementation of the class.

In '''Java''', we typically write a similar code as below:

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}

We can implement the same code skeleton in Ruby. However, there is no special classes or class methods in Ruby since it is a dynamic language. Instead, '''Ruby''' allows us to rename our factory method to be called new.

class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end

Our client class now becomes:

class ObjectUser
def doSomething(factory)
...
my_object = factory.new()
...
end
end

Ruby lets us redefine the new method and allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special <code>createObject</code> method.

==Iterator==
[http://en.wikipedia.org/wiki/Iterator_pattern Iterator pattern] is design pattern used to access the elements of an aggregate object sequentially without exposing its underlying representation.

In order to use Iterator pattern, we need:

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential object in the collection.

In Java, we will need to know the type of objects in the collection and cast them to the right type in order to use them. Whereas in Ruby, iterators are built right in.

Here are some examples that show the ease with which we can use iterators in Ruby:
* Iterates a block of code for each element in the <code>Array</code>

a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

* Iterates code for every line in a file

Thread.list.each { |t| print "Thread: #{t}\n" }

* Iterates code for all active threads

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

* Iterates code for each object in the system

open("data.txt").each_line { |line| print "The line is #{line}\n" }

=Conclusion=

Design pattern is a concept that applicable to solve problems regardless of the languages we use to implement the solution. So I cannot think of a case where a specific pattern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support meta-programming and reflection via Modules and Mixins and support extending/reopening classes and redefining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple <code>include Singleton</code> statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on solving the problem at hand rather than spending time implementing the design patterns.

=References=

* Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). [http://en.wikipedia.org/wiki/Design_patterns_book ''Design Patterns: Elements of Reusable Object-Oriented Software'']. Addison-Wesley. ISBN 0-201-63361-2.

* [http://p-cos.net/documents/dynatype.pdf Dynamic vs Static Typing -- A Pattern-based Analysis] by Pascal Costanza, March 13, 2004.

* Olsen, Russ (2007). [http://www.amazon.com/Design-Patterns-Ruby-Russ-Olsen/dp/0321490452 Design Patterns in Ruby]. Addison-Wesley. ISBN 0-321-49045-2.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-15T19:41:00Z

Tinydancer: /* References */

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-15T19:38:27Z

Tinydancer: /* Iterator */

=Introduction=

[http://en.wikipedia.org/wiki/Ruby_language Ruby] offers more concise implementations of certain [http://en.wikipedia.org/wiki/Design_pattern design patterns] than [http://en.wikipedia.org/wiki/Java_language Java] does. We will look at some design patterns and compare the implementation in '''Ruby vs Java''' with the goal to answer the following:
* Is this typical of dynamic object-oriented languages?

* Are there design patterns that any [http://en.wikipedia.org/wiki/Dynamic_language dynamically typed language] can realize better than a [http://en.wikipedia.org/wiki/Type_system statically typed language]?

* Are there instances when a different pattern should be used in a dynamic language than a static language?

=Design Patterns in Java vs Ruby=

==Singleton Pattern==

[http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern] is a design pattern used to restrict the instantiation of the class to one object.

The implementation of the pattern involves:
* making the constructor private
* declare a instance variable
* implement a <code>getInstance</code> method and make the it thread safe.

Below is the comparison between singleton class written in Java and Ruby.

It is clear that Ruby provides a more concise way of implementing the singleton pattern. Ruby uses the singleton module which automatically provides all the functionality that we need to write manually in Java. By writing <code>include singleton</code> in Ruby, we prevent ourselves from having to repeat writing the same code for each class that we wish to make singleton. In contrast, we need to write the Java class below for every singleton objects we create.

'''Java'''

public class SingletonExample {
// declare instance variable
private static SingletonExample singletonEx;

// Make the constructor is private
private SingletonExample() {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonEx == null) {
singletonEx = new SingletonExample();
}
return singletonEx;
}
}

'''Ruby''' (using singleton module)

require singleton
class SingletonExample
include singleton
end

==Factory Pattern==
[http://en.wikipedia.org/wiki/Factory_pattern Factory pattern] is implemented by isolating the code to create an object from the concrete implementation of the class.

In '''Java''', we typically write a similar code as below:

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}

We can implement the same code skeleton in Ruby. However, there is no special classes or class methods in Ruby since it is a dynamic language. Instead, '''Ruby''' allows us to rename our factory method to be called new.

class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end

Our client class now becomes:

class ObjectUser
def doSomething(factory)
...
my_object = factory.new()
...
end
end

Ruby lets us redefine the new method and allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special <code>createObject</code> method.

==Iterator==
[http://en.wikipedia.org/wiki/Iterator_pattern Iterator pattern] is design pattern used to access the elements of an aggregate object sequentially without exposing its underlying representation.

In order to use Iterator pattern, we need:

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential object in the collection.

In Java, we will need to know the type of objects in the collection and cast them to the right type in order to use them. Whereas in Ruby, iterators are built right in.

Here are some examples that show the ease with which we can use iterators in Ruby:
* Iterates a block of code for each element in the <code>Array</code>

a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

* Iterates code for every line in a file

Thread.list.each { |t| print "Thread: #{t}\n" }

* Iterates code for all active threads

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

* Iterates code for each object in the system

open("data.txt").each_line { |line| print "The line is #{line}\n" }

=Conclusion=

Design pattern is a concept that applicable to solve problems regardless of the languages we use to implement the solution. So I cannot think of a case where a specific pattern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support meta-programming and reflection via Modules and Mixins and support extending/reopening classes and redefining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple <code>include Singleton</code> statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on solving the problem at hand rather than spending time implementing the design patterns.

=References=

* Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). [http://en.wikipedia.org/wiki/Design_patterns_book ''Design Patterns: Elements of Reusable Object-Oriented Software'']. Addison-Wesley. ISBN 0-201-63361-2.

* [http://designpatternsinruby.com/section01/article.html Design Patterns in Ruby] by Russ Olsen, February 27, 2006.

* [http://p-cos.net/documents/dynatype.pdf Dynamic vs Static Typing -- A Pattern-based Analysis] by Pascal Costanza, March 13, 2004.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-15T19:36:30Z

Tinydancer: /* Factory Pattern */

=Introduction=

[http://en.wikipedia.org/wiki/Ruby_language Ruby] offers more concise implementations of certain [http://en.wikipedia.org/wiki/Design_pattern design patterns] than [http://en.wikipedia.org/wiki/Java_language Java] does. We will look at some design patterns and compare the implementation in '''Ruby vs Java''' with the goal to answer the following:
* Is this typical of dynamic object-oriented languages?

* Are there design patterns that any [http://en.wikipedia.org/wiki/Dynamic_language dynamically typed language] can realize better than a [http://en.wikipedia.org/wiki/Type_system statically typed language]?

* Are there instances when a different pattern should be used in a dynamic language than a static language?

=Design Patterns in Java vs Ruby=

==Singleton Pattern==

[http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern] is a design pattern used to restrict the instantiation of the class to one object.

The implementation of the pattern involves:
* making the constructor private
* declare a instance variable
* implement a <code>getInstance</code> method and make the it thread safe.

Below is the comparison between singleton class written in Java and Ruby.

It is clear that Ruby provides a more concise way of implementing the singleton pattern. Ruby uses the singleton module which automatically provides all the functionality that we need to write manually in Java. By writing <code>include singleton</code> in Ruby, we prevent ourselves from having to repeat writing the same code for each class that we wish to make singleton. In contrast, we need to write the Java class below for every singleton objects we create.

'''Java'''

public class SingletonExample {
// declare instance variable
private static SingletonExample singletonEx;

// Make the constructor is private
private SingletonExample() {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonEx == null) {
singletonEx = new SingletonExample();
}
return singletonEx;
}
}

'''Ruby''' (using singleton module)

require singleton
class SingletonExample
include singleton
end

==Factory Pattern==
[http://en.wikipedia.org/wiki/Factory_pattern Factory pattern] is implemented by isolating the code to create an object from the concrete implementation of the class.

In '''Java''', we typically write a similar code as below:

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}

We can implement the same code skeleton in Ruby. However, there is no special classes or class methods in Ruby since it is a dynamic language. Instead, '''Ruby''' allows us to rename our factory method to be called new.

class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end

Our client class now becomes:

class ObjectUser
def doSomething(factory)
...
my_object = factory.new()
...
end
end

Ruby lets us redefine the new method and allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special <code>createObject</code> method.

==Iterator==
[http://en.wikipedia.org/wiki/Iterator_pattern Iterator pattern] is design pattern used to access the elements of an aggregate object sequentially without exposing its underlying representation.

In order to use Iterator patter, we need:

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential object in the collection.

In Java, we will need to know the type of objects in the collection and cast them to the right type in order to use them. Whereas in Ruby, iterators are built right in.

Here are some examples that show the ease with which we can use iterators in Ruby:
* Iterates a block of code for each element in the <code>Array</code>

a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

* Iterates code for every line in a file

Thread.list.each { |t| print "Thread: #{t}\n" }

* Iterates code for all active threads

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

* Iterates code for each object in the system

open("data.txt").each_line { |line| print "The line is #{line}\n" }

=Conclusion=

Design pattern is a concept that applicable to solve problems regardless of the languages we use to implement the solution. So I cannot think of a case where a specific pattern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support meta-programming and reflection via Modules and Mixins and support extending/reopening classes and redefining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple <code>include Singleton</code> statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on solving the problem at hand rather than spending time implementing the design patterns.

=References=

* Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). [http://en.wikipedia.org/wiki/Design_patterns_book ''Design Patterns: Elements of Reusable Object-Oriented Software'']. Addison-Wesley. ISBN 0-201-63361-2.

* [http://designpatternsinruby.com/section01/article.html Design Patterns in Ruby] by Russ Olsen, February 27, 2006.

* [http://p-cos.net/documents/dynatype.pdf Dynamic vs Static Typing -- A Pattern-based Analysis] by Pascal Costanza, March 13, 2004.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-15T19:36:02Z

Tinydancer: /* Singleton Pattern */

=Introduction=

[http://en.wikipedia.org/wiki/Ruby_language Ruby] offers more concise implementations of certain [http://en.wikipedia.org/wiki/Design_pattern design patterns] than [http://en.wikipedia.org/wiki/Java_language Java] does. We will look at some design patterns and compare the implementation in '''Ruby vs Java''' with the goal to answer the following:
* Is this typical of dynamic object-oriented languages?

* Are there design patterns that any [http://en.wikipedia.org/wiki/Dynamic_language dynamically typed language] can realize better than a [http://en.wikipedia.org/wiki/Type_system statically typed language]?

* Are there instances when a different pattern should be used in a dynamic language than a static language?

=Design Patterns in Java vs Ruby=

==Singleton Pattern==

[http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern] is a design pattern used to restrict the instantiation of the class to one object.

The implementation of the pattern involves:
* making the constructor private
* declare a instance variable
* implement a <code>getInstance</code> method and make the it thread safe.

Below is the comparison between singleton class written in Java and Ruby.

It is clear that Ruby provides a more concise way of implementing the singleton pattern. Ruby uses the singleton module which automatically provides all the functionality that we need to write manually in Java. By writing <code>include singleton</code> in Ruby, we prevent ourselves from having to repeat writing the same code for each class that we wish to make singleton. In contrast, we need to write the Java class below for every singleton objects we create.

'''Java'''

public class SingletonExample {
// declare instance variable
private static SingletonExample singletonEx;

// Make the constructor is private
private SingletonExample() {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonEx == null) {
singletonEx = new SingletonExample();
}
return singletonEx;
}
}

'''Ruby''' (using singleton module)

require singleton
class SingletonExample
include singleton
end

==Factory Pattern==
[http://en.wikipedia.org/wiki/Factory_pattern Factory pattern] is implemented by isolating the code to create an object from the concrete implementation of the class.

In '''Java''', we typically write a similar code as below:

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}

We can implement the same code skeleton in Ruby. However, there is no special classes or class methods in Ruby since it is a dynamic language. '''Ruby''' allows us to rename our factory method to be called new.

class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end

Our client class now becomes:

class ObjectUser
def doSomething(factory)
...
my_object = factory.new()
...
end
end

Ruby lets us redefine the new method and allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special <code>createObject</code> method.

==Iterator==
[http://en.wikipedia.org/wiki/Iterator_pattern Iterator pattern] is design pattern used to access the elements of an aggregate object sequentially without exposing its underlying representation.

In order to use Iterator patter, we need:

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential object in the collection.

In Java, we will need to know the type of objects in the collection and cast them to the right type in order to use them. Whereas in Ruby, iterators are built right in.

Here are some examples that show the ease with which we can use iterators in Ruby:
* Iterates a block of code for each element in the <code>Array</code>

a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

* Iterates code for every line in a file

Thread.list.each { |t| print "Thread: #{t}\n" }

* Iterates code for all active threads

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

* Iterates code for each object in the system

open("data.txt").each_line { |line| print "The line is #{line}\n" }

=Conclusion=

Design pattern is a concept that applicable to solve problems regardless of the languages we use to implement the solution. So I cannot think of a case where a specific pattern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support meta-programming and reflection via Modules and Mixins and support extending/reopening classes and redefining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple <code>include Singleton</code> statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on solving the problem at hand rather than spending time implementing the design patterns.

=References=

* Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). [http://en.wikipedia.org/wiki/Design_patterns_book ''Design Patterns: Elements of Reusable Object-Oriented Software'']. Addison-Wesley. ISBN 0-201-63361-2.

* [http://designpatternsinruby.com/section01/article.html Design Patterns in Ruby] by Russ Olsen, February 27, 2006.

* [http://p-cos.net/documents/dynatype.pdf Dynamic vs Static Typing -- A Pattern-based Analysis] by Pascal Costanza, March 13, 2004.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-15T19:35:30Z

Tinydancer: /* Iterator */

=Introduction=

[http://en.wikipedia.org/wiki/Ruby_language Ruby] offers more concise implementations of certain [http://en.wikipedia.org/wiki/Design_pattern design patterns] than [http://en.wikipedia.org/wiki/Java_language Java] does. We will look at some design patterns and compare the implementation in '''Ruby vs Java''' with the goal to answer the following:
* Is this typical of dynamic object-oriented languages?

* Are there design patterns that any [http://en.wikipedia.org/wiki/Dynamic_language dynamically typed language] can realize better than a [http://en.wikipedia.org/wiki/Type_system statically typed language]?

* Are there instances when a different pattern should be used in a dynamic language than a static language?

=Design Patterns in Java vs Ruby=

==Singleton Pattern==

[http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern] is a design pattern used to restrict the instantiation of the class to one object.

The implementation of the pattern involves:
* making the constructor private
* declare a instance variable
* implement a <code>getInstance</code> method and make the it thread safe.

Below is the comparison between singleton class written in Java and Ruby.

It is clear that Ruby provides a more concise way of implementing the singleton pattern. Ruby uses the singleton module which automatically provides all the functionality that we need to write manually in Java. By writing <code>include singleton</code> in Ruby, we prevent ourselves from having to repeat writing the same code for each class that we wish to make singleton. In contrast, we need to write the Java class below for every singleton objects we create.

'''Java'''

public class SingletonExample {
// declare instance variable
private static SingletonExample singletonEx;

// Make the constructor is private
private SingletonExample() {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonEx == null) {
singletonEx = new SingletonExample();
}
return singletonEx;
}
}

'''Ruby''' (using singleton module)

require singleton
class SingletonExample
include singleton
end

==Factory Pattern==
[http://en.wikipedia.org/wiki/Factory_pattern Factory pattern] is implemented by isolating the code to create an object from the concrete implementation of the class.

In '''Java''', we typically write a similar code as below:

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}

We can implement the same code skeleton in Ruby. However, there is no special classes or class methods in Ruby since it is a dynamic language. '''Ruby''' allows us to rename our factory method to be called new.

class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end

Our client class now becomes:

class ObjectUser
def doSomething(factory)
...
my_object = factory.new()
...
end
end

Ruby lets us redefine the new method and allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special <code>createObject</code> method.

==Iterator==
[http://en.wikipedia.org/wiki/Iterator_pattern Iterator pattern] is design pattern used to access the elements of an aggregate object sequentially without exposing its underlying representation.

In order to use Iterator patter, we need:

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential object in the collection.

In Java, we will need to know the type of objects in the collection and cast them to the right type in order to use them. Whereas in Ruby, iterators are built right in.

Here are some examples that show the ease with which we can use iterators in Ruby:
* Iterates a block of code for each element in the <code>Array</code>

a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

* Iterates code for every line in a file

Thread.list.each { |t| print "Thread: #{t}\n" }

* Iterates code for all active threads

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

* Iterates code for each object in the system

open("data.txt").each_line { |line| print "The line is #{line}\n" }

=Conclusion=

Design pattern is a concept that applicable to solve problems regardless of the languages we use to implement the solution. So I cannot think of a case where a specific pattern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support meta-programming and reflection via Modules and Mixins and support extending/reopening classes and redefining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple <code>include Singleton</code> statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on solving the problem at hand rather than spending time implementing the design patterns.

=References=

* Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). [http://en.wikipedia.org/wiki/Design_patterns_book ''Design Patterns: Elements of Reusable Object-Oriented Software'']. Addison-Wesley. ISBN 0-201-63361-2.

* [http://designpatternsinruby.com/section01/article.html Design Patterns in Ruby] by Russ Olsen, February 27, 2006.

* [http://p-cos.net/documents/dynatype.pdf Dynamic vs Static Typing -- A Pattern-based Analysis] by Pascal Costanza, March 13, 2004.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-15T19:27:51Z

Tinydancer: /* References */

=Introduction=

[http://en.wikipedia.org/wiki/Ruby_language Ruby] offers more concise implementations of certain [http://en.wikipedia.org/wiki/Design_pattern design patterns] than [http://en.wikipedia.org/wiki/Java_language Java] does. We will look at some design patterns and compare the implementation in '''Ruby vs Java''' with the goal to answer the following:
* Is this typical of dynamic object-oriented languages?

* Are there design patterns that any [http://en.wikipedia.org/wiki/Dynamic_language dynamically typed language] can realize better than a [http://en.wikipedia.org/wiki/Type_system statically typed language]?

* Are there instances when a different pattern should be used in a dynamic language than a static language?

=Design Patterns in Java vs Ruby=

==Singleton Pattern==

[http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern] is a design pattern used to restrict the instantiation of the class to one object.

The implementation of the pattern involves:
* making the constructor private
* declare a instance variable
* implement a <code>getInstance</code> method and make the it thread safe.

Below is the comparison between singleton class written in Java and Ruby.

It is clear that Ruby provides a more concise way of implementing the singleton pattern. Ruby uses the singleton module which automatically provides all the functionality that we need to write manually in Java. By writing <code>include singleton</code> in Ruby, we prevent ourselves from having to repeat writing the same code for each class that we wish to make singleton. In contrast, we need to write the Java class below for every singleton objects we create.

'''Java'''

public class SingletonExample {
// declare instance variable
private static SingletonExample singletonEx;

// Make the constructor is private
private SingletonExample() {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonEx == null) {
singletonEx = new SingletonExample();
}
return singletonEx;
}
}

'''Ruby''' (using singleton module)

require singleton
class SingletonExample
include singleton
end

==Factory Pattern==
[http://en.wikipedia.org/wiki/Factory_pattern Factory pattern] is implemented by isolating the code to create an object from the concrete implementation of the class.

In '''Java''', we typically write a similar code as below:

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}

We can implement the same code skeleton in Ruby. However, there is no special classes or class methods in Ruby since it is a dynamic language. '''Ruby''' allows us to rename our factory method to be called new.

class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end

Our client class now becomes:

class ObjectUser
def doSomething(factory)
...
my_object = factory.new()
...
end
end

Ruby lets us redefine the new method and allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special <code>createObject</code> method.

==Iterator==
[http://en.wikipedia.org/wiki/Iterator_pattern Iterator pattern] is design pattern used to access the elements of an aggregate object sequentially without exposing its underlying representation.

In order to use Iterator patter, we need:

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential object in the collection.

In Java, we will need to know the type of objects in the collection and cast them to the right type in order to use them. Whereas in Ruby, iterators are built right in.

Here are some examples that show the ease with which we can use iterators in Ruby:

a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

=Conclusion=

Design pattern is a concept that applicable to solve problems regardless of the languages we use to implement the solution. So I cannot think of a case where a specific pattern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support meta-programming and reflection via Modules and Mixins and support extending/reopening classes and redefining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple <code>include Singleton</code> statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on solving the problem at hand rather than spending time implementing the design patterns.

=References=

* Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). [http://en.wikipedia.org/wiki/Design_patterns_book ''Design Patterns: Elements of Reusable Object-Oriented Software'']. Addison-Wesley. ISBN 0-201-63361-2.

* [http://designpatternsinruby.com/section01/article.html Design Patterns in Ruby] by Russ Olsen, February 27, 2006.

* [http://p-cos.net/documents/dynatype.pdf Dynamic vs Static Typing -- A Pattern-based Analysis] by Pascal Costanza, March 13, 2004.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-15T19:27:38Z

Tinydancer: /* References */

=Introduction=

[http://en.wikipedia.org/wiki/Ruby_language Ruby] offers more concise implementations of certain [http://en.wikipedia.org/wiki/Design_pattern design patterns] than [http://en.wikipedia.org/wiki/Java_language Java] does. We will look at some design patterns and compare the implementation in '''Ruby vs Java''' with the goal to answer the following:
* Is this typical of dynamic object-oriented languages?

* Are there design patterns that any [http://en.wikipedia.org/wiki/Dynamic_language dynamically typed language] can realize better than a [http://en.wikipedia.org/wiki/Type_system statically typed language]?

* Are there instances when a different pattern should be used in a dynamic language than a static language?

=Design Patterns in Java vs Ruby=

==Singleton Pattern==

[http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern] is a design pattern used to restrict the instantiation of the class to one object.

The implementation of the pattern involves:
* making the constructor private
* declare a instance variable
* implement a <code>getInstance</code> method and make the it thread safe.

Below is the comparison between singleton class written in Java and Ruby.

It is clear that Ruby provides a more concise way of implementing the singleton pattern. Ruby uses the singleton module which automatically provides all the functionality that we need to write manually in Java. By writing <code>include singleton</code> in Ruby, we prevent ourselves from having to repeat writing the same code for each class that we wish to make singleton. In contrast, we need to write the Java class below for every singleton objects we create.

'''Java'''

public class SingletonExample {
// declare instance variable
private static SingletonExample singletonEx;

// Make the constructor is private
private SingletonExample() {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonEx == null) {
singletonEx = new SingletonExample();
}
return singletonEx;
}
}

'''Ruby''' (using singleton module)

require singleton
class SingletonExample
include singleton
end

==Factory Pattern==
[http://en.wikipedia.org/wiki/Factory_pattern Factory pattern] is implemented by isolating the code to create an object from the concrete implementation of the class.

In '''Java''', we typically write a similar code as below:

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}

We can implement the same code skeleton in Ruby. However, there is no special classes or class methods in Ruby since it is a dynamic language. '''Ruby''' allows us to rename our factory method to be called new.

class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end

Our client class now becomes:

class ObjectUser
def doSomething(factory)
...
my_object = factory.new()
...
end
end

Ruby lets us redefine the new method and allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special <code>createObject</code> method.

==Iterator==
[http://en.wikipedia.org/wiki/Iterator_pattern Iterator pattern] is design pattern used to access the elements of an aggregate object sequentially without exposing its underlying representation.

In order to use Iterator patter, we need:

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential object in the collection.

In Java, we will need to know the type of objects in the collection and cast them to the right type in order to use them. Whereas in Ruby, iterators are built right in.

Here are some examples that show the ease with which we can use iterators in Ruby:

a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

=Conclusion=

Design pattern is a concept that applicable to solve problems regardless of the languages we use to implement the solution. So I cannot think of a case where a specific pattern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support meta-programming and reflection via Modules and Mixins and support extending/reopening classes and redefining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple <code>include Singleton</code> statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on solving the problem at hand rather than spending time implementing the design patterns.

=References=

* Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). [http://en.wikipedia.org/wiki/Design_patterns_book ''Design Patterns: Elements of Reusable Object-Oriented Software'']. Addison-Wesley. ISBN 0-201-63361-2.

* [http://designpatternsinruby.com/section01/article.html "Design Patterns in Ruby"] by Russ Olsen, February 27, 2006.

* [http://p-cos.net/documents/dynatype.pdf Dynamic vs Static Typing -- A Pattern-based Analysis] by Pascal Costanza, March 13, 2004.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-15T18:44:03Z

Tinydancer: /* Introduction */

=Introduction=

[http://en.wikipedia.org/wiki/Ruby_language Ruby] offers more concise implementations of certain [http://en.wikipedia.org/wiki/Design_pattern design patterns] than [http://en.wikipedia.org/wiki/Java_language Java] does. We will look at some design patterns and compare the implementation in '''Ruby vs Java''' with the goal to answer the following:
* Is this typical of dynamic object-oriented languages?

* Are there design patterns that any [http://en.wikipedia.org/wiki/Dynamic_language dynamically typed language] can realize better than a [http://en.wikipedia.org/wiki/Type_system statically typed language]?

* Are there instances when a different pattern should be used in a dynamic language than a static language?

=Design Patterns in Java vs Ruby=

==Singleton Pattern==

[http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern] is a design pattern used to restrict the instantiation of the class to one object.

The implementation of the pattern involves:
* making the constructor private
* declare a instance variable
* implement a <code>getInstance</code> method and make the it thread safe.

Below is the comparison between singleton class written in Java and Ruby.

It is clear that Ruby provides a more concise way of implementing the singleton pattern. Ruby uses the singleton module which automatically provides all the functionality that we need to write manually in Java. By writing <code>include singleton</code> in Ruby, we prevent ourselves from having to repeat writing the same code for each class that we wish to make singleton. In contrast, we need to write the Java class below for every singleton objects we create.

'''Java'''

public class SingletonExample {
// declare instance variable
private static SingletonExample singletonEx;

// Make the constructor is private
private SingletonExample() {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonEx == null) {
singletonEx = new SingletonExample();
}
return singletonEx;
}
}

'''Ruby''' (using singleton module)

require singleton
class SingletonExample
include singleton
end

==Factory Pattern==
[http://en.wikipedia.org/wiki/Factory_pattern Factory pattern] is implemented by isolating the code to create an object from the concrete implementation of the class.

In '''Java''', we typically write a similar code as below:

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}

We can implement the same code skeleton in Ruby. However, there is no special classes or class methods in Ruby since it is a dynamic language. '''Ruby''' allows us to rename our factory method to be called new.

class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end

Our client class now becomes:

class ObjectUser
def doSomething(factory)
...
my_object = factory.new()
...
end
end

Ruby lets us redefine the new method and allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special <code>createObject</code> method.

==Iterator==
[http://en.wikipedia.org/wiki/Iterator_pattern Iterator pattern] is design pattern used to access the elements of an aggregate object sequentially without exposing its underlying representation.

In order to use Iterator patter, we need:

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential object in the collection.

In Java, we will need to know the type of objects in the collection and cast them to the right type in order to use them. Whereas in Ruby, iterators are built right in.

Here are some examples that show the ease with which we can use iterators in Ruby:

a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

=Conclusion=

Design pattern is a concept that applicable to solve problems regardless of the languages we use to implement the solution. So I cannot think of a case where a specific pattern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support meta-programming and reflection via Modules and Mixins and support extending/reopening classes and redefining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple <code>include Singleton</code> statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on solving the problem at hand rather than spending time implementing the design patterns.

=References=

* Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). [http://en.wikipedia.org/wiki/Design_patterns_book ''Design Patterns: Elements of Reusable Object-Oriented Software'']. Addison-Wesley. ISBN 0-201-63361-2.

* [http://designpatternsinruby.com/section01/article.html "Design Patterns in Ruby"] by Russ Olsen, February 27, 2006.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-15T18:35:46Z

Tinydancer: /* Design Patterns in JAVA vs Ruby */

=Introduction=

[http://en.wikipedia.org/wiki/Ruby_language Ruby] offers more concise implementations of certain [http://en.wikipedia.org/wiki/Design_pattern design patterns] than [http://en.wikipedia.org/wiki/Java_language Java] does. We will look at some design patterns and compare the implementation in '''Ruby vs Java''' with the goal to answer the following:
* Is this typical of [http://en.wikipedia.org/wiki/Dynamic_language dynamic] object-oriented languages?

* Are there design patterns that any dynamically typed language can realize better than a statically typed language?

* Are there instances when a different pattern should be used in a dynamic language than a static language?

=Design Patterns in Java vs Ruby=

==Singleton Pattern==

[http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern] is a design pattern used to restrict the instantiation of the class to one object.

The implementation of the pattern involves:
* making the constructor private
* declare a instance variable
* implement a <code>getInstance</code> method and make the it thread safe.

Below is the comparison between singleton class written in Java and Ruby.

It is clear that Ruby provides a more concise way of implementing the singleton pattern. Ruby uses the singleton module which automatically provides all the functionality that we need to write manually in Java. By writing <code>include singleton</code> in Ruby, we prevent ourselves from having to repeat writing the same code for each class that we wish to make singleton. In contrast, we need to write the Java class below for every singleton objects we create.

'''Java'''

public class SingletonExample {
// declare instance variable
private static SingletonExample singletonEx;

// Make the constructor is private
private SingletonExample() {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonEx == null) {
singletonEx = new SingletonExample();
}
return singletonEx;
}
}

'''Ruby''' (using singleton module)

require singleton
class SingletonExample
include singleton
end

==Factory Pattern==
[http://en.wikipedia.org/wiki/Factory_pattern Factory pattern] is implemented by isolating the code to create an object from the concrete implementation of the class.

In '''Java''', we typically write a similar code as below:

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}

We can implement the same code skeleton in Ruby. However, there is no special classes or class methods in Ruby since it is a dynamic language. '''Ruby''' allows us to rename our factory method to be called new.

class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end

Our client class now becomes:

class ObjectUser
def doSomething(factory)
...
my_object = factory.new()
...
end
end

Ruby lets us redefine the new method and allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special <code>createObject</code> method.

==Iterator==
[http://en.wikipedia.org/wiki/Iterator_pattern Iterator pattern] is design pattern used to access the elements of an aggregate object sequentially without exposing its underlying representation.

In order to use Iterator patter, we need:

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential object in the collection.

In Java, we will need to know the type of objects in the collection and cast them to the right type in order to use them. Whereas in Ruby, iterators are built right in.

Here are some examples that show the ease with which we can use iterators in Ruby:

a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

=Conclusion=

Design pattern is a concept that applicable to solve problems regardless of the languages we use to implement the solution. So I cannot think of a case where a specific pattern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support meta-programming and reflection via Modules and Mixins and support extending/reopening classes and redefining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple <code>include Singleton</code> statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on solving the problem at hand rather than spending time implementing the design patterns.

=References=

* Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). [http://en.wikipedia.org/wiki/Design_patterns_book ''Design Patterns: Elements of Reusable Object-Oriented Software'']. Addison-Wesley. ISBN 0-201-63361-2.

* [http://designpatternsinruby.com/section01/article.html "Design Patterns in Ruby"] by Russ Olsen, February 27, 2006.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-15T18:34:13Z

Tinydancer: /* Conclusion */

=Introduction=

[http://en.wikipedia.org/wiki/Ruby_language Ruby] offers more concise implementations of certain [http://en.wikipedia.org/wiki/Design_pattern design patterns] than [http://en.wikipedia.org/wiki/Java_language Java] does. We will look at some design patterns and compare the implementation in '''Ruby vs Java''' with the goal to answer the following:
* Is this typical of [http://en.wikipedia.org/wiki/Dynamic_language dynamic] object-oriented languages?

* Are there design patterns that any dynamically typed language can realize better than a statically typed language?

* Are there instances when a different pattern should be used in a dynamic language than a static language?

=Design Patterns in JAVA vs Ruby=

==Singleton Pattern==

[http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern] is a design pattern used to restrict the instantiation of the class to one object.

The implementation of the pattern involves:
* making the constructor private
* declare a instance variable
* implement a <code>getInstance</code> method and make the it thread safe.

Below is the comparison between singleton class written in Java and Ruby.

It is clear that Ruby provides a more concise way of implementing the singleton pattern. Ruby uses the singleton module which automatically provides all the functionality that we need to write manually in Java. By writing <code>include singleton</code> in Ruby, we prevent ourselves from having to repeat writing the same code for each class that we wish to make singleton. In contrast, we need to write the Java class below for every singleton objects we create.

'''Java'''

public class SingletonExample {
// declare instance variable
private static SingletonExample singletonEx;

// Make the constructor is private
private SingletonExample() {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonEx == null) {
singletonEx = new SingletonExample();
}
return singletonEx;
}
}

'''Ruby''' (using singleton module)

require singleton
class SingletonExample
include singleton
end

==Factory Pattern==
[http://en.wikipedia.org/wiki/Factory_pattern Factory pattern] is implemented by isolating the code to create an object from the concrete implementation of the class.

In '''Java''', we typically write a similar code as below:

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}

We can implement the same code skeleton in Ruby. However, there is no special classes or class methods in Ruby since it is a dynamic language. '''Ruby''' allows us to rename our factory method to be called new.

class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end

Our client class now becomes:

class ObjectUser
def doSomething(factory)
...
my_object = factory.new()
...
end
end

Ruby lets us redefine the new method and allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special <code>createObject</code> method.

==Iterator==
[http://en.wikipedia.org/wiki/Iterator_pattern Iterator pattern] is design pattern used to access the elements of an aggregate object sequentially without exposing its underlying representation.

In order to use Iterator patter, we need:

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential object in the collection.

In Java, we will need to know the type of objects in the collection and cast them to the right type in order to use them. Whereas in Ruby, iterators are built right in.

Here are some examples that show the ease with which we can use iterators in Ruby:

a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

=Conclusion=

Design pattern is a concept that applicable to solve problems regardless of the languages we use to implement the solution. So I cannot think of a case where a specific pattern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support meta-programming and reflection via Modules and Mixins and support extending/reopening classes and redefining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple <code>include Singleton</code> statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on solving the problem at hand rather than spending time implementing the design patterns.

=References=

* Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). [http://en.wikipedia.org/wiki/Design_patterns_book ''Design Patterns: Elements of Reusable Object-Oriented Software'']. Addison-Wesley. ISBN 0-201-63361-2.

* [http://designpatternsinruby.com/section01/article.html "Design Patterns in Ruby"] by Russ Olsen, February 27, 2006.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-15T18:12:26Z

Tinydancer: /* Iterators */

=Introduction=

[http://en.wikipedia.org/wiki/Ruby_language Ruby] offers more concise implementations of certain [http://en.wikipedia.org/wiki/Design_pattern design patterns] than [http://en.wikipedia.org/wiki/Java_language Java] does. We will look at some design patterns and compare the implementation in '''Ruby vs Java''' with the goal to answer the following:
* Is this typical of [http://en.wikipedia.org/wiki/Dynamic_language dynamic] object-oriented languages?

* Are there design patterns that any dynamically typed language can realize better than a statically typed language?

* Are there instances when a different pattern should be used in a dynamic language than a static language?

=Design Patterns in JAVA vs Ruby=

==Singleton Pattern==

[http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern] is a design pattern used to restrict the instantiation of the class to one object.

The implementation of the pattern involves:
* making the constructor private
* declare a instance variable
* implement a <code>getInstance</code> method and make the it thread safe.

Below is the comparison between singleton class written in Java and Ruby.

It is clear that Ruby provides a more concise way of implementing the singleton pattern. Ruby uses the singleton module which automatically provides all the functionality that we need to write manually in Java. By writing <code>include singleton</code> in Ruby, we prevent ourselves from having to repeat writing the same code for each class that we wish to make singleton. In contrast, we need to write the Java class below for every singleton objects we create.

'''Java'''

public class SingletonExample {
// declare instance variable
private static SingletonExample singletonEx;

// Make the constructor is private
private SingletonExample() {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonEx == null) {
singletonEx = new SingletonExample();
}
return singletonEx;
}
}

'''Ruby''' (using singleton module)

require singleton
class SingletonExample
include singleton
end

==Factory Pattern==
[http://en.wikipedia.org/wiki/Factory_pattern Factory pattern] is implemented by isolating the code to create an object from the concrete implementation of the class.

In '''Java''', we typically write a similar code as below:

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}

We can implement the same code skeleton in Ruby. However, there is no special classes or class methods in Ruby since it is a dynamic language. '''Ruby''' allows us to rename our factory method to be called new.

class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end

Our client class now becomes:

class ObjectUser
def doSomething(factory)
...
my_object = factory.new()
...
end
end

Ruby lets us redefine the new method and allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special <code>createObject</code> method.

==Iterator==
[http://en.wikipedia.org/wiki/Iterator_pattern Iterator pattern] is design pattern used to access the elements of an aggregate object sequentially without exposing its underlying representation.

In order to use Iterator patter, we need:

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential object in the collection.

In Java, we will need to know the type of objects in the collection and cast them to the right type in order to use them. Whereas in Ruby, iterators are built right in.

Here are some examples that show the ease with which we can use iterators in Ruby:

a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

=Conclusion=

Design patterns are concepts that are equally applicable to solve problems regardless of the language we use to implement the solution. So I cannot think of a case where a specific pattern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support meta-programming and reflection via Modules and Mixins and support extending/reopening classes and redefining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple "include Singleton" statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on solving the problem at hand rather than spending time implementing the design patterns.

=References=

* Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). [http://en.wikipedia.org/wiki/Design_patterns_book ''Design Patterns: Elements of Reusable Object-Oriented Software'']. Addison-Wesley. ISBN 0-201-63361-2.

* [http://designpatternsinruby.com/section01/article.html "Design Patterns in Ruby"] by Russ Olsen, February 27, 2006.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-15T18:08:30Z

Tinydancer: /* Factory Pattern */

=Introduction=

[http://en.wikipedia.org/wiki/Ruby_language Ruby] offers more concise implementations of certain [http://en.wikipedia.org/wiki/Design_pattern design patterns] than [http://en.wikipedia.org/wiki/Java_language Java] does. We will look at some design patterns and compare the implementation in '''Ruby vs Java''' with the goal to answer the following:
* Is this typical of [http://en.wikipedia.org/wiki/Dynamic_language dynamic] object-oriented languages?

* Are there design patterns that any dynamically typed language can realize better than a statically typed language?

* Are there instances when a different pattern should be used in a dynamic language than a static language?

=Design Patterns in JAVA vs Ruby=

==Singleton Pattern==

[http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern] is a design pattern used to restrict the instantiation of the class to one object.

The implementation of the pattern involves:
* making the constructor private
* declare a instance variable
* implement a <code>getInstance</code> method and make the it thread safe.

Below is the comparison between singleton class written in Java and Ruby.

It is clear that Ruby provides a more concise way of implementing the singleton pattern. Ruby uses the singleton module which automatically provides all the functionality that we need to write manually in Java. By writing <code>include singleton</code> in Ruby, we prevent ourselves from having to repeat writing the same code for each class that we wish to make singleton. In contrast, we need to write the Java class below for every singleton objects we create.

'''Java'''

public class SingletonExample {
// declare instance variable
private static SingletonExample singletonEx;

// Make the constructor is private
private SingletonExample() {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonEx == null) {
singletonEx = new SingletonExample();
}
return singletonEx;
}
}

'''Ruby''' (using singleton module)

require singleton
class SingletonExample
include singleton
end

==Factory Pattern==
[http://en.wikipedia.org/wiki/Factory_pattern Factory pattern] is implemented by isolating the code to create an object from the concrete implementation of the class.

In '''Java''', we typically write a similar code as below:

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}

We can implement the same code skeleton in Ruby. However, there is no special classes or class methods in Ruby since it is a dynamic language. '''Ruby''' allows us to rename our factory method to be called new.

class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end

Our client class now becomes:

class ObjectUser
def doSomething(factory)
...
my_object = factory.new()
...
end
end

Ruby lets us redefine the new method and allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special <code>createObject</code> method.

==Iterators==
Iterators are design patterns used to access the elements of an aggregate object sequentially without exposing its underlying representation. To use iterators we need

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential object in the collection.

In JAVA we will need to know the type of objects in the collection and cast the objects to the right type to use them whereas in Ruby iterators are built right in. Here are some examples that show the ease with which we can use iterators in Ruby

<code>
a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

</code>

=Conclusion=

Design patterns are concepts that are equally applicable to solve problems regardless of the language we use to implement the solution. So I cannot think of a case where a specific pattern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support meta-programming and reflection via Modules and Mixins and support extending/reopening classes and redefining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple "include Singleton" statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on solving the problem at hand rather than spending time implementing the design patterns.

=References=

* Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). [http://en.wikipedia.org/wiki/Design_patterns_book ''Design Patterns: Elements of Reusable Object-Oriented Software'']. Addison-Wesley. ISBN 0-201-63361-2.

* [http://designpatternsinruby.com/section01/article.html "Design Patterns in Ruby"] by Russ Olsen, February 27, 2006.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-15T18:08:17Z

Tinydancer: /* Factory Pattern */

=Introduction=

[http://en.wikipedia.org/wiki/Ruby_language Ruby] offers more concise implementations of certain [http://en.wikipedia.org/wiki/Design_pattern design patterns] than [http://en.wikipedia.org/wiki/Java_language Java] does. We will look at some design patterns and compare the implementation in '''Ruby vs Java''' with the goal to answer the following:
* Is this typical of [http://en.wikipedia.org/wiki/Dynamic_language dynamic] object-oriented languages?

* Are there design patterns that any dynamically typed language can realize better than a statically typed language?

* Are there instances when a different pattern should be used in a dynamic language than a static language?

=Design Patterns in JAVA vs Ruby=

==Singleton Pattern==

[http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern] is a design pattern used to restrict the instantiation of the class to one object.

The implementation of the pattern involves:
* making the constructor private
* declare a instance variable
* implement a <code>getInstance</code> method and make the it thread safe.

Below is the comparison between singleton class written in Java and Ruby.

It is clear that Ruby provides a more concise way of implementing the singleton pattern. Ruby uses the singleton module which automatically provides all the functionality that we need to write manually in Java. By writing <code>include singleton</code> in Ruby, we prevent ourselves from having to repeat writing the same code for each class that we wish to make singleton. In contrast, we need to write the Java class below for every singleton objects we create.

'''Java'''

public class SingletonExample {
// declare instance variable
private static SingletonExample singletonEx;

// Make the constructor is private
private SingletonExample() {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonEx == null) {
singletonEx = new SingletonExample();
}
return singletonEx;
}
}

'''Ruby''' (using singleton module)

require singleton
class SingletonExample
include singleton
end

==Factory Pattern==
[http://en.wikipedia.org/wiki/Factory_pattern Factory pattern] is implemented by isolating the code to create an object from the concrete implementation of the class.

In '''JAVA''', we typically write a similar code as below:

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}

We can implement the same code skeleton in Ruby. However, there is no special classes or class methods in Ruby since it is a dynamic language. '''Ruby''' allows us to rename our factory method to be called new.

class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end

Our client class now becomes:

class ObjectUser
def doSomething(factory)
...
my_object = factory.new()
...
end
end

Ruby lets us redefine the new method and allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special <code>createObject</code> method.

==Iterators==
Iterators are design patterns used to access the elements of an aggregate object sequentially without exposing its underlying representation. To use iterators we need

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential object in the collection.

In JAVA we will need to know the type of objects in the collection and cast the objects to the right type to use them whereas in Ruby iterators are built right in. Here are some examples that show the ease with which we can use iterators in Ruby

<code>
a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

</code>

=Conclusion=

Design patterns are concepts that are equally applicable to solve problems regardless of the language we use to implement the solution. So I cannot think of a case where a specific pattern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support meta-programming and reflection via Modules and Mixins and support extending/reopening classes and redefining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple "include Singleton" statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on solving the problem at hand rather than spending time implementing the design patterns.

=References=

* Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). [http://en.wikipedia.org/wiki/Design_patterns_book ''Design Patterns: Elements of Reusable Object-Oriented Software'']. Addison-Wesley. ISBN 0-201-63361-2.

* [http://designpatternsinruby.com/section01/article.html "Design Patterns in Ruby"] by Russ Olsen, February 27, 2006.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-15T17:39:16Z

Tinydancer: /* Singleton Pattern */

=Introduction=

[http://en.wikipedia.org/wiki/Ruby_language Ruby] offers more concise implementations of certain [http://en.wikipedia.org/wiki/Design_pattern design patterns] than [http://en.wikipedia.org/wiki/Java_language Java] does. We will look at some design patterns and compare the implementation in '''Ruby vs Java''' with the goal to answer the following:
* Is this typical of [http://en.wikipedia.org/wiki/Dynamic_language dynamic] object-oriented languages?

* Are there design patterns that any dynamically typed language can realize better than a statically typed language?

* Are there instances when a different pattern should be used in a dynamic language than a static language?

=Design Patterns in JAVA vs Ruby=

==Singleton Pattern==

[http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern] is a design pattern used to restrict the instantiation of the class to one object.

The implementation of the pattern involves:
* making the constructor private
* declare a instance variable
* implement a <code>getInstance</code> method and make the it thread safe.

Below is the comparison between singleton class written in Java and Ruby.

It is clear that Ruby provides a more concise way of implementing the singleton pattern. Ruby uses the singleton module which automatically provides all the functionality that we need to write manually in Java. By writing <code>include singleton</code> in Ruby, we prevent ourselves from having to repeat writing the same code for each class that we wish to make singleton. In contrast, we need to write the Java class below for every singleton objects we create.

'''Java'''

public class SingletonExample {
// declare instance variable
private static SingletonExample singletonEx;

// Make the constructor is private
private SingletonExample() {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonEx == null) {
singletonEx = new SingletonExample();
}
return singletonEx;
}
}

'''Ruby''' (using singleton module)

require singleton
class SingletonExample
include singleton
end

==Factory Pattern==
Isolate the code to create an object from the concrete implementation of the class.

In JAVA we typically do something like

<code>

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}
</code>

We can technically do the exact same thing in Ruby however Ruby being a dynamic language there are no special classes or class methods in Ruby. Ruby allows us to rename our factory method to be called new.

<code>
class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end
</code>

Our client class now becomes:

<code>
class ObjectUser
def doSomething(factory )
...
my_object = factory.new()
...
end
end
</code>

Ruby lets us redefine the new method and this allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special createObject methods.

==Iterators==
Iterators are design patterns used to access the elements of an aggregate object sequentially without exposing its underlying representation. To use iterators we need

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential object in the collection.

In JAVA we will need to know the type of objects in the collection and cast the objects to the right type to use them whereas in Ruby iterators are built right in. Here are some examples that show the ease with which we can use iterators in Ruby

<code>
a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

</code>

=Conclusion=

Design patterns are concepts that are equally applicable to solve problems regardless of the language we use to implement the solution. So I cannot think of a case where a specific pattern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support meta-programming and reflection via Modules and Mixins and support extending/reopening classes and redefining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple "include Singleton" statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on solving the problem at hand rather than spending time implementing the design patterns.

=References=

* Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). [http://en.wikipedia.org/wiki/Design_patterns_book ''Design Patterns: Elements of Reusable Object-Oriented Software'']. Addison-Wesley. ISBN 0-201-63361-2.

* [http://designpatternsinruby.com/section01/article.html "Design Patterns in Ruby"] by Russ Olsen, February 27, 2006.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-15T17:38:02Z

Tinydancer: /* Singleton Pattern */

=Introduction=

[http://en.wikipedia.org/wiki/Ruby_language Ruby] offers more concise implementations of certain [http://en.wikipedia.org/wiki/Design_pattern design patterns] than [http://en.wikipedia.org/wiki/Java_language Java] does. We will look at some design patterns and compare the implementation in '''Ruby vs Java''' with the goal to answer the following:
* Is this typical of [http://en.wikipedia.org/wiki/Dynamic_language dynamic] object-oriented languages?

* Are there design patterns that any dynamically typed language can realize better than a statically typed language?

* Are there instances when a different pattern should be used in a dynamic language than a static language?

=Design Patterns in JAVA vs Ruby=

==Singleton Pattern==

[http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern] is a design pattern used to restrict the instantiation of the class to one object.

The implementation of the pattern involves:
* making the constructor private
* declare a instance variable
* implement a getInstance method and make the it thread safe.

Below is the comparison between singleton class written in Java and Ruby.

It is clear that Ruby provides a more concise way of implementing the singleton pattern. Ruby uses the singleton module which automatically provides all the functionality that we need to write manually in Java. By writing "include singleton" in Ruby, we prevent ourselves from having to repeat writing the same code for each class that we wish to make singleton. In contrast, we need to write the Java class below for every singleton objects we create.

'''Java'''

public class SingletonExample {
// declare instance variable
private static SingletonExample singletonEx;

// Make the constructor is private
private SingletonExample() {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonEx == null) {
singletonEx = new SingletonExample();
}
return singletonEx;
}
}

'''Ruby''' (using singleton module)

<code>
require singleton
class SingletonExample
include singleton
end
</code>

==Factory Pattern==
Isolate the code to create an object from the concrete implementation of the class.

In JAVA we typically do something like

<code>

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}
</code>

We can technically do the exact same thing in Ruby however Ruby being a dynamic language there are no special classes or class methods in Ruby. Ruby allows us to rename our factory method to be called new.

<code>
class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end
</code>

Our client class now becomes:

<code>
class ObjectUser
def doSomething(factory )
...
my_object = factory.new()
...
end
end
</code>

Ruby lets us redefine the new method and this allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special createObject methods.

==Iterators==
Iterators are design patterns used to access the elements of an aggregate object sequentially without exposing its underlying representation. To use iterators we need

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential object in the collection.

In JAVA we will need to know the type of objects in the collection and cast the objects to the right type to use them whereas in Ruby iterators are built right in. Here are some examples that show the ease with which we can use iterators in Ruby

<code>
a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

</code>

=Conclusion=

Design patterns are concepts that are equally applicable to solve problems regardless of the language we use to implement the solution. So I cannot think of a case where a specific pattern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support meta-programming and reflection via Modules and Mixins and support extending/reopening classes and redefining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple "include Singleton" statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on solving the problem at hand rather than spending time implementing the design patterns.

=References=

* Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). [http://en.wikipedia.org/wiki/Design_patterns_book ''Design Patterns: Elements of Reusable Object-Oriented Software'']. Addison-Wesley. ISBN 0-201-63361-2.

* [http://designpatternsinruby.com/section01/article.html "Design Patterns in Ruby"] by Russ Olsen, February 27, 2006.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-15T17:37:44Z

Tinydancer: /* Singleton Pattern */

=Introduction=

[http://en.wikipedia.org/wiki/Ruby_language Ruby] offers more concise implementations of certain [http://en.wikipedia.org/wiki/Design_pattern design patterns] than [http://en.wikipedia.org/wiki/Java_language Java] does. We will look at some design patterns and compare the implementation in '''Ruby vs Java''' with the goal to answer the following:
* Is this typical of [http://en.wikipedia.org/wiki/Dynamic_language dynamic] object-oriented languages?

* Are there design patterns that any dynamically typed language can realize better than a statically typed language?

* Are there instances when a different pattern should be used in a dynamic language than a static language?

=Design Patterns in JAVA vs Ruby=

==Singleton Pattern==

[http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern] is a design pattern used to restrict the instantiation of the class to one object.

The implementation of the pattern involves:
* making the constructor private
* declare a instance variable
* implement a getInstance method and make the it thread safe.

Below is the comparison between singleton class written in Java and Ruby.

It is clear that Ruby provides a more concise way of implementing the singleton pattern. Ruby uses the singleton module which automatically provides all the functionality that we need to write manually in Java. By writing "include singleton" in Ruby, we prevent ourselves from having to repeat writing the same code for each class that we wish to make singleton. In contrast, we need to write the Java class below for every singleton objects we create.

'''Java'''

public class SingletonExample {
// declare instance variable
private static SingletonExample singletonEx;

// Make the constructor is private
private SingletonExample() {
}

// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonEx == null) {
singletonEx = new SingletonExample();
}
return singletonEx;
}
}

'''Ruby''' (using singleton module)

<code>
require singleton
class SingletonExample
include singleton
end
</code>

==Factory Pattern==
Isolate the code to create an object from the concrete implementation of the class.

In JAVA we typically do something like

<code>

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}
</code>

We can technically do the exact same thing in Ruby however Ruby being a dynamic language there are no special classes or class methods in Ruby. Ruby allows us to rename our factory method to be called new.

<code>
class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end
</code>

Our client class now becomes:

<code>
class ObjectUser
def doSomething(factory )
...
my_object = factory.new()
...
end
end
</code>

Ruby lets us redefine the new method and this allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special createObject methods.

==Iterators==
Iterators are design patterns used to access the elements of an aggregate object sequentially without exposing its underlying representation. To use iterators we need

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential object in the collection.

In JAVA we will need to know the type of objects in the collection and cast the objects to the right type to use them whereas in Ruby iterators are built right in. Here are some examples that show the ease with which we can use iterators in Ruby

<code>
a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

</code>

=Conclusion=

Design patterns are concepts that are equally applicable to solve problems regardless of the language we use to implement the solution. So I cannot think of a case where a specific pattern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support meta-programming and reflection via Modules and Mixins and support extending/reopening classes and redefining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple "include Singleton" statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on solving the problem at hand rather than spending time implementing the design patterns.

=References=

* Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). [http://en.wikipedia.org/wiki/Design_patterns_book ''Design Patterns: Elements of Reusable Object-Oriented Software'']. Addison-Wesley. ISBN 0-201-63361-2.

* [http://designpatternsinruby.com/section01/article.html "Design Patterns in Ruby"] by Russ Olsen, February 27, 2006.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-15T17:35:57Z

Tinydancer: /* Singleton Pattern */

=Introduction=

[http://en.wikipedia.org/wiki/Ruby_language Ruby] offers more concise implementations of certain [http://en.wikipedia.org/wiki/Design_pattern design patterns] than [http://en.wikipedia.org/wiki/Java_language Java] does. We will look at some design patterns and compare the implementation in '''Ruby vs Java''' with the goal to answer the following:
* Is this typical of [http://en.wikipedia.org/wiki/Dynamic_language dynamic] object-oriented languages?

* Are there design patterns that any dynamically typed language can realize better than a statically typed language?

* Are there instances when a different pattern should be used in a dynamic language than a static language?

=Design Patterns in JAVA vs Ruby=

==Singleton Pattern==

[http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern] is a design pattern used to restrict the instantiation of the class to one object.

The implementation of the pattern involves:
* making the constructor private
* declare a instance variable
* implement a getInstance method and make the it thread safe.

Below is the comparison between singleton class written in Java and Ruby.

It is clear that Ruby provides a more concise way of implementing the singleton pattern. Ruby uses the singleton module which automatically provides all the functionality that we need to write manually in Java. By writing "include singleton" in Ruby, we prevent ourselves from having to repeat writing the same code for each class that we wish to make singleton. In contrast, we need to write the Java class below for every singleton objects we create.

'''Java'''

public class SingletonExample {
// declare instance variable
private static SingletonExample singletonEx;
// Make the constructor is private
private SingletonExample() {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonEx == null) {
singletonEx = new SingletonExample();
}
return singletonEx;
}
}

'''Ruby''' (using singleton module)

<code>
require singleton
class SingletonExample
include singleton
end
</code>

==Factory Pattern==
Isolate the code to create an object from the concrete implementation of the class.

In JAVA we typically do something like

<code>

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}
</code>

We can technically do the exact same thing in Ruby however Ruby being a dynamic language there are no special classes or class methods in Ruby. Ruby allows us to rename our factory method to be called new.

<code>
class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end
</code>

Our client class now becomes:

<code>
class ObjectUser
def doSomething(factory )
...
my_object = factory.new()
...
end
end
</code>

Ruby lets us redefine the new method and this allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special createObject methods.

==Iterators==
Iterators are design patterns used to access the elements of an aggregate object sequentially without exposing its underlying representation. To use iterators we need

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential object in the collection.

In JAVA we will need to know the type of objects in the collection and cast the objects to the right type to use them whereas in Ruby iterators are built right in. Here are some examples that show the ease with which we can use iterators in Ruby

<code>
a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

</code>

=Conclusion=

Design patterns are concepts that are equally applicable to solve problems regardless of the language we use to implement the solution. So I cannot think of a case where a specific pattern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support meta-programming and reflection via Modules and Mixins and support extending/reopening classes and redefining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple "include Singleton" statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on solving the problem at hand rather than spending time implementing the design patterns.

=References=

* Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). [http://en.wikipedia.org/wiki/Design_patterns_book ''Design Patterns: Elements of Reusable Object-Oriented Software'']. Addison-Wesley. ISBN 0-201-63361-2.

* [http://designpatternsinruby.com/section01/article.html "Design Patterns in Ruby"] by Russ Olsen, February 27, 2006.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-15T17:35:13Z

Tinydancer: /* References */

=Introduction=

[http://en.wikipedia.org/wiki/Ruby_language Ruby] offers more concise implementations of certain [http://en.wikipedia.org/wiki/Design_pattern design patterns] than [http://en.wikipedia.org/wiki/Java_language Java] does. We will look at some design patterns and compare the implementation in '''Ruby vs Java''' with the goal to answer the following:
* Is this typical of [http://en.wikipedia.org/wiki/Dynamic_language dynamic] object-oriented languages?

* Are there design patterns that any dynamically typed language can realize better than a statically typed language?

* Are there instances when a different pattern should be used in a dynamic language than a static language?

=Design Patterns in JAVA vs Ruby=

==Singleton Pattern==

[http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern] is a design pattern used to restrict the instantiation of the class to one object.

The implementation of the pattern involves:
* making the constructor private
* declare a instance variable
* implement a getInstance method and make the it thread safe.

Below is the comparison between singleton class written in Java and Ruby.

It is clear that Ruby provides a more concise way of implementing the singleton pattern. Ruby uses the singleton module which automatically provides all the functionality that we need to write manually in Java. By writing "include singleton" in Ruby, we prevent ourselves from having to repeat writing the same code for each class that we wish to make singleton. In contrast, we need to write the Java class below for every singleton objects we create.

'''Java'''

<code>
public class SingletonExample {
// declare instance variable
private static SingletonExample singletonEx;
// Make the constructor is private
private SingletonExample() {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonEx == null) {
singletonEx = new SingletonExample();
}
return singletonEx;
}
}
</code>

'''Ruby''' (using singleton module)

<code>
require singleton
class SingletonExample
include singleton
end
</code>

==Factory Pattern==
Isolate the code to create an object from the concrete implementation of the class.

In JAVA we typically do something like

<code>

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}
</code>

We can technically do the exact same thing in Ruby however Ruby being a dynamic language there are no special classes or class methods in Ruby. Ruby allows us to rename our factory method to be called new.

<code>
class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end
</code>

Our client class now becomes:

<code>
class ObjectUser
def doSomething(factory )
...
my_object = factory.new()
...
end
end
</code>

Ruby lets us redefine the new method and this allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special createObject methods.

==Iterators==
Iterators are design patterns used to access the elements of an aggregate object sequentially without exposing its underlying representation. To use iterators we need

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential object in the collection.

In JAVA we will need to know the type of objects in the collection and cast the objects to the right type to use them whereas in Ruby iterators are built right in. Here are some examples that show the ease with which we can use iterators in Ruby

<code>
a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

</code>

=Conclusion=

Design patterns are concepts that are equally applicable to solve problems regardless of the language we use to implement the solution. So I cannot think of a case where a specific pattern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support meta-programming and reflection via Modules and Mixins and support extending/reopening classes and redefining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple "include Singleton" statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on solving the problem at hand rather than spending time implementing the design patterns.

=References=

* Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). [http://en.wikipedia.org/wiki/Design_patterns_book ''Design Patterns: Elements of Reusable Object-Oriented Software'']. Addison-Wesley. ISBN 0-201-63361-2.

* [http://designpatternsinruby.com/section01/article.html "Design Patterns in Ruby"] by Russ Olsen, February 27, 2006.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-15T17:33:53Z

Tinydancer: /* References */

=Introduction=

[http://en.wikipedia.org/wiki/Ruby_language Ruby] offers more concise implementations of certain [http://en.wikipedia.org/wiki/Design_pattern design patterns] than [http://en.wikipedia.org/wiki/Java_language Java] does. We will look at some design patterns and compare the implementation in '''Ruby vs Java''' with the goal to answer the following:
* Is this typical of [http://en.wikipedia.org/wiki/Dynamic_language dynamic] object-oriented languages?

* Are there design patterns that any dynamically typed language can realize better than a statically typed language?

* Are there instances when a different pattern should be used in a dynamic language than a static language?

=Design Patterns in JAVA vs Ruby=

==Singleton Pattern==

[http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern] is a design pattern used to restrict the instantiation of the class to one object.

The implementation of the pattern involves:
* making the constructor private
* declare a instance variable
* implement a getInstance method and make the it thread safe.

Below is the comparison between singleton class written in Java and Ruby.

It is clear that Ruby provides a more concise way of implementing the singleton pattern. Ruby uses the singleton module which automatically provides all the functionality that we need to write manually in Java. By writing "include singleton" in Ruby, we prevent ourselves from having to repeat writing the same code for each class that we wish to make singleton. In contrast, we need to write the Java class below for every singleton objects we create.

'''Java'''

<code>
public class SingletonExample {
// declare instance variable
private static SingletonExample singletonEx;
// Make the constructor is private
private SingletonExample() {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonEx == null) {
singletonEx = new SingletonExample();
}
return singletonEx;
}
}
</code>

'''Ruby''' (using singleton module)

<code>
require singleton
class SingletonExample
include singleton
end
</code>

==Factory Pattern==
Isolate the code to create an object from the concrete implementation of the class.

In JAVA we typically do something like

<code>

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}
</code>

We can technically do the exact same thing in Ruby however Ruby being a dynamic language there are no special classes or class methods in Ruby. Ruby allows us to rename our factory method to be called new.

<code>
class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end
</code>

Our client class now becomes:

<code>
class ObjectUser
def doSomething(factory )
...
my_object = factory.new()
...
end
end
</code>

Ruby lets us redefine the new method and this allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special createObject methods.

==Iterators==
Iterators are design patterns used to access the elements of an aggregate object sequentially without exposing its underlying representation. To use iterators we need

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential object in the collection.

In JAVA we will need to know the type of objects in the collection and cast the objects to the right type to use them whereas in Ruby iterators are built right in. Here are some examples that show the ease with which we can use iterators in Ruby

<code>
a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

</code>

=Conclusion=

Design patterns are concepts that are equally applicable to solve problems regardless of the language we use to implement the solution. So I cannot think of a case where a specific pattern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support meta-programming and reflection via Modules and Mixins and support extending/reopening classes and redefining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple "include Singleton" statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on solving the problem at hand rather than spending time implementing the design patterns.

=References=

* [http://en.wikipedia.org/wiki/Erich_Gamma Gamma, Erich]; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. ISBN 0-201-63361-2.

* [http://designpatternsinruby.com/section01/article.html "Design Patterns in Ruby"] by Russ Olsen, February 27, 2006.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-15T17:31:27Z

Tinydancer: /* References */

=Introduction=

[http://en.wikipedia.org/wiki/Ruby_language Ruby] offers more concise implementations of certain [http://en.wikipedia.org/wiki/Design_pattern design patterns] than [http://en.wikipedia.org/wiki/Java_language Java] does. We will look at some design patterns and compare the implementation in '''Ruby vs Java''' with the goal to answer the following:
* Is this typical of [http://en.wikipedia.org/wiki/Dynamic_language dynamic] object-oriented languages?

* Are there design patterns that any dynamically typed language can realize better than a statically typed language?

* Are there instances when a different pattern should be used in a dynamic language than a static language?

=Design Patterns in JAVA vs Ruby=

==Singleton Pattern==

[http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern] is a design pattern used to restrict the instantiation of the class to one object.

The implementation of the pattern involves:
* making the constructor private
* declare a instance variable
* implement a getInstance method and make the it thread safe.

Below is the comparison between singleton class written in Java and Ruby.

It is clear that Ruby provides a more concise way of implementing the singleton pattern. Ruby uses the singleton module which automatically provides all the functionality that we need to write manually in Java. By writing "include singleton" in Ruby, we prevent ourselves from having to repeat writing the same code for each class that we wish to make singleton. In contrast, we need to write the Java class below for every singleton objects we create.

'''Java'''

<code>
public class SingletonExample {
// declare instance variable
private static SingletonExample singletonEx;
// Make the constructor is private
private SingletonExample() {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonEx == null) {
singletonEx = new SingletonExample();
}
return singletonEx;
}
}
</code>

'''Ruby''' (using singleton module)

<code>
require singleton
class SingletonExample
include singleton
end
</code>

==Factory Pattern==
Isolate the code to create an object from the concrete implementation of the class.

In JAVA we typically do something like

<code>

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}
</code>

We can technically do the exact same thing in Ruby however Ruby being a dynamic language there are no special classes or class methods in Ruby. Ruby allows us to rename our factory method to be called new.

<code>
class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end
</code>

Our client class now becomes:

<code>
class ObjectUser
def doSomething(factory )
...
my_object = factory.new()
...
end
end
</code>

Ruby lets us redefine the new method and this allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special createObject methods.

==Iterators==
Iterators are design patterns used to access the elements of an aggregate object sequentially without exposing its underlying representation. To use iterators we need

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential object in the collection.

In JAVA we will need to know the type of objects in the collection and cast the objects to the right type to use them whereas in Ruby iterators are built right in. Here are some examples that show the ease with which we can use iterators in Ruby

<code>
a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

</code>

=Conclusion=

Design patterns are concepts that are equally applicable to solve problems regardless of the language we use to implement the solution. So I cannot think of a case where a specific pattern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support meta-programming and reflection via Modules and Mixins and support extending/reopening classes and redefining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple "include Singleton" statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on solving the problem at hand rather than spending time implementing the design patterns.

=References=

*{{cite book
| first = Erich
| last = Gamma
| authorlink = Erich Gamma
| coauthors = [[Richard Helm]], [[Ralph Johnson]], and [[John Vlissides]]
| year = 1995
| title = [[Design Patterns (book)|Design Patterns: Elements of Reusable Object-Oriented Software]]
| publisher = [[Addison-Wesley]]
| isbn = 0-201-63361-2
| ref=book_Gamma1995
}}

* [http://designpatternsinruby.com/section01/article.html "Design Patterns in Ruby"] by Russ Olsen, February 27, 2006.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-15T02:11:36Z

Tinydancer:

=Introduction=

[http://en.wikipedia.org/wiki/Ruby_language Ruby] offers more concise implementations of certain [http://en.wikipedia.org/wiki/Design_pattern design patterns] than [http://en.wikipedia.org/wiki/Java_language Java] does. We will look at some design patterns and compare the implementation in '''Ruby vs Java''' with the goal to answer the following:
* Is this typical of [http://en.wikipedia.org/wiki/Dynamic_language dynamic] object-oriented languages?

* Are there design patterns that any dynamically typed language can realize better than a statically typed language?

* Are there instances when a different pattern should be used in a dynamic language than a static language?

=Design Patterns in JAVA vs Ruby=

==Singleton Pattern==

[http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern] is a design pattern used to restrict the instantiation of the class to one object.

The implementation of the pattern involves:
* making the constructor private
* declare a instance variable
* implement a getInstance method and make the it thread safe.

Below is the comparison between singleton class written in Java and Ruby.

It is clear that Ruby provides a more concise way of implementing the singleton pattern. Ruby uses the singleton module which automatically provides all the functionality that we need to write manually in Java. By writing "include singleton" in Ruby, we prevent ourselves from having to repeat writing the same code for each class that we wish to make singleton. In contrast, we need to write the Java class below for every singleton objects we create.

'''Java'''

<code>
public class SingletonExample {
// declare instance variable
private static SingletonExample singletonEx;
// Make the constructor is private
private SingletonExample() {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonEx == null) {
singletonEx = new SingletonExample();
}
return singletonEx;
}
}
</code>

'''Ruby''' (using singleton module)

<code>
require singleton
class SingletonExample
include singleton
end
</code>

==Factory Pattern==
Isolate the code to create an object from the concrete implementation of the class.

In JAVA we typically do something like

<code>

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}
</code>

We can technically do the exact same thing in Ruby however Ruby being a dynamic language there are no special classes or class methods in Ruby. Ruby allows us to rename our factory method to be called new.

<code>
class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end
</code>

Our client class now becomes:

<code>
class ObjectUser
def doSomething(factory )
...
my_object = factory.new()
...
end
end
</code>

Ruby lets us redefine the new method and this allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special createObject methods.

==Iterators==
Iterators are design patterns used to access the elements of an aggregate object sequentially without exposing its underlying representation. To use iterators we need

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential object in the collection.

In JAVA we will need to know the type of objects in the collection and cast the objects to the right type to use them whereas in Ruby iterators are built right in. Here are some examples that show the ease with which we can use iterators in Ruby

<code>
a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

</code>

=Conclusion=

Design patterns are concepts that are equally applicable to solve problems regardless of the language we use to implement the solution. So I cannot think of a case where a specific pattern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support meta-programming and reflection via Modules and Mixins and support extending/reopening classes and redefining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple "include Singleton" statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on solving the problem at hand rather than spending time implementing the design patterns.

=References=

* [http://designpatternsinruby.com/section01/article.html "Design Patterns in Ruby"] by Russ Olsen, February 27, 2006.

CSC/ECE 517 Fall 2009/program2 buddi wn

2009-10-12T18:08:30Z

Tinydancer: /* Required Results */

'''Buddi Project'''

== Important Information ==
* Submission: October 23 (Friday)
* First Feedback: October 30 (Friday)
* Resubmission: November 6 (Friday)
* Final Review: November 9 (Monday)
* Metareview: November 11 (Wednesday)

E-mail for Buddi questions:
wyatt@digitalcave.ca or wyatt.olson+buddi-ncsu@gmail.com.

=== Required Results ===

This project is more about QA and usability testing, rather than pure
development. While some coding may be required to enhance the view
layer, the vast majority of the code written will be in JUnit tests.
The following is required for your results:
# A '''.zip or .tgz archive''' containing the entire Buddi project (or at a minimum, all files which have changed OR a .diff of your changes, as you desire).
# A '''written report on the model testing''', indicating what your unit tests test (paying attention to edge cases where problems are more likely to occur) and the results of these tests. (The actual unit tests themselves will be included in the archive in part a)
# A w'''ritten report on the view testing''', indicating what tests you performed, and what the results were. Screenshots taken throughout the test procedure are optional, but a very good idea to demonstrate what problems (if any) you have found.
# '''A written report on what changes''' you have made to the view (or the model) as a result of your testing. If there were failures or potential improvements discovered in either your tests, this report should include a re-run of the failed tests, showing that they are now working.

== Objectives ==

=== Functionality ===
* Verify that '''splits''' in the data model have been implemented correctly. Ensure that the API wrapper functions allow transparent access to the model. Ensure that there are no edge cases where data corruption occurs.
* Refine and complete the '''view layer''', and verify that it works as desired in all cases.

=== Testing ===
* Verify Model using JUnit.
There are already some model and API tests in the junit source folder - you can use these as a basis for creating more. You should construct some tests to only test the model, others to test the plugin API, and still others to verify that changes written to the API are accessible to the model (and vice-versa).

Be sure to test the edge cases and exceptional input, for instance:
what happens if you try to split a transaction 1000 ways?
What happens if you try to include 0 splits?
What happens when you try to pass null to various setter methods?

* Verify UI
Using your understanding gained from the model tests, you must construct written documents detailing what tests you are planning on doing, and how you plan to go about them. You must then carry out these tests, and document the results. In addition to data integrity, the view tests should include a usability component - is the way which split transactions are expressed intuitive? Are there better ways to do this?

== Bugs or Undesired Behaviors ==

{| class="wikitable" border="1"
|-
! Title
! Details
! Actual Behavior
! Expected Behavior
! Solved
|-valign="top"
| Create New menu
| Undesired behavior. Create new options shouldn't be put under ''Edit'' menu. It's not intuitive for new users.
| Under My Accounts tab, Edit -> Create Account.
Under My Budget tab, Edit -> Create Budget Category.
| Several options:
# Move to under File menu
# Create button for "New Account" and "New Budget Category"
| No
|-valign="top"
| The "+", "-" buttons didn't appear naturally until one switched the focus TWICE after entering the amount.
|
|
|
| No
|-valign="top"
|
|
|
|
| No
|}

== References ==

* [[Unit Test for Buddi]]

== Useful Links ==
# [http://devel.buddi.digitalcave.ca/en/ Buddi docs for Developers]
# [http://buddi.digitalcave.ca/ Buddi docs for Users]

CSC/ECE 517 Fall 2009/program2 buddi wn

2009-10-12T18:07:42Z

Tinydancer: /* Required Results */

'''Buddi Project'''

== Important Information ==
* Submission: October 23 (Friday)
* First Feedback: October 30 (Friday)
* Resubmission: November 6 (Friday)
* Final Review: November 9 (Monday)
* Metareview: November 11 (Wednesday)

E-mail for Buddi questions:
wyatt@digitalcave.ca or wyatt.olson+buddi-ncsu@gmail.com.

=== Required Results ===

This project is more about QA and usability testing, rather than pure
development. While some coding may be required to enhance the view
layer, the vast majority of the code written will be in JUnit tests.
The following is required for your results:
# A '''.zip or .tgz archive''' containing the entire Buddi project (or at
a minimum, all files which have changed OR a .diff of your changes, as
you desire).
# A '''written report on the model testing''', indicating what your unit
tests test (paying attention to edge cases where problems are more
likely to occur) and the results of these tests. (The actual unit tests
themselves will be included in the archive in part a)
# A w'''ritten report on the view testing''', indicating what tests you
performed, and what the results were. Screenshots taken throughout the
test procedure are optional, but a very good idea to demonstrate what
problems (if any) you have found.
# '''A written report on what changes''' you have made to the view (or
the model) as a result of your testing. If there were failures or
potential improvements discovered in either your tests, this report
should include a re-run of the failed tests, showing that they are now
working.

== Objectives ==

=== Functionality ===
* Verify that '''splits''' in the data model have been implemented correctly. Ensure that the API wrapper functions allow transparent access to the model. Ensure that there are no edge cases where data corruption occurs.
* Refine and complete the '''view layer''', and verify that it works as desired in all cases.

=== Testing ===
* Verify Model using JUnit.
There are already some model and API tests in the junit source folder - you can use these as a basis for creating more. You should construct some tests to only test the model, others to test the plugin API, and still others to verify that changes written to the API are accessible to the model (and vice-versa).

Be sure to test the edge cases and exceptional input, for instance:
what happens if you try to split a transaction 1000 ways?
What happens if you try to include 0 splits?
What happens when you try to pass null to various setter methods?

* Verify UI
Using your understanding gained from the model tests, you must construct written documents detailing what tests you are planning on doing, and how you plan to go about them. You must then carry out these tests, and document the results. In addition to data integrity, the view tests should include a usability component - is the way which split transactions are expressed intuitive? Are there better ways to do this?

== Bugs or Undesired Behaviors ==

{| class="wikitable" border="1"
|-
! Title
! Details
! Actual Behavior
! Expected Behavior
! Solved
|-valign="top"
| Create New menu
| Undesired behavior. Create new options shouldn't be put under ''Edit'' menu. It's not intuitive for new users.
| Under My Accounts tab, Edit -> Create Account.
Under My Budget tab, Edit -> Create Budget Category.
| Several options:
# Move to under File menu
# Create button for "New Account" and "New Budget Category"
| No
|-valign="top"
| The "+", "-" buttons didn't appear naturally until one switched the focus TWICE after entering the amount.
|
|
|
| No
|-valign="top"
|
|
|
|
| No
|}

== References ==

* [[Unit Test for Buddi]]

== Useful Links ==
# [http://devel.buddi.digitalcave.ca/en/ Buddi docs for Developers]
# [http://buddi.digitalcave.ca/ Buddi docs for Users]

CSC/ECE 517 Fall 2009/program2 buddi wn

2009-10-12T18:06:29Z

Tinydancer: /* Important Information */

'''Buddi Project'''

== Important Information ==
* Submission: October 23 (Friday)
* First Feedback: October 30 (Friday)
* Resubmission: November 6 (Friday)
* Final Review: November 9 (Monday)
* Metareview: November 11 (Wednesday)

E-mail for Buddi questions:
wyatt@digitalcave.ca or wyatt.olson+buddi-ncsu@gmail.com.

=== Required Results ===

This project is more about QA and usability testing, rather than pure
development. While some coding may be required to enhance the view
layer, the vast majority of the code written will be in JUnit tests.
The following is required for your results:
a) A .zip or .tgz archive containing the entire Buddi project (or at
a minimum, all files which have changed OR a .diff of your changes, as
you desire).
b) A written report on the model testing, indicating what your unit
tests test (paying attention to edge cases where problems are more
likely to occur) and the results of these tests. (The actual unit tests
themselves will be included in the archive in part a)
c) A written report on the view testing, indicating what tests you
performed, and what the results were. Screenshots taken throughout the
test procedure are optional, but a very good idea to demonstrate what
problems (if any) you have found.
d) A written report on what changes you have made to the view (or
the model) as a result of your testing. If there were failures or
potential improvements discovered in either your tests, this report
should include a re-run of the failed tests, showing that they are now
working.

== Objectives ==

=== Functionality ===
* Verify that '''splits''' in the data model have been implemented correctly. Ensure that the API wrapper functions allow transparent access to the model. Ensure that there are no edge cases where data corruption occurs.
* Refine and complete the '''view layer''', and verify that it works as desired in all cases.

=== Testing ===
* Verify Model using JUnit.
There are already some model and API tests in the junit source folder - you can use these as a basis for creating more. You should construct some tests to only test the model, others to test the plugin API, and still others to verify that changes written to the API are accessible to the model (and vice-versa).

Be sure to test the edge cases and exceptional input, for instance:
what happens if you try to split a transaction 1000 ways?
What happens if you try to include 0 splits?
What happens when you try to pass null to various setter methods?

* Verify UI
Using your understanding gained from the model tests, you must construct written documents detailing what tests you are planning on doing, and how you plan to go about them. You must then carry out these tests, and document the results. In addition to data integrity, the view tests should include a usability component - is the way which split transactions are expressed intuitive? Are there better ways to do this?

== Bugs or Undesired Behaviors ==

{| class="wikitable" border="1"
|-
! Title
! Details
! Actual Behavior
! Expected Behavior
! Solved
|-valign="top"
| Create New menu
| Undesired behavior. Create new options shouldn't be put under ''Edit'' menu. It's not intuitive for new users.
| Under My Accounts tab, Edit -> Create Account.
Under My Budget tab, Edit -> Create Budget Category.
| Several options:
# Move to under File menu
# Create button for "New Account" and "New Budget Category"
| No
|-valign="top"
| The "+", "-" buttons didn't appear naturally until one switched the focus TWICE after entering the amount.
|
|
|
| No
|-valign="top"
|
|
|
|
| No
|}

== References ==

* [[Unit Test for Buddi]]

== Useful Links ==
# [http://devel.buddi.digitalcave.ca/en/ Buddi docs for Developers]
# [http://buddi.digitalcave.ca/ Buddi docs for Users]

CSC/ECE 517 Fall 2009/program2 buddi wn

2009-10-12T18:04:57Z

Tinydancer: /* Important Information */

CSC/ECE 517 Fall 2009/program2 buddi wn

2009-10-12T18:04:36Z

Tinydancer:

'''Buddi Project'''

== Important Information ==
Submission: October 23 (Friday)
First Feedback: October 30 (Friday)
Resubmission: November 6 (Friday)
Final Review: November 9 (Monday)
Metareview: November 11 (Wednesday)

E-mail for Buddi questions:
wyatt@digitalcave.ca or wyatt.olson+buddi-ncsu@gmail.com.

== Objectives ==

=== Functionality ===
* Verify that '''splits''' in the data model have been implemented correctly. Ensure that the API wrapper functions allow transparent access to the model. Ensure that there are no edge cases where data corruption occurs.
* Refine and complete the '''view layer''', and verify that it works as desired in all cases.

=== Testing ===
* Verify Model using JUnit.
There are already some model and API tests in the junit source folder - you can use these as a basis for creating more. You should construct some tests to only test the model, others to test the plugin API, and still others to verify that changes written to the API are accessible to the model (and vice-versa).

Be sure to test the edge cases and exceptional input, for instance:
what happens if you try to split a transaction 1000 ways?
What happens if you try to include 0 splits?
What happens when you try to pass null to various setter methods?

* Verify UI
Using your understanding gained from the model tests, you must construct written documents detailing what tests you are planning on doing, and how you plan to go about them. You must then carry out these tests, and document the results. In addition to data integrity, the view tests should include a usability component - is the way which split transactions are expressed intuitive? Are there better ways to do this?

== Bugs or Undesired Behaviors ==

{| class="wikitable" border="1"
|-
! Title
! Details
! Actual Behavior
! Expected Behavior
! Solved
|-valign="top"
| Create New menu
| Undesired behavior. Create new options shouldn't be put under ''Edit'' menu. It's not intuitive for new users.
| Under My Accounts tab, Edit -> Create Account.
Under My Budget tab, Edit -> Create Budget Category.
| Several options:
# Move to under File menu
# Create button for "New Account" and "New Budget Category"
| No
|-valign="top"
| The "+", "-" buttons didn't appear naturally until one switched the focus TWICE after entering the amount.
|
|
|
| No
|-valign="top"
|
|
|
|
| No
|}

== References ==

* [[Unit Test for Buddi]]

== Useful Links ==
# [http://devel.buddi.digitalcave.ca/en/ Buddi docs for Developers]
# [http://buddi.digitalcave.ca/ Buddi docs for Users]

CSC/ECE 517 Fall 2009/program2 buddi wn

2009-10-12T17:56:30Z

Tinydancer: /* Unit Test for Buddi */

'''Buddi Project'''

== Objectives ==

=== Functionality ===
* Verify that '''splits''' in the data model have been implemented correctly. Ensure that the API wrapper functions allow transparent access to the model. Ensure that there are no edge cases where data corruption occurs.
* Refine and complete the '''view layer''', and verify that it works as desired in all cases.

=== Testing ===
* Verify Model using JUnit.
There are already some model and API tests in the junit source folder - you can use these as a basis for creating more. You should construct some tests to only test the model, others to test the plugin API, and still others to verify that changes written to the API are accessible to the model (and vice-versa).

Be sure to test the edge cases and exceptional input, for instance:
what happens if you try to split a transaction 1000 ways?
What happens if you try to include 0 splits?
What happens when you try to pass null to various setter methods?

* Verify UI
Using your understanding gained from the model tests, you must construct written documents detailing what tests you are planning on doing, and how you plan to go about them. You must then carry out these tests, and document the results. In addition to data integrity, the view tests should include a usability component - is the way which split transactions are expressed intuitive? Are there better ways to do this?

== Bugs or Undesired Behaviors ==

{| class="wikitable" border="1"
|-
! Title
! Details
! Actual Behavior
! Expected Behavior
! Solved
|-valign="top"
| Create New menu
| Undesired behavior. Create new options shouldn't be put under ''Edit'' menu. It's not intuitive for new users.
| Under My Accounts tab, Edit -> Create Account.
Under My Budget tab, Edit -> Create Budget Category.
| Several options:
# Move to under File menu
# Create button for "New Account" and "New Budget Category"
| No
|-valign="top"
| The "+", "-" buttons didn't appear naturally until one switched the focus TWICE after entering the amount.
|
|
|
| No
|-valign="top"
|
|
|
|
| No
|}

== References ==

* [[Unit Test for Buddi]]

== Useful Links ==
# [http://devel.buddi.digitalcave.ca/en/ Buddi docs for Developers]
# [http://buddi.digitalcave.ca/ Buddi docs for Users]

CSC/ECE 517 Fall 2009/program2 buddi wn

2009-10-12T17:55:13Z

Tinydancer: /* Functionality */

'''Buddi Project'''

== Objectives ==

=== Functionality ===
* Verify that '''splits''' in the data model have been implemented correctly. Ensure that the API wrapper functions allow transparent access to the model. Ensure that there are no edge cases where data corruption occurs.
* Refine and complete the '''view layer''', and verify that it works as desired in all cases.

=== Testing ===
* Verify Model using JUnit.
There are already some model and API tests in the junit source folder - you can use these as a basis for creating more. You should construct some tests to only test the model, others to test the plugin API, and still others to verify that changes written to the API are accessible to the model (and vice-versa).

Be sure to test the edge cases and exceptional input, for instance:
what happens if you try to split a transaction 1000 ways?
What happens if you try to include 0 splits?
What happens when you try to pass null to various setter methods?

* Verify UI
Using your understanding gained from the model tests, you must construct written documents detailing what tests you are planning on doing, and how you plan to go about them. You must then carry out these tests, and document the results. In addition to data integrity, the view tests should include a usability component - is the way which split transactions are expressed intuitive? Are there better ways to do this?

== Bugs or Undesired Behaviors ==

{| class="wikitable" border="1"
|-
! Title
! Details
! Actual Behavior
! Expected Behavior
! Solved
|-valign="top"
| Create New menu
| Undesired behavior. Create new options shouldn't be put under ''Edit'' menu. It's not intuitive for new users.
| Under My Accounts tab, Edit -> Create Account.
Under My Budget tab, Edit -> Create Budget Category.
| Several options:
# Move to under File menu
# Create button for "New Account" and "New Budget Category"
| No
|-valign="top"
| The "+", "-" buttons didn't appear naturally until one switched the focus TWICE after entering the amount.
|
|
|
| No
|-valign="top"
|
|
|
|
| No
|}

== [[Unit Test for Buddi]] ==

== Useful Links ==
# [http://devel.buddi.digitalcave.ca/en/ Buddi docs for Developers]
# [http://buddi.digitalcave.ca/ Buddi docs for Users]