Programação Modular em C++

Transcrição

1 Programação Modular em C++ Princípios de Projeto Orientado por Objetos Roberto da Silva Bigonha Todos os direitos reservados Proibida a cópia sem autorização do S. Bigonha Princípios de Projeto OO C++ 1

2 Princípio de Projeto #1 Baixa Conectividade Todo módulo deve comunicar-se com um número mínimo de outros módulos 2

3 Modelo das 100 Lâmpadas As lâmpadas podem ser conectadas a qualquer outra Toda lâmpada acesa tem a probabilidade de 50% de desligar-se no próximo segundo Toda lâmpada apagada e que estiver conectada diretamente a pelo menos uma lâmpada acesa tem a probabilidade de 50% de acender-se no próximo segundo Toda lâmpada apagada assim permanece enquanto estiver conectada diretamente a somente lâmpadas apagadas Inicialmente todas as lâmpadas estão acesas 3

4 Modelo das 100 Lâmpadas... Considere três casos: 100 lâmpadas desconectadas 100 lâmpadas completamente conectadas 100 lâmpadas conectadas em grupos de 10 Suponhamos que: cada lâmpada representa um módulo Apagar ou acender uma lâmpada equivale ao ato de modificar a interface de um módulo 4

5 100 Lâmpadas Desconectadas Em quantos segundos 100 lâmpadas acessas atingem estabilidade? Como não há lâmpadas conectadas, a metade delas apaga-se no próximo segundo Como as 50 lâmpadas não estão conectadas, elas nunca se re-acenderão No próximo segundo, mais 25 lâmpadas apagamse Em 7 segundos, todas as lâmpadas estarão apagadas ( 50, 25, 12, 6, 3, 2 e 1) Equilíbrio atingido em 7 segundos 5

6 Lâmpadas Conectadas em Grupos de 10 Particione o conjunto de 100 lâmpadas em 10 grupos de 10, todas conectadas em cada grupo Em quantos segundos o sistema atinge estabilidade? Equilíbrio em 20 minutos 6

7 Todas as 100 Lâmpadas Conectadas 100 lâmpadas completamente conectadas Toda lâmpada tem 99 conexões Em quanto tempo todas se apagam? Equilíbrio em 10^22 anos 7

8 Conectividade X Complexidade HIPÓTESES: Conectividade tem relação direta com complexidade Aumento do grau de conectividade implica em aumento do custo de manutenção 8

9 Princípio de Projeto #2 Interface Pequena Banda de comunicação entre módulos deve ser mínima 9

10 Princípio da Interface Pequena Se dois módulos não podem evitar de se comunicarem, então a comunicação entre eles deve ser a mínima possível. O controle do volume e tipo de comunicação entre módulos é fundamental para obter sistemas modulares Contra-Exemplos: grande área de variáveis globais A melhor forma de comunicação entre módulos deve ser via parâmetros por valor 10

11 Princípio de Projeto #3 Interface Explícita Comunicação entre módulos deve ser óbvia pela simples inspeção dos módulos 11

12 Princípio da Interface Explícita Se dois módulos A e B se comunicam, então este fato deve ser evidente pela simples inspeção do texto de A ou B Princípio relacionado com o seguinte critério: Inteligibilidade: Como entender comportamento de um módulo que é influenciado por outro módulo de forma indireta? 12

13 Princípio de Projeto #4 Encapsulação Minimize a acessibilidade externa de classes e métodos 13

14 O Papel da Encapsulação Encapsulação é um recurso para definir os serviços que uma classe torna disponíveis para seus clientes Há dois tipos de clientes para cada classe (módulo): cliente externo cliente descendente Interface com cliente externo: public Interface com cliente descendente: protected (normalmente acoplamento por conteúdo) Proteção de dados: private 14

15 Encapsulação Encapsulação serve para separar a interface contratual de sua implementação. Encapsulação é um mecanismo usado para esconder os dados, estruturas internas e detalhes de implementação de um objeto, forçando que toda interação seja via operações da interface pública. Classes nunca devem expor seus detalhes de implementação. 15

