[Php-objetos] Nueva entrega de ejercicio 1.

[Leonardo Tadei - Pegasus Tech Supply]

Hola Juan,

El lun, 16-02-2009 a las 19:03 -0200, Juan Marcos escribió:
> De a poco se me aclara la visión, mas que nada entendiendo un poco más
> lo de Composición,

	Me alegra.

>  pero tengo una astilla todavia que me jode un poco. A lo que yo me
> refería con el hecho de que se rompía el encapsulamiento de Vehículo
> es, por ejemplo, que si el constructor de Combustible en lugar de
> tener dos parámetros como en este ejemplo, tiene 3, y el new de
> Combustible lo hago dentro de Vehículo, tengo que pasar un parámetro
> más al Vehículo en el momento de la creación, lo que hace que tenga
> que modificar Vehículo por algo que cambié en Combustible. 

	Bueno, en todo caso esto no rompería el encapsulamiento: a lo sumo un
cambio en la implementación de el Objeto componente te afecta al
constructor del Objeto continente.
	La solución a esto es facilícima: en vez de pasar al constructor
valores del Objeto Componente, directamente pasás una instancia del
Objeto y listo!
	Igual al ser la Composición una relación tan fuerte, es de esperar que
un cambio en un Componente cambie al Objeto entero...

> O si me las arreglo para pasar el valor de otra forma, de todas formas
> cuando llame al new de Combustible voy a tener que agregar el tercer
> parámetro dentro del constructor de Vehículo, lo que hace que se
> necesite un cambio en Vehículo. En cambio, si el new está afuera, esto
> no sucederia, ya que independientemente de cómo se cree el objeto,
> este se ingresaría y pasaría a ser un atributo de Vehículo de la misma
> forma que antes y Vehículo ni se enteraría.

	Esto no es cierto: si bien a nivel de argumentos del mensaje no hay
cambio, no tendrías como saber ni siquiera cómo se llaman los setters y
getters del Objeto, así que estás en la misma, pero en otro lugar.

> Por otro lado lo que me comentabas en:
> > ...
> > $c2 = new Combustible("GNC", 50);
> > $pickup1 = new Pickup($c2, 4, 20, 3000);
> > $consumoPickup = $pickup1->calcularConsumo();
> > print("Y su consumo es de: $$consumoPickup.");
> > // Funciona como se espera.... pero
> > $c2->setTipo("GNC2");
> > $c2->setValor(75);
> > $consumoPickup = $pickup1->calcularConsumo();
> > print("Y su consumo es de: $$consumoPickup.");
> > // devuelve otro valor.
> > ...
> > Cambia el resultado, con lo cual queda demostrado que tu
> implementación
> > es una agregación, en lugar de una composición...
> Es verdad que cambia el resultado, y si se hiciese algo como:
> ...
> $nafta = $pickup1->getCombustible();
> $consumoPickup = $pickup1->calcularConsumo();
> $nafta->setValor(45);
> $consumoPickup = $pickup1->calcularConsumo();
> ...
> Esto también cambiaría,

	Correcto: es una implementación más rebuscada de lo que te envío yo...

>  pero si hicieramos el getCombustible() de una forma que esto no
> pudiera suceder (por ejemplo, devolver los valores de forma que no se
> devuelva el objeto mismo),

	Con la implementación que me mandaste, no hay cómo hacer que
getCombustible() no haga lo que hace... me parece que seguís mareado con
composición/agregación.

>  le quitaría todo propósito de utilizar un objeto para Combustible.

	Por qué le "quitaría el propósito" ???

>  En ambos códigos enunciados, para mi tiene más forma de una "metida
> de pata" en el uso de los mismos. A lo sumo podria hacer un $c2=null
> luego de crear el objeto $pickup1 para asegurarme de no hacer macana.

	Si hacés $c2=null, perdés el atributo y calcularConsumo() de tu
implementación no funciona más...

> Parece una pavada que siga dando vueltas con el ejercicio 1 todavia,
> creo saber qué código es el que esperás que te devuelva, el tema es
> que yo quiero estar convencido de hacer las cosas de la mejor manera
> posible, porque si las hiciera solamente por contentar y sin estar
> convencido, despues voy a hacer las cosas como me parecen de todas
> formas y no habria aprendido nada. Por eso prefiero debatirlo mil
> veces y sacarme todas las dudas. Esto de programar para mi es como el
> ajedréz, las piezas son pocas y es fácil aprender a moverlas, pero
> para saber jugar tenés que tener paciencia y romperte la cabeza mas de
> una vez.

	Yo también prefiero que lo discutamos.
	Tal vez para estar más convencido deberías remitirte a bibliografía más
extensa sobre este tema, además del apunte que necesariamente es un
resumen.
	"Design Object Oriented Software" de Wirf-Brook es un libro que se
explaya varios capítulos sobre este asunto.
	Si me pasás títulos y autores, te ayudo a diferenciar a los
chapuceros...

> Salute!

	=mente!
-- 
Leonardo Tadei
leonardot en pegasusnet.com.ar
http://blog.pegasusnet.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key