Abstract class

Roy Smith roy at panix.com
Sun Sep 14 21:34:21 CEST 2008

Mr.SpOOn <mr.spoon21 at gmail.com> wrote:
> Well, from a SharpNote I can obtain the relative NaturalNote. So if I
> have a C# I can call
> natural('C#')  and get 'C'

And why should you not be allowed to apply natural() to a NaturalNote?  I 
would think it would just be an identity operator.
> While in the class NaturalNote I don't need such a method, but I need
> two methods to get the sharped and flatted version

Well, you may need sharp() and flat() methods on all notes.  Can't you do 
sharp('C#'), which should give you C double-sharp?

> > Consider the following code:
> >
> > note1 = SharpNote("E4")
> > note2 = NaturalNote("F4")
> > if note1 == note2:
> >   print "the same note"
> > else
> >   print "different notes"
> >
> > what should it print?
> Well, that's not so simple.

I know it's not simple.  I don't know what the correct answer is, or even 
if the problem admits to having a single universally correct answer.  I'm 
just pointing out something you should probably think about.
> Anyway, I think I need an abstract class. Or not?

Hard to tell.  My advice would be to start out with a single Note class and 
start writing code.  If you get to the point where you're writing lots of 
conditional logic in your methods (if sharp, do this, if flat, do that), 
that's a hint that you may indeed need to refactor things into subclasses.

The next step would be to figure out what the right hierarchy is.  Offhand, 
I can think of three hierarchies which might be plausible:



This is a relatively flat (sorry about that) hierarchy.  Note (arghhh!!) 
that there is no explicit NaturalNote class; notes which are not sharp or 
flat are just instances of Note.



This one sounds like what I think you've currently got in mind.



This one is similar to the above, except that the double-{sharp,flat} note 
are subclasses of their single versions.


I have no idea which is the right way to represent this.  Some people would 
agonize over the decision for days before writing a single piece of code.  
My personal preference is to start small, get some code written, and let 
the code teach you what makes sense.  If things are flowing smoothly, you 
probably picked a good way to organize your classes.  If things are ugly 
and you find yourself writing lots of gnarly conditional code, that's a 
hint you're off on the wrong track.  Don't be afraid to throw it away and 
start from scratch.

BTW, here's another thing to think about.  Is a C in a signature where C is 
not sharp the same as a C in a signature where it is sharp but written with 
a natural accidental?  I have no clue, but when you figure out what answer 
makes sense for you, that might help you decide how you're going to 
organize your classes.

More information about the Python-list mailing list