I’ve been an advocate of the single-responsibility principle for a long time. I’ve used it effectively on several projects to make sure that each individual class or function has a singular purpose. It’s definitely kept me from making an unholy mess out of some of the more complicated projects I’ve worked on.
However, particularly with large projects, I kept feeling like I needed another layer of abstraction. Something that would help organize all these simple, tiny functions into a cohesive whole. Something that would help guide the structure of the app as new features were added. That’s roughly where my head was at when I began to read about hexagonal architecture.
Read more on Hexagonal Architecture in Action…
Thijs van Dien wrote to us in early 2015 with some great questions about Presenter First’s place in application architecture in the post-MVC era. His well-researched questions were a joy to respond to; while there’ve been many advances in desktop and mobile programming patterns since we first wrote about PF back in 2007, we still find value in the core aspects of Presenter First. I’ve captured our email conversation here for broader sharing and posterity. Read more on Is Presenter First Still Valuable to Modern App Architecture?…
Did you know that you can write inline C# in your XAML file with the x:Code Intrinsic type? When I stumbled on this feature, my first reaction was, “Wow, I didn’t know you could do that!” After several years of using WPF, I thought I knew all the tricks. Discovering something new was exciting!
The initial thrill was tempered once I thought about it, however, and I was soon saying, “Oh no, people should never use this!” I generally keep an open mind about code, because even if it doesn’t fit my immediate needs, I know someone might find it useful. With inline C#, however, I am slightly bewildered that this feature was ever considered useful enough for Microsoft to include. Read more on You Can Write Inline C# in XAML – But Should You?…
Organizing a project’s architecture into layers is a common strategy. But I’ve noticed, over the course of my relatively short career, that a layered architecture becomes counter-productive when a project reaches a certain age or size (I’m not sure which).
When the Layer Model Works
The idea behind a layered approach is nice: any particular layer of the software should be interchangeable with another layer that implements the same interface. This helps to drive the code base to a certain level of reuse.
In general, the layers are stacked. The rules are that a layer may only depend on the layer below it. It may not call into the layer above, and it cannot call into any layers other than the layer underneath it.
In simple cases, this model works out well. There’s a cleanly defined system that’s easily modeled in our minds.
Read more on An Alternative to the Layer Model in C Project Design…
Software is often designed around modeling things in real life. The problem is, these designs do not translate well to clean software. The resulting architecture and code base are often coupled and difficult to maintain. A good example of coupling is interacting with a rails application with the intent of creating a new user record and accidentally triggering a welcome email to be sent. In this example, persistence is tightly coupled with domain logic. These tightly coupled applications violate one of the most important principles in software architecture, the single responsibility principle.
Single Responsibility Principle
The single responsibility principle can be defined in two ways:
- An object should do only one thing.
- An object should have only one reason to change.
The basics and understanding are simple; however, implementation is considerably more difficult. Drawing the dividing line through an object’s responsibilities can be difficult, and it is possible to split an object too many times.
There are also a few more things to keep in mind during when thinking about single responsibility. How often are things changing inside of the class, and how would I describe the object’s purpose to someone without any knowledge? When a class has pieces that are changing at different rates, the single responsibility principle is being probably being violated. Also, if you describe the object and use the words “and” or “or,” the class might be violating single responsibility.
Read more on Improve Your Software Architecture with Ports and Adapters…