Software Patterns: You’d Better Know Them
December 2nd, 2007If you ever want to get a job as a software engineer, moving past that ho-hum data entry or scripting position at 40-50K/year, or if you at least want to impress the person interviewing you, then you’d better know what a software pattern is.
I’ve been asked this question in many job interviews since I graduated college
“do you know any software patterns?”
and I’ve always been able to give examples of my work that use software patterns but never really took the time to “dumb it down” to where I can make it an elevator pitch… so here goes.
What is a software pattern and why is it so important?
Software patterns started to form in the late 1980’s as Object Oriented Programming (OOP) began to emerge. They are an essential part of good software design, especially for large projects.
Lets take an example: Software patterns and humor are both abstract tools used to achieve an end result. Jokes have a purpose depending on the situation: they can serve as commic relief, they can help you impress a date or warm up an otherwise boring speech audience, etc… but if used in the wrong way they can be devistating: try telling a joke about fat people to your slightly overweight interviewer… yea that spells trouble. Try implementing a complex billing system without using data layer abstraction (good luck).
So, a software pattern, like humor, is an abstract solution to an abstract problem, used in different situations and in different ways to help to support the finished computer program become more efficient. If used in the right way, patterns are a wonderful addition to an engineer’s tool bag - but if used in the wrong way or not at all, programming can become horribly inefficient, waisting time and money!
Without patterns, programming can becomes inflexible and inefficient. A pattern could also be though of as an abstract blueprint for helping to develop better software. It’s like a path that you can follow, not really a solution to any specific problem, but a best practice to help you get to the end result: solid software design.
I’ve had a lot of experience programming computers since I began during the late 90’s, from C to C++ to Java to PHP to Perl to shell scripting to XML to AJAX methods to Javascript to MySQL… but unless you understand how underlying software patterns work that make efficient use of programming languages then someone else will get the job.
Parts to a Software Pattern
- Name, every pattern has a short description that “dumbs” down sentences of description into a single word or phrase.
- The Problem should be the reason or motivation to try and implement your software solutions more efficiently. Probably the most difficult part of using patterns is to realize an abstract problem can be approached using an existing or yet to be identified abstract software pattern.
- Solution - this is how your problem is solved. It’s probably going to take the form of a concept rather than code since your problem and solution are both going to be abstract.
- Consequences or trade-offs in using one pattern over another can be thought of in terms of the time/space idea in computer science: pattern flexibility, ease of reuse, extensibility, and portability.
Why should we use Patterns?
Patterns Increase flexibility by allowing us to implement complex systems with loose coupling of code. E.g. we can use interfaces within PHP to ensure that two objects of type A and B (both utilizing the interface) will have an implementation of any and all functions defined in the interface (each object can handle the method a different way while still using the same function name!). This way we can have a controller object C, say a list manager, that can be responsible for telling objects A and B (list observers) that each do different things when changes to the list occur, without C knowing what run() will do on either A or B, just that it happens. This example pattern can be used in process queues such as kernel schedulers within operating systems or email blasting programs.- Patterns are situation independent, meaning you can transfer a pattern from one coding project to another irrespective of the two projects’ specific requirements. .
- Patterns can be thought of as language independent, meaning you can transfer a software pattern from one language to another by modifying the language syntax. E.g. a pattern rooted within a PHP program can be used within a C++ program or can be transfered to a Java based program.
- Patterns are composable, which means you can use more than one pattern or integrate one pattern into another pattern to a solve a given problem. Composing patterns can increase coding efficiency because you are able to build on your previous work to make higher level objects do more complex tasks without spending much more time.
Types of Software Patterns
- Design Patterns help to solve a recurring problems within software engineering. They will typically show relationships or interactions between classes or objects in a system.
- Analysis patterns are more of a way to conceptualize the problem at hand to help the developer gain a deeper understanding of the elements involved.
- Model patterns help to represent data storage implementations within a relational database. For example, an efficient way to store data within a database is to use the primary and foreign key concept to help “normalize” or reduce data repetition within data tables.
- Architectural Patterns, such as the Model View Controller (MVC) , allow programmers to section off parts of a software program and lay out an organization schema to help get a bird’s eye view of how a software system functions as a whole.
Examples of Patterns
One of the most basic architecture patterns is the Model View Controller (MVC) pattern as I mentioned previously. Again, MVC is a way to get a large picture view of how a software system functions. There are 3 parts to MVC:
- The Model is how your data is going to be represented. This is usually in the form of a relational database (MySQL).
- We use a Controller to interact and query the data within the Model layer. The controller also sends data to the view. Some people refer to the Controller as the business logic within a software system.
- The View is a way to represent or serve up the data manipulated by the controller from the model. The view is typically what the end user interacts with, often times in the form of a web page.
The important point about MVC architecture is that the 3 different layers are independent from one another or abstracted away to help one concentrate or be focused on each part when implementation time arrives. For example, the model should know noting about the controller or the view. The View should know nothing about how the model has been implemented. Again, it would be the controller’s job to “talk” or interface between model data and the end user’s point of view.
Another example of a pattern is the Singleton Pattern: You’re creating a program that will be responsible for targeting, loading and shooting ammunition from the main guns of a new Marine fighter jet. You’ve got to access a database over the life of the program in many different places and at different times to calculate and account for ammunition reloading. You could open and close a database connection every-single-time you need to reload but that could create a time overhead too expensive in this mission critical application and our fighter jet might not win. SOLUTION: try using a database connection object that is opened and closed only once over the life of the program and is passed around to the other application objects when needed for data accounting purposes.
Note: There are many more software patterns than the two that I’ve given and probably a lot more still waiting to be found and categorized.
Landing a good Software Job
Good programming comes from experience. Software patterns help to “encapsulate” this experience so that we can study, learn and become better at what we do in the software world. Remember, if you’re looking to get hired, understanding software patterns will probably mean the difference between that 50K/year scripting job and the 75K+/year engineering position.