Single Responsibility Principle - what does it mean to you and your Elixir apps?

I’m moving my thoughts out into a separate post here

To me the SRP means:

• Functions should only be responsible for one thing (use multiple function definitions instead of multiple if/elses)
• Modules should only be concerned with one thing

I’m not sure if this counts as part of the SRP, but apps being split into components could be closely related as well.

Related: From the horses mouth NDC 2012 Norway: Robert C. Martin - The Single Responsibility Principle (51:08)

[quote]Modules should only be concerned with one thing[/quote]

“Responsibility” is a bit vague and its scope is sometimes open to interpretation. “Things that change for the same reason should be grouped together” seems a much clearer way of describing what SRP is all about - and it’s a notion that can be more sensibly applied at varying levels of granularity.

At higher levels of granularity we enter the realm of loose coupling vs. high cohesion (and the boundary that separates both).

• High Cohesion - What belongs together should stay together.
• Loose Coupling - Two collaborating parts should only depend on the least amount of detail between them (and not one iota more than) necessary to complete the collaboration.

Ultimately the idea is to keep change (over time) contained in highly focused areas and minimize “ripple effects” to dependent parts.

PS: Scott Wlaschin likes to point out:

Let’s take the Single Responsibility Principle and the Interface Segregation Principle to the extreme … every interface should only have one method.
An interface with one method is a function type

Thank you for recommending elixir for programmers by Dave Thomas. The course is fantastic and very insightful. The more I learn about FP and Elixir the more my eyes are becoming opened to a better way of writing programs.

I really like the idea of SRP. I usually start with a function that does too much and then chop it up into little digestible chunks, i.e. multiple function definitions

I also really really like Microservices. Of course you shouldn’t go crazy with it but apps being split into components makes a lot of sense to me. I’ve worked on monolithic apps where things were just out of control and unmanageable. I think Elixir is tailor made for SRP and microservice style development. One thing I’m unsure about is the database layer. I know Dave thinks Phoenix should only be a web interface and know nothing about the database but databases can be complicated to configure and use as a microservice.

I have a theory that a lot of these things we learned when doing OOP, no longer make sense when you switch to functional programming. This is precisely because they solve problems that are a result of using Object-Oriented programming in first place.

Take this single responsibility principle for a review, and compare this to how things from standard library work. In either version (one responsibility, one reason to change), this is being broken all the time.

In Elixir & Erlang, modules group together the related functions. That’s it, there’s no big theory behind it. These functions may perform one or multiple things, but as long as it makes sense to keep them in the same module - they are kept there.

It might be pretty good idea to apply this principle to actors however. In particular, breaking down complicated processes to a bunch of related ones. One to keep the state, one to handle the transitions logic (FSM), another one to persist changes etc. Each one being responsible for one thing and one thing only

He talks about splitting things into roles/who might need them - so separate code that’s related to a designer, code that generates reports for a clerk, code responsible for reports for a manager etc. He also suggests that’s ok to repeat code as it may change for one or the other, for example, a clerk and manager may need the same code to begin with but one of their needs might change in the future - so this kind of separation allows that kind of change easily.

Would you agree that’s the gist of it?

For me I think that adds quite a bit of mental overhead, and that it may be simpler to just think in terms of what something does, and create functions and modules focused on that one thing (which would then also allow things to be reused). Perhaps I am being a bit too lazy… or just need a few other examples to better picture it.

You should definitely check out the video in @peerreynders’s post here:

Where Dan talks about the Replaceable Component Architecture (see Peer’s links in the post as they jump right to the appropriate parts).

I’m in the same boat. I hope Dave does another course but this time jumps right into the application (rather than teaching the language basics) and covers databases. I’m going to email him with the suggestion once I’ve finished the course

In the meantime, check out my post and the link in it here (again thanks to Peer for that link!)

I’m glad you are enjoying Dave’s course too - I love it! Am 90% through it now - can’t wait to finish it

I think this is one of the reasons why people are so excited about Elixir (and similar languages) because they make it so easy to follow good principles like the SRP

One of the things that surprised me in Dave’s course is when he got to a Phoenix view and said that it was about 35 lines which seemed a bit large to him (I was like, you should see my Rails models ) and said that’s normally a good indication that there is a group of code related to one thing, and sure enough there were 22 lines related to one thing (state) and we extracted that out into a dedicated _state helper.

This also falls in line with the ‘fits in my head’ mantra, where you shouldn’t be looking at code that is bigger than your head (i.e no scrolling!). “If you have to page up and down - it’s probably too complicated”.

I love that talk btw - so many good ideas presented in it (Thanks Peer!)

I think @pragdave might be importing some wisdom from his object-oriented life ;). I was thinking about it when I first opened Elixir’s own source code files, or sources of prominent Elixir libraries like Ecto, and was shocked by the large files containing hundreds of lines of code (+many more lines of documentation). In Erlang they even add a lot of unit tests at the end of the file to keep the tests close to the module they test! (moduledoc in Elixir but more popular I think)

But then, I realized what is a reason for having a short classes and it suddenly made more sense. The reason why we want to keep our classes short and clean is that we can mentally model how instances of this class will behave, and how they will modify the object’s attributes in it’s life cycle. So - we couple state to the functions that operate on this state, and we want this to be as small as possible - otherwise we easily loose track of how this works, and bugs sneak in.

In Elixir, the module has no state. The main reason for keeping classes short does not apply here anymore. Of course, it becomes tiresome to work with files that are thousands lines long, but there is no such thing as internal state of object to be concerned with.

Having said the above: again, the object-oriented wisdom of keeping classes short does have it’s place in Elixir, and again this is when you create processes (GenServer etc). I think it makes total sense to keep them short in terms of lines of code and focused on one thing.

I like this picture taken from Scott Wlaschin youtube video on functional design pattern.

fpvsoo.jpg932×554 44 KB

But I also enjoyed Uncle Bob’s reply to it.

Personally I feel shorter modules can impact readability and therefore make it easier to ‘make sense’ of what’s going on. I also think they’re less off-putting and fatigue-inducing; when faced with having to make sense of one huge file or a few smaller ones, I think the smaller ones are more digestible and therefore might be more appealing.

There is another example in Dave’s course when working with Genservers. He says one way to go about things is to use a single file, but his preferred way used three. When comparing the two, I preferred his way of breaking things apart too.

I know it probably sounds like I’m on commission (I’m not! I just really REALLY love it!) but I highly recommend his course, even to experienced developers like yourself - if nothing more than to see how other experienced developers are going about things

I… thanks for the kind words but I’m still learning all things Erlang & Elixir