Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Summer 2008/wiki3 5 rp

2008-07-31T01:31:46Z

Rapodraz:

=Pure Fabrication=
Sometimes it is a good idea to introduce into a system an object that has no counterpart in the real world. This is called the pure fabrication pattern. Find examples of pure fabrication, and weave them into a narrative that can teach programmers when it is helpful and when it is not helpful to fabricate objects.

=Background=
All design patterns, regardless of their specific purpose, are born from the same basic principles. These principles include [http://en.wikipedia.org/wiki/Cohesion_(computer_science) high cohesion], [http://en.wikipedia.org/wiki/Coupling_(computer_science) low coupling], and other features which result in flexible, maintainable, extensible code. Most often it is possible to separate the objects of an OO design into real world abstractions, or objects which reflect well known design patterns, such as a factory or an observer. Sometimes, however, the need for high cohesion, low coupling, and separation of dependence exists within software when there is no real world object representation or familiar design pattern to provide a solution. This is when pure fabrication is needed. Simply put, pure fabrication means creating a class object completely unrelated to the problem domain specifically for the purpose of achieving some degree of high cohesion, low coupling, potential for code re-use and high maintainability.

Pure Fabrication is often attributed to Craig Larman as part of his nine [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] design patterns. Each of these patterns is similar to all other design patterns in that they strive to achieve code refactoring, decoupling, and reusability. Arguably, they are more generic than the [http://en.wikipedia.org/wiki/Design_Patterns GoF] patterns, and pure fabrication is perhaps the most generic of them. In fact, pure fabrication is so generic that often existing well-known design patterns can be considered instances of Pure Fabrication. To put it another way, pure fabrication means to create a new design pattern.

=Examples of Pure Fabrication=
As mentioned above, several well known design patterns can be considered instances of Pure Fabrication. For example, Strategy and Command began as Pure Fabrications, but are common enough that a more specific name for each has been adopted. In a problem domain sense, they do not abstract a real world object. Each simply exists to promote decoupling between other objects in a system.

This following example of Pure Fabrication is given in Larman's [http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691/ref=sr_11_1?ie=UTF8&qid=1216994566&sr=11-1 book], Applying UML and Design Patterns - An Introduction to Object-Oriented Analysis and Design and Iterative Development. Consider a class Sale, which represented a purchase or transaction record. The system using the class requires storing the records in a relational database. The functionality required to do this could exist in the Sale class, however, this would mean Sale class would need to know specifics about the interface into the database. It would need to directly call database functions, which is not in the interest of the Sale class (this violates high cohesion). Also, if the system were to change its persistent storage mechanism in the future, the Sale class would have to be modified to adapt to the new storage interface (this violates low coupling).

The solution is to create a new class whose sole responsibility is to save Sale records. This class could be called PersistantStorageBroker, and Sale would interact with it via a single save() method. The save() method is generic enough that it does not introduce unnecessary knowledge into the Sale class, and high cohesion is maintained. The PersistantStorageBroker class would know the details of the relational database interface, and so if future modifications were made to adapt to a new persistant storage mechanism, the Sale class could still use the save() method. In this, low coupling is achieved. The only class which would require modifications then is PersistantStorageBroker, but that is OK because that is the intent. 
[[Image:Wiki3A.jpg]] 
The above picture shows how the Sale class without the PersistantStorageBroker class would adapt to a new database type. It would need an Adapter class to bridge the two interfaces.
[[Image:Wiki3B.jpg]] 
The above picture shows how the PersistantStorageBroker class would facilitate adapting to a new database type. 
It is easy to see that this Pure Fabrication is close to other patterns. It is almost an [http://en.wikipedia.org/wiki/Adapter_pattern Adapter] pattern, except an Adapter typically connects two existing interfaces. In both cases, a design pattern is used to accommodate change in the database interface. It is easy to recognize the first example as using the Adapter pattern: a new class is created to accept the old interface and connect it to the new interface. The other example is similar, but with some key differences. First, the Sale class does not directly interface with any database type, old or new. It only interfaces with the PersistantStorageBroker class. Second, the PersistantStorageBroker class exists from the very beginning; it is not added later when a new interface is required. In this, it anticipates change, unlike the Adaptor which comes about reactively. So, the PersistantStorageBroker class is not quite an Adapter, it is a Pure Fabrication.

=The Case Against Pure Fabrication=
It is important not to overuse Pure Fabrication, or other design patterns for that matter, if it results in many small classes with too much interaction between them. Too much of this can actually cause unexpected coupling problems despite the intent to decouple objects. Further, this can increase the yo-yo effect (both vertical and horizontal) while reading source code. If code is spread among too many classes it can affect maintainability in a different, yet equally as negative way as tightly coupled code.

Similarly, sometimes it is OK to write code that has some degree of coupling, as there is always a trade off. In some cases, code does not necessarily need to be "pluggable" or compatible with all possible future uses and modifications of the code. It is important to realize this is a judgement call, and the design of the code and it's intent must be carefully analyzed. Code that is known ahead of time to have potential reuse obviously would benefit from using the priciples of Pure Fabrication and other design patterns, code such as framework code. However, if concessions are made in the design "just in case" future modification is needed, it may be good to re-evaluate the separation of responsibilities. Remember, re-factoring code in the future for maintenance reasons is not always bad, if it can be foreseen that the modifications are trivial compared to the cost of creating and implementing a very flexible, adaptable design.

=External Links=
[http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Pure Fabrication GRASP Pattern] 
[http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx Over-Architecting with Pure Fabrication] 
[http://www.google.com/url?sa=t&ct=res&cd=4&url=http%3A%2F%2Falcor.concordia.ca%2F~smw%2Fcomp354%2FL22web-2x2.pdf&ei=SdSJSLv8NYWshgTq6u1T&usg=AFQjCNFvKxZzrAps2Z0rGnTGdCrpvI3D6w&sig2=NdOWfIQrIPIIipsaaTZDFg Pure Fabrication Notes] 
[http://www.google.com/url?sa=t&ct=res&cd=9&url=http%3A%2F%2Fhebb.cis.uoguelph.ca%2F~dastacey%2FCIS3200%2FLectures%2FPDF%2FDesignPatterns3.pdf&ei=SdSJSLv8NYWshgTq6u1T&usg=AFQjCNEjBkMRZ_NhQpLp4zWjM9mlrBBhKw&sig2=S8iBydS82trn51IxSMbhbQ More GRASP Patterns] 
[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

File:Wiki3B.jpg

2008-07-31T01:25:52Z

Rapodraz:

File:Wiki3A.jpg

2008-07-31T01:25:35Z

Rapodraz:

CSC/ECE 517 Summer 2008/wiki3 5 rp

2008-07-31T01:25:18Z

Rapodraz:

=Pure Fabrication=
Sometimes it is a good idea to introduce into a system an object that has no counterpart in the real world. This is called the pure fabrication pattern. Find examples of pure fabrication, and weave them into a narrative that can teach programmers when it is helpful and when it is not helpful to fabricate objects.

=Background=
All design patterns, regardless of their specific purpose, are born from the same basic principles. These principles include [http://en.wikipedia.org/wiki/Cohesion_(computer_science) high cohesion], [http://en.wikipedia.org/wiki/Coupling_(computer_science) low coupling], and other features which result in flexible, maintainable, extensible code. Most often it is possible to separate the objects of an OO design into real world abstractions, or objects which reflect well known design patterns, such as a factory or an observer. Sometimes, however, the need for high cohesion, low coupling, and separation of dependence exists within software when there is no real world object representation or familiar design pattern to provide a solution. This is when pure fabrication is needed. Simply put, pure fabrication means creating a class object completely unrelated to the problem domain specifically for the purpose of achieving some degree of high cohesion, low coupling, potential for code re-use and high maintainability.

Pure Fabrication is often attributed to Craig Larman as part of his nine [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] design patterns. Each of these patterns is similar to all other design patterns in that they strive to achieve code refactoring, decoupling, and reusability. Arguably, they are more generic than the [http://en.wikipedia.org/wiki/Design_Patterns GoF] patterns, and pure fabrication is perhaps the most generic of them. In fact, pure fabrication is so generic that often existing well-known design patterns can be considered instances of Pure Fabrication. To put it another way, pure fabrication means to create a new design pattern.

=Examples of Pure Fabrication=
As mentioned above, several well known design patterns can be considered instances of Pure Fabrication. For example, Strategy and Command began as Pure Fabrications, but are common enough that a more specific name for each has been adopted. In a problem domain sense, they do not abstract a real world object. Each simply exists to promote decoupling between other objects in a system.

This following example of Pure Fabrication is given in Larman's [http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691/ref=sr_11_1?ie=UTF8&qid=1216994566&sr=11-1 book], Applying UML and Design Patterns - An Introduction to Object-Oriented Analysis and Design and Iterative Development. Consider a class Sale, which represented a purchase or transaction record. The system using the class requires storing the records in a relational database. The functionality required to do this could exist in the Sale class, however, this would mean Sale class would need to know specifics about the interface into the database. It would need to directly call database functions, which is not in the interest of the Sale class (this violates high cohesion). Also, if the system were to change its persistent storage mechanism in the future, the Sale class would have to be modified to adapt to the new storage interface (this violates low coupling).

The solution is to create a new class whose sole responsibility is to save Sale records. This class could be called PersistantStorageBroker, and Sale would interact with it via a single save() method. The save() method is generic enough that it does not introduce unnecessary knowledge into the Sale class, and high cohesion is maintained. The PersistantStorageBroker class would know the details of the relational database interface, and so if future modifications were made to adapt to a new persistant storage mechanism, the Sale class could still use the save() method. In this, low coupling is achieved. The only class which would require modifications then is PersistantStorageBroker, but that is OK because that is the intent.

It is easy to see that this Pure Fabrication is close to other patterns. It is almost an [http://en.wikipedia.org/wiki/Adapter_pattern Adapter] pattern, except an Adapter typically connects two existing interfaces. Here, the PersistantStorageBroker is connecting to an existing interface (to the relational database), which defining a new one (the save() method). It is like anticipating the need for an Adapter in the future, and so creating one up front.

=The Case Against Pure Fabrication=
It is important not to overuse Pure Fabrication, or other design patterns for that matter, if it results in many small classes with too much interaction between them. Too much of this can actually cause unexpected coupling problems despite the intent to decouple objects. Further, this can increase the yo-yo effect (both vertical and horizontal) while reading source code. If code is spread among too many classes it can affect maintainability in a different, yet equally as negative way as tightly coupled code.

Similarly, sometimes it is OK to write code that has some degree of coupling, as there is always a trade off. In some cases, code does not necessarily need to be "pluggable" or compatible with all possible future uses and modifications of the code. It is important to realize this is a judgement call, and the design of the code and it's intent must be carefully analyzed. Code that is known ahead of time to have potential reuse obviously would benefit from using the priciples of Pure Fabrication and other design patterns, code such as framework code. However, if concessions are made in the design "just in case" future modification is needed, it may be good to re-evaluate the separation of responsibilities. Remember, re-factoring code in the future for maintenance reasons is not always bad, if it can be foreseen that the modifications are trivial compared to the cost of creating and implementing a very flexible, adaptable design.

=External Links=
[http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Pure Fabrication GRASP Pattern] 
[http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx Over-Architecting with Pure Fabrication] 
[http://www.google.com/url?sa=t&ct=res&cd=4&url=http%3A%2F%2Falcor.concordia.ca%2F~smw%2Fcomp354%2FL22web-2x2.pdf&ei=SdSJSLv8NYWshgTq6u1T&usg=AFQjCNFvKxZzrAps2Z0rGnTGdCrpvI3D6w&sig2=NdOWfIQrIPIIipsaaTZDFg Pure Fabrication Notes] 
[http://www.google.com/url?sa=t&ct=res&cd=9&url=http%3A%2F%2Fhebb.cis.uoguelph.ca%2F~dastacey%2FCIS3200%2FLectures%2FPDF%2FDesignPatterns3.pdf&ei=SdSJSLv8NYWshgTq6u1T&usg=AFQjCNEjBkMRZ_NhQpLp4zWjM9mlrBBhKw&sig2=S8iBydS82trn51IxSMbhbQ More GRASP Patterns] 
[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 5 rp

2008-07-31T01:24:27Z

Rapodraz:

=Pure Fabrication=
Sometimes it is a good idea to introduce into a system an object that has no counterpart in the real world. This is called the pure fabrication pattern. Find examples of pure fabrication, and weave them into a narrative that can teach programmers when it is helpful and when it is not helpful to fabricate objects.

=Background=
All design patterns, regardless of their specific purpose, are born from the same basic principles. These principles include [http://en.wikipedia.org/wiki/Cohesion_(computer_science) high cohesion], [http://en.wikipedia.org/wiki/Coupling_(computer_science) low coupling], and other features which result in flexible, maintainable, extensible code. Most often it is possible to separate the objects of an OO design into real world abstractions, or objects which reflect well known design patterns, such as a factory or an observer. Sometimes, however, the need for high cohesion, low coupling, and separation of dependence exists within software when there is no real world object representation or familiar design pattern to provide a solution. This is when pure fabrication is needed. Simply put, pure fabrication means creating a class object completely unrelated to the problem domain specifically for the purpose of achieving some degree of high cohesion, low coupling, potential for code re-use and high maintainability.

Pure Fabrication is often attributed to Craig Larman as part of his nine [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] design patterns. Each of these patterns is similar to all other design patterns in that they strive to achieve code refactoring, decoupling, and reusability. Arguably, they are more generic than the [http://en.wikipedia.org/wiki/Design_Patterns GoF] patterns, and pure fabrication is perhaps the most generic of them. In fact, pure fabrication is so generic that often existing well-known design patterns can be considered instances of Pure Fabrication. To put it another way, pure fabrication means to create a new design pattern.

=Examples of Pure Fabrication=
As mentioned above, several well known design patterns can be considered instances of Pure Fabrication. For example, Strategy and Command began as Pure Fabrications, but are common enough that a more specific name for each has been adopted. In a problem domain sense, they do not abstract a real world object. Each simply exists to promote decoupling between other objects in a system.

This following example of Pure Fabrication is given in Larman's [http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691/ref=sr_11_1?ie=UTF8&qid=1216994566&sr=11-1 book], Applying UML and Design Patterns - An Introduction to Object-Oriented Analysis and Design and Iterative Development. Consider a class Sale, which represented a purchase or transaction record. The system using the class requires storing the records in a relational database. The functionality required to do this could exist in the Sale class, however, this would mean Sale class would need to know specifics about the interface into the database. It would need to directly call database functions, which is not in the interest of the Sale class (this violates high cohesion). Also, if the system were to change its persistent storage mechanism in the future, the Sale class would have to be modified to adapt to the new storage interface (this violates low coupling).

The solution is to create a new class whose sole responsibility is to save Sale records. This class could be called PersistantStorageBroker, and Sale would interact with it via a single save() method. The save() method is generic enough that it does not introduce unnecessary knowledge into the Sale class, and high cohesion is maintained. The PersistantStorageBroker class would know the details of the relational database interface, and so if future modifications were made to adapt to a new persistant storage mechanism, the Sale class could still use the save() method. In this, low coupling is achieved. The only class which would require modifications then is PersistantStorageBroker, but that is OK because that is the intent.
[[Image:Example.jpg]]
It is easy to see that this Pure Fabrication is close to other patterns. It is almost an [http://en.wikipedia.org/wiki/Adapter_pattern Adapter] pattern, except an Adapter typically connects two existing interfaces. Here, the PersistantStorageBroker is connecting to an existing interface (to the relational database), which defining a new one (the save() method). It is like anticipating the need for an Adapter in the future, and so creating one up front.

=The Case Against Pure Fabrication=
It is important not to overuse Pure Fabrication, or other design patterns for that matter, if it results in many small classes with too much interaction between them. Too much of this can actually cause unexpected coupling problems despite the intent to decouple objects. Further, this can increase the yo-yo effect (both vertical and horizontal) while reading source code. If code is spread among too many classes it can affect maintainability in a different, yet equally as negative way as tightly coupled code.

Similarly, sometimes it is OK to write code that has some degree of coupling, as there is always a trade off. In some cases, code does not necessarily need to be "pluggable" or compatible with all possible future uses and modifications of the code. It is important to realize this is a judgement call, and the design of the code and it's intent must be carefully analyzed. Code that is known ahead of time to have potential reuse obviously would benefit from using the priciples of Pure Fabrication and other design patterns, code such as framework code. However, if concessions are made in the design "just in case" future modification is needed, it may be good to re-evaluate the separation of responsibilities. Remember, re-factoring code in the future for maintenance reasons is not always bad, if it can be foreseen that the modifications are trivial compared to the cost of creating and implementing a very flexible, adaptable design.

=External Links=
[http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Pure Fabrication GRASP Pattern] 
[http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx Over-Architecting with Pure Fabrication] 
[http://www.google.com/url?sa=t&ct=res&cd=4&url=http%3A%2F%2Falcor.concordia.ca%2F~smw%2Fcomp354%2FL22web-2x2.pdf&ei=SdSJSLv8NYWshgTq6u1T&usg=AFQjCNFvKxZzrAps2Z0rGnTGdCrpvI3D6w&sig2=NdOWfIQrIPIIipsaaTZDFg Pure Fabrication Notes] 
[http://www.google.com/url?sa=t&ct=res&cd=9&url=http%3A%2F%2Fhebb.cis.uoguelph.ca%2F~dastacey%2FCIS3200%2FLectures%2FPDF%2FDesignPatterns3.pdf&ei=SdSJSLv8NYWshgTq6u1T&usg=AFQjCNEjBkMRZ_NhQpLp4zWjM9mlrBBhKw&sig2=S8iBydS82trn51IxSMbhbQ More GRASP Patterns] 
[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]
[[Image:Example.jpg]]

CSC/ECE 517 Summer 2008/wiki3 5 rp

2008-07-31T01:11:47Z

Rapodraz:

=Pure Fabrication=
Sometimes it is a good idea to introduce into a system an object that has no counterpart in the real world. This is called the pure fabrication pattern. Find examples of pure fabrication, and weave them into a narrative that can teach programmers when it is helpful and when it is not helpful to fabricate objects.

=Background=
All design patterns, regardless of their specific purpose, are born from the same basic principles. These principles include [http://en.wikipedia.org/wiki/Cohesion_(computer_science) high cohesion], [http://en.wikipedia.org/wiki/Coupling_(computer_science) low coupling], and other features which result in flexible, maintainable, extensible code. Most often it is possible to separate the objects of an OO design into real world abstractions, or objects which reflect well known design patterns, such as a factory or an observer. Sometimes, however, the need for high cohesion, low coupling, and separation of dependence exists within software when there is no real world object representation or familiar design pattern to provide a solution. This is when pure fabrication is needed. Simply put, pure fabrication means creating a class object completely unrelated to the problem domain specifically for the purpose of achieving some degree of high cohesion, low coupling, potential for code re-use and high maintainability.

Pure Fabrication is often attributed to Craig Larman as part of his nine [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] design patterns. Each of these patterns is similar to all other design patterns in that they strive to achieve code refactoring, decoupling, and reusability. Arguably, they are more generic than the [http://en.wikipedia.org/wiki/Design_Patterns GoF] patterns, and pure fabrication is perhaps the most generic of them. In fact, pure fabrication is so generic that often existing well-known design patterns can be considered instances of Pure Fabrication. To put it another way, pure fabrication means to create a new design pattern.

=Examples of Pure Fabrication=
As mentioned above, several well known design patterns can be considered instances of Pure Fabrication. For example, Strategy and Command began as Pure Fabrications, but are common enough that a more specific name for each has been adopted. In a problem domain sense, they do not abstract a real world object. Each simply exists to promote decoupling between other objects in a system.

This following example of Pure Fabrication is given in Larman's [http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691/ref=sr_11_1?ie=UTF8&qid=1216994566&sr=11-1 book], Applying UML and Design Patterns - An Introduction to Object-Oriented Analysis and Design and Iterative Development. Consider a class Sale, which represented a purchase or transaction record. The system using the class requires storing the records in a relational database. The functionality required to do this could exist in the Sale class, however, this would mean Sale class would need to know specifics about the interface into the database. It would need to directly call database functions, which is not in the interest of the Sale class (this violates high cohesion). Also, if the system were to change its persistent storage mechanism in the future, the Sale class would have to be modified to adapt to the new storage interface (this violates low coupling).

The solution is to create a new class whose sole responsibility is to save Sale records. This class could be called PersistantStorageBroker, and Sale would interact with it via a single save() method. The save() method is generic enough that it does not introduce unnecessary knowledge into the Sale class, and high cohesion is maintained. The PersistantStorageBroker class would know the details of the relational database interface, and so if future modifications were made to adapt to a new persistant storage mechanism, the Sale class could still use the save() method. In this, low coupling is achieved. The only class which would require modifications then is PersistantStorageBroker, but that is OK because that is the intent.

It is easy to see that this Pure Fabrication is close to other patterns. It is almost an [http://en.wikipedia.org/wiki/Adapter_pattern Adapter] pattern, except an Adapter typically connects two existing interfaces. Here, the PersistantStorageBroker is connecting to an existing interface (to the relational database), which defining a new one (the save() method). It is like anticipating the need for an Adapter in the future, and so creating one up front.

=The Case Against Pure Fabrication=
It is important not to overuse Pure Fabrication, or other design patterns for that matter, if it results in many small classes with too much interaction between them. Too much of this can actually cause unexpected coupling problems despite the intent to decouple objects. Further, this can increase the yo-yo effect (both vertical and horizontal) while reading source code. If code is spread among too many classes it can affect maintainability in a different, yet equally as negative way as tightly coupled code.

Similarly, sometimes it is OK to write code that has some degree of coupling, as there is always a trade off. In some cases, code does not necessarily need to be "pluggable" or compatible with all possible future uses and modifications of the code. It is important to realize this is a judgement call, and the design of the code and it's intent must be carefully analyzed. Code that is known ahead of time to have potential reuse obviously would benefit from using the priciples of Pure Fabrication and other design patterns, code such as framework code. However, if concessions are made in the design "just in case" future modification is needed, it may be good to re-evaluate the separation of responsibilities. Remember, re-factoring code in the future for maintenance reasons is not always bad, if it can be foreseen that the modifications are trivial compared to the cost of creating and implementing a very flexible, adaptable design.

=External Links=
[http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Pure Fabrication GRASP Pattern] 
[http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx Over-Architecting with Pure Fabrication] 
[http://www.google.com/url?sa=t&ct=res&cd=4&url=http%3A%2F%2Falcor.concordia.ca%2F~smw%2Fcomp354%2FL22web-2x2.pdf&ei=SdSJSLv8NYWshgTq6u1T&usg=AFQjCNFvKxZzrAps2Z0rGnTGdCrpvI3D6w&sig2=NdOWfIQrIPIIipsaaTZDFg Pure Fabrication Notes] 
[http://www.google.com/url?sa=t&ct=res&cd=9&url=http%3A%2F%2Fhebb.cis.uoguelph.ca%2F~dastacey%2FCIS3200%2FLectures%2FPDF%2FDesignPatterns3.pdf&ei=SdSJSLv8NYWshgTq6u1T&usg=AFQjCNEjBkMRZ_NhQpLp4zWjM9mlrBBhKw&sig2=S8iBydS82trn51IxSMbhbQ More GRASP Patterns] 
[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 5 rp

2008-07-25T14:16:08Z

Rapodraz:

=Pure Fabrication=
Sometimes it is a good idea to introduce into a system an object that has no counterpart in the real world. This is called the pure fabrication pattern. Find examples of pure fabrication, and weave them into a narrative that can teach programmers when it is helpful and when it is not helpful to fabricate objects.

=Background=
All design patterns, regardless of their specific purpose, are born from the same basic principles. These principles include [http://en.wikipedia.org/wiki/Cohesion_(computer_science) high cohesion], [http://en.wikipedia.org/wiki/Coupling_(computer_science) low coupling], and other features which result in flexible, maintainable, extensible code. Most often it is possible to separate the objects of an OO design into real world abstractions, or objects which reflect well known design patterns, such as a factory or an observer. Sometimes, however, the need for high cohesion, low coupling, and separation of dependence exists within software when there is no real world object representation or familiar design pattern to provide a solution. This is when pure fabrication is needed. Simply put, pure fabrication means creating a class object completely unrelated to the problem domain specifically for the purpose of achieving some degree of high cohesion, low coupling, potential for code re-use and high maintainability.

Pure Fabrication is often attributed to Craig Larman as part of his nine [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] design patterns. Each of these patterns is similar to all other design patterns in that they strive to achieve code refactoring, decoupling, and reusability. Arguably, they are more generic than the [http://en.wikipedia.org/wiki/Design_Patterns GoF] patterns, and pure fabrication is perhaps the most generic of them. In fact, pure fabrication is so generic that often existing well-known design patterns can be considered instances of Pure Fabrication. To put it another way, pure fabrication means to create a new design pattern.

=Examples of Pure Fabrication=
As mentioned above, several well known design patterns can be considered instances of Pure Fabrication. For example, Strategy and Command began as Pure Fabrications, but are common enough that a more specific name for each has been adopted. In a problem domain sense, they do not abstract a real world object. Each simply exists to promote decoupling between other objects in a system.

This following example of Pure Fabrication is given in Larman's [http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691/ref=sr_11_1?ie=UTF8&qid=1216994566&sr=11-1 book], Applying UML and Design Patterns - An Introduction to Object-Oriented Analysis and Design and Iterative Development. Consider a class Sale, which represented a purchase or transaction record. The system using the class requires storing the records in a relational database. The functionality required to do this could exist in the Sale class, however, this would mean Sale class would need to know specifics about the interface into the database. It would need to directly call database functions, which is not in the interest of the Sale class (this violates high cohesion). Also, if the system were to change its persistent storage mechanism in the future, the Sale class would have to be modified to adapt to the new storage interface (this violates low coupling).

The solution is to create a new class whose sole responsibility is to save Sale records. This class could be called PersistantStorageBroker, and Sale would interact with it via a single save() method. The save() method is generic enough that it does not introduce unnecessary knowledge into the Sale class, and high cohesion is maintained. The PersistantStorageBroker class would know the details of the relational database interface, and so if future modifications were made to adapt to a new persistant storage mechanism, the Sale class could still use the save() method. In this, low coupling is achieved. The only class which would require modifications then is PersistantStorageBroker, but that is OK because that is the intent.

It is easy to see that this Pure Fabrication is close to other patterns. It is almost an [http://en.wikipedia.org/wiki/Adapter_pattern Adapter] pattern, except an Adapter typically connects two existing interfaces. Here, the PersistantStorageBroker is connecting to an existing interface (to the relational database), which defining a new one (the save() method). It is like anticipating the need for an Adapter in the future, and so creating one up front.

=The Case Against Pure Fabrication=
It is important not to overuse Pure Fabrication, or other design patterns for that matter, if it results in many small classes with too much interaction between them. Too much of this can actually cause unexpected coupling problems despite the intent to decouple objects. Further, this can increase the yo-yo effect (both vertical and horizontal) while reading source code. If code is spread among too many classes it can affect maintainability in a different, yet equally as negative way as tightly coupled code.

Similarly, sometimes it is OK to write code that has some degree of coupling, as there is always a trade off. In some cases, code does not necessarily need to be "pluggable" or compatible with all possible future uses and modifications of the code. It is important to realize this is a judgement call, and the design of the code and it's intent must be carefully analyzed. Code that is known ahead of time to have potential reuse obviously would benefit from using the priciples of Pure Fabrication and other design patterns, code such as framework code. However, if concessions are made in the design "just in case" future modification is needed, it may be good to re-evaluate the separation of responsibilities. Remember, re-factoring code in the future for maintenance reasons is not always bad, if it can be foreseen that the modifications are trivial compared to the cost of creating and implementing a very flexible, adaptable design.

=External Links=
http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx 
http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx 
http://www.google.com/url?sa=t&ct=res&cd=4&url=http%3A%2F%2Falcor.concordia.ca%2F~smw%2Fcomp354%2FL22web-2x2.pdf&ei=SdSJSLv8NYWshgTq6u1T&usg=AFQjCNFvKxZzrAps2Z0rGnTGdCrpvI3D6w&sig2=NdOWfIQrIPIIipsaaTZDFg 
http://www.google.com/url?sa=t&ct=res&cd=9&url=http%3A%2F%2Fhebb.cis.uoguelph.ca%2F~dastacey%2FCIS3200%2FLectures%2FPDF%2FDesignPatterns3.pdf&ei=SdSJSLv8NYWshgTq6u1T&usg=AFQjCNEjBkMRZ_NhQpLp4zWjM9mlrBBhKw&sig2=S8iBydS82trn51IxSMbhbQ 
[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 5 rp

2008-07-25T14:14:28Z

Rapodraz:

=Pure Fabrication=
Sometimes it is a good idea to introduce into a system an object that has no counterpart in the real world. This is called the pure fabrication pattern. Find examples of pure fabrication, and weave them into a narrative that can teach programmers when it is helpful and when it is not helpful to fabricate objects.

=Background=
All design patterns, regardless of their specific purpose, are born from the same basic principles. These principles include [http://en.wikipedia.org/wiki/Cohesion_(computer_science) high cohesion], [http://en.wikipedia.org/wiki/Coupling_(computer_science) low coupling], and other features which result in flexible, maintainable, extensible code. Most often it is possible to separate the objects of an OO design into real world abstractions, or objects which reflect well known design patterns, such as a factory or an observer. Sometimes, however, the need for high cohesion, low coupling, and separation of dependence exists within software when there is no real world object representation or familiar design pattern to provide a solution. This is when pure fabrication is needed. Simply put, pure fabrication means creating a class object completely unrelated to the problem domain specifically for the purpose of achieving some degree of high cohesion, low coupling, potential for code re-use and high maintainability.

Pure Fabrication is often attributed to Craig Larman as part of his nine [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) GRASP] design patterns. Each of these patterns is similar to all other design patterns in that they strive to achieve code refactoring, decoupling, and reusability. Arguably, they are more generic than the [http://en.wikipedia.org/wiki/Design_Patterns GoF] patterns, and pure fabrication is perhaps the most generic of them. In fact, pure fabrication is so generic that often existing well-known design patterns can be considered instances of Pure Fabrication. To put it another way, pure fabrication means to create a new design pattern.

=Examples of Pure Fabrication=
As mentioned above, several well known design patterns can be considered instances of Pure Fabrication. For example, Strategy and Command began as Pure Fabrications, but are common enough that a more specific name for each has been adopted. In a problem domain sense, they do not abstract a real world object. Each simply exists to promote decoupling between other objects in a system.

This following example of Pure Fabrication is given in Larman's [http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691/ref=sr_11_1?ie=UTF8&qid=1216994566&sr=11-1 book], Applying UML and Design Patterns - An Introduction to Object-Oriented Analysis and Design and Iterative Development. Consider a class Sale, which represented a purchase or transaction record. The system using the class requires storing the records in a relational database. The functionality required to do this could exist in the Sale class, however, this would mean Sale class would need to know specifics about the interface into the database. It would need to directly call database functions, which is not in the interest of the Sale class (this violates high cohesion). Also, if the system were to change its persistent storage mechanism in the future, the Sale class would have to be modified to adapt to the new storage interface (this violates low coupling).

The solution is to create a new class whose sole responsibility is to save Sale records. This class could be called PersistantStorageBroker, and Sale would interact with it via a single save() method. The save() method is generic enough that it does not introduce unnecessary knowledge into the Save class, and high cohesion is maintained. The PersistantStorageBroker class would know the details of the relational database interface, and so if future modifications were made to adapt to a new persistant storage mechanism, the Sale class could still use the save() method. In this, low coupling is achieved. The only class which would require modifications then is PersistantStorageBroker, but that is OK because that is the intent.

It is easy to see that this Pure Fabrication is close to other patterns. It is almost an Adapter pattern, except an Adapter typically connects two existing interfaces. Here, the PersistantStorageBroker is connecting to an existing interface (to the relational database), which defining a new one (the save() method). It is like anticipating the need for an Adapter in the future, and so creating one up front.

=The Case Against Pure Fabrication=
It is important not to overuse Pure Fabrication, or other design patterns for that matter, if it results in many small classes with too much interaction between them. Too much of this can actually cause unexpected coupling problems despite the intent to decouple objects. Further, this can increase the yo-yo effect (both vertical and horizontal) while reading source code. If code is spread among too many classes it can affect maintainability in a different, yet equally as negative way as tightly coupled code.

Similarly, sometimes it is OK to write code that has some degree of coupling, as there is always a trade off. In some cases, code does not necessarily need to be "pluggable" or compatible with all possible future uses and modifications of the code. It is important to realize this is a judgement call, and the design of the code and it's intent must be carefully analyzed. Code that is known ahead of time to have potential reuse obviously would benefit from using the priciples of Pure Fabrication and other design patterns, code such as framework code. However, if concessions are made in the design "just in case" future modification is needed, it may be good to re-evaluate the separation of responsibilities. Remember, re-factoring code in the future for maintenance reasons is not always bad, if it can be foreseen that the modifications are trivial compared to the cost of creating and implementing a very flexible, adaptable design.

=External Links=
http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx 
http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx 
http://www.google.com/url?sa=t&ct=res&cd=4&url=http%3A%2F%2Falcor.concordia.ca%2F~smw%2Fcomp354%2FL22web-2x2.pdf&ei=SdSJSLv8NYWshgTq6u1T&usg=AFQjCNFvKxZzrAps2Z0rGnTGdCrpvI3D6w&sig2=NdOWfIQrIPIIipsaaTZDFg 
http://www.google.com/url?sa=t&ct=res&cd=9&url=http%3A%2F%2Fhebb.cis.uoguelph.ca%2F~dastacey%2FCIS3200%2FLectures%2FPDF%2FDesignPatterns3.pdf&ei=SdSJSLv8NYWshgTq6u1T&usg=AFQjCNEjBkMRZ_NhQpLp4zWjM9mlrBBhKw&sig2=S8iBydS82trn51IxSMbhbQ 
[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 5 rp

2008-07-25T13:46:43Z

Rapodraz:

CSC/ECE 517 Summer 2008/wiki3 5 rp

2008-07-25T13:28:57Z

Rapodraz:

CSC/ECE 517 Summer 2008/wiki3 5 rp

2008-07-25T13:22:50Z

Rapodraz:

CSC/ECE 517 Summer 2008/wiki3 5 rp

2008-07-25T13:17:07Z

Rapodraz:

CSC/ECE 517 Summer 2008/wiki3 5 rp

2008-07-25T13:06:47Z

Rapodraz:

CSC/ECE 517 Summer 2008/wiki3 5 rp

2008-07-24T18:28:30Z

Rapodraz:

CSC/ECE 517 Summer 2008/wiki3 5 rp

2008-07-24T18:26:50Z

Rapodraz:

CSC/ECE 517 Summer 2008/wiki3 5 rp

2008-07-24T18:25:22Z

Rapodraz:

CSC/ECE 517 Summer 2008/wiki3 5 rp

2008-07-24T18:24:54Z

Rapodraz:

==Pure Fabrication==
Sometimes it is a good idea to introduce into a system an object that has no counterpart in the real world. This is called the pure fabrication pattern. Find examples of pure fabrication, and weave them into a narrative that can teach programmers when it is helpful and when it is not helpful to fabricate objects.

=What is Pure Fabrication=

=External Links=

CSC/ECE 517 Summer 2008/wiki3 5 rp

2008-07-24T18:22:23Z

Rapodraz:

Pure Fabrication
Sometimes it is a good idea to introduce into a system an object that has no counterpart in the real world. This is called the pure fabrication pattern. Find examples of pure fabrication, and weave them into a narrative that can teach programmers when it is helpful and when it is not helpful to fabricate objects.

CSC/ECE 517 Summer 2008/wiki3 Assignment

2008-07-24T18:21:13Z

Rapodraz:

#[[CSC/ECE_517_Summer_2008/wiki3_1_th | RDB/OO Patterns]]
#[[CSC/ECE_517_Summer_2008/wiki3_1_PF | Pure Fabrication]]
#[[CSC/ECE_517_Summer_2008/wiki3_5_rp | Pure Fabrication]]
#[[CSC/ECE_517_Summer_2008/wiki3_7_SHOP_PAT | Shopper Pattern]]
#[[CSC/ECE_517_Summer_2008/wiki3_6_esb | Protected Variation]]
----
[[CSC/ECE 517 Summer 2008]]

CSC/ECE 517 Summer 2008/wiki3 5 rp

2008-07-24T18:20:29Z

Rapodraz:

Pure Fabrication

CSC/ECE 517 Summer 2008/wiki2 2 rapodraz

2008-07-07T14:32:48Z

Rapodraz:

=Variable Naming in Programming=
Almost all programming languages allow the programmer a great deal of freedom when naming variables in a program's source code. It may seem like this is an obvious advantage, as it gives the programmer a great deal of flexibility. However, this level of freedom may incorrectly reflect the notion that variable naming is unimportant. Since variable identifiers can be named in many different ways, they often are, and the result is a high degree of inconsistency that can be problematic for code readability and maintenance.

=Naming Conventions=
In most contexts, the term [http://en.wikipedia.org/wiki/Identifier_naming_convention "naming conventions"] refers to a set of rules used to name variables depending on its scope, type, etc. Naming conventions are a form of [http://en.wikipedia.org/wiki/Metadata metadata]. A good set of naming conventions can be very useful and is often part of good programming practice. Naming conventions may differ among programming languages and projects, but the purpose is the same: to provide information about the variable identifier in the name itself. Some examples of common naming conventions include:

*Using lowercase for a single word name
*Using capitalization or underscores to separate multi-word names
*Using all caps for constants
*Using variable prefixes to indicate scope or type

Examples of good, well known naming conventions are [http://msdn.microsoft.com/en-us/library/aa260976(VS.60).aspx Hungarian Notation], and the [http://www.symbian.com/developer/techlib/v70sdocs/doc_source/DevGuides/EssentialIdioms/NamingConvs.guide.html Symbian OS naming conventions].
There are other aspects of naming which may not be specific to a particular naming convention, but are part of general good practice, such a name's length and the use of abbreviations. It is generally preferred to use short names and abbreviations when possible without confusing the meaning of the name. Common examples are using "ptr" for "pointer" or "ctr" for "counter." Be careful when abbreviating, however, and consider whether removing vowels from a word or simply truncating the word is more effective. For example, for a word like "customer," "cust" may be a better abbreviation than "cstmr."

Often variable names include a verb, and in this case it is always best to use the active voice. For example, never use a name like "recieverForMessages" when "messageReciever" would work. It would even be possible to abbreviate this to "msgReceiver" to be even more concise. As another example, don't use "countOfItems" when you can use "itemCount." Never use negative forms of a word for variable names, such as state. Otherwise you may run into confusing [http://en.wikipedia.org/wiki/Double_negative double-negative] boolean expressions in code.

Be careful that your variable name is not the same as a [http://en.wikipedia.org/wiki/Reserved_word reserved word] in a language. Some compilers will not even allow you to do this, but some will, and it may resolve the name clash in a way you or others do not expect. Do not use variables that differ in name by only a few letters, as this may result in accidentally writing incorrect code that compiles without errors.

=Naming Choices=
Choosing a good variable name means naming a variable in a way that will help the reader understand the program's design and purpose. This is different from naming conventions in that it can not be so strictly defined, and is concerned with individual variables as opposed to all variables.

It is best to avoid names that give no information as to how the variable is to be used, or simply tell the type of the variable. Examples are naming a variable something like data, buffer, info, string, etc. These don't tell the reader anything about the variable (of course a variable is data). Further, this is not always a trivial problem to solve, as a descriptive name may not be concise and that can be worse than a meaningless name. An example is an operation on a string that involves parsing and editing a string, then returning the modified string. In this case, naming the two strings "inputString" and "outputString" at least gives some information on how they are intended to be used. Even better would be to replace the word string with what the data is supposed to represent. For example if the code is modifying an address, the variables could be named "inputAddress" and "outputAddress." Another example of this is performing complicated sums of modifications of numbers. Consider the following code:

$total = $price * $qty;
$total2 = $total - $discount;
$total2 += $total * $taxrate;
$total3 = $purchase_order_value + $available_credit;
if ( $total2 < $total3 ) {
print "You can't afford this order.";
}

Even though this is not very complicated code, if one were to look at the end of it first, they would be forced to go back and read the beginning to grasp what was going on. This is a much better version:

$order_total = $price * $qty;
$payable_total = $order_total - $discount;
$payable_total += $payable_total * $taxrate;
$available_funds = $purchase_order_value + $availble_credit;
if ( $payable_total < $available_funds ) {
print "You can't afford this order.";
}

Similarly, often the meaning of a value is lost by using [http://en.wikipedia.org/wiki/Magic_number_(programming) magic numbers]. By using a literal numeric value instead of a named variable identifier, there can be confusing as to the meaning of the value. Although most programmers would recognize 3.14 as an approximation of Pi, it is an example of a value which could be defined as a constant first. By doing this, the programmer provides the reader with some information as to why and how the value is being used.

Whenever possible, it is good to use names relevant to the context of the program's domain. Similarly, it is important to realize whether or not a term used is indeed common knowledge of a domain or not. For example, if you are working on a database application that manages bank accounts, then "account" may be an appropriate word used to name an account record. If it is well documented and there is no other meaning of the word within the context then it will work. However, recognize that "account" has different or ambiguous meanings in other contexts. So, if you used the same word to name records in database of library users, make sure the word means the same thing in that context.

Along these lines, it is a good idea to use design pattern names in class that are meant to implement them. If you are writing a class that uses the Factory class, by naming it with the word Factory, it is immediately clear to other programmers familiar with that design patter what the class is supposed to do and roughly how it is going to do it. This helps greatly with maintenance. In contrast, consider if the same class had been named Creator. The programmer has a general idea the class is going to create things, but will still need to read through the code to realize its purpose and scope.

=External Links=
http://www.symbian.com/developer/techlib/v70sdocs/doc_source/DevGuides/EssentialIdioms/NamingConvs.guide.html 
http://www.kamath.com/columns/squareone/so001_whatname1.asp 
http://msdn.microsoft.com/en-us/library/aa260976(VS.60).aspx 
http://chrisbensen.blogspot.com/2007/07/variable-names-to-avoid.html 
http://blogs.msdn.com/marcelolr/archive/2005/08/04/Marcelo.aspx 
http://www.oualline.com/style/c03.html 
http://www.oreillynet.com/onlamp/blog/2004/03/the_worlds_two_worst_variable.html 
http://perl.plover.com/varvarname.html 
http://c2.com/cgi/wiki?BadVariableNames 
http://www.objectmentor.com/resources/articles/naming.htm 

[[CSC/ECE 517 Summer 2008/wiki2 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki2 2 rapodraz

2008-06-23T20:28:20Z

Rapodraz:

=Variable Naming in Programming=
Almost all programming languages allow the programmer a great deal of freedom when naming variables in a program's source code. It may seem like this is an obvious advantage, as it gives the programmer a great deal of flexibility. However, this level of freedom may incorrectly reflect the notion that variable naming is unimportant. Since variable identifiers can be named in many different ways, they often are, and the result is a high degree of inconsistency that can be problematic for code readability and maintenance.

=Naming Conventions=
In most contexts, the term [http://en.wikipedia.org/wiki/Identifier_naming_convention "naming conventions"] refers to a set of rules used to name variables depending on its scope, type, etc. Naming conventions are a form of [http://en.wikipedia.org/wiki/Metadata metadata]. A good set of naming conventions can be very useful and is often part of good programming practice. Naming conventions may differ among programming languages and projects, but the purpose is the same: to provide information about the variable identifier in the name itself. Some examples of common naming conventions include:

*Using lowercase for a single word name
*Using capitalization or underscores to separate multi-word names
*Using all caps for constants
*Using variable prefixes to indicate scope or type

Examples of good, well known naming conventions are [http://msdn.microsoft.com/en-us/library/aa260976(VS.60).aspx Hungarian Notation], and the [http://www.symbian.com/developer/techlib/v70sdocs/doc_source/DevGuides/EssentialIdioms/NamingConvs.guide.html Symbian OS naming conventions].
There are other aspects of naming which may not be specific to a particular naming convention, but are part of general good practice, such a name's length and the use of abbreviations. It is generally preferred to use short names and abbreviations when possible without confusing the meaning of the name. Common examples are using "ptr" for "pointer" or "ctr" for "counter." Be careful when abbreviating, however, and consider whether removing vowels from a word or simply truncating the word is more effective. For example, for a word like "customer," "cust" may be a better abbreviation than "cstmr."

Often variable names include a verb, and in this case it is always best to use the active voice. For example, never use a name like "recieverForMessages" when "messageReciever" would work. It would even be possible to abbreviate this to "msgReceiver" to be even more concise. As another example, don't use "countOfItems" when you can use "itemCount." Never use negative forms of a word for variable names, such as state. Otherwise you may run into confusing [http://en.wikipedia.org/wiki/Double_negative double-negative] boolean expressions in code.

Be careful that your variable name is not the same as a [http://en.wikipedia.org/wiki/Reserved_word reserved word] in a language. Some compilers will not even allow you to do this, but some will, and it may resolve the name clash in a way your or others do not expect. Do not use variables that different in name by only a few letters, as this may result in accidentally writing incorrect code that compiles without errors.

=Naming Choices=
Choosing a good variable name means naming a variable in a way that will help the reader understand the program's design and purpose. This is different from naming conventions in that it can not be so strictly defined, and is concerned with individual variables as opposed to all variables.

It is best to avoid names that give no information as to how the variable is to be used, or simply tell the type of the variable. Examples are naming a variable something like data, buffer, info, string, etc. These don't tell the reader anything about the variable (of course a variable is data). Further, this is not always a trivial problem to solve, as a descriptive name may not be concise and that can be worse than a meaningless name. An example is an operation on a string that involves parsing and editing a string, then returning the modified string. In this case, naming the two strings "inputString" and "outputString" at least gives some information on how they are intended to be used. Even better would be to replace the word string with what the data is supposed to represent. For example if the code is modifying an address, the variables could be named "inputAddress" and "outputAddress." Another example of this is performing complicated sums of modifications of numbers. Consider the following code:

$total = $price * $qty;
$total2 = $total - $discount;
$total2 += $total * $taxrate;
$total3 = $purchase_order_value + $available_credit;
if ( $total2 < $total3 ) {
print "You can't afford this order.";
}

Even though this is not very complicated code, if one were to look at the end of it first, they would be forced to go back and read the beginning to grasp what was going on. This is a much better version:

$order_total = $price * $qty;
$payable_total = $order_total - $discount;
$payable_total += $payable_total * $taxrate;
$available_funds = $purchase_order_value + $availble_credit;
if ( $payable_total < $available_funds ) {
print "You can't afford this order.";
}

Similarly, often the meaning of a value is lost by using [http://en.wikipedia.org/wiki/Magic_number_(programming) magic numbers]. By using a literal numeric value instead of a named variable identifier, there can be confusing as to the meaning of the value. Although most programmers would recognize 3.14 as an approximation of Pi, it is an example of a value which could be defined as a constant first. By doing this, the programmer provides the reader with some information as to why and how the value is being used.

Whenever possible, it is good to use names relevant to the context of the program's domain. Similarly, it is important to realize whether or not a term used is indeed common knowledge of a domain or not. For example, if you are working on a database application that manages bank accounts, then "account" may be an appropriate word used to name an account record. If it is well documented and there is no other meaning of the word within the context then it will work. However, recognize that "account" has different or ambiguous meanings in other contexts. So, if you used the same word to name records in database of library users, make sure the word means the same thing in that context.

Along these lines, it is a good idea to use design pattern names in class that are meant to implement them. If you are writing a class that uses the Factory class, by naming it with the word Factory, it is immediately clear to other programmers familiar with that design patter what the class is supposed to do and roughly how it is going to do it. This helps greatly with maintenance. In contrast, consider if the same class had been named Creator. The programmer has a general idea the class is going to create things, but will still need to read through the code to realize its purpose and scope.

=External Links=
http://www.symbian.com/developer/techlib/v70sdocs/doc_source/DevGuides/EssentialIdioms/NamingConvs.guide.html 
http://www.kamath.com/columns/squareone/so001_whatname1.asp 
http://msdn.microsoft.com/en-us/library/aa260976(VS.60).aspx 
http://chrisbensen.blogspot.com/2007/07/variable-names-to-avoid.html 
http://blogs.msdn.com/marcelolr/archive/2005/08/04/Marcelo.aspx 
http://www.oualline.com/style/c03.html 
http://www.oreillynet.com/onlamp/blog/2004/03/the_worlds_two_worst_variable.html 
http://perl.plover.com/varvarname.html 
http://c2.com/cgi/wiki?BadVariableNames 
http://www.objectmentor.com/resources/articles/naming.htm 

[[CSC/ECE 517 Summer 2008/wiki2 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki2 2 rapodraz

2008-06-23T20:08:39Z

Rapodraz:

=Variable Naming in Programming=
Almost all programming languages allow the programmer a great deal of freedom when naming variables in a program's source code. It may seem like this is an obvious advantage, as it gives the programmer a great deal of flexibility. However, this level of freedom may incorrectly reflect the notion that variable naming is unimportant. Since variable identifiers can be named in many different ways, they often are, and the result is a high degree of inconsistency that can be problematic for code readability and maintenance.

=Naming Conventions=
In most contexts, the term [http://en.wikipedia.org/wiki/Identifier_naming_convention "naming conventions"] refers to a set of rules used to name variables depending on its scope, type, etc. Naming conventions are a form of [http://en.wikipedia.org/wiki/Metadata metadata]. A good set of naming conventions can be very useful and is often part of good programming practice. Naming conventions may differ among programming languages and projects, but the purpose is the same: to provide information about the variable identifier in the name itself. Some examples of common naming conventions include:

*Using lowercase for a single word name
*Using capitalization or underscores to separate multi-word names
*Using all caps for constants
*Using variable prefixes to indicate scope or type

Examples of good, well known naming conventions are [http://msdn.microsoft.com/en-us/library/aa260976(VS.60).aspx Hungarian Notation], and the [http://www.symbian.com/developer/techlib/v70sdocs/doc_source/DevGuides/EssentialIdioms/NamingConvs.guide.html Symbian OS naming conventions].
There are other aspects of naming which may not be specific to a particular naming convention, but are part of general good practice, such a name's length and the use of abbreviations. It is generally preferred to use short names and abbreviations when possible without confusing the meaning of the name. Common examples are using "ptr" for "pointer" or "ctr" for "counter." Be careful when abbreviating, however, and consider whether removing vowels from a word or simply truncating the word is more effective. For example, for a word like "customer," "cust" may be a better abbreviation than "cstmr."

Often variable names include a verb, and in this case it is always best to use the active voice. For example, never use a name like "recieverForMessages" when "messageReciever" would work. It would even be possible to abbreviate this to "msgReceiver" to be even more concise. As another example, don't use "countOfItems" when you can use "itemCount." Never use negative forms of a word for variable names, such as state. Otherwise you may run into confusing [http://en.wikipedia.org/wiki/Double_negative double-negative] boolean expressions in code.

Be careful that your variable name is not the same as a [http://en.wikipedia.org/wiki/Reserved_word reserved word] in a language. Some compilers will not even allow you to do this, but some will, and it may resolve the name clash in a way your or others do not expect. Do not use variables that different in name by only a few letters, as this may result in accidentally writing incorrect code that compiles without errors.

=Naming Choices=
Choosing a good variable name means naming a variable in a way that will help the reader understand the program's design and purpose. This is different from naming conventions in that it can not be so strictly defined, and is concerned with individual variables as opposed to all variables.

It is best to avoid names that give no information as to how the variable is to be used, or simply tell the type of the variable. Examples are naming a variable something like data, buffer, info, string, etc. These don't tell the reader anything about the variable (of course a variable is data). Further, this is not always a trivial problem to solve, as a descriptive name may not be concise and that can be worse than a meaningless name. An example is an operation on a string that involves parsing and editing a string, then returning the modified string. In this case, naming the two strings "inputString" and "outputString" at least gives some information on how they are intended to be used. Even better would be to replace the word string with what the data is supposed to represent. For example if the code is modifying an address, the variables could be named "inputAddress" and "outputAddress." Another example of this is performing complicated sums of modifications of numbers. Consider the following code:

$total = $price * $qty;
$total2 = $total - $discount;
$total2 += $total * $taxrate;
$total3 = $purchase_order_value + $available_credit;
if ( $total2 < $total3 ) {
print "You can't afford this order.";
}

Even though this is not very complicated code, if one were to look at the end of it first, they would be forced to go back and read the beginning to grasp what was going on. This is a much better version:

$order_total = $price * $qty;
$payable_total = $order_total - $discount;
$payable_total += $payable_total * $taxrate;
$available_funds = $purchase_order_value + $availble_credit;
if ( $payable_total < $available_funds ) {
print "You can't afford this order.";
}

magic numbers
Naming to design patterns

=External Links=
http://www.symbian.com/developer/techlib/v70sdocs/doc_source/DevGuides/EssentialIdioms/NamingConvs.guide.html 
http://www.kamath.com/columns/squareone/so001_whatname1.asp 
http://msdn.microsoft.com/en-us/library/aa260976(VS.60).aspx 
http://chrisbensen.blogspot.com/2007/07/variable-names-to-avoid.html 
http://blogs.msdn.com/marcelolr/archive/2005/08/04/Marcelo.aspx 
http://www.oualline.com/style/c03.html 
http://www.oreillynet.com/onlamp/blog/2004/03/the_worlds_two_worst_variable.html 
http://perl.plover.com/varvarname.html 
http://c2.com/cgi/wiki?BadVariableNames 
http://www.objectmentor.com/resources/articles/naming.htm 

[[CSC/ECE 517 Summer 2008/wiki2 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki2 2 rapodraz

2008-06-23T19:13:33Z

Rapodraz:

CSC/ECE 517 Summer 2008/wiki2 2 rapodraz

2008-06-23T19:09:46Z

Rapodraz:

CSC/ECE 517 Summer 2008/wiki2 2 rapodraz

2008-06-23T18:51:49Z

Rapodraz:

CSC/ECE 517 Summer 2008/wiki2 2 rapodraz

2008-06-23T18:45:10Z

Rapodraz:

CSC/ECE 517 Summer 2008/wiki2 2 rapodraz

2008-06-23T18:29:12Z

Rapodraz:

CSC/ECE 517 Summer 2008/wiki2 2 rapodraz

2008-06-23T18:02:57Z

Rapodraz:

CSC/ECE 517 Summer 2008/wiki2 2 rapodraz

2008-06-23T17:57:50Z

Rapodraz:

CSC/ECE 517 Summer 2008/wiki2 2 rapodraz

2008-06-23T17:50:47Z

Rapodraz:

CSC/ECE 517 Summer 2008/wiki2 2 rapodraz

2008-06-23T17:50:20Z

Rapodraz:

CSC/ECE 517 Summer 2008/wiki2 2 rapodraz

2008-06-23T17:26:30Z

Rapodraz:

CSC/ECE 517 Summer 2008/wiki2 2 rapodraz

2008-06-23T17:26:04Z

Rapodraz:

CSC/ECE 517 Summer 2008/wiki2 2 rapodraz

2008-06-23T17:20:28Z

Rapodraz:

CSC/ECE 517 Summer 2008/wiki2 2 rapodraz

2008-06-23T17:20:10Z

Rapodraz:

==Variable Naming in Programming==
Almost all programming languages allow the programmer a great deal of freedom when naming variables in a program's source code. It may seem like this is an obvious advantage, as it gives the programmer a great deal of flexibility. However, this level of freedom may incorrectly reflect the notion that variable naming is unimportant. Since variables can be named in many different ways, they often are, and the result is a high degree of inconsistency that can be problematic for code readability and maintenance.

=Naming Conventions=

=Naming Choices=

=Using Design Pattern Names=

=External Links=
[[CSC/ECE 517 Summer 2008/wiki2 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki2 2 rapodraz

2008-06-23T14:08:25Z

Rapodraz:

Naming Conventions

[[CSC/ECE 517 Summer 2008/wiki2 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki2 Assignment

2008-06-23T14:07:46Z

Rapodraz:

#[[CSC/ECE_517_Summer_2008/wiki2_1_tm | Rails vs. PHP]]
#[[CSC/ECE_517_Summer_2008/wiki2_2_rapodraz | Naming Conventions]]
----
[[CSC/ECE 517 Summer 2008]]

CSC/ECE 517 Summer 2008/wiki2 2 rapodraz

2008-06-23T14:06:49Z

Rapodraz:

Naming Conventions

CSC/ECE 517 Summer 2008/wiki1 1 rp

2008-06-11T02:01:21Z

Rapodraz:

=Regular Expressions in Ruby vs. Java=
Ruby and Java both support Regular Expressions, but generally speaking, Ruby's dynamic typing and native regular expression support allow for performing equivalent or similar functions more simply and with less code.

==General Differences==
Ruby can perform most regular expression related functions using a combination of the String and Regexp classes. The String class has several methods that take a Regexp as a parameter, and similarly the Regexp class has methods that take a String as a parameter. Ruby also provides a shorthand for defining regular expressions, a string surrounded by forward slashes: Regexp.new('test') and /test/ are equivalent.

Mostly, Java does not have native support for regular expressions. While the String class has a few methods that can perform related functions, they do not necessarily follow the conventional rules of regular expressions. Proper regular expression support is available in Java through several packages, most notably java.util.regex, which is Sun's standard package available in Java 1.4+. This package provides two classes, Pattern and Matcher, which are respectively used to define and operate on regular expressions. These classes work in conjunction with the String class to perform regular expression functions.

==Code Example: find a regular expression match within a String==
In Ruby, there are 2 simple ways to do this, the main difference between them being that one is a String method and one is a Regexp method.
First the String method, the [http://www.ruby-doc.org/core/classes/String.html#M000792 =~] operator, which returns the index in the string at which the pattern first matches.

"This is a string" =~ /is/
>> 2
"This is a string" =~ /hello/
>> nil

An equivalent way to do this is with the Regexp method match(). Note that match() returns a [http://www.ruby-doc.org/core/classes/MatchData.html MatchData] object if successful.

/is/.match("This is a string")
>> #<MatchData:0x5e1715c>
/hello/.match("This is a string")
>> nil

In Java, it is possible to do a simple version of this using only the String.matches() method, however this is a boolean method so we will miss out on the extra index information that Ruby's =~ will give.

String str = "This is a string";
str.matches("is"); // does not do what you expect. This will return false.
str.matches(".*is.*"); // will return true

In the above code, it is important to realize that matches() will only return true if the entire string from beginning to end is a match. In other words, it behaves as if the input regular expression "regexp" is actually "^regexp$". For matching a subsring or the entire string, a workaround such as the third line above must be used.

==Code Example: collecting regular expression matches within a String in an array of Strings==
In Ruby, a simple way to collect regular expression matches from a String is to use the String.scan() method, which takes a regular expression as a parameter, and returns a String array.

matches = "This is a string".scan(/is/)
>> ["is", "is"]

A slightly more complex regular expression:

matches = "This is a string".scan(/\w*i\w*/) # match any word with an i in it
>> ["This", "is", "string"]

In Java, it is a bit more complicated. There are no shortcut methods as part of the String class to help us do what we want, and we need to make use of the Pattern and Matcher classes.

String myString = new String("This is a string");
Pattern myPattern = Pattern.compile("is");
Matcher myMatcher = myPattern.matcher(myString);
Vector results = new Vector(); // to store the resulting matches 
while (myMatcher.find()) { // find() finds the next match, evaluates to false if not found
results.add(myMatcher.group()); // group() returns the matched string
}

=Links=
http://www.regular-expressions.info/ruby.html 
http://www.regular-expressions.info/java.html 
http://www.javaworld.com/javaworld/jw-07-2001/jw-0713-regex.html?page=3 
http://regex.info/java.html 
http://www.blueskyonmars.com/2003/10/31/14-stringmatches-is-dumb/ 
http://www.ruby-doc.org/core/classes/MatchData.html 

[[CSC/ECE 517 Summer 2008/wiki1 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki1 1 rp

2008-06-11T02:01:10Z

Rapodraz:

=Regular Expressions in Ruby vs. Java= hello
Ruby and Java both support Regular Expressions, but generally speaking, Ruby's dynamic typing and native regular expression support allow for performing equivalent or similar functions more simply and with less code.

==General Differences==
Ruby can perform most regular expression related functions using a combination of the String and Regexp classes. The String class has several methods that take a Regexp as a parameter, and similarly the Regexp class has methods that take a String as a parameter. Ruby also provides a shorthand for defining regular expressions, a string surrounded by forward slashes: Regexp.new('test') and /test/ are equivalent.

Mostly, Java does not have native support for regular expressions. While the String class has a few methods that can perform related functions, they do not necessarily follow the conventional rules of regular expressions. Proper regular expression support is available in Java through several packages, most notably java.util.regex, which is Sun's standard package available in Java 1.4+. This package provides two classes, Pattern and Matcher, which are respectively used to define and operate on regular expressions. These classes work in conjunction with the String class to perform regular expression functions.

==Code Example: find a regular expression match within a String==
In Ruby, there are 2 simple ways to do this, the main difference between them being that one is a String method and one is a Regexp method.
First the String method, the [http://www.ruby-doc.org/core/classes/String.html#M000792 =~] operator, which returns the index in the string at which the pattern first matches.

"This is a string" =~ /is/
>> 2
"This is a string" =~ /hello/
>> nil

An equivalent way to do this is with the Regexp method match(). Note that match() returns a [http://www.ruby-doc.org/core/classes/MatchData.html MatchData] object if successful.

/is/.match("This is a string")
>> #<MatchData:0x5e1715c>
/hello/.match("This is a string")
>> nil

In Java, it is possible to do a simple version of this using only the String.matches() method, however this is a boolean method so we will miss out on the extra index information that Ruby's =~ will give.

String str = "This is a string";
str.matches("is"); // does not do what you expect. This will return false.
str.matches(".*is.*"); // will return true

In the above code, it is important to realize that matches() will only return true if the entire string from beginning to end is a match. In other words, it behaves as if the input regular expression "regexp" is actually "^regexp$". For matching a subsring or the entire string, a workaround such as the third line above must be used.

==Code Example: collecting regular expression matches within a String in an array of Strings==
In Ruby, a simple way to collect regular expression matches from a String is to use the String.scan() method, which takes a regular expression as a parameter, and returns a String array.

matches = "This is a string".scan(/is/)
>> ["is", "is"]

A slightly more complex regular expression:

matches = "This is a string".scan(/\w*i\w*/) # match any word with an i in it
>> ["This", "is", "string"]

In Java, it is a bit more complicated. There are no shortcut methods as part of the String class to help us do what we want, and we need to make use of the Pattern and Matcher classes.

String myString = new String("This is a string");
Pattern myPattern = Pattern.compile("is");
Matcher myMatcher = myPattern.matcher(myString);
Vector results = new Vector(); // to store the resulting matches 
while (myMatcher.find()) { // find() finds the next match, evaluates to false if not found
results.add(myMatcher.group()); // group() returns the matched string
}

=Links=
http://www.regular-expressions.info/ruby.html 
http://www.regular-expressions.info/java.html 
http://www.javaworld.com/javaworld/jw-07-2001/jw-0713-regex.html?page=3 
http://regex.info/java.html 
http://www.blueskyonmars.com/2003/10/31/14-stringmatches-is-dumb/ 
http://www.ruby-doc.org/core/classes/MatchData.html 

[[CSC/ECE 517 Summer 2008/wiki1 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki1 1 rapodraz

2008-06-11T02:00:54Z

Rapodraz:

CSC/ECE 517 Summer 2008/wiki1 1 rapodraz

2008-06-11T02:00:45Z

Rapodraz:

=Regular Expressions in Ruby vs. Java=hello
Ruby and Java both support Regular Expressions, but generally speaking, Ruby's dynamic typing and native regular expression support allow for performing equivalent or similar functions more simply and with less code.

==General Differences==
Ruby can perform most regular expression related functions using a combination of the String and Regexp classes. The String class has several methods that take a Regexp as a parameter, and similarly the Regexp class has methods that take a String as a parameter. Ruby also provides a shorthand for defining regular expressions, a string surrounded by forward slashes: Regexp.new('test') and /test/ are equivalent.

Mostly, Java does not have native support for regular expressions. While the String class has a few methods that can perform related functions, they do not necessarily follow the conventional rules of regular expressions. Proper regular expression support is available in Java through several packages, most notably java.util.regex, which is Sun's standard package available in Java 1.4+. This package provides two classes, Pattern and Matcher, which are respectively used to define and operate on regular expressions. These classes work in conjunction with the String class to perform regular expression functions.

==Code Example: find a regular expression match within a String==
In Ruby, there are 2 simple ways to do this, the main difference between them being that one is a String method and one is a Regexp method.
First the String method, the [http://www.ruby-doc.org/core/classes/String.html#M000792 =~] operator, which returns the index in the string at which the pattern first matches.

"This is a string" =~ /is/
>> 2
"This is a string" =~ /hello/
>> nil

An equivalent way to do this is with the Regexp method match(). Note that match() returns a [http://www.ruby-doc.org/core/classes/MatchData.html MatchData] object if successful.

/is/.match("This is a string")
>> #<MatchData:0x5e1715c>
/hello/.match("This is a string")
>> nil

In Java, it is possible to do a simple version of this using only the String.matches() method, however this is a boolean method so we will miss out on the extra index information that Ruby's =~ will give.

String str = "This is a string";
str.matches("is"); // does not do what you expect. This will return false.
str.matches(".*is.*"); // will return true

In the above code, it is important to realize that matches() will only return true if the entire string from beginning to end is a match. In other words, it behaves as if the input regular expression "regexp" is actually "^regexp$". For matching a subsring or the entire string, a workaround such as the third line above must be used.

==Code Example: collecting regular expression matches within a String in an array of Strings==
In Ruby, a simple way to collect regular expression matches from a String is to use the String.scan() method, which takes a regular expression as a parameter, and returns a String array.

matches = "This is a string".scan(/is/)
>> ["is", "is"]

A slightly more complex regular expression:

matches = "This is a string".scan(/\w*i\w*/) # match any word with an i in it
>> ["This", "is", "string"]

In Java, it is a bit more complicated. There are no shortcut methods as part of the String class to help us do what we want, and we need to make use of the Pattern and Matcher classes.

String myString = new String("This is a string");
Pattern myPattern = Pattern.compile("is");
Matcher myMatcher = myPattern.matcher(myString);
Vector results = new Vector(); // to store the resulting matches 
while (myMatcher.find()) { // find() finds the next match, evaluates to false if not found
results.add(myMatcher.group()); // group() returns the matched string
}

=Links=
http://www.regular-expressions.info/ruby.html 
http://www.regular-expressions.info/java.html 
http://www.javaworld.com/javaworld/jw-07-2001/jw-0713-regex.html?page=3 
http://regex.info/java.html 
http://www.blueskyonmars.com/2003/10/31/14-stringmatches-is-dumb/ 
http://www.ruby-doc.org/core/classes/MatchData.html 

[[CSC/ECE 517 Summer 2008/wiki1 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki1 1 rapodraz

2008-06-11T02:00:28Z

Rapodraz: