Depende de lo quieras hacer, esto:
Código PHP:
Ver originalclass A
{
function i()
{
return "Hola";
}
}
class B
{
function v()
{
$f=new A();
return $f->i();
}
}
$dd=new B();
echo $dd->v();
Si lo haces porque lo que quieres es que un metodo de B se comporte como uno de A, esta mal.
Hay (a menos) tres alternativas:
1)
Código PHP:
Ver originalclass A
{
function i()
{
return "Hola";
}
}
$f=new A();
echo $f->i();
2)
Código PHP:
Ver originalclass A
{
function i()
{
return "Hola";
}
}
class B
{
function v($f)
{
return $f->i();
}
}
$dd=new B();
$f=new A();
echo $dd->v($f);
3)
Código PHP:
Ver originalclass A
{
function i()
{
return "Hola";
}
}
class B extends A
{
function v() // Metodo alias
{
return $this->i();
}
}
$dd=new B();
echo $dd->v();
Sin embargo, la tercer opcion es la mas peligrosa de todas, en el sentido de que solo debes extender una clase, si hay una relacion de Generalizacion entre ambas, por ejemplo, imaginate un Tablero y una Casilla, el tablero conoce a la casilla y la casilla conoce al tablero, pero la casilla no es una extencion del tablero, por lo tanto no lo hereda.
Código PHP:
Ver originalclass Tablero
{
private $casillas = [];
function setCasillaRoja($nro)
{
if(!isset($this->casillas[$nro])) $this->casillas[$nro] = new Casilla();
return $this->casillas[$nro]->setColor("Rojo");
}
}
class Casilla
{
private $color;
function setColor($color)
{
if($this->color == $color)
return "El color no cambio";
$this->color = $color;
return "El color se cambio";
}
}
$board=new Tablero();
echo $board->setCasillaRoja(1);
echo $board->setCasillaRoja(2);
echo $board->setCasillaRoja(1);
Del codigo anterior la unica linea en discucion es:
Código PHP:
Ver original$this->casillas[$nro] = new Casilla();
Entonces hay que pensar en el contexto, la pregunta de oro es: ¿Para cuantas cosas quiero que me sirvan esta clases?
Las posibles respuestas son:
1) Solo para este juego en particular.
2) Para todos los juegos que se me ocurran con este tipo de tablero.
3) Para todos los juegos de tablero del mundo.
Si la respuesta es la 1 o la 2, entonces el codigo esta bien y no hay que cambiar nada.
Si la respuesta es la tercera, entonces estamos en un problema, porque no todos los juegos de tablero tienen las mismas casillas, hay que hacer uso del patron Factory o/y usar interfaces.
Los problemas no surgen cuando queres hacer andar algo, sino cuando queres que ese algo te sirva para todo, entonces tenes que hacer abstracciones, muchas y variadas (Eso son los patrones de diseño ni mas ni menos, tecnicas de abstraccion para diferentes problematicas).
Se dice comunmente que usar patrones y buscar siempre algoritmos que sirvan para todo (genericos) es mejor, sin embargo, esto muchas veces no es verdad, te doy un simple ejemplo: PDO.
Si usas PDO puedes usar cualquier motor de base de datos, pero las consultas demoran mas que con un controlador nativo, pretende que cambiando una linea de configuracion puedas pasar de una base de datos FireBird a SQlite sin nada mas, y sin embargo, tienes que reescribir todas las sentencias (o gran parte de ellas, volviendo al ejemplo, el tablero del Monopoly no es el mismo tablero que el del Ajedrez, sus casillas no son las mismas, ni siquiera se comportan igual, entonces ¿Tiene sentido implementar patrones, usar interfaces, traits y demas artilugios solo para tener una clase Tablero bien abstracta que sepa jugar al ajedrez y al monopoly?
Personalmente no le veo el sentido, prefiero que las clases se acoplen y funcionen rapido.