[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