To subclass or not to subclass?
To subclass or not to subclass?
- Subject: To subclass or not to subclass?
- From: Carlo Volpi <email@hidden>
- Date: Wed, 28 Nov 2001 12:11:57 +0100
Hi everybody,
I'm writing my first Cocoa/ObjC app and I'm pretty excited about what I'm
discovering on my (long) way to the first release.
Right now an important design dilemma has to be solved:
I'm writing a calculator (yes, another one...) with some little innovations,
but my problem is in the very heart of it: the operators.
I have an Operator class that describes operators by attributes like the
identifier, the associativity etc. Of course, each operator must have its
own code to do its work.
Since I want to make this calculator extensible I want to load any number of
operators and I want to load them at runtime.
Until now I've found two ways of doing so: subclassing Operator with classes
like 'Sum', 'Multiplication' etc which override the calculation method or
adding new methods to it by adding a calculatingSelector SEL attribute to
the operator description and adding the correspoding methods using
categories.
The first solution represents better the real-world math but creates a
relatively big number of classes each of them with just one instance.
The second solution instead creates a big number of methods for the Operator
class but resolves in just one operator class with as many instances as the
number of operators I want to use.
From what I understood with the first solution it would be easier to create
NSBundles that contain new operators, but I'd really like to hear the
opinion of more experienced programmers before going on.
Thank you very much for your help.
Carlo