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
Line 13: Line 13:


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==
Line 20: Line 22:


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==
==Basic Relationship Patterns==
Line 27: Line 31:


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


==Manager Pattern==
==Manager Pattern==
---


===Conclusion===
===Conclusion===
---


===External References===
===External References===
Line 51: Line 61:


[http://www.smallmemory.com/almanac/Sommerlad98.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]
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]
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.
<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===
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===
[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
[3] http://java.sun.com/j2se/1.4.2/docs/api/java/util/Iterator.html
[4] http://www.java-examples.com/iterate-through-elements-java-arraylist-using-iterator-example
[5] http://en.wikipedia.org/wiki/Ruby_programming_language
[6] http://en.wikipedia.org/wiki/Generator_%28computer_science%29
[7] http://en.wikipedia.org/wiki/Generator_%28computer_science%29
[8] http://www.python.org/dev/peps/pep-0289
[9] http://www.python.org/dev/peps/pep-0289
[10] http://en.wikipedia.org/wiki/Generator_%28computer_science%29
[11] http://www.ibm.com/developerworks/library/l-pycon.html
[12] http://www.ibm.com/developerworks/library/l-pycon.html
[13] http://www.ibm.com/developerworks/library/l-pycon.html
[14] http://www.ibm.com/developerworks/library/l-pycon.html
----

Revision as of 14:27, 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. The discussion of this design pattern could be incorporated with our study of Ruby and design patterns.

---

Manager Pattern

---

Conclusion

---

External References

[11]

[12]

[13]

[14]

[15] to name a few.

[16]

[17]

[18]

[19]

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