Por que é bom dividir um programa em várias classes? [fechadas]

A resposta mais simples é que, se você colocar tudo em uma classe, terá que se preocupar com tudo de uma vez quando estiver escrevendo um novo código. Isso pode funcionar para pequenos projetos, mas para grandes aplicações (estamos falando de centenas de milhares de linhas), isso rapidamente se torna quase impossível.

Para resolver esse problema, você divide partes da funcionalidade em suas próprias classes e encapsula toda a lógica. Então, quando você quer trabalhar na aula, não precisa pensar no que mais está acontecendo no código. Você pode se concentrar apenas nesse pequeno pedaço de código. Isso é inestimável para trabalhar de forma eficiente, no entanto, é difícil apreciar sem trabalhar em aplicativos enormes.

Bem, a resposta mais simples pode ser "Ajuda a organizar as coisas". Se nada mais, você pode compará-lo com seções em um notebook - é simplesmente mais simples se você tem "todas as coisas relacionadas à interface do usuário" aqui e "todas as coisas relacionadas ao jogo" por lá.

No caso específico de classes como um tipo de módulo de software, há também muito comportamento associado a uma classe, e a maioria dos desenvolvedores no paradigma orientado a objetos acha muito útil ter nomes significativos associados às classes esse grupo relaciona funções em conjunto. Então você provavelmente não teria uma classe UI , você provavelmente teria uma classe Button . Há todo um conjunto de conhecimentos e técnicas associados ao design de classes orientadas a objetos e é a maneira mais comum de organizar grandes sistemas na programação principal.

Esta é uma boa pergunta! Simples e bem perguntado. Bem ... a resposta não é tão fácil de entender para um estudante que está estudando ciência da computação e provavelmente não sabe em profundidade OO e provavelmente não tem experiência em trabalhar.

Então, eu posso responder descrevendo um cenário e fazendo você imaginar como o software multi-classes é melhor do que o software monolítico (feito por uma única classe):

• Legibilidade : é muito mais difícil navegar e escrever código dentro de um arquivo com 10000 linhas do que vários arquivos pequenos e organizados.
• Reutilização : se você escrever uma única aula, poderá eliminar a duplicação de código . Isso significa mais linhas de código e provavelmente mais bugs (!)
• Testabilidade : Que tal testar uma única funcionalidade? Se vocês isolar uma funcionalidade lógica em uma classe, sua vida será mais fácil.
• Mantenedor de código : você pode corrigir um bug ou melhorar a funcionalidade com classes multiplas em um único lugar: as boas pequenas classes.
• Estrutura do projeto : oooooh você pode imaginar o quão feia projeto com apenas um arquivo de origem aparecerá?

Há muitas boas respostas aqui, e eu definitivamente concordo com elas, mas sinto que há algo mais que vale a pena mencionar.

No momento, como você disse, você está trabalhando sozinho em seu projeto. No entanto, no futuro, haverá momentos em que você precisará trabalhar em um ambiente de equipe. Durante esses momentos, você estará dividindo o trabalho (presumivelmente, o projeto será bastante grande). Como resultado, existem algumas opções diferentes (acho que são realmente duas principais ). Você pode ter várias cópias de um arquivo e trabalhar em "partes" separadas do arquivo e, em seguida, "combiná-las" com copiar e colar depois e, em seguida, modificá-las para que suas partes funcionem juntas ou dividir essas "partes" facilmente em diferentes classes e discutir como você estará escrevendo essas classes, e usar esse conhecimento para seguir em frente.

Segurando um programa na cabeça de alguém. Link de Giorgio

Com efeito, o que você fez é reinventar a programação procedural. Lembre-se que é bem possível escrever software dessa maneira e o compilador provavelmente não se importará. Por muitos anos, foi assim que as coisas foram feitas até que os computadores ficaram mais rápidos e as ferramentas melhoraram.

Dito isto, se você dividir seu código em diferentes unidades lógicas (Classes, módulos, etc) é que você pode ter um monte de partes fáceis de entender. que pode ser mantido mais tarde. Muitos dos meus módulos têm menos de 20 linhas de código. Eu sei que todo o código de um determinado assunto está em um lugar específico. Isso também significa que, se alguém se juntar ao projeto, terá muito mais facilidade em encontrar as coisas.

