Chris Devers 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. >
It's definitely something that depends on your situation. Personally, I always try to keep my display as separate as possible from the "number crunching" and data retrieval. Of course, there are trade-offs (such as having to buffer the data before sending it to the display subroutines), but more often, the performance (memory consumption, etc) is less an issue, or cheaper to deal with. >>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... > I guess it depends on the definition of your subroutine. What is it supposed to do within the context of your own program. If it's meant to get data, then get data. If it's meant to be given data and return output text/formatting, then that's okay. Maybe I'm not following what you mean, but usually you can keep the display functionality fairly separate. Often it's good to go with a template system, especially with web based apps, as you can abstract not only the concepts, but the files too. I'm a fan of Template Toolkit (Template.pm). >>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. > Yeah, I agree. There's a trade-off with each. Flexibility vs. performance costs... and the balance between the two vary from situation to situation. Knowing when it is more appropriate to separate or not, is learned through experience. >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. > Yes, this is also one way to look at consolodation of functions/subroutines. But I'm also a believer in short subroutines... if one of my subs starts to get kinda long (50-100+ lines) then I start to look at it more closely, and see where I can break it down into concepts... whether it's re-used or not. This isn't for re-use of code, but rather the ease of reading my own code, and having it be self documenting by making "concepts" grouped in subroutines, as opposed to a series of concepts, all bunched into one sub. The latter isn't bad necessarily, especially if lots of comments are used to show the logical concepts. But another reason to separate is for flexibility and maintenance... such that making a change to b() doesn't mean changing a(). In the case of web application content, you don't want to have to open the application just because you're changing the look of a document or dynamically generated web page. Or at very least, you want to minimize the impact. One reason for this is cost (not to drag the whole corporate thing into this again). But if web content, or the look of a web site changes often (more often than the program itself), then it's a good idea to make it so the lower paid web designer or content manager can make changes without requiring a large amount of time from the more expensive programmer/engineer. You can see how abstraction of content from the program can be beneficial in this situation. >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 :) > I agree. Try it one way... try it another... get a sense for how organizing your code different ways can help you. Try to see where doing things one way might simplify tasks you are more likely to do, or do more often than others. The idea of separation of layers between display and application (and even content) layers, is primarily driven by "cost analysis." Finding ways to decrease the cost over as many scenarios as possible, or at least the most common scenarios. The question you have to ask yourself, what things "cost" more in your situation. Just play with it, and see what is right for you. If nothing else, it will be a good learning experience to "know" why one can be better than the other, and when, from experience, and not just "book knowledge." Cheers, -Alex
