Colin Law wrote: > On 8 October 2010 14:48, Marnen Laibow-Koser <[email protected]> > wrote: >> Colin Law wrote: >>>... >>> I think we are just going to have to agree to differ on this one, >> >> I would rather not do that. In general, that's a sign that more >> discussion is needed, as one or both of us is probably missing >> something. Certainly I'm learning a lot from this discussion. >> >> However, I'm perfectly willing to start a new thread for this. > > Done > > I think I would like to start again as I realise (having been forced > to defend my corner and think more about what I am rabbiting on about) > that it not so much _when_ the models are identified that is the issue > for me but _how_ they are identified.
OK -- and once again, thanks for making me really think about what I do! > To go back to your original > suggestion: > >> when I >> put together an application, I usually think first about how I want it >> to present itself to the user and what the user should be able to >> accomplish (and write Cucumber scenarios accordingly). Only as a result >> of making those scenarios reality do I write model classes or anything >> else. > > I read into this (possibly incorrectly) that the purpose of the models > is purely to satisfy the scenarios Well, in a sense, I think that is the case. This may be a little bit of a reductio ad absurdum, but bear with me (as I start inadvertenly channeling Ron Jeffries or someone :) ). The scenarios (ideally, though it's debatable how closely that ideal is ever achieved) describe all the functionality of the application -- that is, everything that is actually of value to the user. The user never sees or cares about the internal workings of the application (except as specified in his requirements); they are not of value to him. Only the functionality is of value to the user. Now, since only the functionality is of value to the user, from that perspective it is clear that the only purpose of the application code is to provide an implementation that delivers that functionality. If we do anything else, we are not providing any particular value to the user. Since the models are part of their app code, their only purpose is to implement the functionality specified by the user (which is what is captured in the scenarios). So yes, on balance, I think I would agree with the contention you attribute to me. Apparently you do not. What else do you think the models -- or any of the rest of the app code -- is there for? I'm hard put to come up with anything else... > and they are identified by > examining the scenarios and generating a set of models to satisfy > them. I think that that is too narrow a view to take, particularly > considering that we are in the first phase of a project and we know > there will be many modifications and extensions to the requirements in > the future. But we don't know what those modifications will be, and therefore (where possible) we do not design for them. We design for what we have now, and refactor later as necessary. Remember YAGNI. (There are a few practical exceptions. For example, I usually put I18N in right at the beginning even if it's not a requirement, because going back and wrapping all display text in translate functions later is a pain in the ass.) > > Generally an app is in some sense simulating or mapping things in the > real world (or some conceptual world), users, shopping carts, products > and so on. I suggest that one should examine the scenarios and > identify the underlying objects in that real world without worrying > too much about the _details_ of the scenarios. Precisely. That's what I meant by business domain objects in my earlier post. If we want the user to be able to purchase products, we know we have "user" and "product" as business domain objects. We don't know (though we might strongly suspect) that we will have User and Product classes in our program. > The models then > represent those objects and one can work out how to satisfy the > scenarios using those models. In many styles of programming, this is the case, but it absolutely does not have to be -- see http://c2.com/cgi/wiki?OopNotForDomainModeling for some discussion of this. This is an implementation detail, and as such it is irrelevant right up till the moment we start implementing. > I believe this should provide a better > base on which to build the app. But it won't. It just forces you into prematurely making implementation decisions on insufficient information, and perhaps slightly ossifies the result of those decisions. Why do you think there is any advantage to doing this. > Scenarios will be modified and added > to dramatically over time but the underlying objects in the > requirements are less likely to change (I don't mean that their > behaviour will not change, but their existence). That's true with regard to the underlying domain objects. It is not necessarily true with regard to the underlying program objects. > If the > identification of the objects is correct (or optimum or whatever) at > the start then this will minimise the effort in tracking the changing > requirements. But that's not even true. It assumes a degree of clairvoyance regarding the future directions the project will take that we do not generally possess. > > I am still not sure that I am expressing myself very well. I think you are...I hope I am too... > > Colin Best, -- Marnen Laibow-Koser http://www.marnen.org [email protected] -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