Como Gerald Sussman disse que nossos programas devem ser escritos primeiro para que as pessoas possam lê-lo e depois para que o computador possa executá-lo. (E se você não tiver lido "Estrutura e Interpretação de Programas de Computador ainda deve)

Um usa várias classes porque, à medida que você entra em coisas maiores, você descobre que não há como controlar tudo quando é uma grande pilha de código.

Você simplesmente tem que dividir e conquistar para lidar com isso.

A programação orientada a objetos é a melhor idéia que já vi na programação. Mas não é a melhor coisa em todos os casos, você precisa de um pouco de experiência de programação para ver o sentido disso, e muitas pessoas estão alegando fazer OOP quando não estão.

Se você puder pesquisar "programação estruturada", provavelmente encontrará algo mais imediatamente útil. (Certifique-se de ler sobre a programação estruturada old . Os termos antigos geralmente têm significados novos e mais sofisticados, e você não precisa de nada extravagante ainda.) Esse é um conceito bastante simples de dividir seu programa em sub-rotinas. , o que é muito mais fácil do que dividi-lo em objetos. A idéia é que seu programa principal é uma rotina curta que chama sub-rotinas ("métodos" em Java) para fazer o trabalho. Cada sub-rotina só sabe o que é dito por seus parâmetros. (Um desses parâmetros pode ser um nome de arquivo, então você pode trapacear um pouco.) Então, olhar para o cabeçalho de uma sub-rotina / método dá uma idéia rápida do que ele faz e saber o que os métodos no programa principal permitem. você vê o que ele faz quase de relance.

Em seguida, todas as sub-rotinas são divididas de forma semelhante até que algumas linhas de código sem chamadas de método façam o trabalho. Um programa principal que chama alguns métodos, cada um dos quais chama alguns métodos, cada um dos quais .... Abaixo de pequenos métodos simples que fazem o trabalho. Desta forma, você pode olhar para qualquer parte de um programa muito grande (ou pequeno programa) e entender rapidamente o que ele faz.

Java é projetado especificamente para pessoas que estão escrevendo código Orientado a Objetos. Mas mesmo o programa OO mais intenso usa alguma programação estruturada, e você sempre pode subverter qualquer idioma. (Eu fiz OO na planície C.) Então você pode fazer SP, ou qualquer outra coisa, em Java. Esqueça as aulas e concentre-se em grandes métodos que podem ser divididos em pequenos e gerenciáveis. Devo acrescentar que o SP ajuda bastante com a possibilidade de você reutilizar seu código e também com o princípio DRY (google it, mas significa "Don't Repeat Yourself").

Espero ter explicado por que e como dividir seu código em várias partes sem incluir "classes". Eles são uma ótima idéia e são a coisa certa para jogos, e o Java é uma excelente linguagem para OOP. Mas é melhor saber por que você está fazendo o que está fazendo. Deixe a OOP em paz até que comece a fazer algum sentido para você.

Um dos benefícios é a reutilização. Um programa é basicamente um grupo de instruções agrupadas. Você descobriria que algumas dessas instruções são adequadas para outros programas também.

Digamos que você faça um jogo de salto. Mais tarde, quando você decide fazer um jogo de canhão, você descobre que o cálculo de física que você usou no jogo de salto é útil aqui.

Então, em vez de escrevê-lo novamente, ou pior copiá-lo e colá-lo no novo programa, você o transforma em uma classe. Então, da próxima vez que você fizer outro jogo em que a mecânica do jogo requer física, você pode reutilizá-lo. É claro que isso é simplista demais, mas espero que faça sentido.

Antes de mais nada, note que sou um C ++ e Python, não Java, portanto, alguns deles podem não se aplicar totalmente. Por favor, corrija-me se eu fizer algumas suposições incorretas sobre como as classes funcionam em Java.

As classes são úteis principalmente quando são instanciadas. Uma classe da qual nenhuma instância é criada realmente é apenas um espaço de nomes glorificado. Se você usar todas as suas classes dessa maneira, então, os benefícios de mover coisas de namespace para namespace podem parecer insignificantes - no máximo, você ganhará tendo alguns dados privados em cada um e, assim, encapsulando um pouco as coisas.

No entanto, não é aqui que as classes brilham. Considere a classe String : você pode ter todos os mesmos recursos usando char arrays e algumas funções estáticas. Neste ponto, as funções lhe dão um pouco de segurança extra e açúcar sintático. Você pode escrever string.length() em vez de length(char_array) ; isso não é um grande negócio, mas muitas pessoas ainda gostam disso. Além disso, você sabe que se alguém lhe deu um String , ele foi criado com o construtor String e que ele deve funcionar com a função length - se a versão da matriz não puder manipular algum caractere, ele não terá maneira de impedir você de colocá-lo lá.

Ainda não é isso. O ponto-chave é que as classes agrupam dados e funções que operam e abstraem ambos. Quando você tiver um método void f(Builder b) , você saberá que receberá um Builder e poderá esperar que ele ofereça suporte a determinado comportamento. No entanto, você não sabe nada sobre dados ou sobre as funções que estão sendo executadas - na verdade, as definições para ambos podem não estar escritas ainda enquanto você escreve e compila f .

O primeiro ponto a ser entendido é, portanto, que as classes facilitam a transmissão de dados, garantindo que elas não sejam quebradas. O segundo ponto é que tanto os dados quanto a função (implementações) de um objeto são algo sobre o objeto, e não algo que você pode simplesmente dizer a partir desse tipo.

A ideia é baseada em uma regra geral chamada dividir e conquistar .
Este paradigma pode ser usado em quase todos os lugares; você divide um problema em problemas menores e resolve esses problemas pequenos, simples e conhecidos.
Dividir seu programa em classes é um dos tipos de divisão que começaram a se tornar comuns na última década. Nesse paradigma de programação, modelamos nosso problema por alguns objetos e tentamos resolver o problema enviando mensagens entre esses objetos.
Algumas pessoas podem dizer que essa abordagem é mais fácil de compreender, expandir e depurar.
Embora algumas pessoas discordem:)

Não se trata de dividir um programa em classes, mas sim de como você modela seu aplicativo, ou seja, como você visualiza partes de seu aplicativo. Dividir as coisas é apenas um mecanismo que usamos para entender melhor as coisas complexas. Não é apenas com programação. Imagine a placa de circuito com muitos fios entrelaçados, formando uma estrutura complexa com cada fio conectando em algum lugar (código de espaguete). Você terá que seguir cada fio até o fim para descobrir as conexões. Ao contrário, imagine fios que são agrupados e codificados por cores conforme sua função. Torna-se muito mais fácil consertar as coisas.

A ideia é que você não comece com um programa longo e depois divida-o em classes. Mas você modela seu aplicativo em termos de objetos / classes primeiro e depois os conecta para construir aplicativos.