A ver... estuve siguiendo este thread cada vez que se publicaba una nueva respuesta, y hasta ahora he visto ciertas formas de opinar y actitudes con las que disiento, y me gustaría expresar por qué:
Cita: si programamos OO...se crean clases con un conjunto d metodos y atributos...a la hora de crear un objeto se carga todos esos metodos en memoria...eso no es problema hasta q nuestra aplicacion sea visitada por miles d usuarios en un mismo minuto....nuestra aplicacion se tornaria lenta...
por eso, mi filosofia en la web...es hacer todo mas rapido y para mi la programacion estructura es lo conveniente...ya q solo usas las lineas d codigo q necesitas...
Aqui tenemos un acierto y un error, al menos a mi manera de verlo. Es cierto, que al instanciar un objeto, se cargan sus datos y el signature de sus métodos, pero esto no debería ser problema, si programamos pensando en objetos, y nos damos cuenta que un objeto no debería tener más de 10 métodos para actuar sobre sus datos. La prog. estructurada no es precisamente sinónimo de eficiencia, todo por el contrario. Se ha demostrado que aplicaciones POO bien diseñadas, se ejecutan utilizando menos recursos que aplicaciones estruturadas sin pensamiento en performance.
Cita: Personalmente me encanta usar Smarty para separa presentación de procesamiento, puede llegar a parecer muy pesado, pero una vez que la aplicación es estable se activa el cache a discreción y se acelera muchisimo más.
Disculpen que disienta, pero Smarty NO SIRVE. Implementaron todo un sub-lenguaje ENCIMA del PHP, para hacer cosas que PHP ya hace, sin necesidad. Por eso de "separar" el código de presentación del código de negocio, no se dan cuenta que el "Lenguaje Smarty" es ... código?!? Entonces, que tenía de malo el código PHP de antemano?
Cita: La mejor forma de darse cuenta es con práctica, yo tengo un Framework con muchos objetos hay algunas clases que tienen más de 2000 líneas de código, ¿qué veneficio tengo? Hago un formulario con un listado y sus respectivas validaciones de datos y grabación en tan sólo 10 minutos...
Disculpa, pero CUALQUIER clase con 2000 líneas de código, es típicamente una clase mal diseñada, sobrecargada. Lo que se llama una "clase Dios", que tiene demasiadas responsabilidades y víctima segura de un buen proceso de refactorización. Cómo dicen más arriba, 1000 líneas de código también siento que son "muchas líneas" y realmente, ni me dedico a ver el código de una clase asi... busco otra o la hago de cero. Yo trato de no sobrepasarme en más de 300 o 400 líneas por clase. Si luego metemos 4 o 5 clases en un solo archivo, eso es otra cosa.
Cita: Mis clases cumplen con los requerimientos de mis sistemas.
Algunas de ellas están destinadas a cumplir sólo una función, no puedo hacer 8 clases que interactúen totalmente entre sí y que cumplan la misma funcionalidad en conjunto.
No dudo que tus clases cumplan los requerimientos de tus sistemas, pero eso de que no puedes hacer más clases de una clase de 2000 líneas, no lo creo. Y si crees que exagero, hagamos algún tipo de ejercicio, postea tu clase gigante y veamos si es o no posible refactorizarla en clases más concentradas y reutilizables.
Cita: Sí, es un buen punto de vista, yo también estoy seguro que podría dividr mi clase en otras más pequeñas como en la validación de datos de ASP.NET, el problema es que estas clases deberían interactuar muchísimo entre sí, fue por ese motivo que lo hice todo en sólo una clase que por cierto llevo mucho tiempo creando esa clase y desde la primer línea de código el objeto fue cambiando mucho....
Solo me hago una pregunta...
¿Qué problema hay que las clases tengan que ser más e interactuar entre ellas? Eso no es precisamente, por lo que tenemos la programación orientada a objetos? Sino, lo que tenemos es funciones encapsuladas dentro de clases, pero cero diseño orientado a objetos.
Bueno, básicamente esta me parece una buena discusión para que entre todos podamos desmistificar un poco el "monstruo" de la Programación Orientda a Objetos, que no es más que una evolución normal y necesaria para cualquier programador.
Saludos y nos seguimos leyendo.