inheriting multiple classes with same basic variables RRS feed

  • Question

  • I have several 3d/geometry libraries.

    they all include some type of point3d/vertex list. 

    4 example...

    class Polygon

    class Polyline

    class PointCollection

    are all lists of points with different functions. 

    In work, I keep converting from one to the other, depending on what function I have. (4 example, Polygon has .MakePlanar(), Polyline has isConcave(), PointCollection has removeDuplicate(), etc etc. 

    I'm interested as to how would one try to "merge" these 3 into one super class with all the available methods in one spot.

    • Edited by Lilith5th Tuesday, December 10, 2019 2:46 PM
    Tuesday, December 10, 2019 2:32 PM

All replies

  • That would go against the general principals of single responsibility. You can, and should, create a base class for any shared functionality and then move any type-specific functionality into derived types. Note also that interfaces are a great way to check for functionality and allow "conversion" without having to do it manually. Alternatively the `is` operator with type declarations can be used to simplify your typecasting.

    Ultimately you should ask, for each method, does it apply to all these types. If it does then it goes into the base class. If it doesn't then don't. Note also that for shared functionality that doesn't fit neatly into a class you could consider using extension methods. For example your removeDuplicate seems like it would be applicable to any list of points (or whatever) so make it an extension method that can be used on any of your types.

    Michael Taylor

    Tuesday, December 10, 2019 2:58 PM
  • the thing is I only have the dll libraries, so I'm managing around those. Hence constant back and forward converting.

    I've been getting by with using extension methods, but with 3+ types, it becomes a tedious job writing converters in each possible way. 

    my alternative idea is to do something like this, but I'd like to know if there's a more elegant or preferred way of getting around this. 

    class Superclass { private List<Point3d> m_PointList { get; set; } private Polyline3d m_Polyline3D { get; set; } private Point3dCollection m_Point3dCollection { get; set; } private void Init(List<Point3d> pointList= null, Polyline3d polyline = null, Point3dCollection point3Ds = null) { //depending on which attribute ....convert and assign to properties } public Superclass(List<Point3d> pointList) { Init(pointList); } public Superclass(Polyline3d polyline) { Init(null,polyline); } public Superclass(Point3dCollection point3Ds) { Init(null,null,point3Ds); } public void PolyLineFunction() //for example optimize, remove duplicate,... { this.Init(m_Polyline3D.PolylineFunction()); }

            //for each function, a new "derived" function would be written same as "PolylineFunction()


    but thing gets complex if there are 100s of functions to include.

    is there some way to "automate" generation of "public Superclass PolyLineFunction()"

    since otherwise I'd have to manually write a function for each of the existing methods. 

    I guess reflections might be the key?

    • Edited by Lilith5th Tuesday, December 10, 2019 4:25 PM
    Tuesday, December 10, 2019 4:17 PM
  • Reflection would be an option to autogenerate but honestly you're then swapping the "dev" time that it would take to do it by hand with doing it every time the app runs. For a dynamic system this makes sense but for static types probably not so much.

    Your example Superclass is the exact opposite of maintainable code and violates the SRP. I strongly recommend against this approach. The mere fact you have 3 different constructors accepting different data and then will need to use if-else in your code to treat each differently is a clear sign of a bad class. More importantly, what happens when you call function X on data Y and data Y doesn't support it?

    I'd use a façade to wrap the types if you have no control over them. You can wrap them in an interface or type that you can manipulate. However you really haven't provided any real concrete example of how any of these types are the same and how they are different (aka functionality) so at this point it is hard to even suggest what that interface/type might look like.

    Michael Taylor

    Tuesday, December 10, 2019 5:18 PM
  • Hi Lilith5th,
    The interface extends the function of the class. It supports multiple inheritance without destroying the inheritance system of the class. 
    Interfaces are more useful in system architecture design methods. so it is recommended to use interface. 
    You can define other classes as interfaces and superclass can implement multiple interfaces.
    Here is a simple code example.
    interface a {...}
    interface b {...}
    interface c {...}
    class A :a  {...}
    class B :b {...}
    class C :c {...}
    class super:a,b,c {...}
    Best Regards,
    Daniel Zhang

    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact

    Wednesday, December 11, 2019 6:36 AM