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

Chat / Discussions
, ,
1

There is a wikipedia definition on this but it doesn’t really cover how you can go further in functional programming. I feel PragDave’s comment (from his course) is better from an Elixir perspective:

I know I’m like a broken record, but I can’t help it. I’m really excited to see how a functional approach makes it so much easier to honor the SRP, both at the function and module level. The fact that state is passed around, and not simply shared, means that functions can and modules can both be split and moved around.

What does the SRP mean to you? How far do you go? How strictly to you adhere to these (or your own) guidelines?

4 Likes
3

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

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.

2 Likes
4

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

“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

3 Likes
5

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.

1 Like
6

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.

8 Likes
7

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 :slight_smile:

3 Likes
8

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 :003:

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 :slight_smile:

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 :slight_smile:

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 :scream: (I was like, you should see my Rails models :lol:) 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 :023: (Thanks Peer!)

1 Like
9

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.

6 Likes
10

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.

http://blog.cleancoder.com/uncle-bob/2014/11/24/FPvsOO.html

5 Likes
11

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 :slight_smile:

1 Like
12

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

1 Like
13

In that case I definitely recommend it :003: you won’t be disappointed, I promise :lol:

1 Like
14

I think it may have more to do with where you are (in reference to understanding the intent of SRP - as it seems to be a new concept for you). If you go by the Dreyfus model of skill acquisition a “novice” will tend towards “rigid adherence to taught rules or plans” - but in design/architecture things are rarely black and white - everything is about making tradeoffs. So the real “mental overhead” comes from the fact that there are numerous design guidelines that have to be balanced to meet the requirements for a particular situation - some will be met while others will be deliberately violated to gain some highly valued benefit.

For Example, Active Record violates SRP because it mixes the responsibilities of business logic AND persistence management. Yet it is listed as a viable Enterprise Application Pattern:
####Pros:

  • Good choice for domain logic that isn’t too complex, such as creates, reads, updates, and deletes.
  • Simplicity; easy to build, easy to understand.
  • Typically less duplication than Transaction Scripts.

####Cons:

  • Works well only if objects correspond directly to the database tables: an isomorphic schema.
  • Complex domain logic using direct relationships, collections, inheritance doesn’t easily map onto Active Record.
  • Couples the object design to the database design; makes it more difficult to refactor either (independently) as a project goes forward.

i.e. if the “cons” aren’t an issue for you (ever) and you value the “simplicity” then Active Record is a valid design choice (and investing in the higher effort alternatives is a waste).

Collectively all these design principles and guidelines are supposed to give you a sense of all the opposing forces and deliberate tradeoffs that come into play when trying to arrive at a “good design”. Ultimately no good comes from applying these principles and guidelines dogmatically.

Aside: Some people don’t like the SRP

Frankly the examples seemed to be easier to justify with “separation of concerns”:

  • Persistence
  • Domain logic
  • UI (+ reports)

Influenced by DDD “Domain Logic” is the focal point - it dictates the data types and is the dominating influence for the interface designs. Given that the domain logic only deals in domain types, SQL statements belong with persistence (provided you’re even using an RDBMS). Ideally the public API exposed by the domain logic should be able to support a whole range of UIs (web, mobile, desktop, command-line, etc. - though possibly with support BFFs) - but even when keeping it simple with a single frontend, domain logic doesn’t belong in the UI (though validation logic may be duplicated there).

The example with the calculations that differed for the clerical and manager report seemed contrived. It’s valid to say that not everything that “looks the same” is automatically duplication - but the example pre-supposes the existence of distinct domain concepts that somehow had the same calculations up to this point.

I think when Scott Wlaschin jovially states (SRP => functions) he is referring to the typically highly focused nature of short, pure functions.

Modules can be used in the role of namespaces. I think the closest thing to a class is a module that defines a struct. That module should focus on the struct and the data within the struct should be focused.

Elsewhere you stated:

To me this read like you felt that Changeset conflated the notion of being a changeset with the responsibility of validation - which sounds like a violation of SRP or at least a lack of cohesion. Yet lots of people seem to appreciate the convenience afforded to them by this conflation (i.e. they are willing to accept this tradeoff).

