CSC/ECE 517 Summer 2008/wiki3 2 acmoore2: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
(6 intermediate revisions by the same user not shown)
Line 8: Line 8:


<pre>
<pre>
In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. [http://en.wikipedia.org/wiki/Design_pattern_(computer_science)]</pre>
In software engineering, a design pattern is a general reusable solution to a commonly
occurring problem in software design. A design pattern is not a finished design that can be
transformed directly into code. It is a description or template for how to solve a problem  
that can be used in many different situations. [http://en.wikipedia.org/wiki/Design_pattern_
computer_science)]</pre>


Most of the design patterns we have discussed in class were O-O design patterns. For example, during our lectures on Ruby we discussed several design patterns such as the Singleton[http://en.wikipedia.org/wiki/Singleton_pattern], the Adapter Pattern[http://en.wikipedia.org/wiki/Adapter_pattern], the Command Pattern[http://en.wikipedia.org/wiki/Command_pattern], and the Strategy Pattern[http://en.wikipedia.org/wiki/Strategy_pattern] to name a few.  
Most of the design patterns we have discussed in class were O-O design patterns. For example, during our lectures on Ruby we discussed several design patterns such as the Singleton[http://en.wikipedia.org/wiki/Singleton_pattern], the Adapter Pattern[http://en.wikipedia.org/wiki/Adapter_pattern], the Command Pattern[http://en.wikipedia.org/wiki/Command_pattern], and the Strategy Pattern[http://en.wikipedia.org/wiki/Strategy_pattern] to name a few.  
Line 14: Line 18:
The design patterns discussed were by no means a comprehensive list. The Patterns Almanac[http://www.smallmemory.com/almanac/] is a resource for other design patterns that could potentially be included in future CSC 517 course lecture work. I have selected to discuss State Patterns[http://www.smallmemory.com/almanac/DysonEtc98.html], Basic Relationship Patterns[http://www.smallmemory.com/almanac/Noble99a.html] and the Manager Pattern[http://www.smallmemory.com/almanac/Sommerlad98.html]
The design patterns discussed were by no means a comprehensive list. The Patterns Almanac[http://www.smallmemory.com/almanac/] is a resource for other design patterns that could potentially be included in future CSC 517 course lecture work. I have selected to discuss State Patterns[http://www.smallmemory.com/almanac/DysonEtc98.html], Basic Relationship Patterns[http://www.smallmemory.com/almanac/Noble99a.html] and the Manager Pattern[http://www.smallmemory.com/almanac/Sommerlad98.html]


==State Patterns==
----
 
====State Patterns====
The State Patterns listed in this section of Linda Risings Patterns Almanac where authored by P. Dyson, B. Anderson under the category 'Behavioral, Finite State Machines'. The patterns included in the State Patterns section are the Patterns State Object, State Member, Pure State, Exposed State, State-Driven Transitions, Owner-Driven Transitions and Pattern:Default State.
The State Patterns listed in this section of Linda Risings Patterns Almanac where authored by P. Dyson, B. Anderson under the category 'Behavioral, Finite State Machines'. The patterns included in the State Patterns section are the Patterns State Object, State Member, Pure State, Exposed State, State-Driven Transitions, Owner-Driven Transitions and Pattern:Default State.


Line 21: Line 27:
Other variations of the State Pattern are also discussed by Wikipedia[http://en.wikipedia.org/wiki/State_pattern] which also references implementing the design pattern with Finite State Machines[http://en.wikipedia.org/wiki/Finite_State_Machine].
Other variations of the State Pattern are also discussed by Wikipedia[http://en.wikipedia.org/wiki/State_pattern] which also references implementing the design pattern with Finite State Machines[http://en.wikipedia.org/wiki/Finite_State_Machine].


==Basic Relationship Patterns==
----
The Basic Relationship Design Pattern narrows in on the design of any relationship between two objects in a program and how these objects can effectively and efficiently communicate and interact. The pattern is made up of a Relationship vs. Attribute Pattern, a Relationship Object
==Manager Pattern==


===Conclusion===
====Basic Relationship Patterns====
The Basic Relationship Design Pattern narrows in on the design of any relationship between two objects in a program and how these objects can effectively and efficiently communicate and interact. This was authored by J. Noble in the Behavioral Category. The pattern is made up of a Relationship vs. Attribute Pattern, a Relationship Object, an Active Value Pattern and a Mutual Friends pattern.


===External References===
I believe this is a viable design pattern for discussion because of the nature of programming that is continuously using relationships between object. To be able to have a design pattern to maximize understanding between programmers on how these relationships always work would be a vast improvement in the current programming standards.


[http://en.wikipedia.org/wiki/Design_pattern_(computer_science)]</pre>
There are many variations on this design pattern, one of which is the Active Record Relationship Design Pattern[http://synthesis.sbecker.net/articles/2006/01/19/active-record-relationship-design-patterns]. The discussion of this design pattern could be incorporated with our study of Ruby and design patterns.


[http://en.wikipedia.org/wiki/Singleton_pattern]
----
 
[http://en.wikipedia.org/wiki/Adapter_pattern]
 
[http://en.wikipedia.org/wiki/Command_pattern]
 
[http://en.wikipedia.org/wiki/Strategy_pattern] to name a few.
 
[http://www.smallmemory.com/almanac/]
 
[http://www.smallmemory.com/almanac/DysonEtc98.html]
 
[http://www.smallmemory.com/almanac/Noble99a.html]
 
[http://www.smallmemory.com/almanac/Sommerlad98.html]
 
 
 
 
Any computer programmer with experience has realized the power of an iterator. As defined by Wikipedia.com an iterator is "an object which allows a programmer to traverse through all the elements of a collection, regardless of its specific implementation."[http://en.wikipedia.org/wiki/Iterator#Iterators_in_different_programming_languages]
   
For example, the programming language Java, has defined an iterator interface in their Java Collections Framework in java.util[http://java.sun.com/j2se/1.4.2/docs/api/java/util/Iterator.html] There are three methods included in the interface which are defined below:
<pre>
boolean hasNext() :  Returns true if the iteration has more elements.
Object next() : Returns the next element in the iteration.
void remove() : Removes from the underlying collection the last element returned by the iterator (optional operation)</pre>[http://java.sun.com/j2se/1.4.2/docs/api/java/util/Iterator.html]
 
We can further explore the operations of these iterator functions in the following section.
 
====Iterator Examples====
 
In the following Java example, an array arrayList has been defined and populated. The iterator is defined, itr, for arrayList and then the contents can easily be printed out by using an iterator. 
<pre>
//get an Iterator object for ArrayList using iterator() method.
Iterator itr = arrayList.iterator();
 
//use hasNext() and next() methods of Iterator to iterate through the elements
    System.out.println("Iterating through ArrayList elements...");
    while(itr.hasNext())
      System.out.println(itr.next());</pre>[http://www.java-examples.com/iterate-through-elements-java-arraylist-using-iterator-example]
Ruby, like Java allows for iterators and provides a mechinism for iteration. It allows for iteration over enumerations and arrays using blocks. Here is an example of a mixed bag array and then iterating over the array to print out the contents.
<pre>
array = [1, 'hi', 3.14]
array.each { |item| puts item }
# => 1
# => 'hi'
# => 3.14</pre>[http://en.wikipedia.org/wiki/Ruby_programming_language]
===Generators Defined===
 
As we have seen with iterators, the ability to traverse through a set or collection is a basic need of any programming language. Just as in Java, Ruby has a means of iteration by using a generator. As described in the wiki question,  Python uses a variation on the iterator and uses generators. Wikipedia.com defines generators as "a special routine that can be used to control the iteration behaviour of a loop."[http://en.wikipedia.org/wiki/Generator_%28computer_science%29]
   
A generator is compared to a function that returns an array. A generator can have parameters, it can be called, and in return it returns a sequence of values.[http://en.wikipedia.org/wiki/Generator_%28computer_science%29] The differnce between a generator and any other function that returns an array is that the generator is used to return the results one at a time, allowing it to act as an iterator.
   
Python.com cites several benefits behind a generator. One improved area is the efficiency of memory use. The generator requires less memory by not having to store and send an entire collection or array rather passing one value at a time.[http://www.python.org/dev/peps/pep-0289]   
Another benefit cited by Python.com is high performance. Like an iterator, a generator returns one value at a time allowing for a process to start accessing the data earlier and faster than it would if it had to wait for the entire array to return.[http://www.python.org/dev/peps/pep-0289]
====Generator Examples====
 
Our first example can be drawn from Python. This generator will produce prime number indefinitely as seen in the code below.
<pre>
# Another generator, which produces prime numbers indefinitely as needed.
def primes():
    n = 2
    p = []
    while True:
        if not any( n % f == 0 for f in p ):
            yield n
            p.append( n )
        n += 1
>>> f = primes()
>>> f.next()
2
>>> f.next()
3
>>> f.next()
5
>>> f.next()
7</pre>[http://en.wikipedia.org/wiki/Generator_%28computer_science%29]
===Generators That Would Be Awkward with Iterators===
 
An article by David Mertz in an ibm.com library discussed the advantage of generators and hence why generators can do some things that iterators can't.


:A generator is a function that remembers the point in the function body where it last returned. Calling a generator function a second (or nth) time jumps into the middle of the function, with all local variables intact from the last invocation.[http://www.ibm.com/developerworks/library/l-pycon.html]
====Manager Pattern====
The Manager Design Pattern listed by the Patterns Almanac is the final pattern that I think would be a great addition to the cirriculum. The Manager Designed Pattern was authored by P. Sommerland and the key aspect is that the management of each instance of a class is extracted from the object itself and designated to a Manager object. This allows for a much wider variation in functionality and for the reuse of Manager objects for a wide array of classes.


He makes a comparison between generators and closures with a distinct difference. "Like a closure, a generator 'remembers' the state of its data. But a generator goes a bit further than a closure: a generator also 'remembers' its position within flow-control constructs."[http://www.ibm.com/developerworks/library/l-pycon.html]
I have seen recently in a project I have worked on at work the implementation of this design pattern. It has led to a simplification of real-time job management where each job object is assigned to a manager to handle it's management operations. I think this would is an excellent design pattern and could use more exposure.


In the following example, is an example of how a generator is used manually, allowing it to be passed around a program and then called when and wherever needed.
Just like I have experienced, EventHelix.com has implemented this design pattern in a realtime system.[http://www.eventhelix.com/RealtimeMantra/ManagerDesignPattern.htm] www.cs.wustl.edu has put together a great presentation on the Manager Design Pattern as well. [http://www.cs.wustl.edu/~schmidt/PLoP-96/sommerlad.ps.gz]
<pre>
from __future__ import generators  # only needed for Python 2.2
import random
def randomwalk_generator():
    last, rand = 1, random.random() # initialize candidate elements
    while rand > 0.1:              # threshhold terminator
        print '*',                  # display the rejection
        if abs(last-rand) >= 0.4:  # accept the number
            last = rand            # update prior value
            yield rand              # return AT THIS POINT
        rand = random.random()      # new candidate
    yield rand                      # return the final small element</pre>[http://www.ibm.com/developerworks/library/l-pycon.html]
A more simple approach is as follows:
<pre>
gen = randomwalk_generator()
try:
    while 1: print gen.next(),
except StopIteration:
    pass</pre>[http://www.ibm.com/developerworks/library/l-pycon.html]


----
----


===Conclusion===
===Conclusion===
There was an incredible number of design patterns that were included in the Pattern Almanac and many of them are extremely effective, even though they are seldom discussed. I have tried to expose a couple of the design patterns I saw most relevant. The conclusion I have reached from my research is that design patterns are a crutial means of software development and design and can be used more than they currently are.


As has been shown, iterators and generators can both be powerful programming elements throughout any programming language. We can also see that the new age view of using generators does allow for uses that are similar to closures and difficult with iterators.
----


===External References===
===External References===
[1] http://en.wikipedia.org/wiki/Iterator#Iterators_in_different_programming_languages


[2] http://java.sun.com/j2se/1.4.2/docs/api/java/util/Iterator.html
[1] http://en.wikipedia.org/wiki/Design_pattern_(computer_science)


[3] http://java.sun.com/j2se/1.4.2/docs/api/java/util/Iterator.html
[2]http://en.wikipedia.org/wiki/Singleton_pattern


[4] http://www.java-examples.com/iterate-through-elements-java-arraylist-using-iterator-example
[3]http://en.wikipedia.org/wiki/Adapter_pattern


[5] http://en.wikipedia.org/wiki/Ruby_programming_language
[4]http://en.wikipedia.org/wiki/Command_pattern


[6] http://en.wikipedia.org/wiki/Generator_%28computer_science%29
[5]http://en.wikipedia.org/wiki/Strategy_pattern


[7] http://en.wikipedia.org/wiki/Generator_%28computer_science%29
[6]http://www.smallmemory.com/almanac/


[8] http://www.python.org/dev/peps/pep-0289
[7] http://www.smallmemory.com/almanac/DysonEtc98.html


[9] http://www.python.org/dev/peps/pep-0289
[8] http://www.smallmemory.com/almanac/Noble99a.html


[10] http://en.wikipedia.org/wiki/Generator_%28computer_science%29
[9] http://www.smallmemory.com/almanac/Sommerlad98.html


[11] http://www.ibm.com/developerworks/library/l-pycon.html
[10] http://en.wikipedia.org/wiki/Finite_State_Machine


[12] http://www.ibm.com/developerworks/library/l-pycon.html
[11] http://synthesis.sbecker.net/articles/2006/01/19/active-record-relationship-design-patterns


[13] http://www.ibm.com/developerworks/library/l-pycon.html
[12] http://www.cs.wustl.edu/~schmidt/PLoP-96/sommerlad.ps.gz
 
[14] http://www.ibm.com/developerworks/library/l-pycon.html
 
----

Latest revision as of 15:00, 26 July 2008

Patterns Almanac. Peruse the Patterns Almanac for additional patterns that seem appropriate to cover in CSC/ECE 517. Explain why the patterns are appropriate for students to learn, and if possible, link to training materials (explanations, examples, etc.) for covering them. Your reviewers should rate your choices on how much value they will add to the course!

Design Patterns

Throughout the semester, the coursework has dedicated a lot of time to the discussion of Design Patterns. As stated by Christopher Alexander, in his book A Timeles Way of Building, a design pattern is a "solution to a problem in a context." Wikipedia defines software design patterns as follows: 

In software engineering, a design pattern is a general reusable solution to a commonly
occurring problem in software design. A design pattern is not a finished design that can be
transformed directly into code. It is a description or template for how to solve a problem 
that can be used in many different situations. [http://en.wikipedia.org/wiki/Design_pattern_
computer_science)]

Most of the design patterns we have discussed in class were O-O design patterns. For example, during our lectures on Ruby we discussed several design patterns such as the Singleton[1], the Adapter Pattern[2], the Command Pattern[3], and the Strategy Pattern[4] to name a few.

The design patterns discussed were by no means a comprehensive list. The Patterns Almanac[5] is a resource for other design patterns that could potentially be included in future CSC 517 course lecture work. I have selected to discuss State Patterns[6], Basic Relationship Patterns[7] and the Manager Pattern[8]

State Patterns

The State Patterns listed in this section of Linda Risings Patterns Almanac where authored by P. Dyson, B. Anderson under the category 'Behavioral, Finite State Machines'. The patterns included in the State Patterns section are the Patterns State Object, State Member, Pure State, Exposed State, State-Driven Transitions, Owner-Driven Transitions and Pattern:Default State.

I thought that this would be an excellent candidate for a potential design pattern addition, especially to a course that discussed processes that could be encapsulated in state objects. The overall pattern tries to define a manner to efficiently handle changes of state, during runtime for example, tracking current state attributes and to try to delegate state-dependant behavior to the state object.

Other variations of the State Pattern are also discussed by Wikipedia[9] which also references implementing the design pattern with Finite State Machines[10].

Basic Relationship Patterns

The Basic Relationship Design Pattern narrows in on the design of any relationship between two objects in a program and how these objects can effectively and efficiently communicate and interact. This was authored by J. Noble in the Behavioral Category. The pattern is made up of a Relationship vs. Attribute Pattern, a Relationship Object, an Active Value Pattern and a Mutual Friends pattern.

I believe this is a viable design pattern for discussion because of the nature of programming that is continuously using relationships between object. To be able to have a design pattern to maximize understanding between programmers on how these relationships always work would be a vast improvement in the current programming standards.

There are many variations on this design pattern, one of which is the Active Record Relationship Design Pattern[11]. The discussion of this design pattern could be incorporated with our study of Ruby and design patterns.

Manager Pattern

The Manager Design Pattern listed by the Patterns Almanac is the final pattern that I think would be a great addition to the cirriculum. The Manager Designed Pattern was authored by P. Sommerland and the key aspect is that the management of each instance of a class is extracted from the object itself and designated to a Manager object. This allows for a much wider variation in functionality and for the reuse of Manager objects for a wide array of classes.

I have seen recently in a project I have worked on at work the implementation of this design pattern. It has led to a simplification of real-time job management where each job object is assigned to a manager to handle it's management operations. I think this would is an excellent design pattern and could use more exposure.

Just like I have experienced, EventHelix.com has implemented this design pattern in a realtime system.[12] www.cs.wustl.edu has put together a great presentation on the Manager Design Pattern as well. [13]

Conclusion

There was an incredible number of design patterns that were included in the Pattern Almanac and many of them are extremely effective, even though they are seldom discussed. I have tried to expose a couple of the design patterns I saw most relevant. The conclusion I have reached from my research is that design patterns are a crutial means of software development and design and can be used more than they currently are.

External References

[1] http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

[2]http://en.wikipedia.org/wiki/Singleton_pattern

[3]http://en.wikipedia.org/wiki/Adapter_pattern

[4]http://en.wikipedia.org/wiki/Command_pattern

[5]http://en.wikipedia.org/wiki/Strategy_pattern

[6]http://www.smallmemory.com/almanac/

[7] http://www.smallmemory.com/almanac/DysonEtc98.html

[8] http://www.smallmemory.com/almanac/Noble99a.html

[9] http://www.smallmemory.com/almanac/Sommerlad98.html

[10] http://en.wikipedia.org/wiki/Finite_State_Machine

[11] http://synthesis.sbecker.net/articles/2006/01/19/active-record-relationship-design-patterns

[12] http://www.cs.wustl.edu/~schmidt/PLoP-96/sommerlad.ps.gz

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Summer_2008/wiki3_2_acmoore2&oldid=15827"