¿Por qué es bueno dividir un programa en varias clases? [cerrado]

Todavía soy un estudiante en la escuela secundaria (ingresando al décimo grado), y todavía tengo que tomar un curso de computación en la escuela. Todo lo que he hecho hasta ahora es a través de libros. Esos libros me han enseñado conceptos como la herencia, pero ¿cómo ayuda dividir un programa en varias clases? Los libros nunca me dijeron.

Estoy preguntando esto principalmente por un proyecto reciente. Es un videojuego arcade, algo así como un juego Flash como han dicho algunas personas (aunque no tengo idea de qué es un juego Flash ). La cosa es que es solo una clase. Funciona perfectamente bien (un pequeño retraso ocasional sin embargo) con solo una clase. Entonces, solo estoy preguntando cómo dividirlo en múltiples clases lo ayudaría.

Este proyecto estaba en Java y soy la única persona que trabaja en él, para el registro.

La respuesta más simple es que si pones todo en una clase, debes preocuparte por todo a la vez cuando escribes un código nuevo. Esto puede funcionar para proyectos pequeños, pero para aplicaciones enormes (estamos hablando de cientos de miles de líneas), esto rápidamente se vuelve casi imposible.

Para resolver este problema, divide las funciones en sus propias clases y encapsula toda la lógica. Luego, cuando desee trabajar en la clase, no necesita pensar en qué más está sucediendo en el código. Puedes concentrarte en ese pequeño fragmento de código. Esto es invaluable para trabajar de manera eficiente, sin embargo, es difícil de apreciar sin trabajar en aplicaciones que son enormes.

Por supuesto, hay innumerables otros beneficios al dividir su código en partes más pequeñas: el código es más fácil de mantener, más comprobable, más reutilizable, etc., pero para mí el mayor beneficio es que hace que los programas masivos sean manejables al reducir la cantidad de código que usted Necesito pensar al mismo tiempo.

Bueno, la respuesta más simple podría ser "Ayuda a organizar las cosas". Por lo menos, puede compararlo con las secciones de un cuaderno: es simplemente más simple si tiene "todas las cosas relacionadas con la interfaz de usuario" aquí y "todas las cosas relacionadas con el juego" allá.

La respuesta más sofisticada es que dividir el trabajo no solo es conveniente, sino que es muy importante para gestionar la complejidad (y "gestionar la complejidad" es más o menos el nombre del juego cuando se trata de programación). Las clases u otros tipos de módulos le permiten "separar preocupaciones". No solo sabe dónde buscar "cosas relacionadas con la interfaz de usuario", sino que puede estar seguro de que si desea hacer un cambio en la interfaz de usuario, puede hacerlo en un solo lugar, y no tiene que hacerlo preocuparse "ahora, ¿es ese el único lugar donde configuro mi fuente en Comic Sans?". Y puede hacer un cambio y saber que el efecto de ese cambio es solo para cualquier alcance (pequeño) que sea apropiado. Si todo está en una sola clase o módulo, esencialmente todo es global,

En el caso específico de las clases como un tipo de módulo de software, también hay mucho comportamiento asociado con una clase, y la mayoría de los desarrolladores en el paradigma orientado a objetos encuentran muy útil tener nombres significativos asociados con las clases que agrupan Funciona juntos. Entonces, probablemente no UItendrías una clase, probablemente tendrías una Buttonclase. Hay todo un conjunto de conocimientos y técnicas asociados con el diseño de clases orientado a objetos y es la forma más común de organizar grandes sistemas en la programación convencional.

¡Esta es una buena pregunta! Simple y bien preguntado. Bueno ... la respuesta no es tan fácil de entender para un estudiante que está estudiando ciencias de la computación y probablemente no sabe en profundidad OO y probablemente no tiene experiencia trabajando.

Entonces, puedo responder describiendo un escenario y haciéndote imaginar cómo es mejor el software multiclase que el software monolítico (hecho por una sola clase):

• Legibilidad : es mucho más difícil navegar y escribir código dentro de un archivo con 10000 líneas que varios archivos pequeños y organizados.
• Reutilización : si escribe una sola clase, puede deslizarse en la duplicación de código . Esto significa más líneas de código y probablemente más errores (!)
• Testabilidad : ¿Qué hay de probar una sola funcionalidad? Si aísla una funcionalidad lógica en una clase, su vida será más fácil.
• Mantenimiento del código : puede corregir un error o mejorar la funcionalidad con múltiples clases en un solo lugar: las pequeñas clases agradables.
• Estructura del proyecto : oooooh, ¿te imaginas lo feo que será un proyecto con un solo archivo fuente?

