In that case I definitely recommend it 
you won’t be disappointed, I promise 
AstonJ
peerreynders
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
hubertlepicki
sasajuric
Author of Elixir In Action
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
Deithrian
SRP is everything! 
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 
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
OvermindDL1
cmkarlsson
The true test comes when you look at the code a year later Do you still love your code? If so well done!
4
Deithrian
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.
(refactoring ftw)
0
gregvaughn
There’s a fine line between good names and Hungarian notation (in whatever language) because you don’t have types.
1
OvermindDL1
None of that has anything whatsoever to do with type driven programming. ^.^
Type driven programming would be something like, oh if we were to emulate Phoenix’s :safe html renderer:
type safe = SafeHTML of string
let make_input_safe input =
SafeHTML (escape_html input)
let raw input = SafeHTML raw
let render_html (SafeHTML html) = render_to_whatever html
Notice that I do define a wrapper type, it is documentation but otherwise no types are listed anywhere, not in the input arguments, no where else, it is all properly inferred. With the above you cannot even accidentally pass a non-safe chunk of html text to the renderer, you have to either mark is as raw or or escape the input. Also notice that the type drove the interface, not vice-versa.
Your examples are much more, hmm, Java-like, and Java is NOT a good language to do type-driven programming.
I’m not even sure what your example is demonstrating, do you have actual code to show?
And your things about the_word_apple and so forth seems very hungarian notation, but significantly more verbose, and verbosity can make code much harder to read as well.
Like say you have a unit of measurement, let’s say a meter:
let width_of_house = 12
Well that is not descriptive at all, we could do:
let meters_width_of_house = 12
That just makes it longer, and does not cause an error when we doing something like:
centimeters_is_expected_in_this_function meters_width_of_house
Wow that becomes unreadable very fast, and sure you may catch it with your eyes, but it is still easily missable. Compare this to a type driven approach to measurements:
type meter = Meter of float
let cm i = Meter (i /. 100.0)
let dm i = Meter (i /. 10.0)
let m i = Meter i
let km i = Meter (i *. 1000.0)
Or you could do something like:
type length =
| Meters of float
| Centimeters of float
| Kilometers of float
| Feet of float
...
let centimeters_of_length = function
| Meters m -> m
| Centimeters cm -> cm /. 100.0
| Kilometers km -> km *. 1000.0
| Feet f -> f *. 30.48
...
Or via Witnesses or a variety of other ways, whatever type style fits the pattern best. And you can keep names short, descriptive, readable, and never worry about the system compiling when you try to pass something to somewhere where it does not belong. ^.^
1