16 Dados Sempre Privados Use sempre membros privados Se inevitável, use acessores e modificadores Por exemplo, public: double peso; deve, no mínimo, ser substituído por private: double peso; public: double getpeso( ){return peso;} void setpeso(double peso) { this->peso = peso; } 16

17 Princípio de Projeto #5 Abertura-Fechamento Entidades de software devem ser implementadas de forma a nunca terem que ser modificadas, mas apenas estendidas (Bertrand Meyer) 17

18 Abertura e Fechamento Módulo fechado é um compilado e armazenado na biblioteca de módulos Módulo deve ser fechado somente quando tiver uma interface bem definida e estável Mas, frequentemente, fecha-se um módulo porque não se pode esperar o levantamento de toda informação sobre o uso do módulo Módulo é fechado para modificações, quando julga-se que se atingiu estabilidade O módulo é adaptado somente via extensões, quando for necessário 18

19 Bom módulo deve ser: Abertura e Fechamento fechado para modificações, porém deve estar sempre aberto para incorporar novas extensões Extensões típicas são: inclusão de novos campos. inclusão de novas funções ou serviços 19

20 O Princípio Aberto-Fechado Módulos que conformam-se com OCP são: abertos para extensão: fechados para modificação 20

21 Princípio de Projeto #6 Substituição de Liskov (LSP) Funções que usam referências para objetos de uma classe devem ser capazes de referenciar objetos das subclasses dessa classe sem saberem (Barbara Liskov) 21

22 Contrato de Classe Contrato de uma classe é a coleção dos métodos e campos por ela exportados Pré-condições e pós-condições dos elementos exportados fazem parte do contrato Campos e métodos privados não fazem parte do contrato Contrato é o que o projetista da classe promete que ela fará. 22

23 Condições de Execução de um Método Pré-Condição: Condição a ser satisfeita pelos valores dos parâmetros do método e o estado do objeto no momento de entrada do método Pós-Condição: Condição a ser satisfeita pelo estado objeto produzido e pelo valor retornado pelo método 23

24 Cumprimento do Contrato Pré-Condição define as condições sob as quais a chamada a uma rotina é legítima. Pós-Condição define as condições que a rotina deve garantir no seu retorno. O retorno normal de um método significa cumprimento do contrato. Falhas no cumprimento do contrato devem sempre causar lançamento de exceções. 24

25 Programação por Contrato O relacionamento entre uma classe e seus clientes é uma relação de direitos e obrigações É uma relação vinculada a idéia de contrato Deve-se definir cláusulas de pré-condição e de póscondição para todo método r Regra Básica do Contrato: Se o usuário se comprometer a chamar o método r com sua pré-condição satisfeita, então r garante devolver um estado final com sua pós-condição satisfeita, ou então informa explicitamente seu insucesso. 25

26 Conceito de Subcontratação A definição de subclasse equivale a estender o contrato da superclasse O contrato herdado pode ser redefinido desde que não viole o contrato da superclasse Na redefinição da implementação de um contrato pode-se enfraquecer as pré-condições e fortalecer as pós-condições de métodos Condição mais fraca é menos restrita Condição mais forte é mais restrita 26

27 Fortalecimento de Pré-Condições Exemplo: substituir caixa-humano por caixaeletrônico Caixa-Humano: autoriza retiradas até R$50,00 sem verificar existência de fundos Caixa-Eletrônico: não as autoriza Há violação do contrato, porque fortaleceu-se indevidamente a pré-condição do método Fortalecimento da pré-condição tem impacto nos módulos cliente 27

28 Enfraquecimento de Pós-Condições Ex: método retorna um inteiro no intervalo [10,20] O valor retornado pode ser usado para indexar arranjos cujo tamanho seja menor ou igual a 20 Problema: método redefinido retorna um valor entre 1 e 100, violando contrato Enfraquecimento da pós-condição tem impacto nos módulos clientes 28

29 Sumário do Princípio de Liskov Para satisfazer o princípio de Liskov (LSP), toda subclasse deve ter o comportamento que os clientes esperam de sua respectiva superclasse Em termos de contrato, uma classe derivada é substituta de uma classe base se: Pré-condições de seus métodos redefinidos nunca são mais fortes que as dos respectivos métodos da classe base Pós-condições de seus métodos redefinidos nunca são mais fracas que as dos respectivos métodos da classe base 29

