Single Responsibility Principle
Episode 238 · April 4, 2018
A class should have only a single responsibility
Discussion
Great series. I would love if you continue with this, plus with testing. Testing is something that you haven't really touched upon much here.
Also with some design patterns that follow along with this principles.
Also with some design patterns that follow along with this principles.
We will finally be diving into testing this year soon. 🤓
+1
+1
Very nice, Chris. It's helpful to hear and see how principles and best practices translate into real world examples. It's easy to fall down a rabbit hole and more difficult to dig yourself out than it is to avoid these pitfalls in the first place. Looking forward to the rest of this series. Also, congrats on Hatch.io. I will be making the move in the near future.
Thanks Ron!
Great episode. Look forward to seeing more! I do something similar, but for domain objects, I generally namespace them by functionality and then throw it in lib. app/ for rails specific stuff /lib for domain stuff
I don't want to sound harsh, but please explain in what Universe is it appropriate to use Rails to configure servers, nginx, SSL, Sidekiq, when there is Chef (ruby), Puppet (ruby), Ansible (python/yaml), Salt (python), and Terraform (C/C++/HashiCorp), not to mention Docker (go) — that already do that incredibly well with a wide community support to pull from? To say that this example comes from a real-world Rails app, and then to proceed to describe what is effectively a very basic cloud automation — as an appropriate use of Rails Web Framework, is (IMHO) ludicrous. It completely flies in the face of the design principles you are touting. Perhaps it would help if you spent a bit of time explaining why Rails is used in such an unusual context.
I think this comment misses the mark, you should use whatever tool you'd like to solve your problems.
Chef/Ansible/Puppet/Salt/Terraform are all added DSLs/other things to learn. If all you need is a basic automation tool, and you're not going to need more, than doing it in Rails will be fine.
Looking forward to seeing your videos on those other tools for how you would do it.
Chef/Ansible/Puppet/Salt/Terraform are all added DSLs/other things to learn. If all you need is a basic automation tool, and you're not going to need more, than doing it in Rails will be fine.
Looking forward to seeing your videos on those other tools for how you would do it.
You don't sound harsh - just badly researched. Chris Oliver is literally the proprietor of an instant-on server configuration company that is an alternative to choosing Chef/Puppet/Ansible et al. It's like telling a young Sergey Brin he should just use Alta Vista because no-one needs another search engine.
Your second mistake was thinking that the application mattered, when clearly it just serves as a vehicle for illustrating the SRP.
Your final mistake is in looking at the result and seeing Rails, when one of the major outcomes by the end of the episode is that the provisioning code is now decoupled from Rails.
Your second mistake was thinking that the application mattered, when clearly it just serves as a vehicle for illustrating the SRP.
Your final mistake is in looking at the result and seeing Rails, when one of the major outcomes by the end of the episode is that the provisioning code is now decoupled from Rails.
Hi Konstantin, welcome to the gorails community.
It seems like you've completely misunderstood the point of this video and point of hatchbox.io. (without meaning to sound harsh of course).
To answer your question, it is perfectly appropriate to use rails when building something like hatchbox.io when you're a rails developer. In fact it would be a strange decision to build it in anything else, do you not agree?
To say this flies in the face of the Single Responsibility Principle suggests you've not yet grasped it but keep trying, we're all here to learn! Good luck with your development!
It seems like you've completely misunderstood the point of this video and point of hatchbox.io. (without meaning to sound harsh of course).
To answer your question, it is perfectly appropriate to use rails when building something like hatchbox.io when you're a rails developer. In fact it would be a strange decision to build it in anything else, do you not agree?
To say this flies in the face of the Single Responsibility Principle suggests you've not yet grasped it but keep trying, we're all here to learn! Good luck with your development!
Great episode!
Some people might misunderstand what happened here and end up with the (unfortunately common) misunderstanding that SRP means "one method per class".
What Chris did is refactor a set of domain-specific behaviours from being collected in one class, to each being classes in their own right. The next step might be to compose them back together as necessary, without over-engineering the infrastructure that does so.
The example I personally like to give is extracting business rules implemented as "just code" into Rule classes, and then delivering new and useful outcomes by re-ordering rule objects or using subclasses and variants.
For the Rails programmer this is hopefully all in contrast to using Concerns which are basically just a way to chop up fat models into separate files and don't lead to new and interesting runtime structures.
Some people might misunderstand what happened here and end up with the (unfortunately common) misunderstanding that SRP means "one method per class".
What Chris did is refactor a set of domain-specific behaviours from being collected in one class, to each being classes in their own right. The next step might be to compose them back together as necessary, without over-engineering the infrastructure that does so.
The example I personally like to give is extracting business rules implemented as "just code" into Rule classes, and then delivering new and useful outcomes by re-ordering rule objects or using subclasses and variants.
For the Rails programmer this is hopefully all in contrast to using Concerns which are basically just a way to chop up fat models into separate files and don't lead to new and interesting runtime structures.
Thanks, great and really interesting episode (as always...) !
I have two questions:
1) What do you think about turning the Server::SSH class into a module, and mixing it in into the two other sever classes (instead of using inheritance).
2) Using service objects to do stuff is a similar technique right ?
Thanks
I have two questions:
1) What do you think about turning the Server::SSH class into a module, and mixing it in into the two other sever classes (instead of using inheritance).
2) Using service objects to do stuff is a similar technique right ?
Thanks
Login or create an account to join the conversation.