Tengo dificultades con algún enfoque OOP general & de Java. Hay varias maneras de permitir que las clases/objetos se comuniquen entre sí. Para dar un ejemplo sencillo:¿Cuál será el enfoque OOP? (¿O TU enfoque?)
entonces Object Una recuperar P , Q y R por sí mismo (dentro de la acción X), o deben estos valores ser parámetros para la acción X?
Si los valores se pueden reutilizar, páselos (o una parte de) como parámetros. O bien, créelos como variables locales dentro de X.
Esta es una pregunta demasiado general que debe responderse concretamente. Cualquiera de los enfoques puede ser bueno en ciertas situaciones. Algunos factores:
Pass P, Q y R a a, de alguna manera, ya sea mediante el establecimiento como propiedades de a o pasándolos a X (dependiendo de si PQR son específicos de X o si A también los necesita A en otras situaciones).
La respuesta es que depende.
Si P, Q y R tienen un vínculo fuerte y significativa a una instancia de A continuación, usted podría considerar la adición de ellos como miembros de la clase A.
public class A {
private P p;
private Q q;
private R r;
public A(P p, Q q, R r) {
this.p = p;
this.q = q;
this.r = r;
}
public void x() {
p.doSomething();
q.doSomething();
r.doSomething();
}
}
Si P, Q y R no son, y son sólo "algunos valores" que la acción ayuda X lo realizan de tarea, entonces es posible que desee utilizar como parámetros
public class A {
public void x(P p, Q q, R r) {
p.doSomething();
q.doSomething();
r.doSomething();
}
}
La segunda versión no mantiene ningún estado por lo que es, por definición, flujos seguros
Enfoque 1
class A{
ctor(P, Q, R)
{
}
void X()
{
P.SomeMethod();
Q.SomeMethod();
R.SomeMethod();
}
}
Enfoque 2
class A{
void X(P, Q, R)
{
P.SomeMethod();
Q.SomeMethod();
R.SomeMethod();
}
}
Clase-diseño es un subconjunto de diseño de software: Así que todo depende.
Como la pregunta es poco subjetiva (todo el mundo tiene un enfoque diferente), solo diré que utilizo este método, sin decir que es el mejor. Probablemente hay muchas formas diferentes.
public interface FuncX {
public void actionX(FuncP p, FuncQ q, FuncR r);
}
Y las clases implementan esta interfaz. Si dos clases son pequeñas pero están relacionadas, les permito implementar ambas interfaces.
Hace que cada implementación sea muy fácil de probar. Para iniciar el sistema, un método principal debe crear instancias de clases específicas. Esto puede ser configurable, por ejemplo.
public class MyFuncX implements FuncX, FuncP {
public void actionX(FuncP p, FuncQ q, FuncR r) {
...
}
public void actionP(...) {
...
}
}
// the caller:
FuncX x = new MyFuncX(); // dependency
FuncQ q = ...;
FuncR r = ...;
x.actionX(x, q, r);
Me suena como el trabajo de Composite Pattern.
Básicamente, pasa los objetos P, Q y R a A y luego ejecuta cierto método dentro de todos ellos. Este patrón se usa cuando necesita varios objetos para realizar la misma acción. Así, como ejemplo de wiki dice, básicamente, que le hace algo como esto:
graphic1.add(ellipse1);
graphic1.add(ellipse2);
graphic1.add(ellipse3);
graphic.print();
y graphic.print(); llamarían print método dentro de cada uno de los objetos de la elipse.
En su proyecto, si el lifetime de los objetos P, Q, R se encuentra dentro de la acción X, entonces cree objetos dentro de la acción misma. En cambio, si el tiempo de vida no depende de la acción X, pásalo como argumento. También cuide el alcance de los objetos P, Q, R. Te recomiendo que revises los conceptos de Asociación, Agregación, Composición y Dependencia antes de diseñar una clase. Realice una llamada en función del alcance y el tiempo de vida de los objetos después de comprender esos conceptos.
Hazlo de la manera más conveniente posible?
Puede escribir una función/método para aceptar más de 18 argumentos, pero no es realmente conveniente.
Si el método que va a hacer la acción A siempre obtiene los mismos argumentos (y está muy seguro de que esto no cambiará), no veo por qué los necesita pasando el argumento.
Dicho esto, normalmente no me atengo a las normas y no sé lo que otros fundamentalistas OOP (gurús del bombo) harían en esta situación.