On 8 October 2010 18:21, Marnen Laibow-Koser <[email protected]> wrote: > Colin Law wrote: >>... >> 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.
I don't entirely agree here. Firstly the scenarios only describe the functionality of the current phase of development. The user has an interest in the internal workings of the application in so far as he expects there to be further phases and therefore expects the design to facilitate later phases as far as possible, even though he may have little idea what those phases may be. I know we don't want to do premature optimisation however, I will come back to this below. > > 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. Again I will quibble, slightly tongue in cheek, though not entirely. The purpose of the code is to provide the implementation, as you state, however the process of developing the application has other purposes. Notably to provide us with a living wage and job satisfaction. I believe that to some extent software development can be an art as well as an engineering operation. Consider initially just small sections of code. Often there are numerous ways of coding a piece of functionality, with no difference in the result of running the code. Usually one of these 'feels' right. Nothing in the scenarios suggests one or the other but we code it the 'right' way because we get satisfaction sitting back and savoring the design. OK, I am getting a bit carried away here but I am sure you know what I mean. In addition we may code it a particular way because we believe it will be easier to maintain and is less likely to have unnoticed bugs. I think these ideas also apply to the larger scale design of the app, including the models and relationships. The overall design can be aesthetically pleasing, or even a thing of beauty (I know, OTT again, sorry). The scenarios do not address that aspect of the design, only the designer can do that. > > 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... The purpose of the models is obviously to satisfy the scenarios, but the purpose of the design is also to facilitate further phases, even though we do not know what they will be (see later again) and to give us satisfaction in the design as discussed above. > >> 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. I am not suggesting adding extra functionality that may or may not be required, but ensuring that the initial design provides a base that is most likely to allow extra functionality to be added without major re-structuring of the design. > > (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. I think now our ideas are starting to diverge. My initial assumption would be that there _will_ be user and product classes _because_ they are domain objects (unless the scenarios show that they do not actually exist in the app). > >> 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. I entirely agree there are different ways of doing things, I can only describe the way that works for me. > This is an implementation detail, and as such > it is irrelevant right up till the moment we start implementing. I am not sure what you mean here. > >> 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. See below. > >> 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. But that is the point, if the domain objects and program objects map onto each other closely, then since the domain objects tend not to change dramatically the program objects will also not change dramatically (though their behaviour will be added to and modified of course. > >> 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. Again, by mapping domain objects closely to program objects then clairvoyance is not required as domain objects tend to be stable. > >> >> I am still not sure that I am expressing myself very well. > > I think you are...I hope I am too... Certainly. Colin PS My brain hurts. -- 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.
