¿Qué opción de diseño es mejor para codificar un marco?

Question

Estoy codificando un marco (en Java, pero la pregunta es genérica) en la que proporcionaré un conjunto de interfaces para que los clientes implementen. Las funciones en el marco dependerán de cómo se construirán las clases de implementación, es decir, dependerán de esas implementaciones para proporcionar otras instancias de interfaces.

Por ejemplo, podría tener:

Interface IContribution {
   public IMyStuff getMyStuff();
   public IHelper getHelper();
}

Interface IMyStuff {
     public void doSomeMethod(IHelper helper);
}

¿Cómo puedo asegurarme de que esas instancias de IMyStuff e IHelper estén disponibles?

Un método sería crear los métodos 'getter' en la interfaz y en mi marco verificar minuciosamente los objetos nulos devueltos.

Otra opción sería crear clases abstractas que implementen una fábrica que llame (usando patrones de estrategia) los métodos de interfaz que se implementarán. Pero esto desafía el hecho de que tengo la interfaz en primer lugar. Los clientes deben usar la clase abstracta. Pero podrían eludir esto usando la interfaz en lugar de la clase abstracta. Por lo tanto, no debería proporcionar la interfaz, sino solo la clase abstracta ...

Entonces, ¿cuáles son sus ideas sobre esto, cuál es un enfoque pragmático para esto?

Answer 1

  

¿Cómo puedo asegurarme de que esas instancias de IMyStuff e IHelper estén disponibles?

Si los clientes son responsables de implementar las interfaces y las clases ellos mismos, diría que es su responsabilidad asegurarse de que esas instancias estén disponibles; no me preocuparía ponerlo en mi propio código.

Answer 2

Para crear un buen marco, debe crear simultáneamente una aplicación a su alrededor. De esa manera, conocerá y comprenderá el dolor que sufrirán sus clientes ANTES de que se les imponga.

En otras palabras, comience con: ¿Cómo trabajarían mis clientes con esta aplicación? ¿Cómo necesitan trabajar con eso?

Te darás cuenta de inmediato de que la forma más simple, desde su perspectiva, será la mejor.

Answer 3

No puede garantizarlo solo con interfaces, no hay comportamiento allí.

Estoy de acuerdo con la filosofía de la programación defensiva en el Framework, ayuda a los desarrolladores a evitar cometer errores.

Puede suministrar un objeto de fábrica:

public class MyPoliceman {
    public IContribution makeContributor( IMyStuff stuffer, IHelper helper)
                    throws BadAssociatesException {

     // check validity of stuffer and helper here, throw exceptions if null
    }
}

Entonces al menos podemos verificar nulos, etc.

Con cierta reflexión, generalmente es posible brindar ayuda a los desarrolladores. En algunos casos, lo mejor que puede hacer es atrapar los errores e informarlos de manera atroz. Por ejemplo, aquí, un IHelper perfectamente bien podría pasarse a su fábrica, pero las acciones posteriores en la clase podrían volverlo incapaz. (p. ej., imagen que era un archivo, y un efecto secundario luego cerró el archivo). Luego, todo lo que puede hacer es atrapar la condición de error resultante, registrar un error en algún lugar y (probablemente) lanzar una excepción. Entonces, al menos, el desarrollador tiene una pista sobre qué solucionar.