The use of design patterns for software developers is the most important area that one must master. Design patterns are the solutions to problems which are commonly, and sometimes uncommonly, occurring throughout the course of a project. The solutions, in the context of object oriented design patterns, usually consists of the general arrangement of classes. Design patterns provide you with an easy way to create objects, control behavior of objects, and structure your code in the most reusable and robust ways. When interviewing people, I always ask about design patterns and disappointingly enough, 90% of new grads I’ve interviewed will have a 4.0 GPA but cannot accurately write an implementation for a singleton pattern. Seriously?!
During my time at MRG/Emerson, I was interviewing interns (post to come on this) and one of the interns put “Design Patterns” under his skills section. I questioned him about it and apparently his school taught design pattern theory with little to no practical implementations of design patterns. He even received an A in the class. Absolutely ridiculous! I proceeded to write a strongly worded email to the dean of his school’s computer science program, explaining how their “Design Patterns” course is inadequate for listing as a skill on their graduates’ resumes. It was incredibly frustrating that an entire organization, being that school, was ignorant to the fact that they were wasting their student’s time and money with their current course. After a few days, a response was given which in all honesty was eschewing the idea that they have a wasteful implementation of this course. He preceded to tell me that, “He could recommend a few other viable interns who would would be very knowledgeable in design patterns.” His suggested candidates weren’t any better. If you want to impress your interviewing, be able to talk at length about why you chose a specific design pattern and how you implemented it.
Design patterns encourages SOLID principles.
- Single responsibility principle
- Open-closed principle
- Liskov substitution principle
- Interface segregation principle
- Dependency inversion principle
The more you use other people’s code, the more you realize the importance of maintaining standards and adhering to a specific guideline. Take for instance the library available on nuget called, NBuilder. This is a unit test object creation library, built upon the builder design pattern. The design pattern dictates how the class must be implemented. We can see below, that a proper implementation of the builder pattern, as used with the NBuilder library, allows for the user of this object to have control over creating custom mocked objects.
var customers = Builder<Customer>.CreateListOfSize(100) .All() .With(c => c.FirstName = Faker.Name.First()) .With(c => c.LastName = Faker.Name.Last()) .With(c => c.EmailAddress = Faker.Internet.Email()) .With(c => c.TelephoneNumber = Faker.Phone.Number()) .Build();
This is just one example of one pattern though. Searching in the nuget repository and throughout code on github, you’ll find design patterns everywhere. In Entity Framework alone, you have the use of 8+ patterns:
Factory Method, an Entity Frameworkhttps://stackoverflow.com/a/8135609/2004122
CreateObjectSet<T>method, which creates an
ObjectSet<T>for the given type. Since those object-sets are the main approach to access the entities within a context, I would say it is also a very important pattern used in EF.
Proxy, obviously EF dynamically creates proxy-types for your entities (unless you tell it not to, or it can’t create a proxy because a class is sealed or does not qualify as a “proxyable” type).
Decorator, this might be a bit far fetched, but to implement lazy-loading in proxy-types, the property-getters of navigation-properties are overloaded, to perform the lazy-loading until requested. This is handled in the proxy type, but also depends on whether lazy-loading is enabled and the navigation-property itself.
Interpreter, EF introduced Entity-SQL which is a somewhat generalized form of SQL that also has knowledge of the object-oriented entities. You can define a those queries as strings which are then interpreted by EF and turned into provider-dependent SQL.
Strategy, looking at the various overloads of the
ObjectContext.SaveChangesmethod, you can select from different strategies that are used to determine changes made on known entities.
ObjectStateManagerkeeps track of changes made to the entities and can be used to access those information including the original-values.
Facade, exposing entity-sets as IQueryable should qualify as “a simplified interface to a large body of code”, since turning such expressions into Entity SQL and than provider-specific SQL is a big deal.
ObjectContextprovides two eventy
SavingChanges. Since .NET events are an implementation of the observer-pattern, EF also qualifies for this one.
Another less talked about aspect of design patterns is that it gives developers common language to talk about solutions. The pattern is agnostic of the implementation language which puts more focus on a strong idea design rather than getting caught up in physical technological design and language limitations. This enables the developer to be more empowered when choosing which technologies to work with for a given project.
Developers should keep in the forefront of their mind that code should be written in a reusable way, whether or not there are any current plans for reuse. I can’t tell you how many, small or one off projects I’ve had that in hindsight, I wish I spent more time analyzing the design and building for reuse.
Why are design patterns important to me?
If you happen to have read my earlier posts, you know that I worked in the field while attending school. Every project that I coded, for school or work, was very procedural in my head. My brain just didn’t have the aptitude to think abstractly about object design. Well, that is until I took a course on design patterns.
We started out learning simple design patterns. By examining the differences between creational patterns such as the abstract factory and the builder pattern, it all started to come together and make sense. Design patterns make your job easier. Anything that makes my job easier, I’m always advocating for.
The class would normally begin with the professor giving us a problem statement on the board and we would individually or sometimes as teams, figure out a design using one of the Gang of Four design patterns, and then justify our design. This exercise demonstrated that not only is there more than one answer to certain problems, but that collaborative design where there is a common shared understanding of design patterns, yields the best software designs. Out of all the classes I have taken for Computer Science and Management Information Systems, this was by far the most valuable class I have taken.
How do I begin learning about design patterns?
Here are a list of resources I recommend:
- Head First Design Patterns: A Brain-Friendly Guide
“Learning from your mistakes makes you smart. Learning from other people’s mistakes makes you a genius.”-Anonymous