On Tue, Jul 30, 2013 at 6:13 PM, Ash Moran <[email protected]>wrote:
> > On 29 Jul 2013, at 17:04, Kevin Rutherford <[email protected]> > wrote: > > > What if your objects had to be immutable? Would that lead to a > > validation pipeline containing objects such as CandidateUser, > > ValidatedCandidate, UserAccount etc? And if so, where do the factory > > methods for each of those types live? > > Hmmmm, I think they would chain. CandidateUser could be a factory for > ValidatedCandidates, and ValidatedCandidate for UserAccount. The factory > method on CandidateUser would depend on a validator, and the factory method > on ValidatedCandidate would depend on a service to check for username > uniqueness. > > ... actually just have a service for uniqueness you pass a set to ... ? Yeah, but why? I can't see what all this extra complexity gives you when the mythical "next guy" (or gal) comes to pick up the code and work with it it will just confuse them, it could be that the user example is too simple. You can create a unique key on the database, in the old days we used to push most of this stuff into the database because it was the single source of truth - now there are services everywhere but I often wonder if the old strategy of a well-designed DB with the constraints enabled (sigh) was easier. You may never have had to work with the J2EE forest of incoherent XML files describing everything, but this feels like that whole enterprisey J2EE pain reinvented, and it was very very hard to work with, and even the smallest change required lots of grepping and head scratching in the code base, and you were always a little unsure you'd got every instance of whatever the parameter was. I think it's the cost of change - with the architecture you describe you will need to look through half a dozen objects before you can even work out which one might need alteration. As a community we have a problem, where the default Rails app first iteration gives you what is effectively an API on top of a (possibly so-so design) database. So now we're trying to come up with ways that guarantee the flex we need for the second to N iterations, which is a really good thing. But this feels too heavy for the majority of trivial things we do all day. Having played with Erlang and Chicago Boss I think in fact what you're describing is really easy to implement with them and already part of the abstraction layer, and in fact that's what I'd do - just go functional and persistent and the hell with it. There's that new Ruby-like language that talks Erlang? Elixir? -- Thanks and Regards, Francis 07764 225 942 "So when targets seem stupid, arbitrary and unfair it's because they *are*. The only way to improve is to look at the whole system people are operating with, the basic tools, their training, how much initiative they are allowed, are you measuring the right things (more about that later) and then you can improve. But it's the *system* you improve, not the people you beat into performing even worse." Unicorns in the mist<https://leanpub.com/unicorns> CV http://www.pharmarketeer.com/francis.html FJFDIDM Consultancy <http://fjfdidm.com/> -- You received this message because you are subscribed to the Google Groups "NWRUG" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/nwrug-members. For more options, visit https://groups.google.com/groups/opt_out.
