Board index » delphi » Polymorphism: just another big word?
Scout
Delphi Developer |
Polymorphism: just another big word?2006-01-07 05:03:09 PM delphi16 I've written a system (in Delphi of course) which has the ability to dynamically load packages. The packages are structured in such a way that they allow not only adding functionality to the system, but they also allow changing the functionality of the system. One aspect of changing functionality shows up in the object factories. An object factory might be asked to construct a TShape descendant based on information on a database. The base system might have a factory which knows how to construct a TCircle, a TSquare and a TTriangle. By loading in a new package, the factory can be overridden so that if the database asks for a dodecahedron, that can be constructed as well. Without the new package, a specification for a dodecahedron in the database will give a runtime-error: exception "I don't know how to make this" or something more informative. So far so good. The specific business problem that I have been given is that some stations should refuse to construct TSquares, and others should refuse to construct TCircles. That sounds easy. Build a NoCircles package which overrides the factory and raises an exception if the spec is for a TCircle. Also, build a NoSquares package which does much the same thing, but refuses to create a TSquare. The factory can just throw an exception which will end up with an error message along the lines of "Please try this at the Circle counter. Circles are not for sale here, they're way too round." A station that should not allow TSquares just needs to load the NoSquares package, and so-on. No code changes are required to the base system, everything is binary compatible, and for ease of testing a system can be switched from allowing TSquares to not allowing TSquares and back again just by loading and unloading the NoSquares package in much the same way that you can load and unload component packages in Delphi itself. Obviously I am just using shapes as an example to protect the guilty, and the real requirements are slightly more complex but do not change the concept at all. The problem happens in that the system used to load data into the database is NOT written in Delphi, is not OO, and is controlled by some very highly paid experts. These experts tell me that they do NOT want to see the program reacting to data in different ways, and have proposed instead a set of inclusion lists which will need to be sent to each station saying which TShapes a station is ALLOWED to construct. In the real-life system, this means hundreds of thousands of records being sent to each database just to say that TTriangles are fine! The business requirement is that certain stations DO react differently to certain data. This is the first time that I have been able to use polymorphism at an APPLICATION level (i.e. the app itself changes its behaviour) with such enormous benefit, and I am surprised at a) the experts don't seem to get it and b) the effort they're prepared to expend to ensure that it can't work 'coz their system can not do it. The inclusion list system also doesn't work in the case of a dodecahedron, 'coz just sticking it into a database list doesn't make the factory become suddenly capable of constructing one. That would require a new factory package, but that is about all that is required. My little loadable packages are tiny: about 4K apiece, and the installer puts the correct ones into the load list. Everything else is Delphi magic. I'm not sure whether or not I am going to win this argument because as we all know, the customer is always right. If you can think of any good ways of talking the customer out of using inclusion lists instead of the polymorphic app, I'd be delighted to hear them. Scout |