On Mon, 15 Apr 2002, PK Eidesis wrote: > afaiunderstand, a sub should be a closed beast, no? poke it with something, > it returns something. That something should be just data (in good MVC > tradition (you can tell I have started to read the beginners guide to > programming Cocoa) and not any display information about that data. How that > returned value is displayed should be kept separate from the sub, so the > display can be modified at will. > > First, is the above premise correct?
I'm not sure if it could be considered a hard & fast rule, but it sounds like reasonable software engineering ethos to me. > If yes, how do I accommodate repeated poking of the sub which repeatedly > returns data in a predictive display format? iow, do I violate the above > premise by making the sub return the display info as well as shown > below? Well if the display info is the data, then there is no conflict... > But, if I were to follow my premise about a sub returning only data > without any knowledge of its view, then I should really be getting all > the data required, and then applying the display logic in the html code. alternatively, you could have two functions -- a data cruncher, and a generic formatter. Depending on how intricate these are, how tightly coupled the roles, etc it might or might not make sense to merge or separate them. You kind of have to play it by ear. My hunch would be that if, after decomposing the functional units of the problem, you find that the units could themselves be useful in different contexts (maybe even in other programs!) then you're on the right track. If on the other hand you always have a() whenever you have b(), *and* you always have b() whenever you have a(), then maybe it didn't make sense to break them apart. But there really are no hard & fast rules here. If decomposition is only getting in the way, then reconsider doing it, and maybe scale back. I'd just say not to dwell on it *too* much -- you're getting into territory on which many a doctoral dissertation has been prepared :) -- Chris Devers [EMAIL PROTECTED] Apache / mod_perl / http://homepage.mac.com/chdevers/resume/ "More war soon. You know how it is." -- mnftiu.cc