30 Princípio de Projeto #7 Preferência à Composição Composição é preferível a Herança 30

31 Composição Método de reúso no qual novas funcões são obtidas por composição com outros objetos As novas funções são obtidas por delegação de funções aos objetos da composição Composição dá-se por agregação ou por conhecimento: 1. Agregação quando um objeto possui responsabilidades sobre outros e todos possuem mesmo tempo de vida 2. Conhecimento quando um objeto faz referências a outros objetos independentes 31

32 Implementação da Composição Composição pode ser implementada por valor por referência Exemplo de ambas as formas: class A {B x; C *y; }; Objetos que formam a composição são chamados de objetos contidos A classe que os contém chama-se compositora 32

33 Vantagens da Composição Objetos contidos são acessados pela classe compositora somente através de suas interfaces É um reúso caixa-preta: detalhes internos dos objetos contidos não são visíveis Boa encapsulação Menos dependência em relação à implementação dos objetos contidos A composição é dinamicamente definida, porque as referências aos objetos contidos são obtidas durante a execução 33

34 Desvantagens da Composição Perda de reusabilidade 34

35 Herança Método de reúso no qual novas classes são obtidas pela extensão de classes existentes A classe generalizada (superclasse) define explicitamente os métodos e atributos comuns A classe especializada (subclasse) estende a implementação com atributos e métodos adicionais Herança pode ser de classe ou de interface 35

36 Vantagens de Herança Fácil gerar novas implementações, porque reúso é facilitado Fácil modificar ou estender as implementações que são reusadas 36

37 Desvantagens de Herança Herança possibilita violar encapsulação, porque detalhes (protected) da superclasse podem estar expostos na subclasse Herança permite reúso de caixa-branca, porque detalhes da superclasse podem ser visíveis nas subclasses Subclasses podem ter que ser mudadas quando altera-se sua superclasse 37

38 Relação Um Tipo Especial de Classe Médico: operações virtuais Doença consulta(paciente&) Remédio receita(doença) Classe Cardiologista : operações Doença consulta(paciente&) Remédio receita(doença) Resultado opera(paciente&) Na relação é um tipo especial de, Cardiologista é de fato uma especialização de Médico POLIMORFISMO: Um cardiologista é um tipo especial de Médico, que pode ser usado onde um médico for desejado. 38

39 Relação Pode Exercer o Papel de Classe Real representada por um float e oferece as seguintes operações virtuais: soma, sub mult, div Classe Complexo representada por dois floats e oferece as seguintes operações: soma, sub mult, div Na relação pode exercer o papel de, Complexo é visto como uma especialização de Real, não é de fato POLIMORFISMO: Um complexo pode ser usado onde um real for desejado, por pode exercer o papel de Real, mas não é Real 39

40 Relação Pode Exercer o Papel de Classe Ponto representada por um par ordenado e oferece as seguintes operações vituais: hide show move Classe Segmento representada por dois pares ordenados e oferece as seguintes operações: hide show move length Na relaçao pode exercer o papel de, Segmento é visto como uma especialização de Ponto POLIMORFISMO: Um segmento pode ser usado onde um ponto for desejado, mas não é Ponto 40

41 Reúso de Implementação (move) class Ponto { float x1, y1 ; public: virtual void adjust(float x,float y){...}; Ponto(float a,float b){x1 = a; y1 = b;}; virtual void hide( ) {... }; virtual void show( ) {... } virtual void move(float x, y ) { hide( ); adjust(x,y); show( ); } } 41

42 Reúso de Implementação (move) class Segmento: public Ponto { float x2, y2; public: void adjust(float x, float y) {... }; Segmento(float a,float b, float c,float d):ponto(a,b) { x2 = c; y2 = d; } void hide( ) {... }; void show ( ) {... }; int length( ) {... }; } 42

43 Uso de Composição class Segmento { Ponto p1, p2 public: void adjust(float x, float y) {... }; Segmento(float a,float b, float c,float d):p1(a,b),p2(c,d){} void hide(){p1.hide();...p2.hide();... }; void show () {... }; int length() {... }; void move(float x, y ) { hide( ); adjust(x,y); show( ); } } 43

