#Este é um post fechado Este post está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais sobre como abrir este post!
dê seu feedback
post favorito
Desenvolvendo software sólido - Java Magazine 79
O artigo trata de cinco princípios básicos do desenvolvimento de software orientado a objetos. Os princípios são o Single Responsibility Principle, o Open Closed Principle, o Liskov Substitution Principle, o Interface Segregation Principle e o Dependency Inversion Principle.
Java Magazine 79
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 79
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 79
BRK##: 0 - 0
Desenvolvendo software sólido
Melhorando o design de aplicações orientadas a objetos
Utilize cinco princípios básicos da orientação a objetos para melhorar o design das suas aplicações, utilizando corretamente a herança e tornando os objetos mais coesos e menos acoplados
Hoje em dia, a maioria dos desenvolvedores de software está utilizando linguagens orientadas a objetos, mas infelizmente, a maioria deles as utiliza sem o devido conhecimento, sem saber como extrair o máximo de benefícios dos recursos que elas oferecem. Muitos desenvolvedores, apesar de utilizar estas linguagens, programam de forma procedural, e assim, o código fica muito complexo e pouco flexível. Por isso, muitas vezes culpam a linguagem que utilizam por um problema causado pela falta de conhecimento.
Ao longo de nossa vida profissional já ouvimos ersos conselhos para melhorar o desenvolvimento de software orientado a objetos, como programar para interfaces, e não para implementações. Assim como já estudamos dezenas de design patterns e os utilizamos para solucionar problemas em nossos softwares. Mas de onde vieram todas essas ideias? Quais são as principais regras que devemos seguir quando estamos utilizando a orientação a objetos?
Este artigo tem como objetivo mostrar os cinco princípios básicos da programação orientada a objetos. Eles foram introduzidos por Robert C. Martin, no início dos anos 2000. Seguir esses princípios torna possível a criação de sistemas muito mais fáceis de manter e estender ao longo do tempo. Os princípios são diretivas que podem ser aplicadas enquanto se trabalha em um software para remover problemas no código através da refatoração até que ele esteja legível e flexível.
A refatoração (do inglês “refactoring”) é o ato de pegar o código já existente de um software e modificar a sua estrutura de forma a melhorá-la sem que haja uma alteração no comportamento do software.
Estes princípios lidam com ersos aspectos da programação orientada a objetos, por exemplo, como aumentar a coesão de uma classe e diminuir o acoplamento entre elas, como utilizar herança de forma correta, como lidar com as dependências de objetos, entre outros.
Os princípios analisados são: Single Responsibility Principle, Open Closed Principle, Liskov Substitution Principle, Interface Segregation Principle e Dependency Inversion Principle. As iniciais dos cinco princípios formam a palavra SOLID, daí o título do artigo.
Single Responsibility Principle
O Single Responsibility Principle, ou Princípio da Responsabilidade Única, foi introduzido por Robert C. Martin, em seu livro Agile Software Development: Principle, Patterns, and Practices. Nessa obra, ele diz que “uma classe deve ter apenas uma razão para mudar”. Esse princípio também é chamado de coesão e implica em dizer que uma classe deve fazer uma única coisa e fazê-la bem. Criar classes especializadas em fazer uma única coisa torna um sistema mais receptivo a mudanças, mais estável. Se uma classe tem mais de uma responsabilidade, ou seja, se ela realiza mais de uma função, então essas responsabilidades se tornam acopladas, de forma que mudanças em uma responsabilidade podem afetar a capacidade da classe em atender à outra. Esse tipo de acoplamento leva a classes e métodos frágeis, que se comportam de forma inesperada quando mudados.
Consideremos o exemplo da Listagem 1. Neste exemplo temos uma classe chamada Computador com um método ligar(). Esse método chama outros métodos privados da classe: exibir(), lerTeclado() e imprimir(). Ao chamar o método ligar(), o computador exibe um texto que pede que o usuário digite uma mensagem pelo teclado, lê a mensagem e a envia para impressão através do método imprimir().
Listagem 1. Exemplo com a classe Computador.
01. public class Computador {
02.
03. public void ligar() {
04. exibir("Digite a mensagem que será impressa: ");
05. String msg = lerTeclado();
06. imprimir(msg);
07. }
08.
09. private void exibir(String msg) {
10. System.out.println(msg);
11. }
12.
13. private String lerTeclado() {
14. Scanner sc = new Scanner(System.in);
15. return sc.nextLine();
16. }
17.
18. private void imprimir(String msg) {
19. System.out.println("Imprimindo: " + msg);
20. }
21.
22. }
A classe Computador exposta no exemplo está quebrando o Single Responsibility Principle, pois ela tem múltiplas responsabilidades: a de exibir um texto na tela, ler a mensagem do teclado e imprimir a mensagem digitada. Se desejarmos mudar a forma como os textos são exibidos na tela, devemos mudar a classe Computador; se desejarmos mudar a forma de ler do teclado, devemos mudar a classe Computador; se desejarmos mudar a forma de impressão da mensagem, também devemos mudar a classe Computador. Ou seja, a classe Computador possui mais de uma razão para mudar.
ATENÇÃO! A exibição deste artigo foi interrompida.
#Este é um post fechado
Este post está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais sobre como abrir este post!
Desenvolvendo software sólido
Melhorando o design de aplicações orientadas a objetos
Utilize cinco princípios básicos da orientação a objetos para melhorar o design das suas aplicações, utilizando corretamente a herança e tornando os objetos mais coesos e menos acoplados
Hoje em dia, a maioria dos desenvolvedores de software está utilizando linguagens orientadas a objetos, mas infelizmente, a maioria deles as utiliza sem o devido conhecimento, sem saber como extrair o máximo de benefícios dos recursos que elas oferecem. Muitos desenvolvedores, apesar de utilizar estas linguagens, programam de forma procedural, e assim, o código fica muito complexo e pouco flexível. Por isso, muitas vezes culpam a linguagem que utilizam por um problema causado pela falta de conhecimento.
Ao longo de nossa vida profissional já ouvimos ersos conselhos para melhorar o desenvolvimento de software orientado a objetos, como programar para interfaces, e não para implementações. Assim como já estudamos dezenas de design patterns e os utilizamos para solucionar problemas em nossos softwares. Mas de onde vieram todas essas ideias? Quais são as principais regras que devemos seguir quando estamos utilizando a orientação a objetos?
Este artigo tem como objetivo mostrar os cinco princípios básicos da programação orientada a objetos. Eles foram introduzidos por Robert C. Martin, no início dos anos 2000. Seguir esses princípios torna possível a criação de sistemas muito mais fáceis de manter e estender ao longo do tempo. Os princípios são diretivas que podem ser aplicadas enquanto se trabalha em um software para remover problemas no código através da refatoração até que ele esteja legível e flexível.
A refatoração (do inglês “refactoring”) é o ato de pegar o código já existente de um software e modificar a sua estrutura de forma a melhorá-la sem que haja uma alteração no comportamento do software.
Estes princípios lidam com ersos aspectos da programação orientada a objetos, por exemplo, como aumentar a coesão de uma classe e diminuir o acoplamento entre elas, como utilizar herança de forma correta, como lidar com as dependências de objetos, entre outros.
Os princípios analisados são: Single Responsibility Principle, Open Closed Principle, Liskov Substitution Principle, Interface Segregation Principle e Dependency Inversion Principle. As iniciais dos cinco princípios formam a palavra SOLID, daí o título do artigo.
Single Responsibility Principle
O Single Responsibility Principle, ou Princípio da Responsabilidade Única, foi introduzido por Robert C. Martin, em seu livro Agile Software Development: Principle, Patterns, and Practices. Nessa obra, ele diz que “uma classe deve ter apenas uma razão para mudar”. Esse princípio também é chamado de coesão e implica em dizer que uma classe deve fazer uma única coisa e fazê-la bem. Criar classes especializadas em fazer uma única coisa torna um sistema mais receptivo a mudanças, mais estável. Se uma classe tem mais de uma responsabilidade, ou seja, se ela realiza mais de uma função, então essas responsabilidades se tornam acopladas, de forma que mudanças em uma responsabilidade podem afetar a capacidade da classe em atender à outra. Esse tipo de acoplamento leva a classes e métodos frágeis, que se comportam de forma inesperada quando mudados.
Consideremos o exemplo da Listagem 1. Neste exemplo temos uma classe chamada Computador com um método ligar(). Esse método chama outros métodos privados da classe: exibir(), lerTeclado() e imprimir(). Ao chamar o método ligar(), o computador exibe um texto que pede que o usuário digite uma mensagem pelo teclado, lê a mensagem e a envia para impressão através do método imprimir().
Listagem 1. Exemplo com a classe Computador.
01. public class Computador {
02.
03. public void ligar() {
04. exibir("Digite a mensagem que será impressa: ");
05. String msg = lerTeclado();
06. imprimir(msg);
07. }
08.
09. private void exibir(String msg) {
10. System.out.println(msg);
11. }
12.
13. private String lerTeclado() {
14. Scanner sc = new Scanner(System.in);
15. return sc.nextLine();
16. }
17.
18. private void imprimir(String msg) {
19. System.out.println("Imprimindo: " + msg);
20. }
21.
22. }
A classe Computador exposta no exemplo está quebrando o Single Responsibility Principle, pois ela tem múltiplas responsabilidades: a de exibir um texto na tela, ler a mensagem do teclado e imprimir a mensagem digitada. Se desejarmos mudar a forma como os textos são exibidos na tela, devemos mudar a classe Computador; se desejarmos mudar a forma de ler do teclado, devemos mudar a classe Computador; se desejarmos mudar a forma de impressão da mensagem, também devemos mudar a classe Computador. Ou seja, a classe Computador possui mais de uma razão para mudar.
ATENÇÃO! A exibição deste artigo foi interrompida.
#Este é um post fechado Este post está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais sobre como abrir este post!
1 COMENTÁRIO
Augusto Lopes
em 10/11/2010 20:13 - Responder
Usar a orientação a objetos de forma correta é um tarefa difícil, mas muito recompensadora, já garante aspectos como robustez e rápida manutenção no código. Este artigo aborda técnicas que todos programdores devem saber e mostra a importância de realmente se implementar aplicações Orientando-se por seus objetos.
em 10/11/2010 20:13 - Responder
[Este post ainda não foi associado a uma sequência]
Você está em:
canal Java
Publicidade
Estudo comparativo entre banco de dados IBM Informix e Microsoft SQL
David Pereira
Space do autor
é engenheiro de computação e mestre em engenharia elétrica pela UFRN. Trabalha como arquiteto de software na Superintendência de Informática da UFRN, é professor da Faculdade Natalense para o Desenvolvimento do RN (FARN) e é consultor independente em arquitetura de software e no Spring Framework.
Space do autor
1
0
Conheça os planos de créditos DevMedia e visualize esse post agora mesmo!