To put take a different angle on it: you might soon get to *like* that it's
usual to pass in everything as a parameter explicitly. It has the advantage
that it's easy to reason about what a function does just by looking at the
function. In the example above, when reading AccountRepository.Save you
need to check elsewhere to see how _connection is defined. Whereas with the
function save, so long as the parameters you feed in are sensible, then you
can be pretty sure what it will do.
Making the functions self-contained like this is also a boon when it comes
to working at the REPL. The OO approach you have often makes it difficult
(for less trivial examples) to run a particular function in the right
context. But with the self-contained function it's just a case of getting
the parameters right, which is often easier to think about.
Jony
On Saturday, 7 February 2015 16:07:45 UTC, Dru Sellers wrote:
>
> Greetings,
>
> I am trying to convert my mind from OO (C#) to one more functionally
> friendly. I am increasingly comfortable with simple applications in
> clojure, but as I start to build more complex applications, I start to fall
> down about how to structure my application. I don't want to just shove OO
> ideas into the functional nature of Clojure. I'm looking for any help
> someone can provide to help shimmy my brain into the right mental patterns.
>
> Background: Long time C# developer who leans heavily on IoC / DI /
> Interfaces / Testing / Object Encapsulation.
>
>
> *Specific Question: Object Encapsulation*
> I feel like my function parameter lists are much "wider" than they would
> be in C#. This is due to the "lack" of a constructor. So if I previously
> had a C# class that looked like:
>
>
> public class AccountRepository : IAccountRepository
> {
> IDatabaseConnection _connection;
>
> public AccountRepository(IDatabaseConnection connection)
> {
> _connection = connection;
> }
>
> public void Save(Account account)
> {
> _connection.Execute("UPDATE accounts SET coupon=@coupon WHERE id=@id",
> { coupon = account.Coupon, id=account.Id});
> }
> }
>
> In the above I have encapsulated the "_connection", the other methods
> don't have to deal with it. In Clojure (especially if you are following
> Sierra's Component pattern) you end up with
>
> (defn save [db account]
> (update db (:coupon account) (:id account))
> )
>
> I end up having to pass this 'db' around all over the place. I think that
> this is just something I'll have to get used to more than anything. Am I
> missing anything?
>
> Thank you for your time.
>
> -d
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
