-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Subclassing Workbook #4
Comments
Hmm... I'm not sure whether adding domain logic to what basically is a reader is a good idea (have a look at this talk: http://www.youtube.com/watch?feature=player_embedded&v=WpkDN78P884 ). I would attempt to keep it completely separate from domain logic and use workbook as a gem in your project, not the base of your project (and if you need specific functionality think whether it belongs in this gem or not (and in the case of StringIO it does fit)). However, if you still feel there is a need... I kind of think there is a smell to the first option with splitting names on '::' that I don't like... I would be ok with taking patches for option 2 but I'd first reconsider whether adding domain logic is a good thing in the first place (you can mail me if you prefer). Op 12 apr. 2013, om 20:22 heeft kianw notifications@github.com het volgende geschreven:
|
One thing I was mulling over was how to subclass Workbook in order to add domain-specific functionality to the classes. I didn't want to monkey-patch your classes, as we may need more than one domain with different functionality, so subclassing seems the way to go.
The issue I was running into was that if I subclass
Workbook::Book
andWorkbook::Sheet
, for example, myWorkbook::Book
subclass will still use the super-classes, such as creating aWorkbook::Sheet
in#initialize
or#push
(instead of my new Sheet subclass). Short of overriding every method that references one of the other Workbook classes (ugh), there doesn't appear to be any way to easily do this right now (maybe I'm missing something obvious?).Two solutions spring to mind: 1) create a new module for each domain, with classes that inherit from Workbook classes. And modify Workbook so that every reference to the Workbook constant is changed to something like
self.class.const_get(self.class.name.split('::')[0..-2].join)
, which would get the module forself
. We'd probably put that code in a helper method.Or 2) replace (in Workbook) every reference to a Workbook class constant (e.g., Workbook::Sheet) with a call to a helper method that returns the class constant. Then when you subclass a Workbook class, you just need to override those helper methods to point to your subclasses instead of the base Workbook classes.
These options are fairly similar; option 1 has the advantage of putting the subclasses into a new module (although you could do that with option 2 also), and it doesn't require you to override any methods. option 2 is probably a bit simpler.
Any ideas or feedback?
The text was updated successfully, but these errors were encountered: