Last post Aug 06, 2009 06:31 PM by akashenk
Aug 06, 2009 02:29 PM|akashenk|LINK
I am rather new to OOP and I have, what may be, a simple question. I am developing an architecture for a project that includes some object inheritence trees. I have been running into a bunch of narrowing conversion issues (the old 'Unable to cast object
of type x to x' error). I understand the limitations of narrowing conversions and why this error exists, but I'm not quite sure how to get around it architecturally. Here is an analogous problem to mine...
Let's say I have a class"vehicle". Ther are also two classes that inherit from this type... "car" and "truck". These two types share a great many properites (hense the inheritance from a common base-class), but they also have a few properties which are peculiar
Now, I have another object with a property of type "car", let's call this property "FavoriteCar". If I try and populate this property with an object of type "vehicle", I get the same old.. cannot convert object of type "vehicle" to type "car" error.
so favoritecar = new vehicle() throws this error, which I guess would be considered a narrowing conversion.
Now, I realize that I can produce code so that I use something like favoritecar = new car(), however, this would mean having to write specific code for each specific sub class of vehicle. Isn't one of the points of using subclasses to reduce the amount of
I also considered using an interface, such as IVehicle. I believe I can get around some of the converison issues... however, an object of type interface cannot be instantiated (so I can't have something like favoritecare = new IVehicle. Furthermore, the
use of an interface, while providing a little more flexibility, also adds a great deal of code bloat and maintenance requirement, because each of the vehicle's properties must be copied in each type that implements the interface.
So, I guess I am asking, in this kind of scenario where it would seem like the use of a base class and a couple sub classes makes the most sense from a code size/reuse point of view, how does one get around the conversion issues in VB, without turning option
Aug 06, 2009 05:57 PM|mbanavige|LINK
Perhaps using the vehicle interface and the Factory pattern might be what you need.
for example: http://wiki.asp.net/page.aspx/310/factory/
Aug 06, 2009 06:31 PM|akashenk|LINK
I was having a look at something similar to that, but my question would be regarding the real-life maintability of interfaces. Let's say my interface has 20 properties and I have 10 classes that implement it. If I need to add a property, or change one, then
I have to go change the same exact code in 10 different classes. That seems like a big pain in the backside when trying to maintain the code. Never mind if somebody else has a class that implements my interface. Then the problem spreads like wildfire.
I do realize in VB that interfaces are the only way to accomplish "multiple inheritance" (to me it's not really multiple inheritence if all you are doing is recreating the same properties/methods in each class), and I can see where using them is quite beneficial,
such as when wanting to make sure any and all sub classes follow a certain model, but as a newbie,tom it definitely looks like there are more reasons against it than for it.