44 Herança X Composição Herança para criação de subtipos: Subclasse corresponde a subconjunto Exemplo: Cardiologista é subconjunto de Médico Herança para reúso de implementação : Subclasse pode não corresponder a subconjunto. Exemplo: Complexo não é subconjunto de Real MELHOR AINDA: Use Composição em vez de herança nestes casos 44

45 Sumário do Princípio Composição e herança são importantes métodos de reúso Use herança com cuidado, sem abusos Projeto pode ser simplificado com uso de composição Composição e herança devem cooperar-se O princípio fundamental é: Prefira composição à herança 45

46 Princípio de Projeto #8 Programação Para Interface Programação deve basear-se em interface e nunca na implementação de classe 46

47 Interfaces Uma interface é o conjunto de métodos que um objeto sabe que pode chamar de outro A interface é um subconjunto dos métodos que uma classe implementa Um objeto é conhecido via sua interface Interface expressa a propriedade de ser um de Um objeto pode então ter muitas interfaces Um tipo é uma interface específica de um objeto Diferentes objetos podem ter o mesmo tipo Um mesmo objeto pode ter diferentes tipos 47

48 Herança X Subtipagem Herança de classe: implementação de um objeto é definida em termos da implementação de outro Subtipagem: descrição de quando um objeto pode ser usado no lugar de um outro Herança em C++ significa herança de classe e herança de interface Herança de interface de C++ é obtida herdando-se de classe abstrata pura Java tem construções distintas para cada caso A construção de interface de Java facilita expressar e implementar projetos focados na interface de S. Bigonha Princípios de Projeto OO C++ 48

49 Benefícios de Interfaces Clientes não precisam preocupar-se com a classe específica do objeto que se está usando Um objeto pode ser dinamicamente substituído por outro de diferente classe Conexões entre objetos não precisam fixar as classes dos objetos, aumentando a flexibilidade Confere menor grau de acoplamento de classes Aumenta grau de reúso de classes Facilita composição, porque objetos contidos podem ser de quaisquer classes que implementem a S. Bigonha Princípios de Projeto OO C++ 49

