Subclassing Workbook

[kianw]

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 and Workbook::Sheet, for example, my Workbook::Book subclass will still use the super-classes, such as creating a Workbook::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 for self. 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?

[murb]

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 and Workbook::Sheet, for example, my Workbook::Book subclass will still use the super-classes, such as creating a Workbook::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 for self. 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?

—
Reply to this email directly or view it on GitHub.