CSC/ECE 517 Fall 2012/ch2a 2w14 bb: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 5: Line 5:
A design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations. Patterns are formalized best practices that the programmer must implement themselves in the application. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such.
A design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations. Patterns are formalized best practices that the programmer must implement themselves in the application. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such.
== Why Design Patterns ==
== Why Design Patterns ==
A design pattern is a pattern—a way to pursue an intent—that uses
A design pattern is a pattern—a way to pursue an intent—that uses classes and their methods in an object-oriented language. Developers often start thinking about design after learning a programming language and writing code for a while. You might notice that someone else’s code seems simpler and works better than yours does, and you might wonder how that developer achieves such simplicity. Design patterns are a level up from code and typically show how to achieve a goal using a few classes. A pattern represents an idea, not a particular implementation.
classes and their methods in an object-oriented language. Developers
often start thinking about design after learning a programming language
and writing code for a while. You might notice that someone
else’s code seems simpler and works better than yours does, and you
might wonder how that developer achieves such simplicity. Design
patterns are a level up from code and typically show how to achieve a
goal using a few classes. A pattern represents an idea, not a particular
implementation.


== Categorization of Patterns ==
== Categorization of Patterns ==

Revision as of 20:50, 25 October 2012

Introduction

The purpose of the wiki is to introduce and show some example about pattern fragility. The contents include definition of pattern fragility and what does the concept cover. We also give some examples of mistakes in code that spoil the benefits of design patterns.

Design Patterns

A design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations. Patterns are formalized best practices that the programmer must implement themselves in the application. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such.

Why Design Patterns

A design pattern is a pattern—a way to pursue an intent—that uses classes and their methods in an object-oriented language. Developers often start thinking about design after learning a programming language and writing code for a while. You might notice that someone else’s code seems simpler and works better than yours does, and you might wonder how that developer achieves such simplicity. Design patterns are a level up from code and typically show how to achieve a goal using a few classes. A pattern represents an idea, not a particular implementation.

Categorization of Patterns

Intent Patterns
Interfaces ADAPTER, FACADE, COMPOSITE, BRIDGE
Responsibility SINGLETON, OBSERVER, MEDIATOR, PROXY, CHAIN OF RESPONSIBILITY, FLYWEIGHT
Construction BUILDER, FACTORY METHOD, ABSTRACT FACTORY, PROTOTYPE, MEMENTO
Operations TEMPLATE METHOD, STATE, STRATEGY, COMMAND, INTERPRETER
Extensions DECORATOR, ITERATOR, VISITOR

Benefits of Design Patterns

Pattern Fragility

Definition of Pattern Fragility

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost.

Symptoms of Rotting Design

There are four primary symptoms that tell us that our designs are rotting. They are not orthogonal, but are related to each other in ways that will become obvious. they are: rigidity, fragility, immobility, and viscosity

Examples

Singleton

Factory

Visitor

Command

The Command design pattern encapsulates commands (method calls) in objects allowing us to issue requests without knowing the requested operation or the requesting object. Command design pattern provides the options to queue commands, undo/redo actions and other manipulations.

There are two extremes that a programmer must avoid when using this pattern:

1. The command is just a link between the receiver and the actions that carry out the request 2. The command implements everything itself, without sending anything to the receiver.

We must always keep in mind the fact that the receiver is the one who knows how to perform the operations needed, the purpose of the command being to help the client to delegate its request quickly and to make sure the command ends up where it should.

One example is:

 class FileDeleteCommand
   def initialize(path)
     @path = path
   end
   def execute
     File.delete(@path)
   end
 end
 fdc = FileDeleteCommand.new('foo.dat')
 fdc.execute

there is nothing simpler than just getting on with it: File.delete('foo.dat')

Conclusion

Reference