Xref: utzoo comp.object:2317 comp.lang.objective-c:113
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!ns-mx!ns-mx.uiowa.edu!dbrenner
From: dbrenner@icon.weeg.uiowa.edu (Doug Brenner)
Newsgroups: comp.object,comp.lang.objective-c
Subject: Re: Object Oriented Design:Scenario:Opinions Sought (long)
Message-ID: <DBRENNER.90Dec26233147@icon.weeg.uiowa.edu>
Date: 27 Dec 90 05:31:47 GMT
References: <3302@mrsvr.UUCP>
Sender: news@ns-mx.uiowa.edu
Followup-To: comp.object,comp.lang.objective-c
Organization: U of Iowa, Iowa City, IA
Lines: 93
In-reply-to: chandra@bhairavi.uucp's message of 26 Dec 90 19:00:30 GMT

In article <3302@mrsvr.UUCP> chandra@bhairavi.uucp (B. Chandramouli) writes:
> There are two choices:
>  1) Create a subclass and override "refresh" and just create one instance
>     of this class to manage Screen Location X.
>     [...code deleted...]
>  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).
>     [...code deleted...]
>
> Now my questions:
>  1) Which is better and why?
>  2) Which is more object oriented?

I hope I've understood your question completely.  Here goes.  First some
questions of my own (and then my answers).

If you pick choice 1 (subclass):
  o Are you *really* creating a new object?
  o What would happen if you did this everytime you needed to add
    functionality to an object?
  o If someone has already subclassed the original object AND they want
    to utilize this new "highlight" functionality, what do THEY do?

If you pick choice 2 (same class, new code):
  o If someone is using the existing class and doesn't want this new
    functionality, what do THEY do?

To try and answer, I would suggest NOT subclassing.  Rather, add new
functionality in a way that makes things upward compatible.

First, I'd say you really don't have a new object, just the same old
object with some new functionality.  Creating a subclass is overkill.

How about this code (written in Objectionable-C):

  BOOL highlight = NO;        /* YES for highlighting; NO for none */
  char *highlightStr = "";    /* string to highlight if seen */

- setHighlight: (BOOL) theHighlight
{
   highlight = theHighlight;
   return self;
}

- setHighlightStr: (const char *) theHighlightStr
{
   /* malloc and strcpy theHighlightStr (an exercise for the reader :-) */
   return self;
}

-refresh
{
   [userInterfaceManager at:INV2 put:INV1];
   if (highlight == YES && INV1 == highlightStr)
      [userInterfaceManager at:INV2 action:REVERSEVIDEO];
   return self;
}

This allows those who used the old class, either directly or via subclassing,
to retain their old functionality.  It also allows those same people to gain
access to this new functionality should they wish.

You, who need the new functionality, must enable it.  (You expected to do
this WITHOUT code changes?  Sorry, you're in the wrong field!  :-) :-)

You must perform two additional steps each time you create the object and you
want it to highlight.

   myObj = [Obj new];
   [myObj setHighlightStr:"PANIC"];  /* set the string to key on */
   [myObj setHighlight:YES];         /* turn on highlighting */

Now to make your life easier, you might consider adding another factory
method that will do this in one step.  Still code changes, but you might
find this to your liking.  (The previous code is still required.)

+ newHighlight: (BOOL) flag highlightStr: (const char *) str;
{
   self = [super new];
   /* malloc and strcpy str */
   highlight = flag;
   return self;
}

Then you would just:

   myObj = [Obj newHighlight:YES highlightStr:"PANIC"];

(I will not agrue if this type of "paramater burden" is a good idea for
factory methods.  The NeXT AppKit is full of such examples, however.)

Good luck and remember...these are just *my* opinions.  -dcb