CSC/ECE 517 Fall 2009/wiki2 13 StaticDynamic: Difference between revisions
Line 12: | Line 12: | ||
!Name !! Description | !Name !! Description | ||
|- | |- | ||
| Creational Patterns | |||
|- | |- | ||
| Abstract Factory || Creates an instance of several families of classes | | Abstract Factory || Creates an instance of several families of classes | ||
Line 24: | Line 24: | ||
| Singleton || A class of which only a single instance can exist | | Singleton || A class of which only a single instance can exist | ||
|- | |- | ||
| Structural Patterns | |||
|- | |- | ||
| Adapter || Match interfaces of different classes | | Adapter || Match interfaces of different classes |
Revision as of 21:52, 8 October 2009
Design Patterns from a Static/Dynamic Point of View
Clearly, Ruby offers more concise realizations of certain design patterns than Java does. Is this typical of dynamic o-o languages? Are there design patterns that any dynamically typed language can realize better than a statically typed language? Are there instances when a different pattern should be used in a dynamic language than a static language?
Introduction
Design Pattern
A design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.
[1]
Name | Description |
---|---|
Creational Patterns | |
Abstract Factory | Creates an instance of several families of classes |
Builder | Separates object construction from its representation |
Factory Method | Creates an instance of several derived classes |
Prototype | A fully initialized instance to be copied or cloned |
Singleton | A class of which only a single instance can exist |
Structural Patterns | |
Adapter | Match interfaces of different classes |
Bridge | Separates an object’s interface from its implementation |
Composite | A tree structure of simple and composite objects |
Decorator | Add responsibilities to objects dynamically |
Facade | A single class that represents an entire subsystem |
Flyweight | A fine-grained instance used for efficient sharing |
Proxy | An object representing another object |
Behavioral Patterns | |
Chain of Resp. | A way of passing a request between a chain of objects |
Command | Encapsulate a command request as an object |
Interpreter | A way to include language elements in a program |
Iterator | Sequentially access the elements of a collection |
Mediator | Defines simplified communication between classes |
Memento | Capture and restore an object's internal state |
Observer | A way of notifying change to a number of classes |
State | Alter an object's behavior when its state changes |
Strategy | Encapsulates an algorithm inside a class |
Template Method | Defer the exact steps of an algorithm to a subclass |
Visitor | Defines a new operation to a class without change |
Static/Dynamic Type Languages
Types usually have associations either with values in memory or with objects such as variables. Because any value simply consists of a sequence of bits in a computer, hardware makes no distinction even between memory addresses, instruction code, characters, integers and floating-point numbers. Assignment to a type informs programs and programmers how those bit collections should be treated.
Major functions provided by type systems include:
- Safety - Use of types may allow a compiler to detect meaningless or probably invalid code. For example, we can identify an expression "Hello, World" as invalid because the rules of arithmetic do not specify how to divide an integer by a string. As discussed below, strong typing offers more safety, but generally does not guarantee complete safety (see type-safety for more information).
- Optimization - Static type-checking may provide useful compile-time information. For example, if a type requires that a value must align in memory at a multiple of 4 bytes, the compiler may be able to use more efficient machine instructions.
- Documentation - In more expressive type systems, types can serve as a form of documentation, since they can illustrate the intent of the programmer. For instance, timestamps may be represented as integers—but if a programmer declares a function as returning a timestamp type rather than merely an integer type, this documents part of the meaning of the function.
- Abstraction (or modularity) - Types allow programmers to think about programs at a higher level than the bit or byte, not bothering with low-level implementation. For example, programmers can think of a string as a collection of character values instead of as a mere array of bytes. Or, types can allow programmers to express the interface between two subsystems. This helps localize the definitions required for interoperability of the subsystems and prevents inconsistencies when those subsystems communicate.
Static Type Languages
A programming language is said to use static typing when type checking is performed during compile-time as opposed to run-time.
C++, C#, Java
Dynamic Type Languages
A programming language is said to be dynamically typed, or just 'dynamic', when the majority of its type checking is performed at run-time as opposed to at compile-time.
Ruby, Python