Object-oriented design and architectural software patterns
As a student I always think about the decisions that are made when receiving a major software development project. All down to the smaller decisions when coding. The first layer of decisions is where we discuss SYSTEM DESIGN POST and choose what architectural pattern(s) we will be using. This is a very critical process, a wrong decision can cause a lot of headache later down the road. It will also cost a lot of money and time to refactor the code and chosen technologies.
Architectural patterns and examples
Architectural patterns are general reusable solutions to commonly occurring problems within a given context. They were made to combat problems in software engineering, such as hardware performance limitations and high availability. The most common software architectural pattern is the layer architecture. Where the request goes through multiple predefined layers:
1. Presentation Layer (ui)
2. Application Layer (services)
3. Business Logic Layer (domain)
4. Data Layer (persistance)
Layers could be grouped. For example, it is common to find the business layer and persistence layer combined into a single layer. This just means that the functions and responsibilities of these two layers have been grouped to occur at a single layer. There are more layers you can include in this process, such as the persistence layer.
So how do you choose the right pattern(s)?
We need to follow the project scope, that means that the goals and the deadlines should be met. You could use the right pattern(s), but in certain situations it could take way longer than the predefined deadlines. Software development isn't always about code and data, but the cost of it is important too. Businesses can't always afford to built the perfect software. However, building and maintaining flexible code is important too. Experienced managerial software engineers and technical software engineers will recognize these patterns after a while and make the right decisions, while thinking about time and cost.
Architectural pattern analysis
Patterns can be rated on the following characteristics:
- Overall agility
- Ease of deployment
- Testability
- Performance
- Scalability
- Ease of development
Each characteristic will get a rating (low vs high) and an analysis/reason of rating. Patterns should not be compared directly, since not every pattern has the same problem description. A summary of rated patterns will help you determine which pattern might be best for your situation. For example your project scope might prefer scalability above ease of development.
Object-oriented design
A design pattern in an object-oriented language is an abstract solution to commonly occurring problems while writing code. Every pattern is identified by name, has a solution to a problem and comes with their consequences.
"Design patterns have developed and evolved over time. They reflect untold redesign and recoding as developers have struggled for greater reuse and flexibility in their software." - Elements of reusable Object-oriented Software book by The gang of four
However not every problem that could be solved using an object-oriented design pattern should be solved with that pattern. The patterns are rather a guideline that you could follow should you want to. As a student I'd come across various repetitive problems such as the Facade, Builder and Singleton patterns. I always wondered what they were, and when to use them. It's very easy to use patterns where you don't need to. Since they are just guidelines, I tried to discover them by implementing them in my code.
I have yet to learn all patterns, but I know for sure I will use them more in the future!
References:
https://www.ou.nl/documents/40554/791670/IM0203_03.pdf/30dae517-691e-b3c7-22ed-a55ad27726d6
https://en.wikipedia.org/wiki/Architectural_pattern#Examples