O documento discute o Princípio da Responsabilidade Única no design de software orientado a objetos. Aborda o que são princípios de design, explica o Princípio da Responsabilidade Única e como identificar as responsabilidades de um objeto. Também ilustra exemplos do mundo real através de frameworks e bibliotecas, mostrando como o uso deste princípio trouxe consequências positivas. Por fim, apresenta exemplos enviados previamente por participantes para discussão.

1. Hangout OOD – Princípio
da Responsabilidade
Única
03/06/2014

2. Participantes:
• João Batista Neto - Hoster
• Augusto Pascutti - Moderador
• Priscila Mayumi Sato – Slider maker
• Ivo nascimento – Controlador do chat
• Luís Otavio
• Henrique Moody
• Daniel Ribeiro

3. Pauta
• Enfatizar o que são princípios de design.
• Abordar, com profundidade e exemplos, o princípio de design S.R.P.
• O que é responsabilidade?
• Como identificar as responsabilidade de um objeto?
• Ilustrar casos do mundo real, através de exemplos em frameworks ou
bibliotecas conhecidas, o uso de S.R.P. e as consequências que esse uso
trouxe para o FW ou biblioteca.
• Pôs pauta: discutir exemplos enviados previamente por cobaias.

4. Princípios de design

5. O Design de Software Orientado a Objetos trata
especificamente da forma com que os objetos se
relacionam, ou seja, como expor a responsabilidade dos
objetos de forma que outros objetos possam se
relacionar.
Vá entender realmente o que é Orientação a Objetos
antes de sair convertendo um código procedural dentro
de classes e chamar isso de Orientação a Objetos.
Decorar todos os Desing Patterns não irá te salvar no dia
a dia.

6. Princípio de design S.R.P.

7. Os motivos dos métodos de uma classe devem
fazer sentido e esta deve fazer conhecer seus
comportamentos sem causar transtorno ao resto
da aplicação.
Why on earth then does the class have a method called
priceFilter() in the middle of it? That method is not defined
by the interface, and if you look at the class name – which
should at least indicate the reason for it to exist – you can
most certainly say that it doesn’t belong to that context.
Como um método
representa UMA ação/comportamento do objeto, ele não
deve ser grande (10~15 linhas) e com isso você terá
classes pequenas (elas sendo bem dividas e talz não
deverão ter mais de 130 linhas não comentadas) .

8. Exemplo
Source: https://gist.github.com/drgomesp/852b7afe7a270958c22a

9. Pôs pauta!

10. • https://gist.github.com/Bolinha1/5112789
Cobaia 1: classe de Desvio Padrão
Métodos:
• _construtor($amostra)
• media()
• somaQuadradodoDesvio()
• desvioPadraoPopulacional()
• desvioPadraoAmostra()

11. • https://gist.github.com/Bolinha1/5112789
Álibi (ou não): teste