[LRUG] The advantage of immutability?

[Roland Swingler]

Yeah, I think there is a distinction between code where you have control of
everything and when you're using a framework such as rails. It is about
whether you're the framework/language supports/is neutral/actively works
against you taking a certain approach.

If you have control of everything then you are free to use immutable
objects everywhere if you so choose, and get the advantages mentioned. If
you take the common types of toy problems that are used as 'challenges' as
part of the recruitment process, 9 out of 10 times your response will be
"better" if you follow the immutable objects approach. But then when you're
in a real world rails project there are a lot of assumptions made by the
framework authors and code already in your project which may not make it
the best/simplest approach, or invalidate the advantages.

Personally think this is why following 'extreme' approaches in toy or
practice problems is useful, because it gives you a pure environment to
experiment and practice; then you can spot small parts of your real
applications where the techniques may apply.

2 other unconnected thoughts:

* In the DDD world, they split things into Entities (things with identity
that change state over time, such as a Customer) and values which are
immutable (such as Address)
* In the Event Sourcing / CQRS model updates to state and viewing current
state are completely separated - all state changes are a log of updates
from which a 'current state' is constructed. Because of the way this work,
you can reconstruct your application state at any point in time since you
started it - an analagous model would be how git works.

Thanks,
Roland

On Thu, Sep 10, 2015 at 10:13 AM, Tom Armitage <tom at infovore.org> wrote:

> On Thu, Sep 10, 2015 at 8:49 AM, Jonathon Horsman <jonathon at arctickiwi.com
> > wrote:
>
>>
>> given that having a data store as a shared global state the situation in
>> the vast majority of apps? Surely shoe-horning immutable objects onto a
>> mutable data store would always be the wrong solution?
>>
>>
> I'm sure someone will correct me if I'm wrong but - that's really a
> fallacy of the ActiveRecord pattern, right, where one domain object
> corresponds directly to its representation data store?
>
> This is the sort of thing something like a Repository pattern solves, ie:
> you have a mutable data store, and a way of communicating to/from it (to
> save/update/delete records) - but your domain objects are actually
> separate. You retrieve data from the database, and use it to build
> immutable objects to pass around the application. Instead of mutating them,
> you replace them with new objects as/when - and then, when you come to
> saving it, your repository interface goes "oh-ho, this is really an edit to
> some rows", and it makes an UPDATE rather than just new rows everywhere -
> even though you've been making new objects in the application.
>
> What that also means is you can represent something that might be stored
> in a single table as a collection of objects, or vice versa, something
> that's correctly distributed across tables with relationships as *fewer* objects.
> It breaks the direct link between A Thing and A Table. This is entirely
> counter to ActiveRecord, but AR is not the only way.
>
> Disclaimer: I've never used this approach personally.
>
> But: I can see the appeal (especially now I've explained it to myself).
>
> As for "doesn't it make it more complex"; as usual, the answer's often
> *yes*; except the number of times I've continued to build on that
> foundation to a point where I either need to a) do a big refactoring or b)
> carry on in a string-and-glue manner means that, as usual, choosing to make
> something more complex is not always the worst idea if it more accurately
> represents the shape of the world. As ever, that's the hard part of making
> software: choosing when to make the decision to change direction.
>
> I hope I've not totally misunderstood Repositories.
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20150910/9be86ef9/attachment.html>