New answers tagged

0

It all depends on what your Shape is used for! Short Answer Robert Bräutigam's answer pretty much nails it. This is technically the best you can do. The Shape class does not need to expose too much, definitely not all of its members. That is, if you are using the Shape class. For all we know, you may be using the Shape just for the purpose of ...


0

I would probably look into using dynamics. You could even do a hybrid type, with the version 1.0 - or the base-version-with-never-to-be-changed properties - coded as usual and any changes implemented down the road handled by dynamic, the path of least resistance being an implementation using ExpandoObject. This should be future proof, allowing new ...


1

There are a couple of alternatives. First of all, objects should not change just because their data changed. That is just a basic consequence of basic concepts object-orientation. One of which is that objects are defined by behavior, and data is encapsulated under that behavior. You could define your Shape to have the behavior you need, like drawing on a ...


1

Creating classes for different versions (approach 1) doesn't scale that well. If there will be many versions to come, you end up with a class inflation which is never a good thing. And then, what if there will be ShapeV3, that can not be modeled as a subclass of V2, but just of a subclass of V1 or the base class, yet it offers similar features than V2? Then ...


Top 50 recent answers are included