Thanks! This is a great article. As primarily a Ruby developer I find Interface Segregation to be a difficult one to convey myself :) It is possible but you need some convoluted examples. I really liked that you came down to cohesion being the responsibility.
I feel like with most of these principled they are great in theory and great to keep in mind whilst working BUT where and when to apply them requires consideration and it is not always best to apply them especially at the outset of solving an issue.
I personally find SRP to be more about dependencies and what would need to change if the assumptions we built this code under change.
I recently attended a course by Sandi Metz where she quite honestly made the point (that I will paraphrase) that OOP is about tradeoffs and that OOP is quite often about making the entire problem harder to think about with the hopes that we'll be able to create lots of little things to think about. By focussing on SOLID we aim to make those pieces so easy to think about, work on and maintain that the overall additional burden of using OOP is moot.
With that in mind I would say that you have to ask, is splitting something like data access into 3 classes beneficial to everybody that would touch this code? Not to mention how often are we in this code fixing bugs and adding features?
In the end I think we should consider ourselves in the application space to be like engineers where our output has to be justified by the resources used to achieve the goal. If we split a simple data access class into 3 classes that we never touch again OR that we need to load every time we think about data access then we have made the wrong choice.
Thanks! This is a great article. As primarily a Ruby developer I find Interface Segregation to be a difficult one to convey myself :) It is possible but you need some convoluted examples. I really liked that you came down to cohesion being the responsibility.
I feel like with most of these principled they are great in theory and great to keep in mind whilst working BUT where and when to apply them requires consideration and it is not always best to apply them especially at the outset of solving an issue.
I personally find SRP to be more about dependencies and what would need to change if the assumptions we built this code under change.
I recently attended a course by Sandi Metz where she quite honestly made the point (that I will paraphrase) that OOP is about tradeoffs and that OOP is quite often about making the entire problem harder to think about with the hopes that we'll be able to create lots of little things to think about. By focussing on SOLID we aim to make those pieces so easy to think about, work on and maintain that the overall additional burden of using OOP is moot.
With that in mind I would say that you have to ask, is splitting something like data access into 3 classes beneficial to everybody that would touch this code? Not to mention how often are we in this code fixing bugs and adding features?
In the end I think we should consider ourselves in the application space to be like engineers where our output has to be justified by the resources used to achieve the goal. If we split a simple data access class into 3 classes that we never touch again OR that we need to load every time we think about data access then we have made the wrong choice.
Thanks again!
Many thanks to you for the long comment!