[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.)

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
>> >>> >