CSC/ECE 517 Summer 2008/wiki3 3 dm: Difference between revisions

Latest revision as of 03:29, 1 August 2008

Topic Description

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!

Introduction

In CSC/ECE 517 we cover a number of basic design patterns in an effort to aid our coding development. Design Patterns like most intellectual processes provide a framework for thought, getting you to think of components and polymorphism. By examining the problem and deciding which pattern fits it most closely, we create a basic framework for the program to be constructed from. A factory pattern dedicates certain components and behaves in a certain manner, so using it for an application implies both structure and function.

However we only cover a small number of the possible patterns, with many of them being either too simplistic to be encompassing or providing the necessary structure for the sort of programming we are likely to need to perform in the work force. While they provide a basic tool box, but that isn't going to sufficient for wielding or electrician's work. So we need more complex patterns to deal with much more likely scenarios.

Pattern Definitions

Acyclical Vistor A more robust version of the more traditional visitor pattern, it defines operations to be performed on an object without adding them to the class itself or the class hierarchy. This can be useful if one needs to build handling or transformation functions that would otherwise not be a part of that class hierarchy. Avoids the dependency loops that can otherwise result in visitor or other rigid designs. This pattern is our default pattern for discussing functions or even classes that we can't fit into a design or to add necessary functionality. So this is your go to pattern when your boss requires additional functionality that your object structure can't handle or you need add a handler/converter function for an object that doesn't fit into your object structure or increase the complexity to unacceptable degrees.
Command Processor A more complex version of the command pattern, it is defined by creating an object to encapsulate a request. It allows you to create parameters for the methods that go with the request, allow for customization based on the client. This pattern allows for scheduling requests and creating queues. This pattern can handle many different 'clients', creating a very versatile request and handling engine. A good example would be an object that handles request for locks or encryption. By creating a central object that handles the other "commands" and the overall scheduling can add a significant amount of flexibility. By creating a basic framework for the command, you can then use that processor to schedule them without having to modify the processor. This is also the basis for any interpreted languages or scripting, and prove valuable insight should you need to construct a custom controls for a program.
Half-Object+Protocol A pattern that deals with multiple address spaces and the problems with getting information between them. Since you cannot have a single object that exists in more than 1 address space, you divide the object into two interdependent objects which use a protocol to communicate. This is a valuable pattern as its the basis of every type of distributed and internet structure, server/clients or even distributed nodes needing to communicate and being in separate address spaces. Besides simply being the basic pattern for anything that functions on the internet or distributed computing, it also can prove useful for dividing objects over multiple threads as well. Given the increasingly common multiple core system, especially with hyperthreading, this is exceptionally useful.
Pipes and Filters A pattern dealing primarily with streams of data, something that is more and more common in days of feeds and streaming. By constructing a pipeline as your primary object and then applying filters to generate the correct objects at the other end are particularly useful. Pipes connect filters which are the abstraction on any data operation. Any sort of input stream will naturally lead to this pattern. This can be a file stream or bit stream, which is becoming more common as more information is streamed in from cameras. Facial recognition and filters designed to break images down to data points a computer can interpret is an ever more common field.
Wrapper Facade Based on the facade pattern, this pattern provides a robust object to encompass low-level data structures and operations. This is designed to make those structures easier to work with and provided additional functionality. Anytime that an object needs to deal with an int or any other primitive, it should have a wrapper. But primarily this deals lower-level interfaces like those that handles or manages the input from registers and other elements. At it can also handle the functionality that we don't want to expose to the rest of program as well, like encryption generation and the like.
Presentation-Abstraction-Controller PAC can be seen as a generalization and extension of Model/View/Controller. It defines a structure for interactive software systems in the form of a hierarchy of cooperating agents.Every agent is responsible for a specific aspect of the application’s functionality and consists of three components: presentation, abstraction and control.The key to the pattern is that PAC agents can be built up into layers with the Presentation API of each lower agent creating a higher abstraction for the next level.
Broker "The Broker architectural pattern can be used to structure distributed software systems with decoupled components that interact by remote service invocations. A broker component is responsible for coordinating communication, such as forwarding requests, as well as for transmitting results and exceptions." (Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software Architecture: A System Of Patterns. West Sussex, England: John Wiley & Sons Ltd., 1996
Client-Dispatcher-Server "The Client-Dispatcher-Server design pattern introduces an intermediate layer between clients and servers, the dispatcher component. It provides location transparency by means of a name service, and hides the details of the establishment of the communication connection between clients and servers." (Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, M. Stal. Pattern-Oriented Software Architecture: A System Of Patterns. West Sussex, England: John Wiley & Sons Ltd., 1996)
Reflection "The Reflection architectural pattern provides a mechanism for changing structure and behavior of software systems dynamically. It supports the modification of fundamental aspects, such as type structures and function call mechanisms. In this pattern, an application is split into two parts. A meta level provides information about selected system properties and makes the software self-aware. A base level includes the application logic. Its implementation builds on the meta level. Changes to information kept in the meta level affect subsequent base-level behavior." (Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software Architecture: A System Of Patterns. West Sussex, England: John Wiley & Sons Ltd., 1996)
Pluggable Factory Create objects from a repository. When a client requests an object from the repository, a reseller object can instantiate a class in the repository by name. Clients can also query the repository for a list of class names.This pattern is an extension of Factory Method [Gamma+95] and Abstract Factory [Gamma+95].

Conclusions

Overall, each of these patterns provides more descriptive and focused scenarios. Each of these design patterns are less likely to appropriate for a given program, as they have more specific requires. But in return they provide much greater detail or deal with problems that the other patterns cannot properly cope with. These select few are examples that will likely be much more common in the future, in both distributed and internet development. These new patterns are more tools for the box, providing more information and dealing with scenarios. Most of the modern applications are likely to fall into using these patterns.

@@ Line 8: / Line 8: @@
 ===Pattern Definitions===
-#[http://www.smallmemory.com/almanac/Martin98.html Acyclical Vistor] A more robust version of the more traditional visitor pattern, it defines operations to be performed on an object without adding them to the class itself or the class hierarchy.  This can be useful if one needs to build handling or transformation functions that would otherwise not be a part of that class hierarchy.  This visitor would be a valuable addition to our hierarchy as it becomes useful in any situation where the class contains information needed in a program but not in the form that is needed or otherwise needs to be operated.  Avoids the dependency loops that can otherwise result in visitor or other rigid designs.
+#[http://www.smallmemory.com/almanac/Martin98.html Acyclical Vistor] A more robust version of the more traditional visitor pattern, it defines operations to be performed on an object without adding them to the class itself or the class hierarchy.  This can be useful if one needs to build handling or transformation functions that would otherwise not be a part of that class hierarchy. Avoids the dependency loops that can otherwise result in visitor or other rigid designs. This pattern is our default pattern for discussing functions or even classes that we can't fit into a design or to add necessary functionality.  So this is your go to pattern when your boss requires additional functionality that your object structure can't handle or you need add a handler/converter function for an object that doesn't fit into your object structure or increase the complexity to unacceptable degrees.
-#[http://www.smallmemory.com/almanac/Sommerlad96.html Command Processor] A more complex version of the command pattern, it is defined by creating an object to encapsulate a request.  It allows you to create parameters for the methods that go with the request, allow for customization based on the client.  This pattern allows for scheduling requests and creating queues. This pattern can handle many different 'clients', creating a very versatile request and handling engine.  A good example would be an object that handles request for locks or encryption.
+#[http://www.smallmemory.com/almanac/Sommerlad96.html Command Processor] A more complex version of the command pattern, it is defined by creating an object to encapsulate a request.  It allows you to create parameters for the methods that go with the request, allow for customization based on the client.  This pattern allows for scheduling requests and creating queues. This pattern can handle many different 'clients', creating a very versatile request and handling engine.  A good example would be an object that handles request for locks or encryption. By creating a central object that handles the other "commands" and the overall scheduling can add a significant amount of flexibility.  By creating a basic framework for the command, you can then use that processor to schedule them without having to modify the processor.  This is also the basis for any interpreted languages or scripting, and prove valuable insight should you need to construct a custom controls for a program.
-#[http://www.smallmemory.com/almanac/Meszaros95.html Half-Object+Protocol] A pattern that deals with multiple address spaces and the problems with getting information between them.  Since you cannot have a single object that exists in more than 1 address space, you divide the object into two interdependent objects which use a protocol to communicate. This is a valuable pattern as its the basis of every type of distributed and internet structure, server/clients or even distributed nodes needing to communicate and being in separate address spaces.
+#[http://www.smallmemory.com/almanac/Meszaros95.html Half-Object+Protocol] A pattern that deals with multiple address spaces and the problems with getting information between them.  Since you cannot have a single object that exists in more than 1 address space, you divide the object into two interdependent objects which use a protocol to communicate. This is a valuable pattern as its the basis of every type of distributed and internet structure, server/clients or even distributed nodes needing to communicate and being in separate address spaces.  Besides simply being the basic pattern for anything that functions on the internet or distributed computing, it also can prove useful for dividing objects over multiple threads as well.  Given the increasingly common multiple core system, especially with hyperthreading, this is exceptionally useful.
-#[http://www.smallmemory.com/almanac/Meunier95.html Pipes and Filters] A pattern dealing primarily with streams of data, something that is more and more common in days of feeds and streaming.  By constructing a pipeline as your primary object and then applying filters to generate the correct objects at the other end are particularly useful. Pipes connect filters which are the abstraction on any data operation.
+#[http://www.smallmemory.com/almanac/Meunier95.html Pipes and Filters] A pattern dealing primarily with streams of data, something that is more and more common in days of feeds and streaming.  By constructing a pipeline as your primary object and then applying filters to generate the correct objects at the other end are particularly useful. Pipes connect filters which are the abstraction on any data operation.  Any sort of input stream will naturally lead to this pattern.  This can be a file stream or bit stream, which is becoming more common as more information is streamed in from cameras.  Facial recognition and filters designed to break images down to data points a computer can interpret is an ever more common field.
-#[http://www.smallmemory.com/almanac/Schmidt99.html Wrapper Facade] Based on the facade pattern, this pattern provides a robust object to encompass low-level data structures and operations. This is designed to make those structures easier to work with and provided additional functionality.
+#[http://www.smallmemory.com/almanac/Schmidt99.html Wrapper Facade] Based on the facade pattern, this pattern provides a robust object to encompass low-level data structures and operations. This is designed to make those structures easier to work with and provided additional functionality.  Anytime that an object needs to deal with an int or any other primitive, it should have a wrapper.  But primarily this deals lower-level interfaces like those that handles or manages the input from registers and other elements.  At it can also handle the functionality that we don't want to expose to the rest of program as well, like encryption generation and the like.
-#[http://www.automationit.hut.fi/julkaisut/documents/seminars/sem_s02/Honkanen_paper.pdf Gamma95]:The approach that [Gamma95] takes is to use design patterns to raise the expressiveness and level of description in object-oriented programming. For [Gamma95] the patterns represent a way to increase reuse of object-oriented software. Once found, the experienced programmers reuse the good solutions again and again." Each design pattern systematically names, explains, and evaluates and important and recurring design in object-oriented system. " [Gamma95, p. 2]The two classification of patterns defined by [Gamma95] are purpose and scope. The purpose reflects what pattern does: Creational patterns such as Abstract Factory, Builder or Singleton involve in creation of objects; Structural patterns such as Adapter, Flyweight, or Proxy structure the object relations and composition; Behavioral patterns such as Iterator, Mediator, or Observer involve in object interactions.The scope specifies whether the pattern applies to classes or to objects. The relationships in class patterns are static and they define relationships between classes. Object patterns deal with dynamic object relationships which can change at run-time. The beauty and pain of object-oriented software is that the software code does not tell much about how the objects and their relationships behave in run-time. The dynamic behavior of well designed object oriented software makes software very flexible and difficult to understand. The design patterns help to divide and structure the software code so that the reusability and flexibility is maximized and the code is still understandable.
+#[http://msdn.microsoft.com/en-us/library/ms998499.aspx Presentation-Abstraction-Controller] PAC can be seen as a generalization and extension of Model/View/Controller. It defines a structure for interactive software systems in the form of a hierarchy of cooperating agents.Every agent is responsible for a specific aspect of the application’s functionality and consists of three components: presentation, abstraction and control.The key to the pattern is that PAC agents can be built up into layers with the Presentation API of each lower agent creating a higher abstraction for the next level.
-#[http://web.ist.utl.pt/rito.silva/mdo/papers/Kobryn.html Buschmann96]:Architectural patterns: We need to develop architectural patterns that can be reused across domains (e.g., banking, insurance, manufacturing) and across implementation strategies (e.g. CORBA, ActiveX/DCOM, Java ORBs). The pattern-oriented software architecture approach described by [Buschmann 96] provides a good foundation for architectural patterns.
+#[http://www.vico.org/pages/PatronsDisseny/Pattern%20Broker Broker] "The Broker architectural pattern can be used to structure distributed software systems with decoupled components that interact by remote service invocations. A broker component is responsible for coordinating communication, such as forwarding requests, as well as for transmitting results and exceptions." (Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software Architecture: A System Of Patterns. West Sussex, England: John Wiley & Sons Ltd., 1996
+#[http://www.smallmemory.com/almanac/SommerladEtc96.html Client-Dispatcher-Server] "The Client-Dispatcher-Server design pattern introduces an intermediate layer between clients and servers, the dispatcher component. It provides location transparency by means of a name service, and hides the details of the establishment of the communication connection between clients and servers." (Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, M. Stal. Pattern-Oriented Software Architecture: A System Of Patterns. West Sussex, England: John Wiley & Sons Ltd., 1996)
+#[http://www.smallmemory.com/almanac/BuschmannEtc96.html Reflection] "The Reflection architectural pattern provides a mechanism for changing structure and behavior of software systems dynamically. It supports the modification of fundamental aspects, such as type structures and function call mechanisms. In this pattern, an application is split into two parts. A meta level provides information about selected system properties and makes the software self-aware. A base level includes the application logic. Its implementation builds on the meta level. Changes to information kept in the meta level affect subsequent base-level behavior." (Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software Architecture: A System Of Patterns. West Sussex, England: John Wiley & Sons Ltd., 1996)
+#[http://www.cix.co.uk/~smallmemory/almanac/VandenBroeckeEtc97.html Pluggable Factory] Create objects from a repository. When a client requests an object from the repository, a reseller object can instantiate a class in the repository by name. Clients can also query the repository for a list of class names.This pattern is an extension of Factory Method [Gamma+95] and Abstract Factory [Gamma+95].
 ===Conclusions===
-Overall, each of these patterns provide a more descriptive and more focused scenario.  Each of these design patterns are less likely to appropriate for a given program, as they have more specific requires.  But in return they provide much greater detail or deal with problems that the other patterns cannot properly cope with.  These select few are examples that will likely be much more common in the future, in both distributed and internet development.
+Overall, each of these patterns provides more descriptive and focused scenarios.  Each of these design patterns are less likely to appropriate for a given program, as they have more specific requires.  But in return they provide much greater detail or deal with problems that the other patterns cannot properly cope with.  These select few are examples that will likely be much more common in the future, in both distributed and internet development.  These new patterns are more tools for the box, providing more information and dealing with scenarios.  Most of the modern applications are likely to fall into using these patterns.
 ===Related Links===
 #http://c2.com/cgi/wiki?AcyclicVisitor
+#http://www.vico.org/pages/PatronsDisseny/Pattern%20Command%20Processor/index.html
+#http://jan.newmarch.name/distjava/hopp/lecture.html
+#http://msdn.microsoft.com/en-us/library/ms978599.aspx
+#http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.5282
 #http://web.ist.utl.pt/rito.silva/mdo/papers/Kobryn.html
 #http://www.automationit.hut.fi/julkaisut/documents/seminars/sem_s02/Honkanen_paper.pdf
@@ Line 27: / Line 34: @@
 #http://www.smallmemory.com/almanac/Martin98.html
 #http://www.smallmemory.com/almanac/Sommerlad96.html
+#http://www.cix.co.uk/~smallmemory/almanac/VandenBroeckeEtc97.html
+#http://www.smallmemory.com/almanac/BuschmannEtc96.html
+#http://www.vico.org/pages/PatronsDisseny/Pattern%20Broker

CSC/ECE 517 Summer 2008/wiki3 3 dm: Difference between revisions

Latest revision as of 03:29, 1 August 2008

Contents

Topic Description

Introduction

Pattern Definitions

Conclusions

Related Links

Navigation menu

CSC/ECE 517 Summer 2008/wiki3 3 dm: Difference between revisions

Latest revision as of 03:29, 1 August 2008

Topic Description

Introduction

Pattern Definitions

Conclusions

Related Links

Navigation menu

Search