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

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

Para resolver este problema, divide las piezas de funcionalidad en sus propias clases y encapsula toda la lógica. Entonces, cuando quiera trabajar en la clase, no necesita pensar en qué más está sucediendo en el código. Solo puedes enfocarte en ese pequeño trozo 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 muchos otros beneficios por 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 del código en el que debes pensar al mismo tiempo.

Bueno, la respuesta más simple podría ser "Ayuda a organizar las cosas". Si no es nada más, puede compararlo con las secciones de un cuaderno. Es mucho más simple si tiene "todas las cosas relacionadas con la interfaz de usuario" de aquí y "todas las cosas relacionadas con el juego" de 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 prácticamente el nombre del juego cuando se trata de la programación). Las clases, u otros tipos de módulos, le permiten "separar las preocupaciones". No solo sabe dónde buscar "cosas relacionadas con la interfaz de usuario", sino que puede estar seguro de que si desea realizar 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 el alcance (pequeño) que sea apropiado. Si todo está en una sola clase o módulo, esencialmente todo es global, y eso hace que las cosas sean muy difíciles de razonar.

En el caso específico de las clases como un tipo de módulo de software, también hay muchos comportamientos asociados 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. Ese grupo relaciona funciones juntas. Entonces, probablemente no tengas una clase UI , probablemente tengas una clase Button . Existe todo un conjunto de conocimientos y técnicas asociadas con el diseño de clase orientado a objetos y es la forma más común de organizar grandes sistemas en la programación general.

Esta es una buena pregunta! Sencillo 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 sepa en profundidad OO y probablemente no tenga experiencia en la experiencia.

Por lo tanto, puedo responder describiendo un escenario y haciéndote imaginar cómo un software de múltiples clases es mejor que un software monolítico (creado por una sola clase):

• Legibilidad : es mucho más difícil explorar y escribir código dentro de un archivo con 10000 líneas que varios archivos pequeños y organizados.
• Reutilización : si escribes una sola clase, puedes deslizarte en duplicación de código . Esto significa más líneas de código y probablemente más errores (!)
• Probabilidad : ¿qué hay de probar una única funcionalidad? Si tu aísle una funcionalidad lógica en una clase, su vida será más fácil.
• Capacidad de mantenimiento de código : puede corregir un error o mejorar la funcionalidad con varias clases en un solo lugar: las clases pequeñas y agradables.
• Estructura del proyecto : oooooh, ¿te imaginas lo fea que es una ¿Aparecerá el proyecto con un solo archivo fuente?

Hay muchas respuestas buenas aquí, y definitivamente estoy de acuerdo con ellas, pero creo 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á ocasiones en las que tendrá que trabajar en un entorno de equipo. Durante esos momentos, estará dividiendo el trabajo (probablemente el proyecto será bastante grande). Como resultado, hay algunas opciones diferentes (supongo que en realidad son dos major ). Puede tener varias copias de un archivo y trabajar en "partes" separadas del archivo y luego "combinarlas" con copiar y pegar más tarde y luego modificarlas para que sus partes puedan trabajar juntas, o puede dividir esas "piezas" bastante fácilmente en diferentes clases y discuta cómo escribirá esas clases y utilizará ese conocimiento para comenzar.

Todavía será necesario trabajar para integrar todas las piezas por separado, pero será mucho más fácil de mantener. Debido a que el archivo x contiene el código y, ese es el código que sabe que necesita modificar. Esto se refiere a la cuestión de la organización de la que habla la mayoría de las otras respuestas.

Mantener un programa en la cabeza. Enlace desde Giorgio

En efecto, lo que ha hecho es reinventar la programación de procedimientos. Tenga en cuenta que es bastante posible escribir software de esa manera y al compilador probablemente no le importará. Durante muchos años, así se hicieron las cosas hasta que las computadoras se aceleraron y las herramientas mejoraron.

Dicho esto, si divide su código en diferentes unidades lógicas (Clases, módulos, etc.) es que puede tener un montón de códigos cortos y fáciles de entender. Eso puede mantenerse 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 dado 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 Gerald Sussman dijo que nuestros programas deberían escribirse primero para que la gente pueda leerlo y luego para que la computadora pueda ejecutarlo. (Y si tiene que leer "Estructura e interpretación de programas de computadora, debería hacerlo")     