4 Likes
15

You, sir, made really good observation here.

16

I personally believe that on some higher-level of thinking many ideas transcend paradigms. In particular, I think that a large module which deals with many things is more problematic to read and understand.

A typical example I see is a case where complex GenServer state is handled directly in the GenServer module. By moving the state manipulation to a separate module, we can separate the domain logic from the time-flow logic, and this allows us to study each aspect of our system in isolation.

For a more concrete example, see my example blackjack code from my To spawn, or not to spawn? article. The domain management is done in separate modules, which means that domain code is not polluted with GenServer and vice versa.

IMO the case for short classes (and also modules and functions) is to allow the reader to understand a single concept without worrying about non-essential details. Being able to understand a domain model without caring how it’s used from the rest of the system simplifies the code analysis, debugging, and extension.

I should also mention that I’m not a purist here. For example, if the process state is simple enough, I just bundle it inside the GenServer. If the model grows, then I split.

But tl;dr I believe that SRP and similar ideas, vague as they are, still apply in FP.

8 Likes
17

SRP is everything! :open_mouth: everything!
Level 1 is the application.
Level 2 are the modules. They break the application apart and their names describe the single problem every one of them is trying to solve.
Level 3 are high level functions. They break the module problem into small steps and their names describe those steps.
Level 4 are the low level functions. They do the actual work and are often one liners, at worst 3.

So when I read my code I go to the main file and look at the module names to recall what’s going on.
Then it’s just a matter of following the module names and function names down the line to add or change stuff.

I love this approach because I don’t like writing tests and I don’t like writing comments.
Why write a unit test for the + sign? It will add two numbers (in every respectable language) right?
Then come the function names which are a living documentation, no need for comments.
def add_two_numbers do end done!
Higher level functions only describe the steps taken to solve a problem, no work is done there.
If there’s a problem, you can instantly tell where it is, because all the work is done in low level functions, and if it’s a logic problem, then it’s a logic problem, and it’s easy to spot because all low level functions must work, which they always should if done right. 1+1 should always work right? (in every respectable language)

In other words, I feel like “comments”, “unit tests”, “types”, “specs”, and so on, are the crutches of the lazy programmer, who didn’t break the top problem into small modules,didn’t write functions that describe the steps taken to solve the problem, didn’t write low level functions that are so simple it’s impossible to have an error, and they just want to write code like this “oifaofiapodihfhopahpofhopasphofhogihasjuivfhus” and then go oh my unit test will help me, and look at all the types I have, the compiler will catch stuff, and check out my 5 pages of unintelligible comments describing my amazing “isdjfhpsaohgapoigaofghpg” code.

Why write comments when I can write verbose names for modules and functions, and if names become too long, then it’s obvious the module or function is trying to solve too much, break it down further, done!

Anyway, I bet I’ll get some heat for this, but it’s ok :slight_smile: I write my code, I love my code, I love, love, love, my code. Did I mention that I love my code? I want to hire a racing horse to kick me on the head when reading other people’s code <3 not your code dear reader! Your code is nice because it’s Elixir and SRP ; )

3 Likes
18

@Deithrian You’ve never tried type-based programming then. ^.^

2 Likes
19

The true test comes when you look at the code a year later :slight_smile: Do you still love your code? If so well done!

4 Likes
20

I just prefer “the_word_apple” and “the_adjective_red” vs “String a = ‘apple’”, “String b = ‘red’”

“the_word_apple” + 3. hmmm
the_word_apple = the_word_hamburger. hmmmm
put_item_in_object(the_word_apple, the_object_basket)

a+3. why not?
a = c. sure! What was “c” again?
g(a,n). Oh no! “g” was milk the cows, buy a newspaper, say the moon is red, 4356334, and “n” was launch the rockets? Dang it…
I’m exaggerating, but not by much. :slight_smile:
(refactoring ftw)

21

There’s a fine line between good names and Hungarian notation (in whatever language) because you don’t have types.

1 Like