As a person calling themselves a software engineer, I need to say I use design patterns, and sound educated in them; their use, and the anti-patterns. I have read the books, and use what was written when it seems relevant to the solution. In many places, I talk with commercial people, or clients; and so never talk about design patterns. There are places, where I intuitively worked out a structure that looked like a pattern, but didn't use the same name. I always write code that I can manage. I value teamwork, which makes design patterns important.

I note that as comprehension in small companies is important, so I focus on DDD. I want to be able to discuss solutions as part of costs; and non-technical people will find the genericness of design patterns opaque. In terms of results, I think this is more important.

Over the last year, mostly for contracts where it has most relevance; I have been naming classes according to design pattern references; specifically as I wouldn't be on tap for later changes. Truthfully, I am just ensuring the classnames to match what the online books say. The structures ~ allowing reuse and stability ~ are needed for both DDD and patterns.

Obviously the best article would reference commercial code samples; but this is more difficult for system/ back end developers. Companies I talk with more recently understand the need for on architect type role; my fluency will help here as well. This text is written without using the internet or paper references.

Structures that I use in no particular order:

  • Inside PHP I am targeting Symfony2 as a framework, I use MVC and related algorithms. Inside Perl I use Catalyst. I have created implementations of this algorithm previously from scratch. I have used MVP in places where there was too much rendering logic. This algorithm is valuable as there are many frameworks for it. It allows large amounts of work to be automated/ done by the libraries. In comparison to tools like Wordpress, it doesn't constrain one to simple things.
  • At time of writing I have yet to build a proper MVVM, but that is a result of giving clients what they need, rather than lack of skill. There are many companies that think it more important to hold decision making on the server (commercial common sense).
  • For most companies, construction as a SOA is most sensible, I have built a couple.
  • EDIT Jan 2015, from 1 I note that there is a formal name for the single access point is Front Side Controller. I have always used this, but not considered it a pattern, as it is barely an object; just reduces errors, and reduces costs. I also have used HMVC where this is relevant to the framework (repacking for multiple output formats is nice with this).
  • Singletons are an item on GoF, but break many OO traits. They are the standard way to build logging or resources that only make sense with a single item. I use them for Logs, and frequently config objects.
  • I use Transformers and Adaptors.
  • I use Factories. I am using this less than I used, due to DI being technically feasible in PHP. I'm not sure if I should include this, as I haven't written a DI yet, but I use other peoples DI libraries. Obviously using DI requires that I am using IoC. I have built some IoC structures.
  • I make a variety of Producers and Consumers.
  • I use Collections/Iterators when it seems to make sense. I prefer to use arrays in some situations, for performance. Where I use data as a scalar, I am using Entities.
  • I use Facade classes, frequently over an array of implementations (single access point, correct behaviour depending on data supplied).
  • I have made alot of Managers and Workers for multiprocess applications. This frequently has better performance than Threads on Unix platforms.
  • I use Validation libraries and Managers for them. Do not know the Pattern for this, but its a common structure. It is used in Symfony2, but the ones I was referencing I wrote from scratch.
  • Output Rasterisers/ templating libraries.
  • Some of my work should be formalised as Observer and Subject pattern. I copied this from graphics rendering pipelines, where it is abit altered.
  • I have built quite a few OO tree structures, and some linked lists. See previous remark on algorithm or Pattern.
  • I have built many state machines, but am not sure if this is a design pattern or a function pointer array.
  • I tend to use SAX XML parsers, rather than DOM. The business uses often have alot of data, so DOM would consume a massive amount of RAM.
  • Where the language allows I use flyweight classes where I need alot of a given object. See the previous SAX parser as an example.

I will write more on this subject in later articles.

Design patterns

RSS. Share: Share this resource on your twitter account. Share this resource on your linked-in account. G+

Design patterns

RSS. Share: Share this resource on your linked-in account. Share this resource on your twitter account. G+ ­ Follow