Uno usa varias clases porque a medida que te metes en cosas más grandes encontrarás que simplemente no hay manera de poder hacer un seguimiento de todo cuando es 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 la programación. Pero no es lo mejor en todos los casos, se necesita un poco de experiencia en programación para comprenderlo, y muchas personas afirman hacer POO cuando no lo están.

Si puedes buscar "programación estructurada", probablemente encuentres algo más útil de inmediato. (Asegúrese de leer acerca de la programación estructurada de old . Los términos antiguos a menudo tienen significados nuevos y más sofisticados, y no necesita nada sofisticado todavía). Este es un concepto bastante simple acerca de dividir su programa en subrutinas. , que es mucho más fácil que descomponerlo 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). Por lo tanto, mirar el encabezado de una subrutina / método le da una idea rápida de lo que hace, y saber cuáles son los métodos del programa principal. ve lo que it hace casi de un vistazo.

Luego, todas las subrutinas se desglosan de manera similar hasta que unas pocas líneas de código sin ningún método de llamada harán 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 ... Abajo, a pequeños métodos simples que hacen el trabajo. De esta manera, puedes mirar cualquier parte de un programa muy grande (o un programa pequeño) y entender rápidamente lo que hace.

Java está diseñado específicamente para personas que están escribiendo código orientado a objetos. Pero incluso el programa OO más intenso usa alguna programación estructurada, y siempre puedes subvertir cualquier lenguaje. (Hice OO en C simple.) Así que puedes hacer SP, o cualquier otra cosa, en Java. Olvídese de las clases y concéntrese en los grandes métodos 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 (busque en Google, pero significa "No se repita").

Esperemos que haya explicado por qué y cómo dividir su código en varias partes sin traer "clases". Son una gran idea y son lo ideal para los juegos, y Java es un gran lenguaje para OOP. Pero es mejor saber por qué estás haciendo lo que estás haciendo. Deje OOP solo 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 decida hacer un juego de cañones, encontrará que el cálculo de física que usó en el juego de saltos es útil aquí.

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

En primer lugar, tenga en cuenta que soy un C ++ y Python, no Java, por lo que es posible que parte de esto no se aplique tan completamente. Corríjame si hago algunas suposiciones incorrectas sobre cómo funcionan las clases en Java.

Las clases son principalmente útiles cuando se crean instancias. Una clase de la que no se crean instancias es en realidad solo un espacio de nombres glorificado. Si usa todas sus clases de esta manera, entonces, de hecho, los beneficios de mover cosas del espacio de nombres al espacio de nombres pueden parecer insignificantes: a lo sumo, ganará al tener algunos datos privados en cada una y, por lo tanto, encapsular las cosas un poco. >

Sin embargo, aquí no es donde brillan las clases. Considere la clase String : podría tener todas las mismas características usando los arreglos char y algunas funciones estáticas. En este punto, las funciones le brindan un poco de seguridad adicional y azúcar sintáctica. Puedes escribir string.length() en 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 , se creó con el constructor String y que debe funcionar con la función length - si la versión de matriz no puede manejar algún carácter, entonces no tiene forma de evitar que lo pongas ahí.

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

El primer punto que hay que entender es que las clases hacen que sea conveniente pasar los datos mientras se asegura de que no están rotos. El segundo punto es que tanto los datos como la función (implementaciones) que tiene un objeto es algo sobre el objeto, no algo que se pueda distinguir por su tipo.

Toda la idea se basa en una regla general denominada divide y vencerás .
Este paradigma puede ser usado 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 comenzó a hacerse común en la última década. En este paradigma de programación, modelamos nuestro problema con algunos objetos e intentamos resolverlo mediante el envío de 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 modelas tu aplicación, es decir, cómo visualizas partes de tu aplicación. Dividir las cosas es solo un mecanismo que utilizamos para entender 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 averiguar 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 modelas tu aplicación en términos de objetos / clases y luego las conectas para crear aplicaciones.