¿Cómo te ayudan las clases a administrar aplicaciones grandes?

Question

Esto surgió en una conversación que estaba teniendo en línea, y se me ocurrió que no tengo idea de cómo se supone que debe funcionar esto: muchos programadores parecen simplemente dar por sentado, de hecho, es obvio que las clases son una función de lenguaje necesaria para gestionar grandes proyectos de software.

No es obvio para mí cómo hacen esto.

Mi pregunta para usted es, ¿cómo lo sabe? ¿Qué medidas objetivas existen que muestren que las clases aumentan la productividad, reutilizan el código y reducen la complejidad de la producción de un programa? ¿Qué aspectos de las clases los hacen ideales para que grandes equipos colaboren?

Y ahora, hay una pregunta que me gustaría hacer, que es algo difícil de expresar. Lo siento si me equivoco y termino confundiendo o enojando a alguien:

Objetivamente, ¿cómo sabes que el uso de clases no es la causa de que la aplicación sea grande para empezar? Es decir, es posible que se haya escrito un programa con una función equivalente, con mucho menos código, lo suficientemente pequeño como para no necesitar medidas especiales para "administrar". ¿Usa alguna otra estrategia de reutilización de código? (hay muchos para elegir, como los de los paradigmas de programación funcional o la programación orientada a aspectos).

Esa última parte es algo que Steve Yegge ha estado insinuando en su blog. Pero soy un poco escéptico con respecto a ambos lados del argumento, debido a la falta real de datos concretos de alguien, y la poca experiencia para llegar a una conclusión por mi cuenta.

¿Qué opinas?

editar: En particular, me interesa saber por qué muchos programadores piensan que la herencia de estilo prototípico no está a la altura de las aplicaciones grandes. Lamento que esta pregunta sea vaga, es producto de mi falta de comprensión sobre este tema.

edit2: parece haber cierta confusión sobre lo que quiero decir con programación funcional. (No creo que ninguna versión de VB haya sido funcional, ciertamente no versiones anteriores). Consulte el artículo de wikipedia. http://en.wikipedia.org/wiki/Functional_programming

edit3: y permítanme enfatizar que estoy buscando medidas objetivas. No opiniones subjetivas.

Answer 1

La teoría de la encapsulación proporciona una razón objetiva por la cual las clases son mejores que no tener clases.

La Organización Internacional de Normalización define la encapsulación como, 'La propiedad de que la información contenida en un objeto es accesible solo a través de interacciones en las interfaces soportadas por el objeto'.

Por lo tanto, como se puede acceder a cierta información a través de estas interfaces, parte de la información debe estar oculta e inaccesible dentro del objeto. La propiedad que exhibe dicha información se llama ocultación de información, que Parnas definió al argumentar que los módulos deberían estar diseñados para ocultar decisiones difíciles y decisiones que probablemente cambien.

Tenga en cuenta esa palabra: cambiar. La ocultación de información se refiere a eventos potenciales, como el cambio de decisiones de diseño difíciles en el futuro.

Considere una clase con dos métodos: método a () que es información oculta dentro de la clase y método b () que es público y, por lo tanto, accesible directamente por otras clases.

Hay una cierta probabilidad de que un cambio futuro al método a () requiera cambios en los métodos en otras clases. También hay una cierta probabilidad de que un cambio futuro al método b () requiera cambios en los métodos en otras clases. Sin embargo, la probabilidad de que tales cambios de ondulación ocurran para el método a (), generalmente será menor que para el método b () simplemente porque el método b () puede depender de más clases.

Esta probabilidad reducida de impactos de ondulación es un beneficio clave de la encapsulación.

Considere el número potencial máximo de dependencias de código fuente (MPE - el acrónimo es de teoría de grafos) en cualquier programa. Extrapolando de las definiciones anteriores, podemos decir que, dados dos programas que ofrecen una funcionalidad idéntica a los usuarios, el programa con el MPE más bajo está mejor encapsulado, y estadísticamente el programa más bien encapsulado será más barato de mantener y desarrollar, porque el costo del cambio de potencial máximo será menor que el cambio de potencial máximo para el sistema menos bien encapsulado & # 233; m.

