[erlang-questions] Design pattern: single responsibility
Judson Lester
nyarly@REDACTED
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?
Judson
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_
> principle
> 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.
> Advantages:
>
> 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.
>
> Disadvantages:
>
> 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.
>
> Example:
>
> Separating logging from working.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150306/f14da8a4/attachment.htm>
More information about the erlang-questions
mailing list