Hi,
Assume I have an instance variable that will contain a Book object. I'd like to initialize it to some sort of null Book. A book whose methods are all NOPs. Should I create a subclass for this purpose or is this what DeafObject is for? Thanks |
Fernando,
> Assume I have an instance variable that will contain a Book object. > I'd like to initialize it to some sort of null Book. A book whose > methods are all NOPs. Getting pedantic (to a purpose) for a moment, it is not possible to have all methods do nothing; even a ProtoObject is required to exhibit some behavior. If your goal is to build something that "learns" new behavior, you should be certain that you really want to do that, and then early on verify that it will work in a deployed executable should that be your goal. It seems more likely that good initialization and unit testing will be a more direct route to something that works. You can rough in some very simple test cases and invoke them directly from the CHB/SB. Since you expect failures early on, it makes sense to include comments like SomeTestCaseSubclass new testSomething in methods as you add them. "When" the test fails, you will go directly to the walkback and you will not need to fuss around with resetting the test browser, selecting which failure to debug, etc. When you have reasonable expectations of tests passing, the SUnitBrowser becomes a great tool. However, when I find a change has given me a stubborn test or two, I still fall back on the do-it approach. > Should I create a subclass for this purpose or is this what DeafObject > is for? I prefer to use DeafObject in situations that involve complex interactions and short time periods that probably lead to a graceful exit as the goal. As an example, I had a dialog box that I could not test via the Show command, and adding a DeafObject in the right place in my #ideModel method (see the archives) got it to, well, shut up<g>, long enough to just go away with some dignity. IMHO, you should think very carefully about using DeafObject in code you intend to ship. Have a good one, Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
In reply to this post by Fernando Rodríguez
"Fernando" <[hidden email]> wrote in message
news:[hidden email]... > Hi, > > Assume I have an instance variable that will contain a Book object. > I'd like to initialize it to some sort of null Book. A book whose > methods are all NOPs. > > Should I create a subclass for this purpose or is this what DeafObject > is for? > > Thanks The first step IMHO is to ask why you want to do this. Step back and ask why you want to approach it that way. You may already have done that, but we don't know that. My purpose in asking is that we need to solve the problem, not come up with ways to do a particular task. If your approach is in fact a good one, we can deal with it at that level. |
In reply to this post by Fernando Rodríguez
Fernando wrote:
> > Assume I have an instance variable that will contain a Book object. > I'd like to initialize it to some sort of null Book. A book whose > methods are all NOPs. > > Should I create a subclass for this purpose or is this what DeafObject > is for? Yes and yes :-) I guess it depends on your preference and on which phase your project is in. DeafObject is nice to do exploratory programming without having to write any scaffolding. My preference is to refactor to using a specialized class when the code has to go beyond being of exploratory quality. HTH, Reinout ------- |
In reply to this post by Schwab,Wilhelm K
On Sun, 13 Mar 2005 13:24:55 -0500, Bill Schwab
<[hidden email]> wrote: >Getting pedantic (to a purpose) for a moment, it is not possible to have >all methods do nothing; even a ProtoObject is required to exhibit some >behavior. If your goal is to build something that "learns" new >behavior, you should be certain that you really want to do that, and >then early on verify that it will work in a deployed executable should >that be your goal. No that's not what I had in mind. Actually I'm not sure what you mean with learning new behavior... I'll explain myself with a concrete example, it should make things more obvious. In an application (non St) I have a series of textboxes for user input. Most of these textboxes have a 'checker' attached that verifies if the text entered is correct: no spelling errors, too little text, no text, way too much text, weird characters, etc... So I have a hierarchy of Checker classes taht use the composite pattern, so you can check for several different conditions. However, a textbox that doesn't need to be checked is a specila case and needs to be handled differently. If you create a Checker subclass that is a null checker (all methods in the Checker protocol are NOPs), this special case disappears. Now ALL textboxes have a checker, those that don't need it, have a null one. It's the null element for a given protocol, just like zero is the null element for the 'addition protocol'. I find this idea extremely useful: a) It removes special cases b) It's a safe initial value c) It's great during debugging: when adding a new hierarchy to an app., start with the Null version and see if the design works and makes sense before getting into the hairy details of the implementation of the protocol. Dolphin's DeafObject seems to be a 'universal null class' that nops almost every protocol, and not just a specific one. I fear that this might introduce subtle bugs... |
Fernando,
> However, a textbox that doesn't need to be checked is a specila case > and needs to be handled differently. If you create a Checker subclass > that is a null checker (all methods in the Checker protocol are NOPs), > this special case disappears. Now ALL textboxes have a checker, those > that don't need it, have a null one. [...] > Dolphin's DeafObject seems to be a 'universal null class' that nops > almost every protocol, and not just a specific one. I fear that this > might introduce subtle bugs... DeafObject would not be suitable for the example you gave. What DeafObject does is /ignore/ all messages, not to provide a /null implementation/ of all messages. Sometimes the difference matters, especially when the method is expected to answer a useful value. In your example, assuming that the checking method is called #isTextOK, the null implementation would probably be to answer true. However if you used a DeafObject in that context it would ignore #isTextOK, and therefore would actually answer itself. The answer would probably then be passed into some #isTrue: or #isFalse: block, and the system would then throw an error because the DeafObject is not a Boolean. -- chris |
In reply to this post by Fernando Rodríguez
Fernando,
> No that's not what I had in mind. Actually I'm not sure what you mean > with learning new behavior... learning behavior == add methods; the problem is to make their content reasonable, except, of course, when a programmer is standing by to assist, as in the debugger's Implement-in command. > I'll explain myself with a concrete example, it should make things > more obvious. > > In an application (non St) I have a series of textboxes for user > input. Most of these textboxes have a 'checker' attached that verifies > if the text entered is correct: no spelling errors, too little text, > no text, way too much text, weird characters, etc... > > So I have a hierarchy of Checker classes taht use the composite > pattern, so you can check for several different conditions. > > However, a textbox that doesn't need to be checked is a specila case > and needs to be handled differently. If you create a Checker subclass > that is a null checker (all methods in the Checker protocol are NOPs), > this special case disappears. Now ALL textboxes have a checker, those > that don't need it, have a null one. You are trying to create a software "yes man" (think of the effect on middle management<g>). IMHO, you should develop something along the lines of AlwaysSearchPolicy along side of the more elaborate classes; it should be by far the easiest of the classes to maintain. Unit tests should be sufficient to help keep it working, but you could also use the protocol browser to establish a textChecker protocol with the required methods; note that it will stub methods with #notYetImplemented or somehting like that. With something analgous to SearchPolicy, I would simply make up some good tests and make them better any time something slipped through them. Have a good one, Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
Free forum by Nabble | Edit this page |