[erlang-questions] Design pattern: single responsibility
Fri Mar 6 18:57:40 CET 2015
I'll admit, I didn't have whole-application patterns in mind when I brought
it up, but it definitely seems like an area in Erlang worthy of discussion.
Which is what design patterns are for: not just "it depends" but "on what"
and "between these alternatives."
It also seems like Single Responsibility might apply to modules, even
within a process. As a novice in Erlang, I think I was getting (read:
misunderstanding) the message that module = process, partly from the
pattern of exposing interfaces in the same module that defines a gen_server
behavior (a practice now enshrined in an Elixir macro). I've been finding
good outcomes from breaking up modules the same way e.g. you might break up
a function into smaller ones. I'm sure I'm not the only one, right?
On Thu, Mar 5, 2015 at 3:55 PM Richard A. O'Keefe <ok@REDACTED> wrote:
> We've had a thread about the use or otherwise of design patterns in Erlang.
> I've also had some mail that had me thinking about this.
> One idea which already has a name is "Single Responsibility".
> The Wikipedia article http://en.wikipedia.org/wiki/Single_responsibility_
> says it's about classes, but really it's nothing but cohesiveness
> by another name.
> In the context of Erlang,
> the idea is that each process should do one job.
> Suppose a process has two jobs, A and B.
> And something about working on A makes it crash.
> Now nobody is doing job B.
> If we have two processes, they can execute on
> different cores.
> If jobs A and B are coupled somehow, there will have
> to be communication between the processes working on
> them that there wouldn't be in a single process.
> Separating logging from working.
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions