Inexperiência. Qual a forma certa de programar?

Olá pessoal do guj,

Estou escrevendo nesse fórum, pois estou terminando o curso de Sistemas de Informação e ainda não me sinto preparando.
Desenvolvi o sistema usando java se, mas durante o processo de desenvolvimento, conversando com amigos do curso,
ouvi falar que a HERANÇA QUEBRA O ENCAPSULAMENTO.
Pensei “Como Assim?”. Muitos disse que ouviu falar, mas não sabia explicar.

Então mudei um pouco a minha forma de desenvolver.
Na Universidade muitas pessoas desenvolviam, tela usando swing da seguinte forma:

public class Tela extends javax.swing.JInternalFrame {}

ou ainda

public class Tela extends javax.swing.JFrame

Pensando na herança
comecei a fazer o seguinte

public class TelaCadastro{ private javax.swing.JInternalFrame internal }

Comecei a usar instancia e não herança, apesar que das duas formas, dependendo da maneira que vc implementa a classe
vão funcionar perfeitamente.

Mas qual a forma certa de se programar???
também não entendi uma coisa que vi aki no forum “Program to interfaces, not classes.” http://www.guj.com.br/posts/list/16282.java
Paulo Siqueira fez uma citação de um livro e não entendi isso.

to um tanto confuso de como programar.
Gostaria de saber de livros ou até mesmo algo na internet que me ajude a dar um norte na carreira

abraços a todos

Olá, esse artigo pode te ajudar, mas ele é um pouco mais avançado:
http://www.artima.com/lejava/articles/designprinciples.html

Essa discussão também (há vários tópicos meus explicando exaustivamente o assunto):
http://www.guj.com.br/posts/list/51866.java#273117

Eu sugeriria que você começasse:

a) Dominando bem uma linguagem e os conceitos de OO.
b) Procure estudar o Java, por exemplo, entender suas APIs e ver como as APIs solucionam problemas comuns do ponto de vista do projeto;
c) Para ajudar na tarefa a), busque alguns livros como: “Effective Java”, “Padrões de Projeto” e “Refatoração”. São livros que mostram maneiras corretas e/ou bem aceitas de resolver problemas comuns.
d) Programe e erre. E procure refletir sobre o que errou, e como poderia fazer para corrigir o problema.

Não adianta, muita coisa você só vai aprender depois de quebrar a cabeça algumas vezes.

Quando tive Java na faculdade, um professor meu disse que alguns autores dizem que a orientação a objetos perfeita não usa herança…

Acho que o grande problema é o uso do modificador de acesso protected desenfreadamente. Se você olhar por um lado, isso pode ser uma “quebra” de encapsulamento, uma vez que outra classe está diretamente modificando o valor de um atributo alheio. Entretanto, se você enxergar que, para herdar, você usa do princípio “é um”, ou seja, uma classe que herda é um sub-conjunto da classe mãe, temos outro ponto de vista… o de que, como a classe filha “é um”, tem todos os atributos da classe mãe. Logo não há problemas em ter acesso direto a seus atributos.

Eu não tenho nada contra herança, ao contrário, ajuda bastante… o que você pode fazer para “rebater” o argumento de que classes filhas (mesmo sendo filhas) não podem alterar livremente os atributos da classe mãe é declarar todos os atributos da classe mãe como private e acessá-los através dos métodos get e set.

Oi,

Geralmente professores de faculdade acabam falando o que não devem falar… rsrs (nem todos é claro).

O que está errado mesmo é o seu conceito de OO. Procure entende-lo! que logo suas dúvidas em relação a Herança, encapsulamento e outros irão desaparecer…

Tchauzin!

A herança é sempre uma relação forte. Muitíssimo mais forte que associar duas classes. Por isso, o seu uso deve ser evitado.
Não significa que ela não tenha utilidade, e o caso do JFrame é um deles. Geralmente, é lógico e prático criar um filho de JFrame.

