Xref: utzoo comp.object:2315 comp.lang.objective-c:112
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!wiml
From: wiml@milton.u.washington.edu (William Lewis)
Newsgroups: comp.object,comp.lang.objective-c
Subject: Re: Object Oriented Design:Scenario:Opinions Sought
Message-ID: <13479@milton.u.washington.edu>
Date: 27 Dec 90 00:44:02 GMT
References: <3302@mrsvr.UUCP>
Organization: University of Washington, Seattle
Lines: 55

In article <3302@mrsvr.UUCP> chandra@bhairavi.uucp (B. Chandramouli) writes:
>	"For just one screen location X, if the value is "PANIC", then 
>	in addition to putting up the value, display it in reverse video."

>1) Create a subclass and override "refresh" and just create one instance
>   of this class to manage Screen Location X.
>
>	-refresh {
>	  if (INV1 == "PANIC") {
>	  	[userInterfaceManager	at:INV2 put:INV1];
>	  	[userInterfaceManager at:INV2 action:REVERSEVIDEO];
>	  }
>	}

>2) Or, modify the refresh of the existing class as follows, such that
>   the new behavior applies only for that screen location (i.e exectued
>   only by the instance responsible for that screen location).

>1) Which is better and why?
>2) Which is more object oriented?

   Well, I don't now if I'm about to answer those two questions ... but
the way I, personally, would do it would be to create a subclass that
checks to see if its value is 'PANIC' and displays it in inverse 
video. Actually, I'd probably add a third instance variable to that class,
such that if INV3 == INV2, it's put in reverse video. If the code allows
INV3 to equal NULL (and never reverse-videos the field in this case),
then the subclass does everything the superclass does and more, and
the superclass can be discarded; equivalently, this is just modifying ths
superclass. (INV3 should be set to NULL in the +new method, for compatibility
with the old class). Why would I do this? ... Well, it seems to me that
"if string = "PANIC" and location = arbitrary-place, then use
inverse video" is a pretty arbitrary condition. Also, the ability
to invert itself under certain conditions seems to me like a quality
of the field on the screen, not of the string ("PANIC" is not inherently
inverse video) or of the location (if you rearranged your display a little
and the field got shifted 1 pixel, you'd still want it to act the same).
So the attribute that causes inversion should be an attribute _of_the_
_field_. And from there it doesn't hurt to generalize to inverting 
strings other than "PANIC".
  This also seems more object-oriented: it's using the field as an 
object which has certain qualities (such as inversion) independent
of other qualities (such as location, or string value). And the generality
makes it easy to reuse the same code in multiple places and multiple
applications. 

  (stows soapbox back under desk)   Well, that's my opinion ...



-- 
 wiml@milton.acs.washington.edu       Seattle, Washington   
     (William Lewis)   |  47 41' 15" N   122 42' 58" W  
"These 2 cents will cost the net thousands upon thousands of 
dollars to send everywhere. Are you sure you want to do this?"