Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2010/ch7 7a ed

2010-12-02T06:41:26Z

Ehanders: /* Dynamically Named Methods */

=Novel Implementations of Design Patterns in Dynamic Languages=

Dynamic languages such as Ruby and Javascript allow many novel implementations of the design patterns we cover in previous chapters, which would not be possible or feasible in complied languages such as Java and C. Language features only available in dynamic languages give developers an increased amount of flexibility in how they can implement design patterns. These language features and the some examples of the implementations they allow are detailed in this section, with a focus on implementations in the Ruby language.

=Language Features=

"These behaviors can be emulated in nearly any language of sufficient complexity, but dynamic languages provide direct tools to make use of them" [http://en.wikipedia.org/wiki/Dynamic_programming_language]. Some of the most helpful tools are as follows:

==Closures==

Closures are a feature that allow blocks of code to be passed around as arguments to functions. Closures are also known as lambdas or procs in Ruby. The code in a closure has access to all variables in the scope where it was created, and it can have additional data passed in as parameters to the closure from the caller. [http://jibbering.com/faq/notes/closures/]

==eval==

In dynamic languages, any arbitrary code can be executed dynamically at runtime. This can include code that is generated from user input. This is a subset of metaprogramming. Eval is explored further in section 3E.

==Reflection==

Reflection is the ability of a language to inspect the different methods exist on an object. Reflection is explored further in section 1C.

==Runtime Object Modification==

Dynamic languages allow metaprogramming, or the ability of the program to modify itself, creating or adding to objects and classes. This is explored further in section 4G.

==Dynamically Named Methods==

Dynamic languages often allow objects to handle method calls to methods that do not exist. In ruby, method_missing provides this functionality.

=Design Pattern Implementations=

==Strategy Pattern==

Using '''closures''', dynamic languages are able to simply pass in blocks of code that implement the strategy to be used.

For example, the Ruby sort method accepts a closure block, with which you can pass in the sorting metric.

>> list = ["10", "2", "5"]
=> ["10", "2", "5"]
>> list.sort{|a, b| a.length <=> b.length} # length strategy
=> ["5", "2", "10"]
>> list.sort{|a, b| a.to_i <=> b.to_i} # integer strategy
=> ["2", "5", "10"]
>> list.sort{|a, b| a <=> b} # string strategy
=> ["10", "2", "5"]

These strategies can also be stored and used later or chosen based on a conditional. For example:

length_strategy = lambda {|a, b| a.length <=> b.length}
list.sort(&length_strategy)

==Command Pattern==

Using '''eval''' or '''send''', one can implement the command pattern. This is implemented in Ruby on Rails' ActionController. A web application user enters a URL, which is the a form of a command. The URL typically contains the name of the controller and the action (command) that is to be executed on that controller.

The application checks to see if the a method with the action name exists in the controller and runs that method if so. Checking to see if the method exists is an example of class '''reflection'''. Without this language capability, the controller would have to keep an external list of its actions.

==Object Relational Mapping==

Ruby on Rails' ActiveRecord implementation of the Object Relational Mapping (ORM) pattern uses '''runtime object modification''' and '''dynamically named methods''' to achieve a very clean implementation.

===Runtime Object Modification===

Every ActiveRecord model contains accessors for each field in the corresponding database table. These accessors are created at runtime and do not require the programmer to manually create and update accessors for each field in the database. It does this by inspecting the database and adding accessor methods to the model's class for each field.
[http://ar.rubyonrails.org] This allows for much cleaner model code.

===Dynamically Named Methods===
By overriding Ruby's method_missing method in models, ActiveRecord can look for certain patterns in method calls on the models where no method is explicitly defined. One such example is <code>find_all_by_FIELD_NAME()</code>, where FIELD_NAME can be any field in the model's database table. Using these convenience methods, the models can be less cluttered, and Rails developers can write code that is easier to read.

=Conclusion=

Dynamic programming languages have several features which allow for novel ways to implement existing design patterns. These implementations are simpler and far less tedious than their compiled language counterparts.

=References=
# Wikipedia. Dynamic programming language. 2 October 2010. http://en.wikipedia.org/wiki/Dynamic_programming_language
# Cornford, Richard. Javascript Closures. March 2004. http://jibbering.com/faq/notes/closures
# 37Signals. Active Record — Object-relation mapping put on rails. 27 June 2008. http://ar.rubyonrails.org

CSC/ECE 517 Fall 2010/ch7 7a ed

2010-12-02T06:39:35Z

Ehanders:

=Novel Implementations of Design Patterns in Dynamic Languages=

Dynamic languages such as Ruby and Javascript allow many novel implementations of the design patterns we cover in previous chapters, which would not be possible or feasible in complied languages such as Java and C. Language features only available in dynamic languages give developers an increased amount of flexibility in how they can implement design patterns. These language features and the some examples of the implementations they allow are detailed in this section, with a focus on implementations in the Ruby language.

=Language Features=

"These behaviors can be emulated in nearly any language of sufficient complexity, but dynamic languages provide direct tools to make use of them" [http://en.wikipedia.org/wiki/Dynamic_programming_language]. Some of the most helpful tools are as follows:

==Closures==

Closures are a feature that allow blocks of code to be passed around as arguments to functions. Closures are also known as lambdas or procs in Ruby. The code in a closure has access to all variables in the scope where it was created, and it can have additional data passed in as parameters to the closure from the caller. [http://jibbering.com/faq/notes/closures/]

==eval==

In dynamic languages, any arbitrary code can be executed dynamically at runtime. This can include code that is generated from user input. This is a subset of metaprogramming. Eval is explored further in section 3E.

==Reflection==

Reflection is the ability of a language to inspect the different methods exist on an object. Reflection is explored further in section 1C.

==Runtime Object Modification==

Dynamic languages allow metaprogramming, or the ability of the program to modify itself, creating or adding to objects and classes. This is explored further in section 4G.

==Dynamically Named Methods==

Dynamic languages often allow objects to handle method calls to methods that do not exist. In ruby, method_missing provides this functionality.

=Design Pattern Implementations=

==Strategy Pattern==

Using '''closures''', dynamic languages are able to simply pass in blocks of code that implement the strategy to be used.

For example, the Ruby sort method accepts a closure block, with which you can pass in the sorting metric.

>> list = ["10", "2", "5"]
=> ["10", "2", "5"]
>> list.sort{|a, b| a.length <=> b.length} # length strategy
=> ["5", "2", "10"]
>> list.sort{|a, b| a.to_i <=> b.to_i} # integer strategy
=> ["2", "5", "10"]
>> list.sort{|a, b| a <=> b} # string strategy
=> ["10", "2", "5"]

These strategies can also be stored and used later or chosen based on a conditional. For example:

length_strategy = lambda {|a, b| a.length <=> b.length}
list.sort(&length_strategy)

==Command Pattern==

Using '''eval''' or '''send''', one can implement the command pattern. This is implemented in Ruby on Rails' ActionController. A web application user enters a URL, which is the a form of a command. The URL typically contains the name of the controller and the action (command) that is to be executed on that controller.

The application checks to see if the a method with the action name exists in the controller and runs that method if so. Checking to see if the method exists is an example of class '''reflection'''. Without this language capability, the controller would have to keep an external list of its actions.

==Object Relational Mapping==

Ruby on Rails' ActiveRecord implementation of the Object Relational Mapping (ORM) pattern uses '''runtime object modification''' and '''dynamically named methods''' to achieve a very clean implementation.

===Runtime Object Modification===

Every ActiveRecord model contains accessors for each field in the corresponding database table. These accessors are created at runtime and do not require the programmer to manually create and update accessors for each field in the database. It does this by inspecting the database and adding accessor methods to the model's class for each field.
[http://ar.rubyonrails.org] This allows for much cleaner model code.

===Dynamically Named Methods===
By overriding Ruby's method_missing method in models, ActiveRecord can look for certain patterns in method calls on the models where no method is explicitly defined. One such pattern is <code>find_all_by_FIELD_NAME</code>, where FIELD_NAME can be any field in the model's database table. Using these convenience methods, the models can be less cluttered, and Rails developers can write code that is easier to read.

=Conclusion=

Dynamic programming languages have several features which allow for novel ways to implement existing design patterns. These implementations are simpler and far less tedious than their compiled language counterparts.

=References=
# Wikipedia. Dynamic programming language. 2 October 2010. http://en.wikipedia.org/wiki/Dynamic_programming_language
# Cornford, Richard. Javascript Closures. March 2004. http://jibbering.com/faq/notes/closures
# 37Signals. Active Record — Object-relation mapping put on rails. 27 June 2008. http://ar.rubyonrails.org

CSC/ECE 517 Fall 2010/ch7 7a ed

2010-12-02T06:35:21Z

Ehanders:

=Novel Implementations of Design Patterns in Dynamic Languages=

Dynamic languages such as Ruby and Javascript allow many novel implementations of the design patterns we cover in previous chapters, which would not be possible or feasible in complied languages such as Java and C. Language features only available in dynamic languages give developers an increased amount of flexibility in how they can implement design patterns. These language features and the some examples of the implementations they allow are detailed in this section, with a focus on implementations in the Ruby language.

=Language Features=

"These behaviors can be emulated in nearly any language of sufficient complexity, but dynamic languages provide direct tools to make use of them" [http://en.wikipedia.org/wiki/Dynamic_programming_language]. Some of the most helpful tools are as follows:

==Closures==

Closures are a feature that allow blocks of code to be passed around as arguments to functions. Closures are also known as lambdas or procs in Ruby. The code in a closure has access to all variables in the scope where it was created, and it can have additional data passed in as parameters to the closure from the caller. [http://jibbering.com/faq/notes/closures/]

==eval==

In dynamic languages, any arbitrary code can be executed dynamically at runtime. This can include code that is generated from user input. This is a subset of metaprogramming. Eval is explored further in section 3E.

==Reflection==

Reflection is the ability of a language to inspect the different methods exist on an object. Reflection is explored further in section 1C.

==Runtime Object Modification==

Dynamic languages allow metaprogramming, or the ability of the program to modify itself, creating or adding to objects and classes. This is explored further in section 4G.

==Dynamically Named Methods==

Dynamic languages often allow objects to handle method calls to methods that do not exist. In ruby, method_missing provides this functionality.

=Design Pattern Implementations=

==Strategy Pattern==

Using '''closures''', dynamic languages are able to simply pass in blocks of code that implement the strategy to be used.

For example, the Ruby sort method accepts a closure block, with which you can pass in the sorting metric.

>> list = ["10", "2", "5"]
=> ["10", "2", "5"]
>> list.sort{|a, b| a.length <=> b.length} # length strategy
=> ["5", "2", "10"]
>> list.sort{|a, b| a.to_i <=> b.to_i} # integer strategy
=> ["2", "5", "10"]
>> list.sort{|a, b| a <=> b} # string strategy
=> ["10", "2", "5"]

These strategies can also be stored and used later or chosen based on a conditional. For example:

length_strategy = lambda {|a, b| a.length <=> b.length}
list.sort(&length_strategy)

==Command Pattern==

Using '''eval''' or '''send''', one can implement the command pattern. This is implemented in Ruby on Rails' ActionController. A web application user enters a URL, which is the a form of a command. The URL typically contains the name of the controller and the action (command) that is to be executed on that controller.

The application checks to see if the a method with the action name exists in the controller and runs that method if so. Checking to see if the method exists is an example of class '''reflection'''. Without this language capability, the controller would have to keep an external list of its actions.

==Object Relational Mapping==

Ruby on Rails' ActiveRecord implementation of the Object Relational Mapping (ORM) pattern uses '''runtime object modification''' and '''dynamically named methods''' to achieve a very clean implementation.

===Runtime Object Modification===

Every ActiveRecord model contains accessors for each field in the corresponding database table. These accessors are created at runtime and do not require the programmer to manually create and update accessors for each field in the database. It does this by inspecting the database and adding accessor methods to the model's class for each field.
[http://ar.rubyonrails.org] This allows for much cleaner model code.

===Dynamically Named Methods===
By overriding Ruby's method_missing method in models, ActiveRecord can look for certain patterns in method calls on the models where no method is explicitly defined. One such pattern is <code>find_all_by_FIELD_NAME</code>, where FIELD_NAME can be any field in the model's database table. Using these convenience methods, the models can be less cluttered, and Rails developers can write code that is easier to read.

=References=
# Wikipedia. Dynamic programming language. 2 October 2010. http://en.wikipedia.org/wiki/Dynamic_programming_language
# Cornford, Richard. Javascript Closures. March 2004. http://jibbering.com/faq/notes/closures
# 37Signals. Active Record — Object-relation mapping put on rails. 27 June 2008. http://ar.rubyonrails.org

CSC/ECE 517 Fall 2010/ch7 7a ed

2010-12-02T06:29:51Z

Ehanders:

=Novel Implementations of Design Patterns in Dynamic Languages=

Dynamic languages such as Ruby and Javascript allow many novel implementations of the design patterns we cover in previous chapters, which would not be possible or feasible in complied languages such as Java and C. Language features only available in dynamic languages give developers an increased amount of flexibility in how they can implement design patterns. These language features and the some examples of the implementations they allow are detailed in this section, with a focus on implementations in the Ruby language.

=Language Features=

"These behaviors can be emulated in nearly any language of sufficient complexity, but dynamic languages provide direct tools to make use of them" [http://en.wikipedia.org/wiki/Dynamic_programming_language]. Some of the most helpful tools are as follows:

==Closures==

Closures are a feature that allow blocks of code to be passed around as arguments to functions. Closures are also known as lambdas or procs in Ruby. The code in a closure has access to all variables in the scope where it was created, and it can have additional data passed in as parameters to the closure from the caller. [http://jibbering.com/faq/notes/closures/]

==Reflection==

Reflection is the ability of a language to inspect the different methods exist on an object. Reflection is explored further in section 1C.

==eval==

In dynamic languages, any arbitrary code can be executed dynamically at runtime. This can include code that is generated from user input. This is a subset of metaprogramming. Eval is explored further in section 3E.

==Runtime Object Modification==

Dynamic languages allow metaprogramming, or the ability of the program to modify itself, creating or adding to objects and classes. This is explored further in section 4G.

==Dynamically Named Methods==

Dynamic languages often allow objects to handle method calls to methods that do not exist. In ruby, method_missing provides this functionality.

=Design Pattern Implementations=

==Strategy Pattern==

Using '''closures''', dynamic languages are able to simply pass in blocks of code that implement the strategy to be used.

For example, the Ruby sort method accepts a closure block, with which you can pass in the sorting metric.

>> list = ["10", "2", "5"]
=> ["10", "2", "5"]
>> list.sort{|a, b| a.length <=> b.length} # length strategy
=> ["5", "2", "10"]
>> list.sort{|a, b| a.to_i <=> b.to_i} # integer strategy
=> ["2", "5", "10"]
>> list.sort{|a, b| a <=> b} # string strategy
=> ["10", "2", "5"]

These strategies can also be stored and used later or chosen based on a conditional. For example:

length_strategy = lambda {|a, b| a.length <=> b.length}
list.sort(&length_strategy)

==(reflection)==

==Command Pattern==

Using '''eval''' or '''send''', one can implement the command pattern. This is implemented in Ruby on Rails' ActionController. A web application user enters a URL, which is the a form of a command. The URL typically contains the name of the controller and the action (command) that is to be executed on that controller. The application checks to see if the a method with the action name exists in the controller and runs that method if so.

==Object Relational Mapping==

Ruby on Rails' ActiveRecord implementation of the Object Relational Mapping (ORM) pattern uses '''runtime object modification''' and '''dynamically named methods''' to achieve a very clean implementation.

===Runtime Object Modification===

Every ActiveRecord model contains accessors for each field in the corresponding database table. These accessors are created at runtime and do not require the programmer to manually create and update accessors for each field in the database. It does this by inspecting the database and adding accessor methods to the model's class for each field.
[http://ar.rubyonrails.org] This allows for much cleaner model code.

===Dynamically Named Methods===
By overriding Ruby's method_missing method in models, ActiveRecord can look for certain patterns in method calls on the models where no method is explicitly defined. One such pattern is <code>find_all_by_FIELD_NAME</code>, where FIELD_NAME can be any field in the model's database table. Using these convenience methods, the models can be less cluttered, and Rails developers can write code that is easier to read.

=References=
# Wikipedia. Dynamic programming language. 2 October 2010. http://en.wikipedia.org/wiki/Dynamic_programming_language
# Cornford, Richard. Javascript Closures. March 2004. http://jibbering.com/faq/notes/closures
# 37Signals. Active Record — Object-relation mapping put on rails. 27 June 2008. http://ar.rubyonrails.org

CSC/ECE 517 Fall 2010/ch7 7a ed

2010-12-02T06:27:24Z

Ehanders:

=Novel Implementations of Design Patterns in Dynamic Languages=

Dynamic languages such as Ruby and Javascript allow many novel implementations of the design patterns we cover in previous chapters, which would not be possible or feasible in complied languages such as Java and C. Language features only available in dynamic languages give developers an increased amount of flexibility in how they can implement design patterns. These language features and the some examples of the implementations they allow are detailed in this section, with a focus on implementations in the Ruby language.

=Language Features=

"These behaviors can be emulated in nearly any language of sufficient complexity, but dynamic languages provide direct tools to make use of them" [http://en.wikipedia.org/wiki/Dynamic_programming_language]. Some of the most helpful tools are as follows:

==Closures==

Closures are a feature that allow blocks of code to be passed around as arguments to functions. Closures are also known as lambdas or procs in Ruby. The code in a closure has access to all variables in the scope where it was created, and it can have additional data passed in as parameters to the closure from the caller. [http://jibbering.com/faq/notes/closures/]

==Runtime Object Modification==

Dynamic languages allow metaprogramming, or the ability of the program to modify itself, creating or adding to objects and classes. This is explored further in section 4G.

==eval==

In dynamic languages, any arbitrary code can be executed dynamically at runtime. This can include code that is generated from user input. This is a subset of metaprogramming. Eval is explored further in section 3E.

==Reflection==

Reflection is the ability of a language to inspect the different methods exist on an object. Reflection is explored further in section 1C.

==Dynamically Named Methods==

Dynamic languages often allow objects to handle method calls to methods that do not exist. In ruby, method_missing provides this functionality.

=Design Pattern Implementations=

==Strategy Pattern==

Using closures, dynamic languages are able to simply pass in blocks of code that implement the strategy to be used.

For example, the Ruby sort method accepts a closure block, with which you can pass in the sorting metric.

>> list = ["10", "2", "5"]
=> ["10", "2", "5"]
>> list.sort{|a, b| a.length <=> b.length} # length strategy
=> ["5", "2", "10"]
>> list.sort{|a, b| a.to_i <=> b.to_i} # integer strategy
=> ["2", "5", "10"]
>> list.sort{|a, b| a <=> b} # string strategy
=> ["10", "2", "5"]

These strategies can also be stored and used later or chosen based on a conditional. For example:

length_strategy = lambda {|a, b| a.length <=> b.length}
list.sort(&length_strategy)

==(reflection)==

==Command Pattern==

Using '''eval''' or '''send''', one can implement the command pattern. This is implemented in Ruby on Rails' ActionController. A web application user enters a URL, which is the a form of a command. The URL typically contains the name of the controller and the action (command) that is to be executed on that controller. The application checks to see if the a method with the action name exists in the controller and runs that method if so.

==Object Relational Mapping==

Ruby on Rails' ActiveRecord implementation of the Object Relational Mapping (ORM) pattern uses '''runtime object modification''' and '''dynamically named methods''' to achieve a very clean implementation.

===Runtime Object Modification===

Every ActiveRecord model contains accessors for each field in the corresponding database table. These accessors are created at runtime and do not require the programmer to manually create and update accessors for each field in the database. It does this by inspecting the database and adding accessor methods to the model's class for each field.
[http://ar.rubyonrails.org] This allows for much cleaner model code.

===Dynamically Named Methods===
By overriding Ruby's method_missing method in models, ActiveRecord can look for certain patterns in method calls on the models where no method is explicitly defined. One such pattern is <code>find_all_by_FIELD_NAME</code>, where FIELD_NAME can be any field in the model's database table. Using these convenience methods, the models can be less cluttered, and Rails developers can write code that is easier to read.

=References=
# Wikipedia. Dynamic programming language. 2 October 2010. http://en.wikipedia.org/wiki/Dynamic_programming_language
# Cornford, Richard. Javascript Closures. March 2004. http://jibbering.com/faq/notes/closures
# 37Signals. Active Record — Object-relation mapping put on rails. 27 June 2008. http://ar.rubyonrails.org

CSC/ECE 517 Fall 2010/ch7 7a ed

2010-12-02T05:46:13Z

Ehanders:

=Novel Implementations of Design Patterns in Dynamic Languages=

Dynamic languages such as Ruby and Javascript allow many novel implementations of the design patterns we cover in previous chapters, which would not be possible or feasible in complied languages such as Java and C. Language features only available in dynamic languages give developers an increased amount of flexibility in how they can implement design patterns. These language features and the some examples of the implementations they allow are detailed in this section, with a focus on implementations in the Ruby language.

=Language Features=

"These behaviors can be emulated in nearly any language of sufficient complexity, but dynamic languages provide direct tools to make use of them" [http://en.wikipedia.org/wiki/Dynamic_programming_language]. Some of the most helpful tools are as follows:

==Closures==

Closures are a feature that allow blocks of code to be passed around as arguments to functions. Closures are also known as lambdas or procs in Ruby. The code in a closure has access to all variables in the scope where it was created, and it can have additional data passed in as parameters to the closure from the caller. [http://jibbering.com/faq/notes/closures/]

==Runtime Object Modification==

Dynamic languages allow metaprogramming, or the ability of the program to modify itself, creating or adding to objects and classes. This is explored further in section 4G.

==eval==

In dynamic languages, any arbitrary code can be executed dynamically at runtime. This can include code that is generated from user input. This is a subset of metaprogramming. Eval is explored further in section 3E.

==Reflection==

Reflection is the ability of a language to inspect the different methods exist on an object. Reflection is explored further in section 1C.

==Dynamically Named Methods==

Dynamic languages often allow objects to handle method calls to methods that do not exist. In ruby, method_missing provides this functionality.

=Design Pattern Implementations=

==(Closures)==

==(reflection)==

==Command Pattern==

Using '''eval''' or '''send''', one can implement the command pattern. This is implemented in Ruby on Rails' ActionController. A web application user enters a URL, which is the a form of a command. The URL typically contains the name of the controller and the action (command) that is to be executed on that controller. The application checks to see if the a method with the action name exists in the controller and runs that method if so.

==Object Relational Mapping==

Ruby on Rails' ActiveRecord implementation of the Object Relational Mapping (ORM) pattern uses '''runtime object modification''' and '''dynamically named methods''' to achieve a very clean implementation.

===Runtime Object Modification===

Every ActiveRecord model contains accessors for each field in the corresponding database table. These accessors are created at runtime and do not require the programmer to manually create and update accessors for each field in the database. It does this by inspecting the database and adding accessor methods to the model's class for each field.
[http://ar.rubyonrails.org] This allows for much cleaner model code.

===Dynamically Named Methods===
By overriding Ruby's method_missing method in models, ActiveRecord can look for certain patterns in method calls on the models where no method is explicitly defined. One such pattern is <code>find_all_by_FIELD_NAME</code>, where FIELD_NAME can be any field in the model's database table. Using these convenience methods, the models can be less cluttered, and Rails developers can write code that is easier to read.

=References=
# Wikipedia. Dynamic programming language. 2 October 2010. http://en.wikipedia.org/wiki/Dynamic_programming_language
# Cornford, Richard. Javascript Closures. March 2004. http://jibbering.com/faq/notes/closures
# 37Signals. Active Record — Object-relation mapping put on rails. 27 June 2008. http://ar.rubyonrails.org

CSC/ECE 517 Fall 2010/ch7 7a ed

2010-12-02T04:35:46Z

Ehanders: /* Language Features */

CSC/ECE 517 Fall 2010/ch7 7a ed

2010-12-02T03:56:43Z

Ehanders: /* eval */

CSC/ECE 517 Fall 2010/ch7 7a ed

2010-12-02T03:50:34Z

Ehanders: /* Closures */

CSC/ECE 517 Fall 2010/ch7 7a ed

2010-12-02T03:47:02Z

Ehanders:

CSC/ECE 517 Fall 2010/ch7 7a ed

2010-12-02T03:31:43Z

Ehanders: /* Novel Implementations of Design Patterns in Dynamic Languages */

CSC/ECE 517 Fall 2010/ch7 7a ed

2010-12-02T03:30:10Z

Ehanders: /* Novel Implementations of Design Patterns in Dynamic Languages */

=Novel Implementations of Design Patterns in Dynamic Languages=

Dynamic languages such as Ruby and Javascript allow many novel implementations of design patterns which would not be possible or feasible in complied languages such as Java and C. Language features only available in dynamic languages give developers an increased amount of flexibility in how they can implement design patterns. These language features and the some examples of the implementations they allow are detailed in this section.

=References=

CSC/ECE 517 Fall 2010/ch1 S10 ms

2010-12-02T03:28:57Z

Ehanders: 7a,7e

*[[CSC/ECE 517 Fall 2010/ch1 1a vc]]

*[[CSC/ECE 517 Fall 2010/ch1 1a br]]

*[[CSC/ECE 517 Fall 2010/ch1 1b mg]]

*[[CSC/ECE 517 Fall 2010/ch1 1c JF]]

*[[CSC/ECE 517 Fall 2010/ch1 1e az]]

*[[CSC/ECE 517 Fall 2010/ch1 1e bb]]

*[[CSC/ECE 517 Fall 2010/ch1 1f vn]]

*[[CSC/ECE 517 Fall 2010/ch1 25 ag]]

*[[CSC/ECE 517 Fall 2010/ch2 2b dg]]

*[[CSC/ECE 517 Fall 2010/ch1 2e RI]]

*[[CSC/ECE 517 Fall 2010/ch1 S6 aa]]

*[[CSC/ECE 517 Fall 2010/ch1 S6 km]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 GP]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 MS]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 MM]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 PH]]

*[[CSC/ECE 517 Fall 2010/ch2 2a CB]]

*[[CSC/ECE 517 Fall 2010/ch2 2a mw]]

*[[CSC/ECE 517 Fall 2010/ch2 2c ck]]

*[[CSC/ECE 517 Fall 2010/ch2 S23 GP]]

*[[CSC/ECE 517 Fall 2010/ch2 S24 NS]]

*[[CSC/ECE 517 Fall 2010/ch2 S23 SS]]

*[[CSC/ECE 517 Fall 2010/ch2 S23 NR]]

*[[CSC/ECE 517 Fall 2010/ch2 S20 TT]]

*[[CSC/ECE 517 Fall 2010/ch2 2d AS]]

*[[CSC/ECE 517 Fall 2010/ch2 S24 rm]]

*[[CSC/ECE 517 Fall 2010/ch3 3a SN]]

*[[CSC/ECE 517 Fall 2010/ch3 3b ka]]

*[[CSC/ECE 517 Fall 2010/ch3 3e br]]

*[[CSC/ECE 517 Fall 2010/ch3 3f lj]]

*[[CSC/ECE 517 Fall 2010/ch3 3h az]]

*[[CSC/ECE 517 Fall 2010/ch3 3h PW]]

*[[CSC/ECE 517 Fall 2010/ch3 3i IC]]

*[[CSC/ECE 517 Fall 2010/ch3 3i MM]]

*[[CSC/ECE 517 Fall 2010/ch3 3j KS]]

*[[CSC/ECE 517 Fall 2010/ch3 S30 SK]]

*[[CSC/ECE 517 Fall 2010/ch3 4b mt]]

*[[CSC/ECE 517 Fall 2010/ch4 4e ms]]

*[[CSC/ECE 517 Fall 2010/ch4 4f sv]]

*[[CSC/ECE 517 Fall 2010/ch4 4g HW]]

*[[CSC/ECE 517 Fall 2010/ch4 4g km]]

*[[CSC/ECE 517 Fall 2010/ch4 4h am]]

*[[CSC/ECE 517 Fall 2010/ch5 5b mt]]

*[[CSC/ECE 517 Fall 2010/ch5 5b jz]]

*[[CSC/ECE 517 Fall 2010/ch5 5c ck]]

*[[CSC/ECE 517 Fall 2010/ch5 5c IC]]

*[[CSC/ECE 517 Fall 2010/ch5 5f SN]]

*[[CSC/ECE 517 Fall 2010/ch5 5a KR]]

*[[CSC/ECE 517 Fall 2010/ch5 5b RR]]

*[[CSC/ECE 517 Fall 2010/ch5 5e ms]]

*[[CSC/ECE 517 Fall 2010/chd 6d isb]]

*[[CSC/ECE 517 Fall 2010/ch6 6b SK]]

*[[CSC/ECE 517 Fall 2010/ch6 6c AW]]

*[[CSC/ECE 517 Fall 2010/ch6 6d bb]]

*[[CSC/ECE 517 Fall 2010/ch6 6h AS]]

*[[CSC/ECE 517 Fall 2010/ch6 6f AZ]]

*[[CSC/ECE 517 Fall 2010/ch6 6b AK]]

*[[CSC/ECE 517 Fall 2010/ch6 6g ss]]

*[[CSC/ECE 517 Fall 2010/ch6 6d NM]]

*[[ CSC/ECE 517 Fall 2010/ch6 6a PC]]

*[[ CSC/ECE 517 Fall 2010/ch2 4d RB]]

*[[ CSC/ECE 517 Fall 2010/ch7 71 ed]]

*[[ CSC/ECE 517 Fall 2010/ch7 7c ed]]

*[[ CSC/ECE 517 Fall 2010/ch7 7e GP]]

*[[ CSC/ECE 517 Fall 2010/ch7 7e GS]]

*[[ CSC/ECE 517 Fall 2010/ch7 7f PW]]

*[[ CSC/ECE 517 Fall 2010/ch7 7g ms]]

*[[ CSC/ECE 517 Fall 2010/ch7 7i sr]]

CSC/ECE 517 Fall 2010/ch7 7a ed

2010-12-02T03:10:42Z

Ehanders: /* Overview */

=Novel Implementations of Design Patterns in Dynamic Languages=

=References=

CSC/ECE 517 Fall 2010/ch7 7c ed

2010-12-02T02:56:36Z

Ehanders: /* Disadvantages */

=Pure Fabrication=
Pure Fabrication is a design pattern in which objects are created that do not correlate directly to real-world objects. This is generally used to achieve low cohesion and high coupling, as discussed in previous chapters. Although low cohesion and high coupling is an important design principle, fabricating objects that do not exist in the problem domain may lead to problems [http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx], thus classifying it as an anti-pattern.

Pure Fabrication is the second [http://en.wikipedia.org/wiki/GRASP_(object-oriented_design) GRASP] (General Responsibility Assignment Software Principles) principle covered in this chapter. All of these are general principles that "help aid developers in assigning responsibilities to objects" [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx].

==Example==
Larman, the author of this design principle, provides an example of the Pure Fabrication pattern in his book ''Applying UML and Patterns''. [http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691/ref=sr_11_1?ie=UTF8&qid=1216994566&sr=11-1]

Scenario: A retail sales application contains the classes Sale and DatabaseA. The Sale class represents a purchase transaction, and DatabaseA is the database backend it is stored in.

With only these two objects, the Sale class would need to contain the logic required to persist a sale to the database, which violates high cohesion. If DatabaseA were to change, the Sale class would also have to change. This violates low coupling [http://www.ibm.com/developerworks/rational/library/jun07/cuellar/].
If the database were to change to DatabaseB, an adapter would be required, as visualized in Figure 1:

[[Image:Wiki3A.jpg]] 
'''Figure 1'''

Instead, one could create a Broker class in the initial design that sits between the Sale and database, as in Figure 2 below:

[[Image:Wiki3B.jpg]] 
'''Figure 2'''

The Broker would contain all the logic necessary to take the data from a Sale-like object and all the logic needed to persist that data in the database. Sale and other Sale-like objects would all interact with Broker in the same way and would not need to know about the database, thus achieving high cohesion. If the DatabaseA is replaced with DatabaseB, only the Broker class must change, thus achieving low coupling. Since there is no Broker concept in the problem domain, this qualifies as a Pure Fabrication.

==Similar Patterns==

===Adapter===

This is similar to the Adapter pattern, except for a few key differences. The Adapter pattern applies when a new class is created to sit in the middle of to two existing classes that interact, such as in Figure 1. This does not decrease coupling or increase cohesion. Instead, the Broker class is part of the initial design, and the Sale never has to know how to interact with a database [3].

===Controllers in MVC===

In the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model View Controller pattern], the Controller could be viewed as a Pure Fabrication, because it does not represent a concept in the problem domain. Instead, it is a layer that sits in between the Views and Models, allowing each to main high cohesion and low coupling [http://www.martinfowler.com/eaaDev/PassiveScreen.html]. MVC is such a common application of the Pure Fabrication principle that it has become its own design principle.

==Disadvantages==

In many cases, adhering excessively to the low cohesion principle makes things more complicated and harder to maintain. "Obviously if you are building frameworks and reusable components the idea of low coupling and coding to interfaces is important, but I have seen and done this myself in the past with custom / opinionated software as a 'just-in-case.' In more times than not, this just-in-case type of development leads to over-architected and hard to maintain software" [1].

=References=
# Hayden, David. Over-Architecting Via Pure Fabrication and Indirection to Reduce Coupling. 26 Aug 2006. http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx
# Hayden, David. Pure Fabrication GRASP Pattern - Software Design Patterns and Principles - Applying UML and Patterns - Domain-Driven Design. 18 September 2005. http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx
# Larman, Craig. ''Applying UML and Patterns: an Introduction to Object-oriented Analysis and Design and Iterative Development''. Upper Saddle River, NJ: Prentice Hall PTR, 2005. Print.
# Cuellar, Ezequiel. Performing use-case realizations: The case for high cohesion and low coupling. 15 Jun 2007. http://www.ibm.com/developerworks/rational/library/jun07/cuellar
# Fowler, Martin. Passive View. 18 July 2006. http://www.martinfowler.com/eaaDev/PassiveScreen.html
# Wikipedia. GRASP (object-oriented design). 18 October 2010. http://en.wikipedia.org/wiki/GRASP_(object-oriented_design)

CSC/ECE 517 Fall 2010/ch7 7c ed

2010-12-02T02:56:08Z

Ehanders: /* Pure Fabrication */

=Pure Fabrication=
Pure Fabrication is a design pattern in which objects are created that do not correlate directly to real-world objects. This is generally used to achieve low cohesion and high coupling, as discussed in previous chapters. Although low cohesion and high coupling is an important design principle, fabricating objects that do not exist in the problem domain may lead to problems [http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx], thus classifying it as an anti-pattern.

Pure Fabrication is the second [http://en.wikipedia.org/wiki/GRASP_(object-oriented_design) GRASP] (General Responsibility Assignment Software Principles) principle covered in this chapter. All of these are general principles that "help aid developers in assigning responsibilities to objects" [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx].

==Example==
Larman, the author of this design principle, provides an example of the Pure Fabrication pattern in his book ''Applying UML and Patterns''. [http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691/ref=sr_11_1?ie=UTF8&qid=1216994566&sr=11-1]

Scenario: A retail sales application contains the classes Sale and DatabaseA. The Sale class represents a purchase transaction, and DatabaseA is the database backend it is stored in.

With only these two objects, the Sale class would need to contain the logic required to persist a sale to the database, which violates high cohesion. If DatabaseA were to change, the Sale class would also have to change. This violates low coupling [http://www.ibm.com/developerworks/rational/library/jun07/cuellar/].
If the database were to change to DatabaseB, an adapter would be required, as visualized in Figure 1:

[[Image:Wiki3A.jpg]] 
'''Figure 1'''

Instead, one could create a Broker class in the initial design that sits between the Sale and database, as in Figure 2 below:

[[Image:Wiki3B.jpg]] 
'''Figure 2'''

The Broker would contain all the logic necessary to take the data from a Sale-like object and all the logic needed to persist that data in the database. Sale and other Sale-like objects would all interact with Broker in the same way and would not need to know about the database, thus achieving high cohesion. If the DatabaseA is replaced with DatabaseB, only the Broker class must change, thus achieving low coupling. Since there is no Broker concept in the problem domain, this qualifies as a Pure Fabrication.

==Similar Patterns==

===Adapter===

This is similar to the Adapter pattern, except for a few key differences. The Adapter pattern applies when a new class is created to sit in the middle of to two existing classes that interact, such as in Figure 1. This does not decrease coupling or increase cohesion. Instead, the Broker class is part of the initial design, and the Sale never has to know how to interact with a database [3].

===Controllers in MVC===

In the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model View Controller pattern], the Controller could be viewed as a Pure Fabrication, because it does not represent a concept in the problem domain. Instead, it is a layer that sits in between the Views and Models, allowing each to main high cohesion and low coupling [http://www.martinfowler.com/eaaDev/PassiveScreen.html]. MVC is such a common application of the Pure Fabrication principle that it has become its own design principle.

==Disadvantages==

In many cases, adhering excessively to the low cohesion principle just makes things more complicated. "Obviously if you are building frameworks and reusable components the idea of low coupling and coding to interfaces is important, but I have seen and done this myself in the past with custom / opinionated software as a 'just-in-case.' In more times than not, this just-in-case type of development leads to over-architected and hard to maintain software" [1].

=References=
# Hayden, David. Over-Architecting Via Pure Fabrication and Indirection to Reduce Coupling. 26 Aug 2006. http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx
# Hayden, David. Pure Fabrication GRASP Pattern - Software Design Patterns and Principles - Applying UML and Patterns - Domain-Driven Design. 18 September 2005. http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx
# Larman, Craig. ''Applying UML and Patterns: an Introduction to Object-oriented Analysis and Design and Iterative Development''. Upper Saddle River, NJ: Prentice Hall PTR, 2005. Print.
# Cuellar, Ezequiel. Performing use-case realizations: The case for high cohesion and low coupling. 15 Jun 2007. http://www.ibm.com/developerworks/rational/library/jun07/cuellar
# Fowler, Martin. Passive View. 18 July 2006. http://www.martinfowler.com/eaaDev/PassiveScreen.html
# Wikipedia. GRASP (object-oriented design). 18 October 2010. http://en.wikipedia.org/wiki/GRASP_(object-oriented_design)

CSC/ECE 517 Fall 2010/ch7 7c ed

2010-12-02T02:49:41Z

Ehanders: /* References */

=Pure Fabrication=
Pure Fabrication is a design pattern in which objects are created that do not correlate directly to real-world objects. This is generally used to achieve low cohesion and high coupling, as discussed in previous chapters. Although low cohesion and high coupling is an important design principle, fabricating objects that do not exist in the problem domain may lead to problems [http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx], thus classifying it as an anti-pattern.

Pure Fabrication is the second [http://en.wikipedia.org/wiki/GRASP_(object-oriented_design) GRASP] (General Responsibility Assignment Software Principles) principle covered in this chapter. All of these are general principles that "help aid developers in assigning responsibilities to objects" [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx].

==Example==
Larman, the author of this design principle, provides an example of the Pure Fabrication pattern in his book ''Applying UML and Patterns''. [http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691/ref=sr_11_1?ie=UTF8&qid=1216994566&sr=11-1]

Scenario: A retail sales application contains the classes Sale and DatabaseA. The Sale class represents a purchase transaction, and DatabaseA is the database backend it is stored in.

With only these two objects, the Sale class would need to contain the logic required to persist a sale to the database, which violates high cohesion. If DatabaseA were to change, the Sale class would also have to change. This violates low coupling [http://www.ibm.com/developerworks/rational/library/jun07/cuellar/].
If the database were to change to DatabaseB, an adapter would be required, as visualized in Figure 1:

[[Image:Wiki3A.jpg]] 
'''Figure 1'''

Instead, one could create a Broker class in the initial design that sits between the Sale and database, as in Figure 2 below:

[[Image:Wiki3B.jpg]] 
'''Figure 2'''

The Broker would contain all the logic necessary to take the data from a Sale-like object and all the logic needed to persist that data in the database. Sale and other Sale-like objects would all interact with Broker in the same way and would not need to know about the database, thus achieving high cohesion. If the DatabaseA is replaced with DatabaseB, only the Broker class must change, thus achieving low coupling. Since there is no Broker concept in the problem domain, this qualifies as a Pure Fabrication.

==Similar Patterns==

===Adapter===

This is similar to the Adapter pattern, except for a few key differences. The Adapter pattern applies when a new class is created to sit in the middle of to two existing classes that interact, such as in Figure 1. This does not decrease coupling or increase cohesion. Instead, the Broker class is part of the initial design, and the Sale never has to know how to interact with a database [3].

===Controllers in MVC===

In the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model View Controller pattern], the Controller could be viewed as a Pure Fabrication, because it does not represent a concept in the problem domain. Instead, it is a layer that sits in between the Views and Models, allowing each to main high cohesion and low coupling [http://www.martinfowler.com/eaaDev/PassiveScreen.html]. MVC is such a common application of the Pure Fabrication principle that it has become its own design principle.

=References=
# Hayden, David. Over-Architecting Via Pure Fabrication and Indirection to Reduce Coupling. 26 Aug 2006. http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx
# Hayden, David. Pure Fabrication GRASP Pattern - Software Design Patterns and Principles - Applying UML and Patterns - Domain-Driven Design. 18 September 2005. http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx
# Larman, Craig. ''Applying UML and Patterns: an Introduction to Object-oriented Analysis and Design and Iterative Development''. Upper Saddle River, NJ: Prentice Hall PTR, 2005. Print.
# Cuellar, Ezequiel. Performing use-case realizations: The case for high cohesion and low coupling. 15 Jun 2007. http://www.ibm.com/developerworks/rational/library/jun07/cuellar
# Fowler, Martin. Passive View. 18 July 2006. http://www.martinfowler.com/eaaDev/PassiveScreen.html
# Wikipedia. GRASP (object-oriented design). 18 October 2010. http://en.wikipedia.org/wiki/GRASP_(object-oriented_design)

CSC/ECE 517 Fall 2010/ch7 7c ed

2010-12-02T02:47:03Z

Ehanders: /* Example */

=Pure Fabrication=
Pure Fabrication is a design pattern in which objects are created that do not correlate directly to real-world objects. This is generally used to achieve low cohesion and high coupling, as discussed in previous chapters. Although low cohesion and high coupling is an important design principle, fabricating objects that do not exist in the problem domain may lead to problems [http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx], thus classifying it as an anti-pattern.

Pure Fabrication is the second [http://en.wikipedia.org/wiki/GRASP_(object-oriented_design) GRASP] (General Responsibility Assignment Software Principles) principle covered in this chapter. All of these are general principles that "help aid developers in assigning responsibilities to objects" [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx].

==Example==
Larman, the author of this design principle, provides an example of the Pure Fabrication pattern in his book ''Applying UML and Patterns''. [http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691/ref=sr_11_1?ie=UTF8&qid=1216994566&sr=11-1]

Scenario: A retail sales application contains the classes Sale and DatabaseA. The Sale class represents a purchase transaction, and DatabaseA is the database backend it is stored in.

With only these two objects, the Sale class would need to contain the logic required to persist a sale to the database, which violates high cohesion. If DatabaseA were to change, the Sale class would also have to change. This violates low coupling [http://www.ibm.com/developerworks/rational/library/jun07/cuellar/].
If the database were to change to DatabaseB, an adapter would be required, as visualized in Figure 1:

[[Image:Wiki3A.jpg]] 
'''Figure 1'''

Instead, one could create a Broker class in the initial design that sits between the Sale and database, as in Figure 2 below:

[[Image:Wiki3B.jpg]] 
'''Figure 2'''

The Broker would contain all the logic necessary to take the data from a Sale-like object and all the logic needed to persist that data in the database. Sale and other Sale-like objects would all interact with Broker in the same way and would not need to know about the database, thus achieving high cohesion. If the DatabaseA is replaced with DatabaseB, only the Broker class must change, thus achieving low coupling. Since there is no Broker concept in the problem domain, this qualifies as a Pure Fabrication.

==Similar Patterns==

===Adapter===

This is similar to the Adapter pattern, except for a few key differences. The Adapter pattern applies when a new class is created to sit in the middle of to two existing classes that interact, such as in Figure 1. This does not decrease coupling or increase cohesion. Instead, the Broker class is part of the initial design, and the Sale never has to know how to interact with a database [3].

===Controllers in MVC===

In the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model View Controller pattern], the Controller could be viewed as a Pure Fabrication, because it does not represent a concept in the problem domain. Instead, it is a layer that sits in between the Views and Models, allowing each to main high cohesion and low coupling [http://www.martinfowler.com/eaaDev/PassiveScreen.html]. MVC is such a common application of the Pure Fabrication principle that it has become its own design principle.

=References=
# Hayden, David. Over-Architecting Via Pure Fabrication and Indirection to Reduce Coupling. 26 Aug 2006. http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx
# Larman, Craig. ''Applying UML and Patterns: an Introduction to Object-oriented Analysis and Design and Iterative Development''. Upper Saddle River, NJ: Prentice Hall PTR, 2005. Print.
# Cuellar, Ezequiel. Performing use-case realizations: The case for high cohesion and low coupling. 15 Jun 2007. http://www.ibm.com/developerworks/rational/library/jun07/cuellar
# Fowler, Martin. Passive View. 18 July 2006. http://www.martinfowler.com/eaaDev/PassiveScreen.html
# Wikipedia. GRASP (object-oriented design). 18 October 2010. http://en.wikipedia.org/wiki/GRASP_(object-oriented_design)
# Hayden, David. Pure Fabrication GRASP Pattern - Software Design Patterns and Principles - Applying UML and Patterns - Domain-Driven Design. 18 September 2005. http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx

CSC/ECE 517 Fall 2010/ch7 7c ed

2010-12-02T02:46:28Z

Ehanders:

=Pure Fabrication=
Pure Fabrication is a design pattern in which objects are created that do not correlate directly to real-world objects. This is generally used to achieve low cohesion and high coupling, as discussed in previous chapters. Although low cohesion and high coupling is an important design principle, fabricating objects that do not exist in the problem domain may lead to problems [http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx], thus classifying it as an anti-pattern.

Pure Fabrication is the second [http://en.wikipedia.org/wiki/GRASP_(object-oriented_design) GRASP] (General Responsibility Assignment Software Principles) principle covered in this chapter. All of these are general principles that "help aid developers in assigning responsibilities to objects" [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx].

==Example==
Larman provides an example of the Pure Fabrication pattern in his book ''Applying UML and Patterns''. [http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691/ref=sr_11_1?ie=UTF8&qid=1216994566&sr=11-1]

Scenario: A retail sales application contains the classes Sale and DatabaseA. The Sale class represents a purchase transaction, and DatabaseA is the database backend it is stored in.

With only these two objects, the Sale class would need to contain the logic required to persist a sale to the database, which violates high cohesion. If DatabaseA were to change, the Sale class would also have to change. This violates low coupling [http://www.ibm.com/developerworks/rational/library/jun07/cuellar/].
If the database were to change to DatabaseB, an adapter would be required, as visualized in Figure 1:

[[Image:Wiki3A.jpg]] 
'''Figure 1'''

Instead, one could create a Broker class in the initial design that sits between the Sale and database, as in Figure 2 below:

[[Image:Wiki3B.jpg]] 
'''Figure 2'''

The Broker would contain all the logic necessary to take the data from a Sale-like object and all the logic needed to persist that data in the database. Sale and other Sale-like objects would all interact with Broker in the same way and would not need to know about the database, thus achieving high cohesion. If the DatabaseA is replaced with DatabaseB, only the Broker class must change, thus achieving low coupling. Since there is no Broker concept in the problem domain, this qualifies as a Pure Fabrication.

==Similar Patterns==

===Adapter===

This is similar to the Adapter pattern, except for a few key differences. The Adapter pattern applies when a new class is created to sit in the middle of to two existing classes that interact, such as in Figure 1. This does not decrease coupling or increase cohesion. Instead, the Broker class is part of the initial design, and the Sale never has to know how to interact with a database [3].

===Controllers in MVC===

In the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model View Controller pattern], the Controller could be viewed as a Pure Fabrication, because it does not represent a concept in the problem domain. Instead, it is a layer that sits in between the Views and Models, allowing each to main high cohesion and low coupling [http://www.martinfowler.com/eaaDev/PassiveScreen.html]. MVC is such a common application of the Pure Fabrication principle that it has become its own design principle.

=References=
# Hayden, David. Over-Architecting Via Pure Fabrication and Indirection to Reduce Coupling. 26 Aug 2006. http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx
# Larman, Craig. ''Applying UML and Patterns: an Introduction to Object-oriented Analysis and Design and Iterative Development''. Upper Saddle River, NJ: Prentice Hall PTR, 2005. Print.
# Cuellar, Ezequiel. Performing use-case realizations: The case for high cohesion and low coupling. 15 Jun 2007. http://www.ibm.com/developerworks/rational/library/jun07/cuellar
# Fowler, Martin. Passive View. 18 July 2006. http://www.martinfowler.com/eaaDev/PassiveScreen.html
# Wikipedia. GRASP (object-oriented design). 18 October 2010. http://en.wikipedia.org/wiki/GRASP_(object-oriented_design)
# Hayden, David. Pure Fabrication GRASP Pattern - Software Design Patterns and Principles - Applying UML and Patterns - Domain-Driven Design. 18 September 2005. http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx

CSC/ECE 517 Fall 2010/ch7 7c ed

2010-12-02T02:23:45Z

Ehanders: /* Examples */

=Overview=
Pure Fabrication is a design pattern in which objects are created that do not correlate directly to real-world objects. This is generally used to achieve low cohesion and high coupling, as discussed in previous chapters. Although low cohesion and high coupling is an important design principle, fabricating objects that do not exist in the problem domain may lead to problems [http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx], thus classifying it as an anti-pattern.

=Pure Fabrication=
Pure Fabrication is a [http://en.wikipedia.org/wiki/GRASP_(object-oriented_design) GRASP] (General Responsibility Assignment Software Patterns) principle.

==Example==
Larman provides an example of the Pure Fabrication pattern in his book ''Applying UML and Patterns''. [http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691/ref=sr_11_1?ie=UTF8&qid=1216994566&sr=11-1]

Scenario: A retail sales application contains the classes Sale and DatabaseA. The Sale class represents a purchase transaction, and DatabaseA is the database backend it is stored in.

With only these two objects, the Sale class would need to contain the logic required to persist a sale to the database, which violates high cohesion. If DatabaseA were to change, the Sale class would also have to change. This violates low coupling [http://www.ibm.com/developerworks/rational/library/jun07/cuellar/].
If the database were to change to DatabaseB, an adapter would be required, as visualized in Figure 1:

[[Image:Wiki3A.jpg]] 
'''Figure 1'''

Instead, one could create a Broker class in the initial design that sits between the Sale and database, as in Figure 2 below:

[[Image:Wiki3B.jpg]] 
'''Figure 2'''

The Broker would contain all the logic necessary to take the data from a Sale-like object and all the logic needed to persist that data in the database. Sale and other Sale-like objects would all interact with Broker in the same way and would not need to know about the database, thus achieving high cohesion. If the DatabaseA is replaced with DatabaseB, only the Broker class must change, thus achieving low coupling. Since there is no Broker concept in the problem domain, this qualifies as a Pure Fabrication.

==Similar Patterns==

===Adapter===

This is similar to the Adapter pattern, except for a few key differences. The Adapter pattern applies when a new class is created to sit in the middle of to two existing classes that interact, such as in Figure 1. This does not decrease coupling or increase cohesion. Instead, the Broker class is part of the initial design, and the Sale never has to know how to interact with a database [2].

===Controllers in MVC===

In the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model View Controller pattern], the Controller could be viewed as a Pure Fabrication, because it does not represent a concept in the problem domain. Instead, it is a layer that sits in between the Views and Models, allowing each to main high cohesion and low coupling [http://www.martinfowler.com/eaaDev/PassiveScreen.html]. MVC is such a common application of the Pure Fabrication principle that it has become its own design principle.

=References=
# Hayden, David. Over-Architecting Via Pure Fabrication and Indirection to Reduce Coupling. 26 Aug 2006. http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx
# Larman, Craig. ''Applying UML and Patterns: an Introduction to Object-oriented Analysis and Design and Iterative Development''. Upper Saddle River, NJ: Prentice Hall PTR, 2005. Print.
# Cuellar, Ezequiel. Performing use-case realizations: The case for high cohesion and low coupling. 15 Jun 2007. http://www.ibm.com/developerworks/rational/library/jun07/cuellar
# Fowler, Martin. Passive View. 18 July 2006. http://www.martinfowler.com/eaaDev/PassiveScreen.html
# Wikipedia. GRASP (object-oriented design). 18 October 2010. http://en.wikipedia.org/wiki/GRASP_(object-oriented_design)

CSC/ECE 517 Fall 2010/ch7 7c ed

2010-12-02T02:09:47Z

Ehanders:

=Overview=
Pure Fabrication is a design pattern in which objects are created that do not correlate directly to real-world objects. This is generally used to achieve low cohesion and high coupling, as discussed in previous chapters. Although low cohesion and high coupling is an important design principle, fabricating objects that do not exist in the problem domain may lead to problems [http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx], thus classifying it as an anti-pattern.

=Pure Fabrication=
Pure Fabrication is a [http://en.wikipedia.org/wiki/GRASP_(object-oriented_design) GRASP] (General Responsibility Assignment Software Patterns) principle.

==Examples==
Larman provides an example of the Pure Fabrication pattern in his book ''Applying UML and Patterns''. [http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691/ref=sr_11_1?ie=UTF8&qid=1216994566&sr=11-1]

Scenario: A retail sales application contains the classes Sale and DatabaseA. The Sale class represents a purchase transaction, and DatabaseA is the database backend it is stored in.

With only these two objects, the Sale class would need to contain the logic required to persist a sale to the database, which violates high cohesion. If DatabaseA were to change, the Sale class would also have to change. This violates low coupling [http://www.ibm.com/developerworks/rational/library/jun07/cuellar/].
If the database were to change to DatabaseB, an adapter would be required, as visualized in Figure 1:

[[Image:Wiki3A.jpg]] 
'''Figure 1'''

Instead, one could

[[Image:Wiki3B.jpg]] 
'''Figure 2'''

==Similar Patterns==

===Adapter===

This is similar to the Adapter pattern, except for a few key differences. The Adapter pattern applies when a new class is created to sit in the middle of to two existing classes that interact, such as in Figure 1. This does not decrease coupling or increase cohesion. Instead, the Broker class is part of the initial design, and the Sale never has to know how to interact with a database [2].

===Controllers in MVC===

In the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model View Controller pattern], the Controller could be viewed as a Pure Fabrication, because it does not represent a concept in the problem domain. Instead, it is a layer that sits in between the Views and Models, allowing each to main high cohesion and low coupling [http://www.martinfowler.com/eaaDev/PassiveScreen.html]. MVC is such a common application of the Pure Fabrication principle that it has become its own design principle.

=References=
# Hayden, David. Over-Architecting Via Pure Fabrication and Indirection to Reduce Coupling. 26 Aug 2006. http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx
# Larman, Craig. ''Applying UML and Patterns: an Introduction to Object-oriented Analysis and Design and Iterative Development''. Upper Saddle River, NJ: Prentice Hall PTR, 2005. Print.
# Cuellar, Ezequiel. Performing use-case realizations: The case for high cohesion and low coupling. 15 Jun 2007. http://www.ibm.com/developerworks/rational/library/jun07/cuellar
# Fowler, Martin. Passive View. 18 July 2006. http://www.martinfowler.com/eaaDev/PassiveScreen.html
# Wikipedia. GRASP (object-oriented design). 18 October 2010. http://en.wikipedia.org/wiki/GRASP_(object-oriented_design)

CSC/ECE 517 Fall 2010/ch7 7c ed

2010-12-02T00:49:30Z

Ehanders: /* References */

CSC/ECE 517 Fall 2010/ch7 7a ed

2010-12-02T00:39:49Z

Ehanders:

=Overview=

=References=

CSC/ECE 517 Fall 2010/ch7 7c ed

2010-12-01T23:43:27Z

Ehanders: /* References */

CSC/ECE 517 Fall 2010/ch7 7c ed

2010-12-01T23:42:28Z

Ehanders: /* References */

CSC/ECE 517 Fall 2010/ch7 7c ed

2010-12-01T23:40:32Z

Ehanders: /* Pure Fabrication */

CSC/ECE 517 Fall 2010/ch7 7c ed

2010-12-01T23:40:22Z

Ehanders: /* Overview */

CSC/ECE 517 Fall 2010/ch7 7c ed

2010-12-01T23:39:39Z

Ehanders:

CSC 216/s08/wholesome discipline

2008-04-23T21:20:00Z

Ehanders:

==Stacks & Queues==

===The problem===

In this exercise, students will learn the difference between stacks and queues, mainly which end to push and pop from. In a stack, the items are added and removed from the top of a stack (LIFO); where as in a queue the items are added to the end and removed from the front (FIFO).

===Participants and props===

For this exercise about seven students will be needed to act as objects. The props will be plates, and candy.

===The script===

Each participant will be given a plate to write their name on, and will then stack them in a pile (Push). Afterwards, a certain name will have to be found, and the only way to get to it will be by taking off the top plate (Pop), until the desired name is found. This demonstrates the Last In First Out concept of a stack.

Then another group of students will demonstrate how queues work. Each student will line up to get a piece of candy. The first person to line up will be in the front and everyone else in the line will line up behind him (Push). Once the first person gets his piece of candy and leaves (Pop), the next person in line will then be able to get a piece of candy (which will most definitely raise class participation). This demonstrates the First In First Out concept of a queue.

After having done the exercise, give some examples of where queues and stacks are used in real programming. For example, stacks are used to keep track of method calls. Queues are used whenever using a buffer, or keeping track of things to do.

CSC 216/s08/wholesome discipline

2008-04-23T20:25:44Z

Ehanders: quick formatting fix

==Stacks & Queues==

===The problem===

In this exercise, students will learn the difference between stacks and queues, mainly which end to push and pop from. In a stack, the items are added and removed from the top of a stack (LIFO); where as in a queue the items are added to the end and removed from the front (FIFO).

===Participants and props===

For this exercise about seven students will be needed to act as objects. The props will be plates, and candy.

===The script===

Each participant will be given a plate to write their name on, and will then stack them in a pile (Push).
Afterwards, a certain name will have to be found, and the only way to get to it will be by taking off the top
plate (Pop), until the desired name is found. This demonstrates the last in first out concept of a stack.

Then another group of students will demonstrate how queues work. Each student will line up to get a
piece of candy. The first person to line up will be in the front and everyone else in the line will line up
behind him (Push). Once the first person gets his piece of candy and leaves (Pop), the next person in line
will then be able to get a piece of candy. This demonstrates the First in First out concept of a queue.

Side note: the promise of candy will most definitely raise class participation.

CSC 216/s08/be cheerful

2008-04-03T22:06:19Z

Ehanders: Clarify how the code doesn't match.

==That's what it's all about!==

===Overview===

In this active learning exercise, you can teach the value of superclassing and writing "don't repeat yourself" code to prevent error. When a programmer writes the same code twice, to do the same job, this increases logistical overhead and introduces more chances for error. But if he writes the code once and tells the classes that use it to look at the same piece of code, this can be handily eliminated. This is where inheritance comes in.

===How It's Done===

To model writing the code twice, and writing it once, you'll need two volunteers and an inside man -- you could do this yourself or delegate it. Your insider will instruct each of the two volunteers in how to do the hokey pokey. You can do this however you like: by word of mouth, by written instructions, whatever. But the one thing that you have to make sure is that one of the sets of instructions is ''wrong''. You'll see why in a second.

Now, have your two volunteers start dancing, strictly adhering to their instructions. Soon enough, they'll come out of sync, and you'll have your error. As you should reveal to the class at this time, this represents what happens when your two sections of supposedly identical code don't match perfectly. The program breaks or contains bugs.

To fix this, you can use a superclass that they will both take their instructions from. In this case, a nice Google video of a [http://video.google.com/videoplay?docid=-4742763335053216439 strange man doing the hokey pokey]. (This video will also be of use if your volunteers are a little too nervous: it's hard to be more ridiculous than that guy.) Once they've both received the same set of instructions, they can dance the hokey pokey in unison 'til the cows come home.

After a bit more dancing, bring it all together with a nice review of what each part of the exercise represents: repetitive coding, unintended errors, and the efficacy of a superclass. If done right, this will leave a strong impression of the importance of not repeating code.

===References===
* [http://courses.ncsu.edu/csc216/lec/001/homework/le Learning activity assignment]

CSC 216/s08/be cheerful

2008-03-22T20:48:09Z

Ehanders: /* Participants */

==That's what it's all about!==

===The problem===

Teach the value of superclassing and writing DRY code to prevent error.

===Participants===

3 group members: 1 programmer and 2 classes
Possibly volunteers to do the hokey pokey?

===Hokey Pokey Music/Video Candidates===

* http://video.google.com/videoplay?docid=-4742763335053216439
* http://video.google.com/videoplay?docid=8805519462208735145

===The script===

# The coder first creates two or more people classes that are supposed to do the Hokey Pokey. He tells them individually how to do the hokey pokey.
# Because he has a bad memory, he forgets to tell one to turn himself about and to do the incorrect 2nd action.
# They dance the first 2 segments (right foot, left foot) and get it wrong.
# The coder decides to use superclassing and inheritance so that all of his people share the same instructions -> show the video.
# They dance the next 2 segments (right arm, left arm) right!
# The best part is that now that I have a superclass, I can extend HokeyPokey to as many classes as I want! Like... the whole class! ;)
# Those willing can watch the video and do the hokey pokey with us. :D
# Reiterate how this example applies to real programming.

===References===
* [http://courses.ncsu.edu/csc216/lec/001/homework/le Learning activity assignment]

CSC 216/s08/be cheerful

2008-03-22T20:47:56Z

Ehanders: /* Participants */

==That's what it's all about!==

===The problem===

Teach the value of superclassing and writing DRY code to prevent error.

===Participants===

3 group members: 1 programmer and 2 classes
Possibly volunteers to do the hokey pokey?
How many students will participate? What else do you need (e.g., old tennis ball, Powerpoint slides, software).

===Hokey Pokey Music/Video Candidates===

* http://video.google.com/videoplay?docid=-4742763335053216439
* http://video.google.com/videoplay?docid=8805519462208735145

===The script===

# The coder first creates two or more people classes that are supposed to do the Hokey Pokey. He tells them individually how to do the hokey pokey.
# Because he has a bad memory, he forgets to tell one to turn himself about and to do the incorrect 2nd action.
# They dance the first 2 segments (right foot, left foot) and get it wrong.
# The coder decides to use superclassing and inheritance so that all of his people share the same instructions -> show the video.
# They dance the next 2 segments (right arm, left arm) right!
# The best part is that now that I have a superclass, I can extend HokeyPokey to as many classes as I want! Like... the whole class! ;)
# Those willing can watch the video and do the hokey pokey with us. :D
# Reiterate how this example applies to real programming.

===References===
* [http://courses.ncsu.edu/csc216/lec/001/homework/le Learning activity assignment]

CSC 216/s08/be cheerful

2008-03-22T20:47:13Z

Ehanders: Add link to assignment

==That's what it's all about!==

===The problem===

Teach the value of superclassing and writing DRY code to prevent error.

===Participants===

3 group members: 1 programmer and 2 classes
Possibly volunteers to do the hokey pokey?
How many students will participate? What else do you need (e.g., old tennis ball, Powerpoint slides, software).
Participants:

===Hokey Pokey Music/Video Candidates===

* http://video.google.com/videoplay?docid=-4742763335053216439
* http://video.google.com/videoplay?docid=8805519462208735145

===The script===

# The coder first creates two or more people classes that are supposed to do the Hokey Pokey. He tells them individually how to do the hokey pokey.
# Because he has a bad memory, he forgets to tell one to turn himself about and to do the incorrect 2nd action.
# They dance the first 2 segments (right foot, left foot) and get it wrong.
# The coder decides to use superclassing and inheritance so that all of his people share the same instructions -> show the video.
# They dance the next 2 segments (right arm, left arm) right!
# The best part is that now that I have a superclass, I can extend HokeyPokey to as many classes as I want! Like... the whole class! ;)
# Those willing can watch the video and do the hokey pokey with us. :D
# Reiterate how this example applies to real programming.

===References===
* [http://courses.ncsu.edu/csc216/lec/001/homework/le Learning activity assignment]

CSC 216/s08/be cheerful

2008-03-22T20:42:18Z

Ehanders: Initial proposal

==That's what it's all about!==

===The problem===

Teach the value of superclassing and writing DRY code to prevent error.

===Participants===

3 group members: 1 programmer and 2 classes
Possibly volunteers to do the hokey pokey?
How many students will participate? What else do you need (e.g., old tennis ball, Powerpoint slides, software).
Participants:

===Hokey Pokey Music/Video Candidates===

* http://video.google.com/videoplay?docid=-4742763335053216439
* http://video.google.com/videoplay?docid=8805519462208735145

===The script===

# The coder first creates two or more people classes that are supposed to do the Hokey Pokey. He tells them individually how to do the hokey pokey.
# Because he has a bad memory, he forgets to tell one to turn himself about and to do the incorrect 2nd action.
# They dance the first 2 segments (right foot, left foot) and get it wrong.
# The coder decides to use superclassing and inheritance so that all of his people share the same instructions -> show the video.
# They dance the next 2 segments (right arm, left arm) right!
# The best part is that now that I have a superclass, I can extend HokeyPokey to as many classes as I want! Like... the whole class! ;)
# Those willing can watch the video and do the hokey pokey with us. :D
# Reiterate how this example applies to real programming.