Aquí hay muchas buenas respuestas, y definitivamente estoy de acuerdo con ellas, pero siento que hay algo más que vale la pena mencionar.

En este momento, como has dicho, estás trabajando solo en tu proyecto. Sin embargo, en el futuro, habrá momentos en los que necesitará trabajar en equipo. Durante esos momentos, dividirá el trabajo (presumiblemente, el proyecto será bastante grande). Como resultado, hay algunas opciones diferentes (supongo que realmente dos principales ). Puede tener múltiples copias de un archivo, y trabajar en "partes" separadas del archivo y luego "combinarlas" con copiar y pegar más tarde y luego modificar para que sus partes puedan trabajar juntas, o puede dividir esas "piezas" bastante fácilmente en diferentes clases y discuta cómo va a escribir esas clases, y use ese conocimiento para comenzar.

Aún será necesario trabajar para integrar todas las piezas separadas, pero será mucho más fácil de mantener. Porque el archivo x contiene el código y y ese es el código que sabes que necesitas modificar. Esto entra en la cuestión de la organización de la que hablan la mayoría de las otras respuestas.

Tener un programa en la cabeza. Enlace de Giorgio

En efecto, lo que ha hecho es reinventar la programación de procedimientos. Eso sí, es muy posible escribir software de esa manera y al compilador probablemente no le importe. Durante muchos años, así se hicieron las cosas hasta que las computadoras se hicieron más rápidas y las herramientas mejoraron.

Dicho esto, si divide su código en diferentes unidades lógicas (clases, módulos, etc.) es que puede tener muchos fragmentos de código cortos y fáciles de entender. eso se puede mantener más tarde. Muchos de mis módulos tienen menos de 20 líneas de código. Sé que todo el código sobre un tema determinado está en un lugar específico. También significa que si alguien más se une al proyecto, será mucho más fácil encontrar cosas.

Como dijo Gerald Sussman, nuestros programas deben escribirse primero para que las personas puedan leerlo y segundo para que la computadora pueda ejecutarlo. (Y si aún no ha leído "Estructura e interpretación de los programas informáticos, debería hacerlo")

Uno usa múltiples clases porque a medida que te adentras en cosas más grandes encontrarás que simplemente no hay forma de que puedas hacer un seguimiento de todo cuando se trata de una gran pila de código.

Simplemente tienes que dividir y conquistar para manejarlo.

La programación orientada a objetos es la mejor idea que he visto en programación. Pero no es lo mejor en todos los casos, necesita un poco de experiencia en programación para ver el punto, y muchas personas afirman que hacen POO cuando no lo hacen.

Si puede buscar "programación estructurada", probablemente encontrará algo más útil de inmediato. (Asegúrese de leer sobre programación estructurada antigua . Los términos antiguos a menudo adquieren significados nuevos y más elegantes, y aún no necesita nada sofisticado). Este es un concepto bastante simple sobre dividir su programa en subrutinas, que es mucho más fácil que descomponiéndolo en objetos. La idea es que su programa principal es una rutina corta que llama a subrutinas ("métodos" en Java) para hacer el trabajo. Cada subrutina solo sabe lo que le dicen sus parámetros. (Uno de esos parámetros podría ser un nombre de archivo, por lo que puede hacer trampa un poco.) Entonces, al mirar el encabezado de una subrutina / método, se obtiene una idea rápida de lo que hace, hace casi de un vistazo.

Luego, todas las subrutinas se desglosan de manera similar hasta que unas pocas líneas de código sin ninguna llamada a método hagan el trabajo. Un programa principal que llama a algunos métodos, cada uno de los cuales llama a algunos métodos, cada uno de los cuales ... Hasta pequeños métodos simples que hacen el trabajo. De esta manera, puede ver cualquier parte de un programa muy grande (o pequeño) y comprender rápidamente lo que hace.

Java está diseñado específicamente para personas que escriben código orientado a objetos. Pero incluso el programa OO más intenso utiliza una programación estructurada, y siempre puedes subvertir cualquier lenguaje. (Hice OO en el plano C.) Para que pueda hacer SP, o cualquier otra cosa, en Java. Olvídese de las clases y concéntrese en los métodos grandes que se pueden dividir en pequeños y manejables. Debo agregar que SP ayuda mucho al permitirle reutilizar su código, y también con el principio DRY (google it, pero significa "No se repita").

