Patterns with a small 'p'
[Programming Concepts]
Collaboration diagram for Patterns with a small 'p':
|
Detailed Description
Patterns are a great way of being able to communicate clearly about a programming concept, but some people get a little too hung up on them. We use patterns sparingly and, hopefully, only where appropriate...
Modules | |
| Handle/Body idiom | |
| We use the Handle/Body idiom to provide compilation 'firewalling' that protects the main body of code from becoming unintentionally coupled to code that we're integrating with. By breaking an object into a Handle and a Body and only allowing the Body to have knowledge of the code that we're integrating with we make sure that our main body of code never includes an integration header file directly or uses any types from the integrated library. The advantages of this approach are that, theoretically, the implementation of the Body can change without affecting our main code base. See here and here for more details. This section contains links to the code that implements this concept. | |
| RAII - Resource Acquisition Is Initialization | |
| This simple idiom relies on the lifetime of an object to control the lifetime of an associated resource. In essence, the resource is released when the object is destroyed. This gives us simple, scope-based usage of resources that is safe in the presence of exceptions and multiple function exit points. See here for more details. This section contains links to the code that implements this concept. | |
| Parameterise From Above | |
| Parameterise From Above is an informal Pattern that was first used by Kevlin Henney. It describes a system of explicitly 'plugging together' objects to provide services rather than allowing objects to 'reach out' and grab the services that they require. In essence objects are configured 'from above' by being given the other objects that they require to do their work. This is pretty much the opposite of a Singleton. See here for more details. This section contains links to the code that implements this concept. | |
| Abstract Factory Pattern | |
| This simple idiom provides a way to centralise the creation of a particular type of object so that to obtain an instance of the class that you want must ask the factory to create it for you. This allows for different factories to provide slightly different variations on the object that you get. See here for more details. This section contains links to the code that implements this concept. | |
| Null Objects | |
| These objects implement various Interfaces in a way that does nothing. They exist so that we can use the Null Object Pattern see here, rather than allowing optionality via pointers that can be null we use references and use a 'null object' when we don't require the functionality. This simplifies the code as it removes the need to test for null and switch depending on a pointer's state; we always call the method and if the object is a null object the call just does nothing. This section contains links to the code that implements this concept. | |