Considere, además, un lenguaje con métodos justos y sin clases y, por lo tanto, sin medios para ocultar información entre sí. Digamos que nuestro programa tiene 1000 métodos. ¿Cuál es el MPE de este programa?

La teoría de encapsulación nos dice que, dado un sistema de n nodos públicos, el MPE de este sistema es n (n-1). Por lo tanto, el MPE de nuestros 1000 métodos públicos es 999,000.

Ahora separemos ese sistema en dos clases, cada una con 500 métodos. Como ahora tenemos clases, podemos elegir tener algunos métodos públicos y algunos métodos privados. Este será el caso a menos que cada método sea realmente dependiente de cualquier otro método (lo cual es poco probable). Digamos que 50 métodos en cada clase son públicos. ¿Cuál sería el MPE del sistema & # 233; m?

La teoría de encapsulación nos dice que es: n ((n / r) -1 + (r-1) p) donde r es el número de clases, y p es el número de métodos públicos por clase. Esto le daría a nuestro sistema de dos clases & # 233; m un MPE de 499,000. Por lo tanto, el costo potencial máximo de un cambio en este sistema de dos clases & # 233; m ya es sustancialmente menor que el del sistema sin encapsular & # 233; m.

Digamos que divide su sistema en 3 clases, cada una con 333 clases (bueno, una tendrá 334), y nuevamente cada una con 50 métodos públicos. ¿Qué es el MPE? Usando la ecuación anterior nuevamente, el MPE sería aproximadamente 482,000.

Si el sistema & # 233; m se divide en 4 clases de 250 métodos cada una, el MPE será de 449,000.

Si parece que aumentar el número de clases en nuestro sistema & # 233; m siempre disminuirá su MPE, pero esto no es así. La teoría de la encapsulación muestra que el número de clases en las que el sistema & # 233; m debe descomponerse para minimizar el MPE es: r = sqrt (n / p), que para nuestro sistema & # 233; m es en realidad 4. Un sistema & # 233; m con 6 clases, por ejemplo, tendría una M

Answer 2

Esta es una muy buena pregunta. Organizar el código en clases es una forma para que un equipo de desarrollo cree módulos pequeños y reutilizables. Además, estos módulos tienen interfaces expresivas y limitadas que expresan solo lo que la clase es capaz de hacer y no cómo lo hace. Cada clase es ortogonal a las demás y, por lo tanto, es altamente comprobable y modular en caso de error.

Ahora lo que acabo de describir es una escena extraña de un mundo perfecto. Pero cualquier buen desarrollador que haga trabajo de OOP debería estar luchando por algo como esto.

OOP es un reconocimiento de que nosotros, los desarrolladores, somos simplemente humanos y no podemos comprender un sistema completo a la vez. Entonces dividimos el sistema en pequeñas partes reutilizables y nos enfocamos en ellas.

Tome un número de teléfono estadounidense de diez dígitos como ejemplo. Es difícil recordar un número de diez dígitos en su cabeza, por lo que hacemos lo que los psicólogos llaman `` fragmentación ''. Esto significa que descomponemos mentalmente los números en fragmentos que podemos recordar mejor.

Entonces 1234567890 se convierte en 123-456-7890 . Afortunadamente para nosotros, las compañías telefónicas también desglosan estos números de la misma manera y asignan el significado de los fragmentos. 123 es el código de área, 456 es el prefijo y 7890 es el número de línea. Cada uno de estos fragmentos es como una clase, todos tienen responsabilidades, formatos y significados individuales.

Entonces, en conclusión, lo mejor que puedo decir es que OOP nos permite construir sistemas grandes y escalables que tienen funcionalidad centralizada y encapsulada. Nos permite no tener que ver el panorama general todo el tiempo y poder concentrarnos en hacer una cosa y hacerlo bien.

