As dúvidas que eu tenho são simples mas acredito que farão toda a diferença na maneira como eu implemento P.O.O dentro de java, vamos por partes
1 Como realmente saber quais partes do codigo devem realmente estar localizadas dentro da classe? (Você que lê agora deve estar pensando: tudo referente ao objeto) Ok. mas até sua manipulação?
2 É adequado criar outros objetos dentro de uma classe que já possui um objeto definido? como por exemplo um scanner?
3 por fim, como posso ficar atento para estar seguindo os padrões da linguagem?
Desde já agradeço
Cara, até onde eu sei não existe um modo certo de fazer as coisas. Existem convenções que são bem vistas.
-
Depende. Existem varias convenções e padrões. E para cada projeto um modelo é melhor do que outro.
-
Não compreendi, mas acredito que você esteja falando de composição. Composição é tida como mais eficiente do que por exemplo herança, mas dependendo do projeto isso pode mudar.
-
Volto a me repetir. Cada caso é um caso.
Uma boa saída pra essas duvidas é estudar padrões de projeto. Eu comecei a estudar semana passada e já comecei a perceber a programação de uma nova maneira. Uma dica: não se prenda aos padrões.
1 curtida
Estou iniciando, mas, pelo que entendo, é o seguinte:
- Depende dos problemas do negócio que seu app quer resolver. Digamos que seu app será responsável por controlar uma biblioteca, então vc poderia ter as seguintes classes:
class Biblioteca { /* ... */ }
class Livro { /* ... */ }
class Funcionario { /* ... */ }
class Usuario { /* ... */ }
- Não há problemas em criar outros objetos dentro de uma outra classe. No exemplo acima, um novo
Livro deve poder ser adicionado em algum lugar e este lugar provavelmente será em Biblioteca.
O que não pode acontecer é ter uma determinada classe com responsabilidades demais ou com responsabilidades que não deveriam ser dela.
A classe Biblioteca é apenas uma abstração do que seria uma biblioteca real, ela representa esta entidade em código. Ela não deveria ser responsável por exibir a interface gráfica, por exemplo; para isso seria melhor ter uma classe TelaInicial. Na verdade, uma classe pra cada tela: TelaCadastroLivros, TelaCadastroUsuario, etc…
- Normalmente, linguagens não estabelecem diretrizes sobre como vc deve criar suas classes.
No caso do Java o que vc tem são convenções para a criação de nomes, que no caso das classes devem começar com letra maiúsculas. Os métodos devem começar com um verbo e, assim como variáveis, devem começar com letra minúscula e, caso contenha mais de uma palavra, estas palavras adicionais devem começar com letra maiúscula.
class Pessoa { // classes começam sempre com letra maiúscula
int idade; // variáveis e métodos começam com minúscula
String nomeDaPessoa; // variável com nome composto
void exibirDadosDaPessoa() { /* ... */ } // métodos começam com verbo
}
Mas isso não passa de convenção apenas.
Para nos ajudar a resolver problemas recorrentes em desenvolvimento de software de forma padronizada há os Design Patterns, eles são independentes de linguagem e são muito importantes. Para desenvolver software de maior qualidade, comece estudando eles; leia também sobre SOLID e DRY.
Bons estudos!
1 curtida
Em geral, uma classe deve ter alguns atributos e alguns métodos que atuam sobre esses atributos. Se você tem um método que não atua sobre nenhum atributo da classe, e ele poderia ser estático, há boas chances deste método não precisar estar nessa classe.
Os atributos devem ser manipulados pelos métodos da classe, eles devem manter o Estado consistente e implementar as regras que mudam o Estado.
Se uma classe tem muitos métodos e atributos, provavelmente está fazendo coisas demais.
Você deve tomar cuidado ao Instanciar Objetos dentro de uma Classe, se sua Instância é Composta por outras Instâncias você terá maior Flexibilidade se criar uma Classe Fábrica que fábrica a sua Instância instanciando as dependências delas e montando-a.
Não se prenda aos Padrões. Para fazer um bom Design você deve ter uma visão clara de como sua Aplicação irá crescer e estabelecer padrões nela que facilitem esse crescimento. Adicionar uma nova funcionalidade que era previsível desde o começo deve ser simples como criar uma nova Classe; mas se você tiver que editar várias Classes para adicioná-la, então seu Design é um problema.
Se para adicionar funcionalidades na sua Aplicação você precisa editar várias Classes para “encaixá-la”, é melhor refatorar seu Design (quanto mais cedo mais barato sai a refatoração).
Obrigado, vou começar a estudar tais padrões logo mais, é muito comum eu acabar me enrolando com coisas simples
“Se para adicionar funcionalidades na sua Aplicação você precisa editar várias Classes para “encaixá-la”, é melhor refatorar seu Design (quanto mais cedo mais barato sai a refatoração).”
Pude perceber que isso as vezes acontece quando tenho muitas classes num projeto
Cara, como a galera já falou ai em cima, não existe uma “verdade absoluta”, existem diversas boas práticas que dependendo do cenário pode ser a melhor ou não…
Conheço esse blog do Marcos Brizeno, onde ele aborda diversos padrões de projetos (GOF e outros): https://brizeno.wordpress.com/
E caso queira aprofundar, tem a “bíblia” dos padrões de projetos: https://www.amazon.com.br/Padrões-Projetos-Erich-Gamma/dp/8573076100/ref=sr_1_1?ie=UTF8&qid=1493595746&sr=8-1&keywords=padrões+de+projetos