Simple inheritence question
in [OOP]
|
Prev: Deployment flowcharts vs. cross-functional flowcharts
Next: Requirements management - Traceability
From: VisionSet on 1 Jan 2006 07:24 This is something I find myself doing and I'm not sure it is correct. Say we have a class to represent a scrabble tile and a subclass to represent a blank. in the parent I have an isBlank method that always returns false in the subclass it always returns true I also have an overridden changeLetter method as the blank needs assigning to a letter, but the parent never should so in the parent I do: (or I could do nothing) public void changeLetter(Character chr) { throw new UnsupportedOperationException(); } We know it will do this since it is documented and there is the isBlank method to check. My reasoning for this approach is that of polymorphism, we should not care what the type is just that its behaviour is appropriate. So instead of littering other code with conditionals we now do a similar thing by asking isBlank(), so what is the advantage? How should this be done? TIA -- Mike W
From: Sanjay on 2 Jan 2006 04:52 Mike, my thoughts on this, if I were to model the same, I wouldnt have made blank an extension(sub class) of a cell. I really see that a cell can be a blank if its value is null or no string. I will go in that route, may be inheritance will not come into picture. But whatever you have chosen may be a good way, but needs to be compared. Like Is it possible to instantiate the cell class. where will it be used, so how is the transition made from blank to cell.... Cheers Sanjay
From: VisionSet on 2 Jan 2006 08:07 "Sanjay" <sanjay.chittar(a)gmail.com> wrote in message news:1136195530.697575.18680(a)o13g2000cwo.googlegroups.com... > Mike, > > my thoughts on this, > > if I were to model the same, I wouldnt have made blank an extension(sub > class) of a cell. > I really see that a cell can be a blank if its value is null or no > string. Thanks Sanjay but... No a blank in scrabble is a special tile, and anyway even an empty cell has behaviour and I believe null is nearly always a poor option it precludes any behaviour and makes the code really messy. > > I will go in that route, may be inheritance will not come into picture. > But whatever you have chosen may be a good way, but needs to be > compared. > Like > Is it possible to instantiate the cell class. where will it be used, so > how is the transition made from blank to cell.... As above all tiles are instantiated once at the begining of the game, they merely change some state during the game. -- Mike W
From: Michael Redlich on 2 Jan 2006 08:27 Hi, Mike: Happy New Year! VisionSet wrote: > > My reasoning for this approach is that of polymorphism, we should not care > what the type is just that its behaviour is appropriate. So instead of > littering other code with conditionals we now do a similar thing by asking > isBlank(), so what is the advantage? How should this be done? > >From your description of your application, I think what may work here is to make the ScrabbleTile class and changeLetter() method abstract. This will force any subclasses of ScrabbleTile to implement changeLetter() as necessary. The isBlank() method can be implemented in the ScrabbleTile class so that it can used as is by all other subclasses except for class Blank which can override it to return true. So, here's how I see the cod for this: public abstract class ScrabbleTile { //... public boolean isBlank() { return false; } public abstract changeLetter(Character chr); } public class Blank { // ... public boolean isBlank() { return true; } public changeLetter(Character chr) { // code to implement changeLetter } } What do you think??? Sincerely, Mike. --- ACGNJ Java Users Group (http://www.javasig.org/)
From: VisionSet on 2 Jan 2006 08:59
"Michael Redlich" <mike(a)redlich.net> wrote in message news:1136208473.801810.159460(a)f14g2000cwb.googlegroups.com... > > So instead of > > littering other code with conditionals we now do a similar thing by asking > > isBlank(), so what is the advantage? How should this be done? > > > > So, here's how I see the cod for this: > > public abstract class ScrabbleTile .... > What do you think??? > Happy New Year to you too! Pretty much the same then, I was after some major redesign (see my original quoted above), I guess I've got it about right. This was really my last ditch attempt at upsetting of my now firmly engrained approach to one aspect of inheritence. Yes I realise the Exceptions aren't necessary. Thanks. Mike W |