Answer 3

De ninguna manera soy un fanático de ningún paradigma de programación, pero he estado operando de manera OO por un tiempo.

Personalmente, he tenido muchos 'a-HA!' momentos en que las clases me han ayudado directamente a comprender mejor el dominio en el que estoy trabajando.

Lo más notable es que, en los casos en que existe confusión sobre por qué un sistema no funciona correctamente, o lo que se supone que debe hacer un sistema, las clases a menudo me han obligado a pensar en lo que debería hacer esta parte discreta del conjunto, y con mayor frecuencia que no llevar a refactorizar las clases / métodos disponibles.

En resumen, la encapsulación realmente me hace una persona más feliz. ;)

Espero que eso ayude.

Answer 4

Creo que las clases pueden ayudar, porque corresponden al concepto cognitivo muy general de categorización y, por lo tanto, puede ayudar a describir aplicaciones grandes de forma natural.

Answer 5

Prefiero las clases para poder dividir un gran problema en piezas manejables que se puedan probar como unidades individuales. En mi humilde opinión, la reutilización de código está sobrevalorada: apenas he visto que suceda donde trabajo. Para mí, lo que más obtengo de un buen OO es una buena capacidad de prueba.

El otro extremo es usar un grupo de variables globales y bloquear toda su lógica en public static void main (o Page_Load en ASP.NET) y llamar a métodos estáticos que llaman a otros métodos estáticos y así sucesivamente ... (Me mareé al final de la última oración).

Lo único que rompería mi mentalidad OO es si estuviera trabajando con un lenguaje funcional puro, que es algo en lo que no he pensado desde la universidad, lamentablemente.

Answer 6

Probablemente sea posible sobre-diseñar un problema simple haciéndolo innecesariamente complejo (OO hasta el final). Sin embargo, para cualquier problema lo suficientemente grande, no creo que sea probable que el paradigma OO sea lo que causó que fuera grande en primer lugar. Tomemos un sistema operativo, por ejemplo, es difícil imaginar que sea fácil de mantener (en cuanto a código) si no está escrito de forma orientada a objetos.

Answer 7

Si tienes un montón de "desnudo" funciones en una aplicación grande, es difícil hacer cambios a esas funciones.

• es más difícil ver quién está usando la función (" si cambio esto, ¿a quién afecta? ")
• difícil hacer cambios a las funciones sin romper el código de otras personas.

Si ajusta las funciones en clases, ayuda a aislar el alcance del código. No es una bala mágica, pero ayuda.

Answer 8

Dos cosas.

La primera es la idea de que una clase es una entidad de dominio opaca . Cuando se hace correctamente , los programas orientados a objetos introducen una capa de abstracción: en la siguiente capa más alta, reúne los objetos para hacer lo que desea, en lugar de tratar con detalles. No necesita saber cómo funcionan los objetos y las clases: solo lo que hacen. Este es un tipo de ocultación de información y reduce la complejidad que un equipo tiene que tener en mente mientras trabaja.

El segundo es que la programación OO permite un tipo de reutilización de código: puede definir clases que anulen ciertos comportamientos en otras clases (herencia), o clases cuyas instancias incluyen instancias de otras clases, usándolas para lograr sus objetivos (encapsulación y composición).

Correctamente usando técnicas OO puede reducir la cantidad de código que necesita administrar y reducir la cantidad de cosas que debe tener en cuenta mientras trabaja o mantiene el sistema. En la práctica, este enfoque no siempre funciona.

Answer 9

  

Objetivamente, ¿cómo sabes que el   el uso de clases no es la causa de la   ¿la aplicación es grande para empezar?

Tome cualquier programa / aplicación de gran tamaño que no se haya escrito en un lenguaje OO (por ejemplo, C, COBOL, incluso SQL simple) y debería poder presenciar que el tamaño del código no se atribuye directamente al paradigma del lenguaje. Para cada número de componentes C # o Java bien diseñados, altamente refinados y reutilizables, también hay un número igual de DLL de C bien reutilizados, altamente refinados y reutilizables. Por el contrario, hay un número igual de código horrible e hinchado.