Existem muitos mecanismos que substituem a herança em vários casos, e por isso é interessante estudar os padrões de projetos. Eu, particularmente, evito cadeias de herança maiores que três níveis. Sendo que mesmo heranças de 3 níveis são raras.

Eu acho que na verdade, quando você esta utilizando o Swing + NetBeans, diversas praticas de OO são quebradas sem “perceber”.

[quote=Andr?Heidi Moriya]Olá pessoal do guj,

Estou escrevendo nesse fórum, pois estou terminando o curso de Sistemas de Informação e ainda não me sinto preparando.
Desenvolvi o sistema usando java se, mas durante o processo de desenvolvimento, conversando com amigos do curso,
ouvi falar que a HERANÇA QUEBRA O ENCAPSULAMENTO.
Pensei “Como Assim?”. Muitos disse que ouviu falar, mas não sabia explicar.

Então mudei um pouco a minha forma de desenvolver.
Na Universidade muitas pessoas desenvolviam, tela usando swing da seguinte forma:

public class Tela extends javax.swing.JInternalFrame {}

ou ainda

public class Tela extends javax.swing.JFrame

Pensando na herança
comecei a fazer o seguinte

public class TelaCadastro{ private javax.swing.JInternalFrame internal }

Comecei a usar instancia e não herança, apesar que das duas formas, dependendo da maneira que vc implementa a classe
vão funcionar perfeitamente.

Mas qual a forma certa de se programar???
também não entendi uma coisa que vi aki no forum “Program to interfaces, not classes.” http://www.guj.com.br/posts/list/16282.java
Paulo Siqueira fez uma citação de um livro e não entendi isso.

to um tanto confuso de como programar.
Gostaria de saber de livros ou até mesmo algo na internet que me ajude a dar um norte na carreira

abraços a todos
[/quote]

Para entender isto vc tem que entender a diferença entre o verbo ser e o verbo ter.
Uma tela é um jframe ou tem um jframe ?

Se vc responder “é”, então use herança
Se vc responder “tem”, então use composição ( que é o jeito que vc mostrou que está fazendo).

Nenhuma é errada ou certa por si mesma.

Mas a realidade é mais crua que isso. Durante o desenvolvimento vc vai chegar a conclusão que se a tela fosse um jframe várias coisas seriam simplificadas. Isto significa que vc escolheu errado e deveria ter usado herança. O mesmo podemos pensar da outra escolha.

Uma outra forma de analisar é dizer assim : “se a tela não é um jframe o que ela é então ?” ou seja, qual seria o pai dela (sem contar object). Achou algum outro candidato ? Não ? então é porque provavelmente ela é mesmo um jframe.

em relação a “programe para interfaces” é o seguinte:

Como vc sabe que a tela é uma tela ? que comportametos todas as telas têm ? como vc força esse contrato em todas as suas telas ?
A resposta é: usando uma interface.

Vc pode escrever assim


public TelaDeCadastroDeCliente extends JFrame implements Tela

ai vc usa assim


 Tela cadastro = new TelaDeCadastroDeCliente ();
 cadastro.setVisible(true);

Veja que setVisible é um método de JFrame mas isso é uma coincidência.
Veja que naquele codigo vc não sabe que está usando JFrame.
Agora imagine um metodo encarregado por mostrar todas as telas e posicioná-las corretamente no desktop


public void showInDesktop (Tela tela){

   tela.setBounds(0,0, screenWidth, screenHeight);
   tela.setVisible(true);
}

Repare que não sei que estou usando Jframe. Repare que se Tela herdar de jframe ou não tanto faz para este código.

Programar para interfaces significa : use interfaces para declarar tipos de argumentos, retornos e atributos apenas use classes
na instanciação( no new). Isso lhe dá uma flexibilidade aburda e torna o desenvolvimento mais fácil.

public class JIFCadClientes extends JIFPadraoEdicao(){

implementar métodos abstratos salvar editar etc …

}