¿Clase base abstracta con interfaces como comportamientos?

[1] Agrega virtual "getters" & "configuradores" de sus propiedades, tuve que hackear otra biblioteca de control, porque necesito esta función:

abstract class Control
{
    // internal fields for properties
    protected int _Width;
    protected int _Height;
    protected int _BackColor;
    protected int _X;
    protected int _Y;
    protected bool Visible;

    protected int BorderWidth;
    protected int BorderColor;


    // getters & setters virtual !!!

    public virtual int getWidth(...) { ... }
    public virtual void setWidth(...) { ... }

    public virtual int getHeight(...) { ... }
    public virtual void setHeight(...) { ... }

    public virtual int getBackColor(...) { ... }
    public virtual void setBackColor(...) { ... }

    public virtual int getX(...) { ... }
    public virtual void setX(...) { ... }

    public virtual int getY(...) { ... }
    public virtual void setY(...) { ... }

    public virtual int getBorderWidth(...) { ... }
    public virtual void setBorderWidth(...) { ... }

    public virtual int getBorderColor(...) { ... }
    public virtual void setBorderColor(...) { ... }

    public virtual bool getVisible(...) { ... }
    public virtual void setVisible(...) { ... }

    // properties WITH virtual getters & setters

    public int Width { get getWidth(); set setWidth(value); }

    public int Height { get getHeight(); set setHeight(value); }

    public int BackColor { get getBackColor(); set setBackColor(value); }

    public int X { get getX(); set setX(value); }

    public int Y { get getY(); set setY(value); }

    public int BorderWidth { get getBorderWidth(); set setBorderWidth(value); }

    public int BorderColor { get getBorderColor(); set setBorderColor(value); }

    public bool Visible { get getVisible(); set setVisible(value); }

    // other methods

    public Rectangle ClipRectange { get; protected set; }   
    abstract public void Draw();
} // class Control

/* concrete */ class MyControl: Control
{
    public override bool getVisible(...) { ... }
    public override void setVisible(...) { ... }
} // class MyControl: Control

Sé que esta sugerencia es más "detallada" o compleja, pero es muy útil en el mundo real.

[2] Agregue una propiedad "IsEnabled", no confunda con "IsReadOnly":

abstract class Control
{
    // internal fields for properties
    protected bool _IsEnabled;

    public virtual bool getIsEnabled(...) { ... }
    public virtual void setIsEnabled(...) { ... }

    public bool IsEnabled{ get getIsEnabled(); set setIsEnabled(value); }
} // class Control

Significa que puede tener que mostrar su control, pero no mostrar ninguna información.

[3] Agregue una propiedad "IsReadOnly", no confunda con "IsEnabled":

abstract class Control
{
    // internal fields for properties
    protected bool _IsReadOnly;

    public virtual bool getIsReadOnly(...) { ... }
    public virtual void setIsReadOnly(...) { ... }

    public bool IsReadOnly{ get getIsReadOnly(); set setIsReadOnly(value); }
} // class Control

Eso significa que el control puede mostrar información, pero el usuario no puede cambiarlo.

Buena pregunta! Lo primero que noté es que el método de dibujo no tiene ningún parámetro, ¿dónde se dibuja? Creo que debería recibir algún objeto Surface o Graphics como parámetro (como interfaz, por supuesto).

Una cosa más que me parece extraña es la interfaz de IContainer. Tiene el método GetChild que devuelve un solo elemento secundario y no tiene parámetros; tal vez debería devolver una colección o si mueve el método Draw a una interfaz, podría implementar esta interfaz y tener un método de dibujo que pueda dibujar su colección secundaria interna. sin exponerlo.

Tal vez para ideas, también podría ver WPF, en mi opinión, es un marco muy bien diseñado. También puedes echar un vistazo a los patrones de diseño de Composición y Decorador. El primero puede ser útil para los elementos contenedores y el segundo para agregar funcionalidad a los elementos. No puedo decir qué tan bien funcionará a primera vista, pero esto es lo que pienso:

Para evitar la duplicación, podría tener algo como elementos primitivos, como el elemento de texto. Luego puedes construir los elementos más complicados usando estos primitivos. Por ejemplo, un Border es un elemento que tiene un solo elemento secundario. Cuando llama a su método Draw , dibuja un borde y un fondo y luego dibuja a su hijo dentro del borde. Un TextElement solo dibuja un texto. Ahora, si desea un botón, puede crear uno componiendo esas dos primitivas, es decir, colocando texto dentro del borde. Aquí la frontera es algo así como un decorador.

La publicación se está haciendo bastante larga, así que avísame si la idea te parece interesante y puedo dar algunos ejemplos o más explicaciones.

Cortar el código e ir al núcleo de su pregunta "¿Mi diseño con clase base abstracta e interfaces no como tipos, sino más como comportamientos es un buen diseño o no?", diría que no hay nada de malo en ese enfoque .

De hecho, he utilizado un enfoque de este tipo (en mi motor de representación) donde cada interfaz definió el comportamiento que esperaba el subsistema consumidor. Por ejemplo, IUpdateable, ICollidable, IRenderable, ILoadable, ILoader y así sucesivamente. Para mayor claridad, también separé cada uno de estos "comportamientos" en clases parciales separadas como "Entity.IUpdateable.cs", "Entity.IRenderable.cs" y traté de mantener los campos y métodos lo más independientes posible.

El enfoque de usar interfaces para definir patrones de comportamiento también está de acuerdo conmigo porque los parámetros genéricos, de restricciones y de tipo de variante de co (ntra) funcionan muy bien juntos.

Una de las cosas que observé sobre este método de diseño fue: si alguna vez te encuentras definiendo una interfaz con más de un puñado de métodos, probablemente no estés implementando un comportamiento.