El punto es que los buenos programadores pueden refinar los diseños de sus sistemas independientemente del idioma / plataforma.

Con respecto a OOP, al menos para mí, trae a la mesa un "potencial". - una vista del mundo de programación un poco más cerca de nuestro mundo real. Todos conocemos nuestro mundo y este universo de materia está lleno de objetos compuestos de objetos más pequeños . Siga haciendo zoom desde los sistemas estelares galácticos hasta la molécula, el átomo y las partículas subatómicas, es realmente sorprendente la forma en que se forman materias muy diferentes de las mismas pequeñas partículas combinadas en varios patrones. Mire nuestra propia biología, incluso, es alucinante a veces pensar que el 60% de nuestros cuerpos en realidad es solo agua cuando se descompone al máximo. Sin embargo, observe todos los diversos sistemas y órganos en el lugar que arden con química para mantenernos en funcionamiento y vivos.

Cuando aprendemos a comprender la simplicidad (oh realmente ... ja, ja) de los bloques de construcción que forman los sistemas del mundo real que vemos en la naturaleza cotidiana, entonces deberíamos ser capaces de comprender que diseñar y construir extremadamente Los sistemas complicados o sofisticados deberían comenzar con componentes pequeños que hacen muy poco por sí mismos. Y al combinarlos y combinarlos lentamente en componentes cada vez más grandes podemos obtener más funcionalidad y capacidad. Hasta que alcancemos el sistema deseado que imaginamos.

El uso (apropiado) de clases es descomponer un sistema en su máxima expresión. Como sea posible. Para que pueda mirar algo a la vez y un nivel particular de abstracción y no sentirse abrumado por los propósitos y la lógica que no se ocupa de su área actual de preocupación. Siempre que diseñe un sistema, piense en su propia anatomía; piensa cómo diseñarías el cuerpo humano. Siempre que diseñe un sistema, piense en comenzar una nueva empresa ; cuáles son las divisiones principales, los departamentos que necesita para operar el negocio. ¿Quiénes son el tipo de personal requerido para dirigir esos departamentos? Los diversos equipos que necesitan usar e interactuar para realizar sus trabajos. ¿Cómo desglosa las operaciones comerciales en su máxima expresión para permitirte entenderlo mejor?

Cuando comprenda el principio básico de que algún objeto está compuesto simplemente por objetos más pequeños, estará en camino de crear células o moléculas altamente reutilizables.

Answer 10

Las clases me han sido de gran ayuda en el aspecto en el que puedo trabajar en un aspecto pequeño de un proyecto complejo a la vez. Ser capaz de desacoplar un aspecto del código del gran proyecto es muy útil para que no se sienta abrumado. Al final, la cohesión entre esas clases puede darle una visión general rápida de cómo funciona un programa sin tener que lidiar con las entrañas.

En lo que respecta a la capacidad de mantenimiento, es mucho más fácil mirar un diagrama de clase UML y descubrir cómo se presenta todo que mirar una lista de funciones, en mi opinión.

Answer 11

Creo que al decir clases, deberías decir objetos. Las clases no son más que un lugar donde puedes colocar tus objetos. El paradigma OOP es tan exitoso por una razón. Una vez que tengas ese '¡ajá!' en el momento en que crees que finalmente has entendido el concepto de OOP, puedes comenzar a programar de una manera mucho más organizada.

He programado en Visual Basic 3 durante mucho tiempo, por lo que tenía mucha experiencia con la programación funcional, y luego ir a VB5 y descubrir objetos fue un gran alivio porque podía relacionar entidades del mundo real con mi código, y ayudó mucho.

De eso se trata, recrear entidades del mundo real en su código. Facilita la lectura y el trabajo porque puede recoger algo y hacer cosas con él, o hacer cosas con él.