[erlang-questions] Decomposing Modules

[Garrett Smith]

Could be :)

If a set of functions stand out as forming a coherent interface for
some common scenarios, that might be a candidate for a separate
module. On the other hand, some modules are natural sinks for
functions - e.g. erlang or an application 'util' module.

For me, there's a clear separation of concerns between process
management (e.g. gen_server) and data type manipulation (e.g. dict,
graphs, etc.) Other concerns might deal with IO for a subsystem (e.g.
database, service, etc.) Still others with a type of computation, etc.

I wouldn't really worry too much about this and let real pain drive
your refactoring. There's no rule that says a module must be small or
limited to N functions. There was even a proposal by a prominent
Erlang programmer to get rid of modules altogether and just have a
single global namespace for functions.

You could experiment with various interfaces and see if that makes any
difference to your understanding, usability, or maintainability of the
software you're building. I would time-box that though as you run the
risk of over thinking this problem of keeping modules small. It might
not be an actual problem.

On Thu, Nov 12, 2015 at 4:16 PM, Judson Lester <nyarly@REDACTED> wrote:
> The further question, in my mind, is: does it make sense to split out the
> queries from the data structure? Or some of the utility stuff that transform
> representations of edges to and from statements for instance.
>
> On Thu, Nov 12, 2015 at 2:04 PM Garrett Smith <g@REDACTED> wrote:
>>
>> Without spending much time on this, my first impression is that you
>> may want to decouple the gen_server implementation from the data
>> structure implementation. These are probably separate concerns.
>>
>> The gen_server deals with state initialization and mutation for
>> processes. The data structure implementation is a bunch of pure
>> functions.
>>
>> On Thu, Nov 12, 2015 at 3:58 PM, Judson Lester <nyarly@REDACTED> wrote:
>> > Yeah, so, for my sins:
>> > https://git.lrdesign.com/judson/ergo/blob/master/src/ergo_graphs.erl
>> >
>> > On Thu, Nov 12, 2015 at 1:53 PM Judson Lester <nyarly@REDACTED> wrote:
>> >>
>> >> It's the depgraph manager for a build tool. The module is >1000 lines,
>> >> with 280 function clauses, and shares some type specs and record defs
>> >> through a .hrl.  The project isn't public yet, but maybe I should get
>> >> over
>> >> that.
>> >>
>> >> On Thu, Nov 12, 2015 at 12:05 PM Garrett Smith <g@REDACTED> wrote:
>> >>>
>> >>> What's an example of a really large module that is triggering your
>> >>> spidey senses?
>> >>>
>> >>> On Thu, Nov 12, 2015 at 12:48 PM, Judson Lester <nyarly@REDACTED>
>> >>> wrote:
>> >>> > I suspect I'm not alone in having modules that grow to unwieldy
>> >>> > sizes.
>> >>> > I'm
>> >>> > starting to understand better general classes of module that make
>> >>> > sense
>> >>> > to
>> >>> > address, but I'm wondering if there's advice about particular
>> >>> > features
>> >>> > within a module that suggest how to separate functions into smaller,
>> >>> > more
>> >>> > module chunks.
>> >>> >
>> >>> > My slowly developing intuition is that it has a lot to do with the
>> >>> > parameters of the functions, and I get the sense that there's a gap
>> >>> > in
>> >>> > my
>> >>> > understanding that'll make the decomposition easier. Maybe a
>> >>> > refactoring of
>> >>> > those parameters that'll make the separation more obvious?
>> >>> >
>> >>> > Judson
>> >>> >
>> >>> > _______________________________________________
>> >>> > erlang-questions mailing list
>> >>> > erlang-questions@REDACTED
>> >>> > http://erlang.org/mailman/listinfo/erlang-questions
>> >>> >