¿Sería la sintaxis para la composición una adición útil a Java? [cerrado]

Question

Primero que nada, no sé casi nada acerca de la teoría del lenguaje, y apenas conozco otros lenguajes excepto Java, pero tuve una idea que creo que sería genial, pero necesito que me digan:
a: por qué apesta
b: como el lenguaje x ha tenido eso por años
c: como mi mente apesta
d: todas las anteriores

La idea le daría a la composición la misma facilidad de reutilización de código que extiende .

Entonces, si tuvieras una clase como esta:

public interface A {  
    public void methodInA();  
}

Y luego tuviste una clase como esta:

public class B {  
    private composed A;
    public B() {
        // construct A within constructor
    }
}

Entonces podrías hacer esto:

B myB = new B();
myB.methodInA();

Sin tener que agregar la delegación en la clase B. Pero también puede hacer lo mismo que con la herencia, es decir:

@Overrides
public void methodInA(){
    // B's own delegation method
}

Las desventajas incluyen:

• los métodos están ocultos en el código fuente, lo que hace que sea menos obvio de dónde proviene la llamada, pero este también es el caso con extends
• si los campos compuestos comparten la misma firma de método, debe haber un conflicto resuelto (¿cómo resuelven esto las interfaces en conflicto?)
• si quisiera tener varios campos compuestos del mismo tipo, habría un conflicto obvio en el cual los campos delegar a
• probablemente 100 otras cosas que no he pensado

Como digo, obviamente no soy un teórico del lenguaje, y no he pasado mucho tiempo pensando en ello, la idea me vino a la mente y quería saber cuán equivocada estoy. Creo que sería genial.

Answer 1

Creo que si lo restringiera de modo que una clase solo pudiera usar esta función para componer una sola clase, sería algo útil y evitaría muchos de los dolores de cabeza que se están discutiendo.

Personalmente odio la herencia de clases concretas. Soy un gran defensor del ítem 14 de Effective Java de Bloch,

Honestamente, si realmente supieras lo que estabas haciendo, apuesto a que podrías escribir una anotación del compilador que manejaría esto. Entonces, suponiendo que tuvieras una barra de clase que implementó la interfaz IBar, tu clase se vería así:

public class Foo {

  @Delegate(IBar.class)
  private Bar bar;

  // initialize bar via constructor or setter
}

Luego, durante la compilación, se podría hacer que Foo implementara IBar y cualquiera de los métodos en esa interfaz que no estaban implementados por Foo terminaría generándose para verse así:

public Baz method1(Qux val) {
  return bar.method1(val);
}

Como se mencionó anteriormente, querría hacer la restricción de que solo un campo por clase podría usar esta anotación. Si varios campos tuvieran esta anotación, probablemente querrá lanzar un error de compilación. Alternativamente, podría encontrar una manera de codificar algún tipo de modelo de precedencia en los parámetros que se le pasan.

Ahora que he escrito esto, parece un poco genial. Tal vez voy a jugar con eso la próxima semana. Actualizaré esto si logro resolver algo.

Answer 2

Suena bien, pero creo que hace que algunas construcciones de lenguaje horribles. Obviamente, existe un problema si declara más de una 'composición' de la misma clase, pero incluso si prohíbe eso, ¿qué ocurre cuando una llamada coincide con un método en más de una de las clases compuestas (diferentes)? Tendría que especificar a cuál se llamó en la clase principal, y necesitaría una sintaxis adicional para eso. La situación se vuelve aún peor si hay miembros públicos en las clases.

La composición se utiliza para prevenir problemas con herencia múltiple. Permitir una composición como esta permite efectivamente la herencia múltiple, al menos en términos de resolver qué método llamar. Dado que una decisión de diseño clave con Java fue no permitir la herencia múltiple (por buenas razones), creo que es poco probable que esto se introduzca en Java.

Answer 3

No estoy seguro de ver una clara ventaja al hacer esto. Entiendo el punto que estás haciendo. En el momento de llamar a un método en A tienes que myB.getAInstance (). MethodInA (), pero quieres hacer que myB.methodInA ().

Pero, ¿qué sucede si tienes varias instancias de A? ¿Cómo se resolvería la llamada al método? Muchas veces la composición implica una asociación de uno a muchos, por lo que B tiene muchas instancias. ¿Qué pasa entonces?

Estoy de acuerdo con sus desventajas enumeradas. Simplemente puede causar demasiada confusión de lo que vale.

Answer 4

Echa un vistazo a lo que se llama " Mixins " en algunos idiomas, y " Roles " en el sistema Perl 5 Moose OO.

Answer 5

También existe la diferencia entre composición y agregación a considerar. ¿Cómo sabe el compilador si te refieres a las relaciones 'is-a' o 'has-a'?

• ¿El gráfico completo del objeto se vuelve elegible para la recolección de basura o solo el jefe del gráfico?

Un par de marcos y herramientas de mapeo ORM sobre / alrededor de ellos proporcionan las relaciones belongsTo o has-many entre objetos persistentes y algunos también proporcionan la eliminación en cascada ( para la composición). No conozco a nadie que le proporcione el azúcar sintáctico simple que está buscando.

En realidad, pensándolo bien, los lenguajes (es) MetaClass y MetaProgramming de Groovy pueden proporcionar algo muy similar, con delegación "auto-magic".

Answer 6

Se permite la herencia múltiple en C ++, sé que es diferente, pero sigue el mismo proceso de pensamiento. Java fue diseñado para no permitir la herencia múltiple, por lo que habría menos confusión, por lo tanto, errores y explotaciones.

Lo que has sugerido está en conflicto directo con los principios de java.

Habiendo dicho eso, sería genial (no necesariamente útil). Soy un programador de java que cambió de C ++. Me gusta poder cometer mis propios errores.