Design Pattern Overview

Design Pattern Overview
In   software engineering, creational design patterns are design patterns that   deal with object creation mechanisms, trying to create objects in a manner   suitable to the situation. The basic form of object creation could result in   design problems or added complexity to the design. Creational design patterns   solve this problem by somehow controlling this object creation.

Creational design patterns are composed of two dominant ideas. One is   encapsulating knowledge about which concrete classes the system uses. Another   is hiding how instances of these concrete classes are created and   combined.[1]

Creational design patterns are further categorized into Object-creational   patterns and Class-creational patterns, where Object-creational patterns deal   with Object creation and Class-creational patterns deal with   Class-instantiation. In greater details, Object-creational patterns defer   part of its object creation to another object, while Class-creational   patterns defer its object creation to subclasses
The   abstract factory pattern provides a way to encapsulate a group of individual   factories that have a common theme without specifying their concrete   classes.[1] In normal usage, the client software creates a concrete   implementation of the abstract factory and then uses the generic interface of   the factory to create the concrete objects that are part of the theme. The   client doesn’t know (or care) which concrete objects it gets from each of   these internal factories, since it uses only the generic interfaces of their   products.[1] This pattern separates the details of implementation of a set of   objects from their general usage and relies on object composition, as object   creation is implemented in methods exposed in the factory interface.
The   factory method pattern is an object-oriented creational design pattern to   implement the concept of factories and deals with the problem of creating   objects (products) without specifying the exact class of object that will be   created. The essence of this pattern is to “Define an interface for   creating an object, but let the classes that implement the interface decide   which class to instantiate. The Factory method lets a class defer   instantiation to subclasses.”[
In   software engineering, the singleton pattern is a design pattern that   restricts the Instantiation of a class to one object. This is useful when   exactly one object is needed to coordinate actions across the system. The   concept is sometimes generalized to systems that operate more efficiently   when only one object exists, or that restrict the instantiation to a certain   number of objects. The term comes from the mathematical concept of a   singleton.
The builder pattern is an object creation software   design pattern. Unlike the abstract factory pattern and the factory method   pattern whose intention is to enable polymorphism, the intention of the   builder pattern is to find a solution to the telescoping constructor   anti-pattern. The telescoping constructor anti-pattern occurs when the   increase of object constructor parameter combination leads to an exponential   list of constructors. Instead of using numerous constructors, the builder   pattern uses another object, a builder, that receives each initialization   parameter step by step and then returns the resulting constructed object at   once.
In   computer programming, lazy initialization is the tactic of delaying the   creation of an object, the calculation of a value, or some other expensive   process until the first time it is needed.

This is typically accomplished by maintaining a flag indicating whether the   process has taken place. Each time the desired object is summoned, the flag   is tested. If it is ready, it is returned. If not, it is initialized on the   spot. In multithreaded code, access to the flag must be synchronized to guard   against a race condition.
In   software engineering, the multiton pattern is a design pattern similar to the   singleton, which allows only one instance of a class to be created. The   multiton pattern expands on the singleton concept to manage a map of named   instances as key-value pairs.

Rather than having a single instance per application (e.g. the   java.lang.Runtime object in the Java programming language) the multiton   pattern instead ensures a single instance per key.
The   object pool pattern is a software creational design pattern that uses a set   of initialized objects kept ready to use, rather than allocating and   destroying them on demand. A client of the pool will request an object from   the pool and perform operations on the returned object. When the client has   finished, it returns the object, which is a specific type of factory object,   to the pool rather than destroying it.

Object pooling can offer a significant performance boost in situations   where the cost of initializing a class instance is high, the rate of   instantiation of a class is high, and the number of instances in use at any   one time is low. The pooled object is obtained in predictable time when   creation of the new objects (especially over network) may take variable   time.
The   prototype pattern is a creational design pattern in software development. It   is used when the type of objects to create is determined by a prototypical   instance, which is cloned to produce new objects. This pattern is used   to:
avoid subclasses of an object creator in the client application, like the   abstract factory pattern does.
avoid the inherent cost of creating a new object in the standard way (e.g.,   using the ‘new’ keyword) when it is prohibitively expensive for a given   application.

To implement the pattern, declare an abstract base class that specifies a   pure virtual clone() method. Any class that needs a “polymorphic   constructor” capability derives itself from the abstract base class, and   implements the clone() operation.
Resource   Acquisition Is Initialization (RAII)[1] is a programming idiom used in   several object-oriented languages like C++, D, Ada and Vala. The technique   was invented by Bjarne Stroustrup[2] to deal with resource allocation and   deallocation in C++. In this language, if an exception is thrown, and proper   exception handling is in place, the only code that will be executed for the   current scope are the destructors of objects declared in that scope. Resource   management therefore needs to be tied to the lifespan of suitable objects in   order to gain automatic allocation and reclamation. Resources are acquired   during initialization, when there is no chance of them being used before they   are available, and released with the destruction of the same objects, which   is guaranteed to take place even in case of errors.
In   software engineering, structural design patterns are design patterns that   ease the design by identifying a simple way to realize relationships between   entities.
In   computer programming, the adapter pattern (often referred to as the wrapper   pattern or simply a wrapper – an alternative naming shared with the Decorator   pattern according to the GoF Design Patterns book ) is a design pattern that   translates one interface for a class into a compatible interface.[1] An   adapter allows classes to work together that normally could not because of   incompatible interfaces, by providing its interface to clients while using   the original interface. The adapter translates calls to its interface into   calls to the original interface, and the amount of code necessary to do this   is typically small. The adapter is also responsible for transforming data   into appropriate forms. For instance, if multiple boolean values are stored   as a single integer (i.e. flags) but the client requires individual boolean   values, the adapter would be responsible for extracting the appropriate   values from the integer value. Another example is transforming the format of   dates (e.g. YYYYMMDD to MM/DD/YYYY or DD/MM/YYYY ).
In   object-oriented programming, the decorator pattern (also known as Wrapper, an   alternative naming shared with the Adapter pattern) is a design pattern that   allows behavior to be added to an individual object, either statically or   dynamically, without affecting the behavior of other objects from the same   class.[1]
The   bridge pattern is a design pattern used in software engineering which is   meant to “decouple an abstraction from its implementation so that the   two can vary independently”.[1] The bridge uses encapsulation,   aggregation, and can use inheritance to separate responsibilities into   different classes.

When a class varies often, the features of object-oriented programming   become very useful because changes to a program’s code can be made easily   with minimal prior knowledge about the program. The bridge pattern is useful   when both the class as well as what it does vary often. The class itself can   be thought of as the implementation and what the class can do as the   abstraction. The bridge pattern can also be thought of as two layers of   abstraction.

When there is only one fixed implementation, this pattern is known as the   Pimpl idiom in the C++ world.
In   software engineering, the composite pattern is a partitioning design pattern.   The composite pattern describes that a group of objects are to be treated in   the same way as a single instance of an object. The intent of a composite is   to “compose” objects into tree structures to represent part-whole   hierarchies. Implementing the composite pattern lets clients treat individual   objects and compositions uniformly.[1]
The   facade pattern (or façade pattern) is a software design pattern commonly used   with object-oriented programming. The name is by analogy to an architectural   facade.

A facade is an object that provides a simplified interface to a larger body   of code, such as a class library. A facade can:
make a software library easier to use, understand and test, since the   facade has convenient methods for common tasks;
make the library more readable, for the same reason;
reduce dependencies of outside code on the inner workings of a library,   since most code uses the facade, thus allowing more flexibility in developing   the system;
wrap a poorly designed collection of APIs with a single well-designed API   (as per task needs).
In   computer programming, flyweight is a software design pattern. A flyweight is   an object that minimizes memory use by sharing as much data as possible with   other similar objects; it is a way to use objects in large numbers when a   simple repeated representation would use an unacceptable amount of memory.   Often some parts of the object state can be shared, and it is common practice   to hold them in external data structures and pass them to the flyweight   objects temporarily when they are used.
In   software engineering, the module pattern is a design pattern used to   implement the concept of software modules, defined by modular programming, in   a programming language that does not or only partially supports it.
The   Front Controller Pattern is a software design pattern listed in several   pattern catalogs. The pattern relates to the design of web applications. It   “provides a centralized entry point for handling   requests.”[1]

Front controllers are often used in web applications to implement   workflows. While not strictly required, it is much easier to control   navigation across a set of related pages (for instance, multiple pages might   be used in an online purchase) from a front controller than it is to make the   individual pages responsible for navigation.
In   computer programming, the proxy pattern is a software design pattern.

A proxy, in its most general form, is a class functioning as an interface   to something else. The proxy could interface to anything: a network   connection, a large object in memory, a file, or some other resource that is   expensive or impossible to duplicate.

A well-known example of the proxy pattern is a reference counting pointer   object.
In   software engineering, behavioral design patterns are design patterns that   identify common communication patterns between objects and realize these   patterns. By doing so, these patterns increase flexibility in carrying out   this communication.
In   object-oriented design, the chain-of-responsibility pattern is a design   pattern consisting of a source of command objects and a series of processing   objects.[1] Each processing object contains logic that defines the types of   command objects that it can handle; the rest are passed to the next   processing object in the chain. A mechanism also exists for adding new   processing objects to the end of this chain.

In a variation of the standard chain-of-responsibility model, some handlers   may act as dispatchers, capable of sending commands out in a variety of   directions, forming a tree of responsibility. In some cases, this can occur   recursively, with processing objects calling higher-up processing objects   with commands that attempt to solve some smaller part of the problem; in this   case recursion continues until the command is processed, or the entire tree   has been explored. An XML interpreter might work in this manner.
In   object-oriented programming, the command pattern is a behavioral design   pattern in which an object is used to represent and encapsulate all the   information needed to call a method at a later time. This information   includes the method name, the object that owns the method and values for the   method parameters.

Four terms always associated with the command pattern are command,   receiver, invoker and client. A command object has a receiver object and   invokes a method of the receiver in a way that is specific to that receiver’s   class. The receiver then does the work. A command object is separately passed   to an invoker object, which invokes the command, and optionally does   bookkeeping about the command execution. Any command object can be passed to   the same invoker object. Both an invoker object and several command objects   are held by a client object. The client contains the decision making about   which commands to execute at which points. To execute a command, it passes   the command object to the invoker object.
The   observer pattern is a software design pattern in which an object, called the   subject, maintains a list of its dependents, called observers, and notifies   them automatically of any state changes, usually by calling one of their   methods. It is mainly used to implement distributed event handling systems.   The Observer pattern is also a key part in the familiar Model View Controller   (MVC) architectural pattern. [1] In fact the observer pattern was first   implemented in Smalltalk’s MVC based user interface framework.[2] The   observer pattern is implemented in numerous programming libraries and   systems, including almost all GUI toolkits.
A   blackboard system is an artificial intelligence application based on the   blackboard architectural model, where a common knowledge base, the   “blackboard”, is iteratively updated by a diverse group of   specialist knowledge sources, starting with a problem specification and   ending with a solution. Each knowledge source updates the blackboard with a   partial solution when its internal constraints match the blackboard state. In   this way, the specialists work together to solve the problem. The blackboard   model was originally designed as a way to handle complex, ill-defined   problems, where the solution is the sum of its parts.
The   memento pattern is a software design pattern that provides the ability to   restore an object to its previous state (undo via rollback).

The memento pattern is implemented with three objects: the originator, a   caretaker and a memento. The originator is some object that has an internal   state. The caretaker is going to do something to the originator, but wants to   be able to undo the change. The caretaker first asks the originator for a   memento object. Then it does whatever operation (or sequence of operations)   it was going to do. To roll back to the state before the operations, it   returns the memento object to the originator. The memento object itself is an   opaque object (one which the caretaker cannot, or should not, change). When   using this pattern, care should be taken if the originator may change other   objects or resources – the memento pattern operates on a single object.
In   computer programming, the specification pattern is a particular software   design pattern, whereby business rules can be recombined by chaining the   business rules together using boolean logic.

A specification pattern outlines a business rule that is combinable with   other business rules. In this pattern, a unit of business logic inherits its   functionality from the abstract aggregate Composite Specification class. The   Composite Specification class has one function called IsSatisfiedBy that   returns a boolean value. After instantiation, the specification is   “chained” with other specifications, making new specifications   easily maintainable, yet highly customizable business logic. Furthermore upon   instantiation the business logic may, through method invocation or inversion   of control, have its state altered in order to become a delegate of other   classes such as a persistence repository.
In   computer programming, the strategy pattern (also known as the policy pattern)   is a software design pattern, whereby an algorithm’s behaviour can be   selected at runtime. Formally speaking, the strategy pattern defines a family   of algorithms, encapsulates each one, and makes them interchangeable.   Strategy lets the algorithm vary independently from clients that use it.[1]   Strategy is one of the patterns included in the influential book “Design   Patterns” by Gamma et al. that popularized the concept of using patterns   in software design.
In   software engineering, the template method pattern is a behavioral design   pattern that defines the program skeleton of an algorithm in a method, called   template method, which defers some steps to subclasses.[1] It lets one   redefine certain steps of an algorithm without changing the algorithm’s   structure.[2] This use of “template” is unrelated to C++ templates.
In   computer programming, the interpreter pattern is a design pattern that   specifies how to evaluate sentences in a language. The basic idea is to have   a class for each symbol (terminal or nonterminal) in a specialized computer   language. The syntax tree of a sentence in the language is an instance of the   composite pattern and is used to evaluate (interpret) the sentence.[1]
The   mediator pattern defines an object that encapsulates how a set of objects   interact. This pattern is considered to be a behavioral pattern due to the   way it can alter the program’s running behavior.

Usually a program is made up of a large number of classes. So the logic and   computation is distributed among these classes. However, as more classes are   developed in a program, especially during maintenance and/or refactoring, the   problem of communication between these classes may become more complex. This   makes the program harder to read and maintain. Furthermore, it can become   difficult to change the program, since any change may affect code in several   other classes.
In   object-oriented computer programming, a Null Object is an object with defined   neutral (“null”) behavior. The Null Object design pattern describes   the uses of such objects and their behavior (or lack thereof). It was first   published in the Pattern Languages of Program Design book series.[1]
Servant   is a design pattern used to offer some functionality to a group of classes   without defining that functionality in each of them. A Servant is a class   whose instance (or even just class) provides methods that take care of a   desired service, while objects for which (or with whom) the servant does   something, are taken as parameters.
The   state pattern, which closely resembles Strategy Pattern, is a behavioral   software design pattern, also known as the objects for states pattern. This   pattern is used in computer programming to encapsulate varying behavior for   the same routine based on an object’s state object. This can be a cleaner way   for an object to change its behavior at runtime without resorting to large   monolithic conditional statements[1]:395
In   object-oriented programming, the iterator pattern is a design pattern in   which an iterator is used to traverse a container and access the container’s   elements. The iterator pattern decouples algorithms from containers; in some   cases, algorithms are necessarily container-specific and thus cannot be   decoupled.

For example, the hypothetical algorithm SearchForElement can be implemented   generally using a specified type of iterator rather than implementing it as a   container-specific algorithm. This allows SearchForElement to be used on any   container that supports the required type of iterator.
In   object-oriented programming and software engineering, the visitor design   pattern is a way of separating an algorithm from an object structure on which   it operates. A practical result of this separation is the ability to add new   operations to existing object structures without modifying those structures.   It is one way to follow the open/closed principle.
In   software engineering, concurrency patterns are those types of design patterns   that deal with the multi-threaded programming paradigm.
Data   binding is the process that establishes a connection between the application   UI (User Interface) and business logic. If the settings and notifications are   correctly set, the data reflects changes when made. It can also mean that   when data is changed, the underlying data will reflect that change.

It is a term referred to in WPS, but is not specifically to programming   language or platform, though it is often most often used with Java and XML.   As an example, a change in a TextBox element could modify the underlying data   value.[1]
In   (multithreaded) object-oriented programming, asynchronous method invocation   (AMI), also known as asynchronous method calls or asynchronous pattern is a   design pattern for asynchronous invocation of potentially long-running   methods of an object.[1] It is equivalent to the IOU pattern described in   1996 by Allan Vermeulen.[2][3] The event-based asynchronous pattern in .NET   Framework and the java.util.concurrent.FutureTask class in Java use events to   solve the same problem. This pattern is a variant of AMI whose implementation   carries more overhead, but it is useful for objects representing software   components.
In   computer programming, the scheduler pattern is a software design pattern. It   is a concurrency pattern used to explicitly control when threads may execute   single-threaded code, like write operation to a file.

The scheduler pattern uses an object that explicitly sequences waiting   threads. It provides a mechanism to implement a scheduling policy, but is   independent of any specific scheduling policy — the policy is encapsulated in   its own class and is reusable.

The read/write lock pattern is usually implemented using the scheduler   pattern to ensure fairness in scheduling.
In   computer programming, the thread pool pattern (also replicated workers or   worker-crew model[1]) is where a number of threads are created to perform a   number of tasks, which are usually organized in a queue. The results from the   tasks being executed might also be placed in a queue, or the tasks might   return no result (for example, if the task is for animation). Typically,   there are many more tasks than threads. As soon as a thread completes its   task, it will request the next task from the queue until all tasks have been   completed. The thread can then terminate, or sleep until there are new tasks   available.
The   active object design pattern decouples method execution from method   invocation for objects that each reside in their own thread of control.[1]   The goal is to introduce concurrency, by using asynchronous method invocation   and a scheduler for handling requests.[2]
The   balking pattern is a software design pattern that only executes an action on   an object when the object is in a particular state. For example, if an object   reads ZIP files and a calling method invokes a get method on the object when   the ZIP file is not open, the object would “balk” at the request.   In the Java programming language, for example, an IllegalStateException might   be thrown under these circumstances.
In   software engineering, double-checked locking (also known as   “double-checked locking optimization”[1]) is a software design   pattern used to reduce the overhead of acquiring a lock by first testing the   locking criterion (the “lock hint”) without actually acquiring the   lock. Only if the locking criterion check indicates that locking is required   does the actual locking logic proceed.

The pattern, when implemented in some language/hardware combinations, can   be unsafe. At times, it can be considered an anti-pattern.[2]
In   concurrent programming, a monitor is a synchronization construct that allows   threads to have both mutual exclusion and the ability to wait (block) for a   certain condition to become true. Monitors also have a mechanism for   signalling other threads that their condition has been met. In essence, a   monitor M = (m, c)  is a pair of a   mutex (lock) object m and a condition variable c. A condition variable is   basically a container of threads that are waiting on a certain condition.   Monitors provide a mechanism for threads to temporarily give up exclusive   access in order to wait for some condition to be met, before regaining   exclusive access and resuming their task.
The   reactor design pattern is an event handling pattern for handling service   requests delivered concurrently to a service handler by one or more inputs.   The service handler then demultiplexes the incoming requests and dispatches   them synchronously to the associated request handlers.[
In   concurrent programming, guarded suspension[1] is a software design pattern   for managing operations that require both a lock to be acquired and a   precondition to be satisfied before the operation can be executed. The   guarded suspension pattern is typically applied to method calls in   object-oriented programs, and involves suspending the method call, and the   calling thread, until the precondition (acting as a guard) is satisfied.
In   computer science, a lock is a synchronization mechanism for enforcing limits   on access to a resource in an environment where there are many threads of   execution. A lock is designed to enforce a mutual exclusion concurrency   control policy.
In   software architecture, a messaging pattern is a network-oriented   architectural pattern which describes how two different parts of a message   passing system connect and communicate with each other.
In   computer science, a readers-writer or shared-exclusive lock (also known as   the multiple readers / single-writer lock[1] or the multi-reader lock,[2] or   by typographical variants such as readers/writers lock) is a synchronization   primitive that solves one of the readers-writers problems. A readers-writer   lock is like a mutex, in that it controls access to a shared resource,   allowing concurrent access to multiple threads for reading but restricting   access to a single thread for writes (or other changes) to the resource. A   common use might be to control access to a data structure in memory that   can’t be updated atomically and isn’t valid (and shouldn’t be read by another   thread) until the update is complete.
Thread-local   storage (TLS) is a computer programming method that uses static or global   memory local to a thread.

This is sometimes needed because normally all threads in a process share   the same address space, which is sometimes undesirable. In other words, data   in a static or global variable is normally always located at the same memory   location, when referred to by threads from the same process. Variables on the   call stack however are local to threads, because each thread has its own stack,   residing in a different memory location. The underlying problem is that,   since all threads share an address space, no fixed memory location can be   used to store the location of the storage.
In   software engineering, 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 in the   application.[1] Object-oriented design patterns typically show relationships   and interactions between classes or objects, without specifying the final   application classes or objects that are involved. Patterns that imply   object-orientation or more generally mutable state, are not as applicable in   functional programming languages.
In   computer programming, unit testing is a method by which individual units of   source code, sets of one or more computer program modules together with   associated control data, usage procedures, and operating procedures are   tested to determine if they are fit for use.[1] Intuitively, one can view a   unit as the smallest testable part of an application. In procedural   programming, a unit could be an entire module, but is more commonly an   individual function or procedure. In object-oriented programming, a unit is   often an entire interface, such as a class, but could be an individual   method.[2] Unit tests are created by programmers or occasionally by white box   testers during the development process.
Revision   control, also known as version control and source control (and an aspect of   software configuration management), is the management of changes to   documents, computer programs, large web sites, and other collections of   information. Changes are usually identified by a number or letter code,   termed the “revision number”, “revision level”, or simply   “revision”. For example, an initial set of files is “revision   1”. When the first change is made, the resulting set is “revision   2”, and so on. Each revision is associated with a timestamp and the   person making the change. Revisions can be compared, restored, and with some   types of files, merged.

E.g.: Git, Mercurial
In   software engineering, inversion of control (IoC) is a programming technique,   expressed here in terms of object-oriented programming, in which object   coupling is bound at run time by an assembler object and is typically not   known at compile time using static analysis.

In traditional programming, the flow of the business logic is determined by   objects that are statically assigned to one another. With inversion of   control, the flow depends on the object graph that is instantiated by the assembler.   Such a dynamic flow is made possible by object interactions being defined   through abstractions. The binding process is achieved through dependency   injection, although some argue that the use of a service locator also   provides inversion of control.

E.g: Autofac, Windsor Container, StructureMap
Continuous   integration (CI) is the practice, in software engineering, of merging all   developer working copies with a shared mainline several times a day. It was   first named and proposed as part of extreme programming (XP). Its main aim is   to prevent integration problems, referred to as “integration hell”   in early descriptions of XP. CI can be seen as an intensification of   practices of periodic integration advocated by earlier published methods of   incremental and iterative software development, such as the Booch method. CI   isn’t universally accepted as an improvement over frequent integration, so it   is important to distinguish between the two as there is disagreement about   the virtues of each.

E.g.: TeamCity, Hudson, CruiseControl.NET
NHibernate   (ORM) solution for the Microsoft .NET platform: it provides a framework for   mapping an object-oriented domain model to a traditional relational database.   Its purpose is to relieve the developer from a significant portion of   relational data persistence-related programming tasks. NHibernate is free as   open source software that is distributed under the GNU Lesser General Public   License. NHibernate is a port of Hibernate.

E.g.: CouchDB, MongoDB, RavenDB
Cloud   computing is a phrase used to describe a variety of computing concepts that   involve a large number of computers connected through a real-time   communication network such as the Internet.[1] In science, cloud computing is   a synonym for distributed computing over a network, and means the ability to   run a program or application on many connected computers at the same time.   The phrase also more commonly refers to network-based services, which appear   to be provided by real server hardware, and are in fact served up by virtual   hardware, simulated by software running on one or more real machines. Such   virtual servers do not physically exist and can therefore be moved around and   scaled up (or down) on the fly without affecting the end user – arguably, rather   like a cloud.

E.g.: Azure, AWS
In   computer science, message queues and mailboxes are software-engineering   components used for interprocess communication, or for inter-thread   communication within the same process. They use a queue for messaging – the   passing of control or of content. Group communication systems provide similar   kinds of functionality.

NServiceBus, MassTransit, RhinoQueues
Domain-driven   design (DDD) is an approach to develop software for complex needs by   connecting the implementation to an evolving model.[1] The premise of   domain-driven design is the following:
Placing the project’s primary focus on the core domain and domain   logic.
Basing complex designs on a model of the domain.
Initiating a creative collaboration between technical and domain experts to   iteratively refine a conceptual model that addresses particular domain   problems.
Command–query   separation (CQS) is a principle of imperative computer programming. It was   devised by Bertrand Meyer as part of his pioneering work on the Eiffel   programming language.

It states that every method should either be a command that performs an   action, or a query that returns data to the caller, but not both. In other   words, asking a question should not change the answer. More formally, methods   should return a value only if they are referentially transparent and hence   possess no side effects. It is noteworthy that rigid implementation of this   specification makes tracking the number of times queries have been issued   essentially impossible; it is clearly intended as a programming guideline   rather than a rule for good coding, such as avoiding the use of a goto from a   nested loop.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s