Duda sobre teoria de clases

[Keysher]

Buenas,

Tengo una duda de concepto.

Imaginemos que tengo una clase. Para usar el ejemplo típico de POO, la llamaremos "Coche", además tengo otras dos clases: "Rueda" y "Tapacubos" (sería casi absurdo, pero es por poner un ejemplo).


El caso es que quiero saber cual sería la forma más óptima de implementar esto, sabiendo que sólo quiero que se creen objetos de la clase "Coche" (que será la encargada de crear los diferentes objetos del resto de clases).

La herencia no creo que aplique aquí, ya que "Rueda" no es estrictamente hija de "Coche", no hereda ni sus propiedades ni sus métodos.

Tampoco quiero que se puedan crear objetos de la clase "Rueda" o "Tapacubos", de eso se encargará la clase "Coche".

Resumiendo un poco, necesito saber cómo sería el esquema de un sistema de clases como el que propongo.

Lo puedo hacer con clases independientes, y funcionaría bien, pero entonces cualquiera podría crear un objeto de la clase "Rueda o "tapacubos", pero eso no me interesa, ya que un objeto de esa clase sería inutil por sí mismo.

La otra opción es que vayan herando, "Rueda" heredaría de "Coche" y "Tapacubos" de "Rueda", pondría las clases, los atributos y los métodos como protected, salvo los de la clase Tapacubos y sólo usaría esa clase, pero no sé si éste es el mejor método, es decir, realmente no estaría creando un objeto "Tapacubos", sino el Coche entero....

Espero que se entienda medianamente bien.

[GatorV]

Hola keysher,

Lo que quieres es un híbrido de lo que es el patrón factory, para crear los objetos, pero pertenecientes a la clase carro, y lo puedes hacer siguiendo una teoría básica, por ejemplo:

Código php:

class Carro {
       private $_id = null;
       private $_ruedas = array();
 
       public function getId() {
                return $this->_id;
       }
 
       public function creaRueda() {
                $rueda = new Rueda($this); // Aqui dentro de rueda llamamos a getId por ejemplo de Carro..
                $this->_ruedas[] = $rueda;
                return $rueda;
       }
}
 

Con eso estas "atando" la rueda a esa instancia de carro..

Saludos.

[Keysher]

Sí, eso lo tenía más o menos claro, que cada "rueda" iba a estar en un array dentro de la clase "coche".

Umm, bueno, puede valer, aún así sería posible crear objetos de esa clase (rueda) desde fuera de "Coche", pero siempre habría que pasarle un objeto "Coche" como parámetro... No se me había ocurrido... Estaba ofuscado buscando algo más "limpio" (como tener una clase dentro de otra).

Gracias por la ayuda!!
Un saludo.

[GatorV]

Mmm desafortunadamente PHP no dispone de clases privadas como Java, pero igual te puede servir, si crean una rueda sin pasar por carro no la podrían "agregar" a un carro aunque se lo pases como parámetro, ya que es dentro de carro donde se agrega la rueda al array así garantizas que Rueda este realmente atada a un Carro.

Saludos.

[Keysher]

Es una pena lo de las clases privadas.... sobre todo si tienes obsesión por un código "limpio"...

Ahora tengo dos opciones. Que sea la clase rueda quien se asocie al coche:

Código php:

class Coche {
    public $ruedas = array();
    public function agregarRueda() {
        new Rueda($this);
    }
}
 
 
class Rueda {
    function __construct($auxCoche) {
        array_push($auxCoche->ruedas, $this);       
    }
}
 

De éste modo sólo funcionará si se le pasa como parámetro al constructor de "Rueda" un objeto de la clase "Coche".

O que sea el método de "Coche" el que cree el objeto y luego lo añada al array:

Código php:

class Coche {
    public $ruedas = array();
 
    public function agregarRueda() {
        array_push($this->ruedas, new Rueda()
    }
}
 
 
class Rueda {   
 
    function __construct() {
        return $this;
    }
}
 

[GatorV]

De hecho en tu primera forma, no podrías ponerla a menos que Coche tuviera una propiedad publica, y quedaria expuesta el array a que cualquiera agregue datos, por lo que si quieres limpieza debges de optar por la segunda.

Saludos.

[Keysher]

Tienes razón, no me había percatado de ello. Sigue sin gustarme que se "cualquiera" pueda crear un objeto de esa clase...


Aunque podríamos ser un poco más paranóicos, y hacer algo del estilo:

Código php:

class Coche {
        private $ruedas = array();
        public function agregarRueda() {
            new Rueda($this);
        }
 
