26
Hangout OOD - Princípio Open/Closed 11/06/2014

OOD - Princípio Open/Closed

Embed Size (px)

DESCRIPTION

Slides do Hangout sobre design orientada a objetos, dessa vez sobre o princípio Open/Closed, o OCP

Citation preview

Page 1: OOD - Princípio Open/Closed

Hangout OOD - Princípio Open/Closed11/06/2014

Page 2: OOD - Princípio Open/Closed

Participantes:• João Batista Neto – Hoster

• Daniel Ribeiro - Moderador

• Priscila Mayumi Sato – Slides

• Ivo nascimento – Controlador do chat

• Luís Otavio

Page 3: OOD - Princípio Open/Closed

Pauta• Repassar o que foi discutido no hangout passado e apontar o link

para a gravação.

• Abordar, com profundidade e exemplos, o princípio de design O.C.P.

• Aberto mas fechado, como algo pode ser aberto mas fechado?

• Como saber se meu código não está fechado?

• Ilustrar casos do mundo real, através de exemplos em frameworks ou bibliotecas conhecidas, o uso de O.C.P. e as consequências que esse uso trouxe para o FW ou biblioteca.

Page 5: OOD - Princípio Open/Closed

Princípio Open/Closed

Page 6: OOD - Princípio Open/Closed

Princípio Open/Closed• “Nem sempre a coisa pressuposta é eternamente

aquilo planejada, e como a classe não foi feita para poder editar você não consegue. Por isso o principio se trata sobre isso” João

• “A ideia geral dos princípios SOLID é evitar a mudança ao máximo, e o principio Open/Closed evita ao máximo a mudança daquele participante, ao invés de alterar ele estende” Luiz Otávio

• “Assim nós temos o recurso da herança e do polimorfismo para lidar com esse principio” Daniel

Page 7: OOD - Princípio Open/Closed

Princípio Open/Closed• “OCP e SRP não são dependentes um do outro, um

código pode ter 3 responsabilidades e mesmo assim não violar OCP” João

• “A ordem das letras do SOLID possuem uma certa lógica, uma razão” Daniel

• “Quanto maior o número de responsabilidades maior a possibilidade de violar o OCP. Der repente você toma todo o cuidado com o SRP e cria uma pré suposição que não deveria.” João

Page 8: OOD - Princípio Open/Closed

Princípio Open/Closed• “Quando você vê os dois princípios (SRP e OCP)

aumenta a qualidade do código, seguir SRP diminui a possibilidade de cometer erros com o OCP” Ivo

• “O OCP está relacionado não só a classe, mas módulos, funções e pacotes. Estender não só objetos como também outros itens” Daniel

• “Quando falamos de pacotes não são os mesmos nomes do SOLID mas o conteúdo é a mesma coisa: ao entregue uma coisa não editar mais a coisa, estender e não editar” João

Page 9: OOD - Princípio Open/Closed

Princípio Open/Closed• “O código que está em produção está funcionando, se

você editar o código em produção aumenta a chance de adicionar um bug. Então escreva um código que é estendível e não editável, tornando ela escalável sem edição.” João

• “Herança e polimorfismo são duas coisas ligadas da qual juntas ajudam a lidar com o OCP” Daniel

Page 10: OOD - Princípio Open/Closed

Princípio Open/Closed• “Quando falamos de OCP falamos que o

comportamento deve ser extensível e uma forma de escalar um objeto é falar de herança vertical, que é algo muito delicado (tema do próximo hangout). Quando falamos de polimorfismo falamos de várias formas de algumas coisa se comportar.” João

Page 11: OOD - Princípio Open/Closed

Princípio Open/Closed• “Escalar verticalmente é fazer uma classe filho ser do

tipo da classe pai.

Escalar horizontalmente é injetar a dependência.” João

• “A forma mais simples é passar um participante como parâmetro (não vamos entrar nos assuntos futuros).” João

• “Ou seja, estamos passando responsabilidade, delegando, e isso tem forte relação com o SRP” Daniel

Page 12: OOD - Princípio Open/Closed

Princípio Open/Closed• “Herança é ‘reaproveitar’ criando um sub tipo,

exemplo: a classe A é um tipo, e a classe B é do tipo da A também.Na questão do Polimorfismo é algo que tem várias formas, você tem uma assinatura para aquele lugar, não interessa como vão fazer.” Luíz

Page 13: OOD - Princípio Open/Closed

ExemplosENVIADOS ANONIMAMENTE PELO PÚBLICO

Page 14: OOD - Princípio Open/Closed

User

Page 15: OOD - Princípio Open/Closed

User Viola o OCP porquê deixando a configuração de servidor aqui o código terá que ser alterado

a cada mudança o servidor

Page 16: OOD - Princípio Open/Closed

User Você está assumindo que sempre irá usar PDO, se um dia a fonte de dados mudar

essa classe precisará mudar.

Page 17: OOD - Princípio Open/Closed

UserO método CREATE viola OCP por culpa do

construtor.

Page 18: OOD - Princípio Open/Closed

User Se no construtor você passasse uma interface e não direto a PDO, o método CREATE não saberia da implementação

direta da PDO.

Page 19: OOD - Princípio Open/Closed

User Inclusive há uma violação de SRP: conexão de base de dados não precisa ser de

responsabilidade dessa classe.

Page 20: OOD - Princípio Open/Closed

User

Solução: passar por parâmetro os dados de configuração (porém ainda viola o SRP)

Page 21: OOD - Princípio Open/Closed

Login

Page 22: OOD - Princípio Open/Closed

LoginEle quebra OCP pois

em uma futura evolução a classe será mudada para

adicionar condições no switch.

Pense que foi

adicionado o

tipo God.

Será necessário

adicionar um

switch case pro God.

Page 23: OOD - Princípio Open/Closed

Login

Se a lógica de um dos cases mudar a classe

será mudada.

Page 24: OOD - Princípio Open/Closed

Login

Além do que mudar a lógica de uma dessas lógicas pode quebrar

o resto do código.

Page 25: OOD - Princípio Open/Closed

Login

Solução: usar interfaces

(dica: padrão estrategy).

Page 26: OOD - Princípio Open/Closed

Pôs pauta!DISCUSSÃO ALÉM DA PAUTA E RESOLUÇÃO DE DÚVIDAS DO PÚBLICO