50 Exemplo 1: Interface class Maneuverable { public: virtual void left( ) = 0 ; virtual void right( ) = 0 ; virtual void forward( ) = 0 ; virtual void reverse( ) = 0 ; virtual void climb( ) = 0 ; virtual void dive( ) = 0 ; virtual void setspeed(double speed) = 0 ; virtual double getspeed( ) = 0 ; S. Bigonha Princípios de Projeto OO C++ 50

51 Exemplo 1: Interface class Car: public Maneurable{ código }; class Boat: public Maneurable{ }; código class Submarine: public Maneurable{ }; S. Bigonha Princípios de Projeto OO C++ 51

52 Exemplo 1 : Interface Um método travel de uma outra classe pode dirigir um veículo do tipo Maneurable sem se preocupar com sua real classe (Car, Boat, Submarine) void travel(maneurable& vehicle) { vehicle.setspeed(35.0); vehicle.forward(); vehicle.left(); vehicle.climb(); S. Bigonha Princípios de Projeto OO C++ 52

53 Sumário do Princípio Todo objeto deve ter seu tipo definido por uma Interface Os usuários de um objeto somente devem conhecêlo por sua interface O princípio fundamental: O uso de um objeto deve sempre independer de sua S. Bigonha Princípios de Projeto OO C++ 53

54 Princípio de Projeto #9 Segregação de Interfaces Interfaces mais específicas são melhores que interfaces de propósito S. Bigonha Princípios de Projeto OO C++ 54

55 Exemplo de Interface Poluída Considere um sistema de segurança para portas Portas podem ser trancadas ou não Portas sabem quando estão abertas ou não class Porta { public: virtual void fecha( ){ } virtual void abre( ) { } virtual bool portaaberta( ) { } } S. Bigonha Princípios de Projeto OO C++ 55

56 Porta de Segurança Certas portas, e.g., as de Cofre, somente podem ser abertas em determinados horários class PortaDeCofre: public Porta { public: }; void definehorario ( ){ } bool podeabrir( ) { } As Portas são usadas em todo o sistema class Predio { }; Porta porta[100]; ; porta[i] = new P S. Bigonha Princípios de Projeto OO C++ 56

57 Melhoria da Segurança do Cofre Deseja-se então acrescentar ao sistema a capacidade de as portas de cofre dispararem alarme se ficarem abertas além de um certo tempo Suponha que já exista implementada a classe Temporizador, que não se pode alterar Deseja-se usar o temporarizador com o mínino de alteração no S. Bigonha Princípios de Projeto OO C++ 57

58 O Temporizador class Temporizador { }; public:void registra(int t,monitorado* c){ }... C->disparaAlarme();... class Monitorado { }; public: virtual disparaalarme( ){... } Método registra toma nota do objeto monitorado c, o qual será automaticamente notificado, via chamada ao seu método disparaalarme, após decorrido o tempo t de S. Bigonha Princípios de Projeto OO C++ 58

59 Alarme Temporizado nas Portas Somente objetos do tipo Monitorado podem ser passados ao método registra Portanto objetos Porta não podem ser passados ao método registra Uma solução, para contornar esta dificuldade, é tornar a classe Porta uma extensão da classe Monitorado Em consequência, Porta agora passa a ter o método disparaalarme em sua S. Bigonha Princípios de Projeto OO C++ 59

60 Hierarquia dos Monitorados Monitorado Porta S. Bigonha Princípios de Projeto OO C++ 60

61 A Poluição Uma classe é obrigada a ter em sua interface um ou mais métodos somente porque uma de suas subclasses precisa deste comportamento Considerando que estes métodos nada têm a ver com a classe, pode-se considerar sua presença como um poluente Esta é a síndrome da Interface S. Bigonha Princípios de Projeto OO C++ 61

62 Solução com Herança Múltipla class Porta { public: virtual void fecha( ){ } virtual void abre( ) { } virtual bool portaaberta( ) { } }; class PortaDeCofre: public Porta, public Monitorado { public: void definehorario ( ){ } public bool podeabrir( ) { } public void disparaalarme( ) { } S. Bigonha Princípios de Projeto OO C++ 62

63 Solução com Composição... class Porta { public: virtual void fecha( ){ } virtual void abre( ) { } virtual bool portaaberta( ) { } }; class PortaDeCofre: public Porta { public: void definehorario ( ){ } bool podeabrir( ) { } void disparaalarme( ) { } S. Bigonha Princípios de Projeto OO C++ 63

64 Solução com Composição... class MeuMonitorado: public Monitorado { PortaDeCofre* p; public: MeuMonitorado(PortaDeCofre* p){this->p=p;} void disparaalarme(){p->disparaalarme( );} };... int tempo = 100; Temporizador t = Temporizador( ); PortaDeCofre* p = new PortaDeCofre( ); MeuMonitorado* m = new MeuMonitorado(p); t.registra(tempo, S. Bigonha Princípios de Projeto OO C++ 64

65 Princípio de Projeto #10 Única Responsabilidade: Nunca deve haver mais de um motivo para uma classe ser S. Bigonha Princípios de Projeto OO C++ 65

66 Responsabilidades de Classe Cada responsabilidade constitui-se uma dimensão de mudanças Se uma classe tem mais de uma responsabilidade, então haverá mais de uma razão para alterá-la Quanto mais responsabilidades houver numa classe, mais frágil torna-se o S. Bigonha Princípios de Projeto OO C++ 66

67 Exemplo 1: Violação do Princípio Considere o projeto da classe Retangulo: Aplicação Geométrica Retangulo desenha () double area() Aplicação Gráfica GUI Implicações: Aplicações geométricas têm que ter o GUI disponível, apesar de não precisar dele Mudanças nas aplicações gráficas têm impacto nas aplicações geométricas (retestes, recompilação, S. Bigonha Princípios de Projeto OO C++ 67

68 Solução do Exemplo 1 Criar uma classe para cada responsabilidade: Aplicação Geometrica Aplicação Gráfica Retângulo Geométrico double area() Retângulo desenha () GUI Agora, mudanças feitas na apresentação gráfica do Retangulo não afetam as aplicações S. Bigonha Princípios de Projeto OO C++ 68