Keep It Simple, Stupid | |
PerlMonks |
Re^9: Why encapsulation mattersby BrowserUk (Patriarch) |
on May 20, 2008 at 08:15 UTC ( [id://687540]=note: print w/replies, xml ) | Need Help?? |
And you still haven't pointed out how my response to the OP was at odds with the first article. The first thing to note is that I never responded directly to your "response to the OP". I responded to his response to it--for counterpoint--and you then responded to me. What made my post, and the article it cited, counterpoint to your first post, is this. You suggested that he move the Paper->Issues->Articles->process() loops inside the Paper class, thus effectively reducing the main application to simply instantiating an instance of the Paper class, with all the processing being done as side-effect (calling _initialise()) of that top-level instantiation. The benefit you ascribe to this, is that it allows the marking of the issues(), articles(), process() and post_process() methods as private. Therebye increasing encapsulation. But work that through a little. Once you've instantiated that $paper object, all the work of the application is done (by _initialise()), so what do you do with it then? Discard it during global destruction. Now, besides that the OP himself pointed out one flaw (in the post to which I responded), that of the possibility that he might need to break the processing up into smaller chunks: It may be best to show the user a list of outstanding issues and prompt to select one, rinse and repeat etc.. What's important is that all of an issue's articles are processed together not that all the issues are processed together.. There are also other good reasons for not hiding all those apis. The next application that deals with this dataset might need to filter the articles processed by the issue they come from, or the article author, or keywords within the articles. So, where does that fit with your proposal? Rename _initialise() to (say) _process(), and the add another method (say) _filter(), and then pass a parameter to the constructor to allow it to choose whether to call _process() or _filter() in place of the call to _initialise()? Go that route and you have another top-level application that is reduced to instantiating a single instance of a class, and then discarding it again. And your class contains two single purpose methods of which only one will ever be called for any given application run. And then another for the next application. And another. And another... And that's where my stuffing everything inside your objects phrase comes from. Putting application specific code inside the class rather than leaving it at the application level, in order to increase encapsulation, fails. And it is directly to this suggestion:
that the article I referenced, speaks. Hence, counterpoint. If you can see another way of interpreting those words and snippets, then I'll apologise for having misunderstood you. With respect to confrontational. I attempted to paraphrase the opening line of your response to me: The problem I generally have with OO is that most people don't know it and then they get frustrated .... This is because it's not being taught very well .... I was more pointed than you for sure. But to whom was the reader meant to infer you to mean, by "most people" and "they" in that opening paragraph? Me? Scott Meyers? The OP? Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
In Section
Meditations
|
|