¿Qué debo considerar al elegir entre chainability y lenguaje construcciones?

Question

Tengo momento difícil tomar esta decisión de diseño.

Podría seguir con la construcción tradicional lenguaje new para inicializar objetos, y utilizarlos a través de variables, tales como:

$o = new Object('arg');
$o->method();
$o->property = 'value';
$o->save();

O puedo elegir patrón de fábrica y agresivo como chainability como

Object::new('arg')->method()->setProperty('value')->save();

lo que resultaría en

• LOC menos a
  • leer,
  • mantener,
  • refactor,
• hay necesidad de nombrar las variables.

Sin embargo, no estoy seguro si esto es una aproximación aceptable, y si se me olvidó tomar algo en cuenta.

Por favor, expresar sus preocupaciones o acuerdo, y la orientación como la forma en que pude tomar mi decisión.

Answer 1

Lo bueno de la interfaz fluida es que la carne del código no se pierde entre las cañerías sintáctica adicional por lo que es más fácil de leer. Sin embargo, es un lenguaje menos familiar que el enfoque de procedimiento, línea por línea, y no como general; No todas las estructuras de código será un buen ajuste para este estilo, por ejemplo

if (something) $o->method();

No se traducirá tan limpiamente. Así que si estas cosas son típicas, puede que no sea un buen ajuste.

Ten en cuenta también el contexto de otro código que le rodean. Si el código va a ser en su mayoría este tipo de repetitivo buscando segmentos como

$o = new Object('arg');
$o->method();
$o->property = 'value';
$o->save();

A continuación, haciéndolos más sucinta que seguramente sería una mejora. Pero si tal código se pierde entre tanto otro código en un estilo diferente, tal vez no.

Si se parece como que es probablemente una buena idea, yo diría que ir a por ello. Si no juega bien, el pequeño esfuerzo de cambiar de nuevo tendrá un valor de la experiencia de aprendizaje.

Answer 2

Tengo sentimientos encontrados sobre la reciente moda Fluido interfaz.

Para mí, interfaces fluidas tiene sentido cuando la cadena global método expresa un solo concepto de principio a fin. Por ejemplo:

var SuperLate = (new Coffee()).AddMocha().AddCream().Invert().Blend();

Cada paso necesita el contexto de la cadena de sentido y el orden en que los métodos de la cadena se ejecutan asuntos. Si Blend () se llama antes de Invertir (), sería el caos.

En su ejemplo, hay muy poco acoplamiento temporal entre los métodos de la interfaz. Configuración de las propiedades y métodos de ejecución no deben ser dependientes del orden. Creo que la introducción de una interfaz fluida para la manipulación rutinaria invocación del método y la propiedad sólo aumenta la complejidad de la interfaz mientras que da la percepción de acoplamiento temporal.

Además, la adición de una interfaz fluida aumenta el acoplamiento entre cada método, ya que ahora son dependientes de valor de cada uno de retorno. Este acoplamiento tiene sentido cuando cada método expresa sólo una parte de un concepto global (como un paso para hacer café), pero puede dificultar la refactorización futuro cuando cada método se encuentra solo.

Si bien puede ser más detallado, que no recomendaría la introducción de una interfaz fluida para el ajuste de la invocación de métodos y propiedades de rutina.

Answer 3

Soy un gran fan de su diseño 'conexión en cadena'. Este tipo de diseño a veces se llama una Fluido interfaz .

Answer 4

¿por qué no tener varios constructores que toman los valores para la inicialización. Por lo que tendría:

Object::new()
Object::new('arg1')
Object::new('arg1','arg2')

etc.