        public function crearRueda($auxRueda) {
            if (get_class($auxRueda) == 'Rueda')
                array_push($this->ruedas, $auxRueda);
        }
}
 
 
class Rueda {
    function __construct($auxCoche) {
        if (get_class($auxCoche) == 'Coche') {
            $auxCoche->crearRueda($this);
    }
}
 

[GatorV]

La única forma de prevenir que se pudiera crear un tema es usando un constructor privado, pero en ese caso no lo podrías crear desde Coche...

Creo lo mejor es ver la forma de hacer las cosas limpias y bien documentadas, así tus usuarios sabrán que creando un objeto sin dueño no tiene mucha funcionalidad.

Saludos.

[enriqueplace]

Disculpen, un comentario... por qué no dejan de jugar con los objetos? veo que en cualquier momento se pueden sacar un ojo.

Te sugiero que leas sobre conceptos básicos de POO antes de jugar con sintaxis para ver de empezar, ya que aunque "ejecute sin errores", no significa que esté bien conceptualmente ni que el diseño sea "correcto" para resolver un problema.

Hablar de "rueda hereda de coche", simple y llanamente es un disparate. Tampoco veo que tengas claras las relaciones posibles entre los objetos (además de Herencia) y cuando deberías aplicarlas.

Y que GatorV me perdone, no concibo hablar de diseño con objetos sin diagramas UML, es como querer jugar a construir un edificio pero sin planos.

[GatorV]

jejej a veces es divertido, pero si tienes razón es importante (como base) tener los diagramas UML ya que puedes ver las relaciones de forma más clara.

[Keysher]

Creo que precisamente estábamos hablando del diseño, simplificando mucho. Sé lo que es un disparate y lo que no lo es. Y están clarísimas las relaciones entre los diferentes objetos. Precisamente por eso lanzaba la pregunta, para ver cual era la mejor manera de actuar en esos casos.

Estábamos tratando (al menos yo) un problema de diseño con un ejemplo para que se entendiese mejor, pero no dejaba de ser algo sobre el papel. La finalidad era tener un diseño correcto, no un código que funcione. Eso es muy fácil y puedo hacerlo sin ningún problema.

En ningún momento he dejado entrever que rueda hereda de coche, simplemente lo he comentado como algo que compilaría y funcionaría, pero que no entra dentro de la lógica de programación orienta a objetos. Sé perfectamente el tipo de relación que hay entre los objetos y mi idea era que fuesen clases privadas, pero PHP no permite esto. Así que la duda era simple: En éste lenguaje el concreto, cuál era la mejor opción para manejar estos casos. Sin más.

Lo único que buscaba era una aclaración sobre cómo podría hacer una interrelación entre dos objetos, uno que dependa del otro sin poder usar clases privadas. Y a partir de ahí fui divagando sobre opciones que añadan simplicidad, seguridad y orden a esa relación.

No sé porque no se puede “jugar” con los objetos. Tan sólo es un debate, en éste caso en concreto no creo que haya una “manera correcta que haya que seguir por cojones”, por muchos diagramas UML que se hagan. Hay un problema (imposibilidad de tener clases privadas) y se plantean soluciones. Punto. En ningún momento hemos debatido sobre cuál es la relación entre las dos clases (creo que eso quedaba bastante claro con el ejemplo, que era bastante gráfico), el fin del post era conseguir la mejor manera de implementarlo en PHP. Y al final es algo muy parecido a lo que había deducido en un principio: clases públicas independientes.

En fin, puede que no me explique bien o que sea duro de cabeza…

[venkman]

A mi lo que no me queda claro con el ejemplo es el hecho de que Rueda necesite ser una clase interna a Coche. Quiero decir, no sé cómo será tu caso original, pero claramente debería poder instanciar una Rueda y ponérsela a un Coche. Si un Coche pincha una Rueda, debería poder ponerle una nueva, ¿no? ¿Y si quiero ponerle unas más anchas?

De modo que no es tanto el hecho de que Rueda tenga o no utilidad por sí misma y pueda o no utilizarse ella sola. Sino que se trata de que Rueda puede instanciarse por sí misma para añadirla a un Coche o a otro.

[Keysher]

Umm, vale, yo no he dicho que no se puedan crear varias ruedas, o con atributos diferentes, sino que SIEMPRE debería estar atada a un coche, quizás no sea el ejemplo más claro, pero supongamos que es un objeto que solamente tiene sentido y utilidad (o nosotros queremos que así sea) si forma parte de otro objeto concreto.

Y tal vez por simpleza, limpieza o utilidad, nos interese que no sea ese nuevo objeto el que se agrege al anterior, sino que sea el más amplio el que seleccione los otros (en éste caso es el coche el que añade las ruedas, no es una rueda la que se ata a un coche).

Técnicamente no está mal que se pueda crear esa clase independientemente, de hecho es muy probable que si la creas fuera del entorno especifico que hemos diseñado para ella, esa instancia del objeto no sirva para nada. Pero lo que yo quería saber es si había alguna forma más ordenada (una forma de tener clases privadas, vamos).

[venkman]

Mmm... creo que preferiría que pusieras un ejemplo que justifique la necesidad de clases internas.

El asunto es que estás ligando el uso a la instanciación. Así pierdes mucha flexibilidad.

En realidad, no nada es bueno que sea el coche el que cree las ruedas. La realidad es que habrá un encargado de crear el coche, crear las ruedas, poner las ruedas en el coche y darte a ti el conjunto ya montado. Lo que necesitas, entonces, es una factoría de coches.

[Keysher]

Pero si el objeto "Rueda" sólo es usable por "Coche", ¿qué sentido tiene usar un tercero para crear la Rueda e instanciarla al Coche? Llegamos a un punto en que no interesa que la "Rueda" se pueda usar fuera del "Coche".

Un ejemplo más enfocado a la realidad. Tenemos una clase HTML o Documento o cómo sea. Esta clase se encargará de construir una página HTML (cabeceras, cuerpo....)
Pero también tenemos estilos, es decir que se puede construir una página HTML de un determinado estilo. O incluso usar dos estilos para un mismo HTML.
Entonces tenemos una segunda clase llamada Estilo. Por si sola esta clase no hace nada, ya que sólo devolvería una porción de código HTML. Necesita de la clase anterior para armar la página. Y a su vez la clase anterior tiene que saber qué estilo o estilos tiene que armar.

Entonces, ¿Cuál sería la forma de hacer esto? ¿Creo un objeto HTML, uno Estilo y luego los asocio? Personalmente creo que es más limpio crear un objeto HTML y que sea un método dentro de esta clase la que me cree el objeto Estilo y lo asocie.

[venkman]

Iniciado por Keysher

Pero si el objeto "Rueda" sólo es usable por "Coche", ¿qué sentido tiene usar un tercero para crear la Rueda e instanciarla al Coche? Llegamos a un punto en que no interesa que la "Rueda" se pueda usar fuera del "Coche".

Sí, sí, una Rueda siempre se usará con un Coche. Pero una determinada Rueda puede usarse con distintos Coches y un determinado Coche puede utilizar diferentes Ruedas.


Lo que estás haciendo es que si instancias un cocheX = new Coche() y un cocheY = new Coche() ambos llevan el mismo tipo de Ruedas obligatoriamente. Y eso no es bueno, ni práctico. En general lo que querrás es que cocheX = FactoríaDeCoches.crearCoche("sport") y cocheY = FactoríaDeCoches.crearCoche("confort"). Y sea la Factoría de Coches la que sabe que para la configuración "sport" debe crear un Coche, 4 RuedasAnchas y 4 LlantasDeAleación y montarlo todo y devolverte todo montado. Y que para la configuración "confort" debe crear un Coche y 4 RuedasNormales y 4 LlantasDeCuboDeLata y montarlo todo y devolverte el conjunto.

Lo importante es:
- Que el Coche es exactamente el mismo en ambos casos.
- Que un Coche puede llevar diferentes tipos de Ruedas.
- Que sólo 1 clase (FactoríaDeCoches) se encarga de montar Coches.
- Que sí, cuando pides un Coche (a la Factoría) ya te lo da con todo montado. No tienes que encargarte tú de ponerle las Ruedas.
- Que en un momento dado, si es necesario, puedes realmente crear Ruedas independientemente de Coches.
- Más importante aún, que puedes definir diversos Coches y Ruedas de forma independiente.



Lo mismo es aplicable a Páginas y Estilos.

[Keysher]

No, dos coches diferentes no tendrían las mismas ruedas. Es un método dentro de coche quien se encarga de crear la rueda en base a lo que se le especifique.

Yo creo que en éste caso me podría ahorrar la clase Factoría. Es tener una clase que lo único que haga sea crear los dos objetos y asociarlos. Puede que en determinados escenarios esté muy bien el uso de una clase así, pero no lo veo tan claro para el caso que me ocupa.

Volvamos a los Estilos. A la hora de crear la clase HTML no tengo por qué conocer los estilos que se van a aplicar. Y aunque los conozca, pueden ser dos, o tres, o los que sean.... Entonces primero creo la clase HTML y posteriormente le iré agregando las clases Estilo que necesite. Cada una de esas instancias de la clase Estilo tendrá sus caracteristicas propias, independientes.

A lo que voy es que con la clase HTML creada me puede interesar jugar con la clase Estilo, creándolos, destruyendolos, modificándolos, etc... No tiene porque venir todo armado desde un principio.

[GatorV]

Por eso el ejemplo que te propuse desde un inicio, y mira un ejemplo más en concreto, un Documento XML y un nodo XML, por si solo el Nodo no hace nada, y tiene que estar mejor atado a un documento para que realmente sirva, es por eso lo que te proponia de dejar a DocumentoXML te devuelva objetos del tipo Nodo XML al llamar a uno de sus métodos, pero dejar la flexibilidad para que si quieres iniciar un Nodo XML y LUEGO atarlo a un Documento XML lo puedas hacer.

Por eso yo dejar tu clase lo suficientemente flexibles para que puedas iniciar una Rueda y luego atarla a un Carro, o en su caso también tener un Carro que te genere objetos del tipo Rueda.

Saludos.

[venkman]

Noto cierta contradicción con todo lo que has dicho antes tú mismo que ahora digas que es preferible crear el objeto HTML y luego agregarle lo Estilos, que es lo que te han/hemos dicho desde el principio. (O eso o que no te he entendido bien)


El problema de tener dentro de Coche (o de HTML) un método que cree las Ruedas (o los Estilos) es que la clase Coche (o HTML) empieza a tener demasiados objetivos. Un principio básico es hacer que cada cosa se ocupe de un único objetivo. Con esto lo que estarías haciendo es que Coche (o HTML) tenga que preocuparse de muchas cosas: de su propio funcionamiento y de la instanciación de Estilos (o Ruedas).
Por eso mismo es preferible que Coche (o HTML) se ocupe de lo que se tiene que ocupar (su funcionamiento propio) y que nos ocupemos de la instanciación de Estilos (o Ruedas) fuera.

Imagina que además de Ruedas (Estilos) tienes también Volantes (Scripts), Asientos (Divs), Frenos (Imágenes), Pedales (Botones), etc. Si hiciste eso con Ruedas, ahora por coherencia, Coche tendría que ocuparse también de la instanciación de todos esos. Cualquier cosa que cambie en la instanciación de uno de esos elementos, afecta directamente a Coche (HTML). Entonces Coche (HTML) está fuertemente acoplado con un montón de clases. El acoplamiento es algo a evitar.

Separation of concerns.

[Keysher]

Sí, es lo que me plantearon al principio y de hecho es lo que había pensado al comprobar que no había clases privadas. Y es la opción que he mantenido, quizás no lo haya expresado bien.

De todos modos, aunque la clase Coche no cree las demás, cuando cree una Rueda, o lo que sea, tendré que tener un método en Coche para atar la Rueda al Coche, así que al final estaría haciendo lo mismo.

Vamos, que haría:

Creo Coche
Creo Rueda
Asigno Rueda a Coche

Para mi es más ordenado y simple:
Creo Coche
Llamo a un método de Coche que me crea un nuevo objeto de Rueda y la agrega al Coche.

Evito que haya Ruedas sueltas, quizás pierda flexibilidad, pero en la lógica del programa no se va a dar el caso en el que una Rueda no tenga coche, y si quiero hacer una copia de una Rueda de un coche para meterla en otro Coche, puedo llamar a un método de Coche que me devuelva esa Rueda.

Es cierto que Coche empezaría a ser una clase muy grande, encargada de hacer bastantes cosas, pero en mi caso en particular lo veo más útil así.

De hecho es parecido a lo que me planteabas antes con la Factoría de Coches, que se encarga de ensamblar todos los objetos. Pero mi factoría sería la clase HTML (o como se llame) que además de ensamblar se encargaría de crear objetos, y luego armar todo el código, por ejemplo.

Estoy de acuerdo en que hay que dar a cada clase un objetivo, pero a veces el exceso de simplicidad tampoco es bueno.

Ahora mismo, para mi la opción más útil sería la siguiente:

Clase HTML con un método que crea clase Estilo
Método en HTML para agregar un objeto de la clase Estilo a ese opjeto de la clase HTML

La segunda opción preferiría ahorrarmerla, por coherencia, no sirve de nada tener esa clase suelta, así que preferiría que no se crease ella sóla sin estar atada a la otra clase.

Además (y esto ya es duda de código), si creo objeto Estilo, ¿cómo lo instanciaria en la clase HTML? ¿Haciendo una copia suya en un array dentro de HTML? (se duplica la clase, no viable) ¿Agregando simplemente el nombre del objeto? (reconozco que no lo he investigado).

[Lord Kazuky]

Si Buenas, me gusta "jugar" con los objetos así que me voy a colar en la conversación ;)
Jaja (es molestando ) Pero creo que se le puede sacar algo de provecho a estas discusiones.

Bueno aun no tengo claro la necesidad de crear clases privadas. Sin embargo creo que deben ser una característica que se use en un contexto muy especifico y muy limitado, porque de lo contrario estamos comprometiendo la escalabilidad de nuestro sistema y desaprovechando la reutilización. (O eso creería yo )

Esto porque estamos restringiendo o condicionando el funcionamiento de los objetos. Para el ejemplo planteado del Coche y la Rueda. Digamos que en principio el sistema funciona, pero que luego necesitamos no solo manejar Coches sino digamos... Bicicletas, entonces ya no podríamos usar el objeto Rueda porque su uso esta condicionado a funcionar solo con Coches. Entonces esto nos obliga a modificar la clase Rueda, o a definir una clase distinta, o diferentes maromas que hacen que ya "no podamos reutilizar" lo que habíamos hecho previamente.

Pero vuelvo a decir, todo depende, del diseño, de lo que se quiera y pretenda implementar, de como se proyecte el sistema a futuro e infinidad de cosas más.

[Keysher]

Ya, tienes razón. por eso dije que igual el ejemplo de las ruedas y el coche no era el más adecuado en éste caso.

Y está claro que todo sistema es más escalable con clases individuales. Pero, como bien dices, depende del diseño del caso conreto. También creo que hay puntos en los que se lleva a un extremo ridiculo la creación de clases.

Para plantearlo más claramente, lo que estaba haciendo era un "sistema" que me genera una página HTML. Para ello tenía la propia clase que contendría todo el HTML (HTMLDocument), una que gestionaría los estilos (y cuando me refiero a estilos no se limita a un CSS), y otra que, dependería del estilo y serían las diferentes plantillas (templates) que tiene un estilo concreto.

Es un sistema muy simple, al final será cargar plantillas (con unas determinadas variables) y armar código HTML.

Yo creo que en un sistema así la clase HTMLDocument debería tener control sobre todo, ya que el único objetivo de esa clase es crear el Documento, no veo muy útil manejar un estilo, o una plantilla de forma independiente. La plantilla siempre tendrá que estar ligada a un estilo (de hecho es el propio estilo quien especifica las plantillas que le pertenecen). Y el estilo irá en un documento HTML.

Estoy totalmente de acuerdo en que hay que intentar hacerlo lo más escalable y flexible posible, pero en éste caso en particular eso terminaría en la clase HTMLDocument, dentro de ella se puede extender todo lo que se desee en un futuro, pero si intenta abarcar más de lo que su diseño le marcó en un principio, quizás tengamos que replantear el sistema.

Como todo, es una forma de ver las cosas. Yo no creo que esté limitando su expansión, sino el objetivo final del sistema. Lo veo como un paquete, todo junto. Ahora, si alguien cree que sólo necesita la clase Estilo, que se la lleve sólo esa y la implemente como quiera, ¿para qué va a necesitar el resto?

Aunque esa clase en concreto tiene total dependencia de la clase Template, ya que el estilo por si mismo no hace nada, sólo selecciona plantillas y le asigna variables. Es decir, prepara las plantillas, luego se las pasa a la clase HTMLDocument, que tomará esas plantillas + los diferentes ficheros que sean necesarios (css, js, etc....) y si hubiese más estilos, los cogerá también. Armará las cabeceras HTML, le meterá el body y ya tendremos una página HTML válida, para mostrarla, guardarla en un archivo .html, enviarla por correo, guardarla en una BDD o lo que queramos hacer con ella.

Y con respecto a las discusiones, si son en un tono cordial, con argumentos y aportaciones, siempre son bienvenidas. Nunca están demaś el resto de puntos de vista, se aprenderá mucho con ello.

[enriqueplace]

"Y está claro que todo sistema es más escalable con clases individuales"

Deja de jugar con los objetos, te avisé, te vas a sacar un ojo tú solo...PD: lo que acabas de decir es un disparate, la esencia de la POO es construir objetos complejos a partir de objetos más simples... ahora no me vengas a decir que justamente estas diciendo lo mismo.

[Keysher]

No, no te vengo a decir nada. No voy a intentar explicarme mejor, ni siquiera quiero que me expliques porque una cosa y otra son incompatibles. Jugaré con lo que quiera y cuando quiera. Gracias por los consejos y la ayuda, pero en éste punto dejo de discutir con gente que lo único que hace es utilizar la prepotencia para intentar demostrar que sabe de algo sin preocuparse en aportar nada útil. Prefiero vivir en la ignorancia a que me intenten abrir los ojos con esas formas. Suerte que hay otro tipo de gente que se dedica a dialogar y debatir con coherencia mostrando por qué creen que la otra persona está equivocada sin ningún aire de superioridad.

Saludos.

[CAT Shannon]

No creo que sea correcto decir que enriqueplace no aporta nada útil. Llevo tiempo leyendo este foro y los mejores mensajes y más argumentados siempre han sido los suyos.

Es normal no saber algo, a todos nos pasa. Pero si te dicen que no estás haciendo algo correctamente, te indican el camino a seguir y sigues empeñandote en seguir tu propio camino, no esperes luego recibir ayuda.

Está claro que tienes un problema de base con la POO. Empieza por ahí y luego podrás jugar todo lo que quieras con tus objetos, pero siguiendo las instrucciones del juego, que para eso están.

Por cierto, si quieres aprender POO bien explicada, muy fácil de entender, pásate por el blog de enriqueplace.

Sin acritud.

[Keysher]

No he leído el resto de mensajes de ese usuario (ni me interesa), tan sólo estábamos debatiendo el tema actual. No era ni empeño pesonal, ni cabezonería ni nada de eso. Intercambiabamos opiniones. Ya desde los primeros mensajes me dejaron claro el camino a seguir (y que me parece lógico). Después de ello hemos seguido discutiendo el por qué de crear un escenario así y si era realmente útil. Creo que he intentado exponer mis argumentos de una forma coherente, aunque es probable que no lo haya conseguido. Los demás usuarios han aportado buenas respuestas, intentando que vea por qué mi modelo no es funcional, sigo sin saber exactamente qué se ganaría en mi caso en particular con el sistema que me han propuesto sin usar clases privadas (que por otra parte no es posible en PHP).

Puede que tenga un problema de base con la POO, eso no lo niego. Pero con lo que he leído y aprendido me sigue pareciendo que en ciertas ocasiones está bien tener clases privadas que sólo se utilicen desde otras claes. Quizás una ayuda sería que me explicaseis cómo montariaís un escenario como el que propongo y qué ventajas tiene el no usar clases privadas.


Creo que el tema se ha desvirtuado mucho, era una duda sencilla. ¿Tanto choca con la filosofia de POO el querer tener una clase privada?

En cuanto a lo que éste usuario en concreto decía, no quiero empezar una discusión con él (porque me da la impresión que no sería una discusión amistosa, coherente ni fundada) ni sobre lo que dice o deja de decir. Y si digo que no aporta nada útil es porque me lo parece. El primer mensaje suyo no tenía mucho sentido, quizás fue que no entendió de lo que estábamos hablando, pero no tenía mucha lógica (en el tema en concreto) lo que exponía.

El resto del debate fue un poco redundante, dabamos vueltas sobre la misma idea, el tener o no clases privadas o internas a otra clase. Al final se acabó donde se empezó (con el primer aporte de GatorV). Y repito que me parece la forma más lógica de hacerlo en PHP. Pero viendo mi modelo, viendo las relaciones entre las clases, la finalidad de ese sistema, y lo que se quiere de él, creo que es lógico el mantener las subclases (igual me crucifican por utilizar éste termino) privadas y sin acceso desde fuera.

[Lord Kazuky]

Bueno yo sigo este hilo también para ver si alguien nos puede dar un poco más de luz sobre este tema que domino muy poco.

Lo que creo hasta ahora
Una ventaja es que tienes el total control sobre esos objetos. Puede ser asi por motivos de seguridad, una forma de ocultar y proteger la información y los procedimientos. Controlas las instancias. También de cierto modo se controla la dependencia, porque cambios de la clase privada solo afectaran a la otra donde se encuentre.

Desventaja, La clase privada no se podrá reutilizar en otros contextos distintos a lo que le ofrece la clase en la que esta contenida. La funcionalidad de los objetos que se instancien estará limitada y condicionada. Solo podrán utilizarse dentro de la otra clase.

Además estas obligando a que el funcionamiento del conjunto se siga en determinado orden, eso puede ser bueno o malo (jeje como todo ).

Con el ejemplo que pusiste el ultimo el del sistema de plantillas. Al restringir la creación y uso de algunos objetos pues simplemente hace que tu sistema solo se pueda usar de una forma y que sea la que tu definiste. Son necesarias esas restricciones ?. No estas complicando algo que debería ser fácil de utilizar? Porque no dejas que los programadores definan la manera como quieran usar ese sistema o librería, porque finalmente tu estas pensando es en otras personas ajenas a ti, si tu los restringes y los obligas algunos puede que se rebelen (jaja ) y otros puede que si te hagan caso.

Esas preguntas ya igual supongo y espero que ya te las hayas hecho. Pero bueno quedan aqui por si alguien (como yo) se las quiere hacer en otro momento.

Hay que tener un buen motivo, y buenos argumentos para hacer las cosas. Digamos a veces uno mismo se puede estar complicando, al agregar a un sistema un montón de restricciones que al final no van a aportar nada bueno, sino simplemente volver mas lento, complicado, ofuscado los procedimientos. Este espacio de discusión y debate es para que cada cual exponga sus motivos y ver si le sirven y convencen a otros más, y en momentos de duda recurrir a ellos para tomar una decisión.

Para terminar creo que el uso de clases privadas si bien es una alternativa, no se debe abusar de su uso y dejar todo un sistema completo lleno de clases privadas. Y de esa forma supongo que lo opuesto tampoco debe ser del todo bueno (sigue la discusión )

Alejándonos de la parte "filosófica" del asunto y entrando en la parte técnica, sencillamente digo que confío en el código de GatorV

[Keysher]

Estoy complemante de acuerdo con esas argumentaciones.

Aunque en el sistema que estoy diseñando yo, creo que no estoy limitando el funcionamiento, sólo "obligando" a que se cree primero una clase que controlará a las demás.

Lo que buscaba era seguir un orden "lógico". Creo que el caso más claro es la dependencia de Estilos y Plantillas. Un Estilo tiene x plantillas que están definidas en su fichero de configuración, en donde se especifica tanto el nombre de la plantilla como el fichero que contiene dicha plantilla.
En sí la clase plantilla sólo tiene estos dos datos, así como un array con nombres de variable y valores que se le pasarán a esa plantilla (por ejemplo el titulo de una página o lo que sea).

Se puede construir una plantilla si se le da el nombre de la misma así como su fichero asocieado. Pero creo que en éste caso no compensaría hacerlo desde fuera de la clase Estilo. Ya que primero se tendría que consultar esta clase, sacar los dos datos, crear una nueva plantilla con esos datos y asociarla al objeto de la clase estilo.

¿Es más flexible? Posbilemente. Pero también está más sujeto a errores o vulnerabilidades. Creo que hay que buscar un punto entre la flexibilidad, la escalabilidad y la simplicidad.

Tal como estaba ideado el sistema no tenía sentido usar las clases individualmente. Y si llega un programador y quiere hacerlo, no tiene más que coger la clase correspondiente.

De todos modos cada caso es un mundo, no se pueden afrontar todos los sistemas del mismo modo. Con las limitaciones de PHP para crear clases privadas, se podrán crear objetos de todas las clases, incluso proveeré de métodos para asociar un objeto de la clase plantilla a uno de la clase estilo (por ejemplo), pero no creo que sea útil hacer eso (por lo que he comentado más arriba).

[enriqueplace]

Creo que precisamente estábamos hablando del diseño, simplificando mucho. Sé lo que es un disparate y lo que no lo es. Y están clarísimas las relaciones entre los diferentes objetos. Precisamente por eso lanzaba la pregunta, para ver cual era la mejor manera de actuar en esos casos.

Disculpa, disculpa, disculpa! Una cosa es que venga un novato que dice que no sabe a hacer una pregunta y diga un disparate (que es entendible) y luego que vengas tú a de decir luego que tienes muy claro los conceptos de POO, luego no solo "no dejas entrever", lo haces de forma EXPLÍCITA! y si nos quedaran dudas, sigues agregando código cual más disparatado y -aún más- sigues defendiendo la loca posiblidad que tu tienes claros los conceptos!

(luego dicen que yo me enojo con facilidad, es que me lo dejan muy difícil).

En ningún momento he dejado entrever que rueda hereda de coche, simplemente lo he comentado como algo que compilaría y funcionaría, pero que no entra dentro de la lógica de programación orienta a objetos.

No sé como puedes mentir de esa forma y luego dejar tanta evidencia en tu contra, tú solo.

Sé perfectamente el tipo de relación que hay entre los objetos y mi idea era que fuesen clases privadas, pero PHP no permite esto. Así que la duda era simple: En éste lenguaje el concreto, cuál era la mejor opción para manejar estos casos. Sin más.

Me recuerdas al dicho "si no puedes con ellos, confúndelos"... justamente, si no entiendes o sabes manejar los conceptos base poco te servirá que PHP tenga o no clases "privadas".

Lo único que buscaba era una aclaración sobre cómo podría hacer una interrelación entre dos objetos, uno que dependa del otro sin poder usar clases privadas. Y a partir de ahí fui divagando sobre opciones que añadan simplicidad, seguridad y orden a esa relación.

Tengo dolor de estómago... en qué orden dijiste qué? "simplicidad, seguridad y orden"... con "rueda que extiende de Coche"? con un constructor que hace "return $this"? con un crear rueda que pregunta antes si es una rueda?

Mmmm....

No sé porque no se puede “jugar” con los objetos.

Como poder puedes, pero si tienes un mínimo de conceptos. Estoy seguro que si dejo a mis hijas pequeñas que no saben escribir que jueguen con ellos no llegarán a ningún lado productivo a pesar que pasen 12 meses... el mismo grado de productividad vas a tener sin conceptos, por lo tanto "probar por probar" es una pérdida de tiempo.

Tan sólo es un debate, en éste caso en concreto no creo que haya una “manera correcta que haya que seguir por cojones”, por muchos diagramas UML que se hagan.

Tomando en cuenta todo el código que intentas aplicar, sí, obviamente hay una manera incorrecta y es esta.

Hay un problema (imposibilidad de tener clases privadas) y se plantean soluciones. Punto. En ningún momento hemos debatido sobre cuál es la relación entre las dos clases (creo que eso quedaba bastante claro con el ejemplo, que era bastante gráfico), el fin del post era conseguir la mejor manera de implementarlo en PHP. Y al final es algo muy parecido a lo que había deducido en un principio: clases públicas independientes.

No te hacen falta las clases privadas si no sabes usar bien todo el resto de herramientas básicas del lenguaje.

La necesidad de clases privadas es tan importante como la herencia múltiple... ninguna.

En fin, puede que no me explique bien o que sea duro de cabeza…

Fuera de mi sentido del humor y mi ironía innata (los más viejos de este foro me conocerán), te lo digo muy amistosamente, creo que a cualquier con algo de experiencia que está para dar una mano a los novatos, no hay nada más molesto que un "intermedio", es decir, "alguien que no sabe, pero cree que sabe, y pero, tiene orgullo desmedido cuando lo corrigen".

No hay problema con equivocarse, pero tirar bombas de humo cuando cometes errores tan evidentes dentro de una pagoda repleta de ninjas, va a ser difícil que salgas bien parado

[enriqueplace]

Umm, vale, yo no he dicho que no se puedan crear varias ruedas, o con atributos diferentes, sino que SIEMPRE debería estar atada a un coche, quizás no sea el ejemplo más claro, pero supongamos que es un objeto que solamente tiene sentido y utilidad (o nosotros queremos que así sea) si forma parte de otro objeto concreto.

Si dices por "atada" que "dependa", y luego dices "a un coche", nuevamente estás afirmando tu desconocimiento del uso y las relaciones de los objetos.

Y tal vez por simpleza, limpieza o utilidad, nos interese que no sea ese nuevo objeto el que se agrege al anterior, sino que sea el más amplio el que seleccione los otros (en éste caso es el coche el que añade las ruedas, no es una rueda la que se ata a un coche).

Vas para adelante y para atrás, lo correcto y habitual es que el Coche agregue sus ruedas, por lo tanto lo que estás planteando, ni la versión 1 y 2 son diseños ni nuevos ni innovadores, el primero es un error conceptual y lo segundo es una de las formas más básicas de relación entre objetos.... por lo tanto no se entiende qué estás queriendo decir.

Técnicamente no está mal que se pueda crear esa clase independientemente, de hecho es muy probable que si la creas fuera del entorno especifico que hemos diseñado para ella, esa instancia del objeto no sirva para nada. Pero lo que yo quería saber es si había alguna forma más ordenada (una forma de tener clases privadas, vamos).

Sigue sin tener sentido lo que buscas: "más ordenada"? que tiene que ver una clase privada con sacar una clase del entorno específico y hacerla "privada"?

Me parece que no tienes claro qué es ni para que sirve.