Espero haber explicado por qué y cómo dividir su código en varias partes sin incluir "clases". Son una gran idea y son ideales para juegos y Java es un gran lenguaje para OOP. Pero es mejor saber por qué estás haciendo lo que estás haciendo. Deje la POO sola hasta que comience a tener sentido para usted.

Uno de los beneficios es la reutilización. Un programa es básicamente un conjunto de instrucciones agrupadas. Encontrará que algunas de esas instrucciones también son adecuadas para otros programas.

Digamos que haces un juego de saltos. Más adelante, cuando decidas hacer un juego de cañones, encontrarás que el cálculo físico que usaste en el juego de saltos es útil aquí.

Entonces, en lugar de escribirlo nuevamente, o peor copiarlo y pegarlo en el nuevo programa, lo conviertes en una clase. Entonces, la próxima vez que crees otro juego donde la mecánica del juego requiera física, puedes reutilizarlo. Por supuesto, esto está demasiado simplificado, pero espero que tenga sentido.

En primer lugar, tenga en cuenta que soy C ++ y Python, no Java, por lo que algo de esto puede no aplicarse del todo. Corríjame si hago algunas suposiciones incorrectas sobre cómo funcionan las clases en Java.

Las clases son principalmente útiles cuando se instancian. Una clase de la cual no se crean instancias es realmente solo un espacio de nombres glorificado. Si usa todas sus clases de esta manera, los beneficios de mover cosas de un espacio de nombres a otro pueden parecer insignificantes; a lo sumo, ganará al tener algunos datos privados en cada uno y, por lo tanto, encapsulará un poco las cosas.

Sin embargo, aquí no es donde brillan las clases. Considere la Stringclase: podría tener las mismas características usando charmatrices y algunas funciones estáticas. En este punto, las funciones le brindan un poco más de seguridad y azúcar sintáctica. Puedes escribir en string.length()lugar de length(char_array); eso no es un gran problema, pero a muchas personas todavía les gusta. Además, sabe que si alguien le dio un String, fue creado con el Stringconstructor y que debe funcionar con la lengthfunción: si la versión de matriz no puede manejar algún carácter, entonces no tiene forma de evitar que lo coloque allí .

Sin embargo, todavía no es así. El punto clave es que las clases agrupan datos y funciones que operan en él y abstraen ambos. Cuando tiene un método void f(Builder b)que sabe que obtendrá Builder, y puede esperar que respalde cierto comportamiento. Sin embargo, no sabe nada de datos o de las funciones que se están ejecutando; de hecho, las definiciones para ambos pueden no escribirse aún mientras escribe y compila f.

El primer punto a entender es, por lo tanto, que las clases hacen que sea conveniente pasar datos mientras se aseguran de que no se rompan. El segundo punto es que tanto qué datos como qué función (implementaciones) tiene un objeto es algo sobre el objeto, no algo que simplemente se puede distinguir de su tipo.

Toda la idea se basa en una regla general llamada divide y vencerás .
Este paradigma se puede usar en casi todas partes; divide un problema en problemas más pequeños y luego resuelve estos problemas pequeños, simples y conocidos.
Dividir su programa en clases es uno de los tipos de división que comenzaron a ser comunes en la última década. En este paradigma de programación modelamos nuestro problema mediante algunos objetos e intentamos resolver el problema enviando mensajes entre estos objetos.
Algunas personas podrían decir que este enfoque es más fácil de comprender, expandir y depurar.
Aunque algunas personas no están de acuerdo :)

No se trata de dividir un programa en clases, sino de cómo modela su aplicación, es decir, cómo visualiza partes de su aplicación. Dividir cosas es solo un mecanismo que utilizamos para comprender mejor las cosas complejas. No es solo con la programación. Imagine una placa de circuito con muchos cables enredados entre sí, formando una estructura compleja con cada cable conectado en algún lugar (código de espagueti). Tendrás que seguir cada cable hasta su final para descubrir las conexiones. Por el contrario, imagine cables agrupados y codificados por colores según su función. Se vuelve mucho más fácil arreglar las cosas.

La idea es que no comiences con un programa largo y luego lo dividas en clases. Pero primero modela su aplicación en términos de objetos / clases y luego los conecta para crear aplicaciones.