On Thu, Jul 23, 2009 at 11:59 AM, C N Davies <[email protected]> wrote:
> I’m a bit of a puritan when it come to abstractions, and while > abstraction is a great thing I must confess to feeling that sometime I take > it to the n’th degree and try push it too far. > > Well, we could argue forever on such things - I've had some pretty heated discussions with developers that feel the need to push things too abstract. I like to balance the abstract with the practical (and the budget!). > All of my entities are created (integrated using a fileinputstream of CSV > or XLS/XLSX) using a model whereby I read the file headers then search for a > setter method that uses “set”<column header name>, then call the setter. > I definitely get what you are trying to do, though I don't know why. A Class is a template for an object that has certain known properties and behaviors. Since you are modifying it at runtime, you don't really know anything about the new properties. You don't have any code that calls getWidget() just in case the new CSV file has a new column called "widget". So is this just a "puritanical" issue or do you have a good reason not to simply use a Map of some kind to extend the core entity? Reflection is a great way for a running system to discover the fixed definition of things, but it seems like you are using a form of reflection on both sides of a running system which ultimately doesn't look any different to the coder developing around it. -- Daryl Stultz _____________________________________ 6 Degrees Software and Consulting, Inc. http://www.6degrees.com mailto:[email protected]
