Princípios S.O.L.I.D - DevDay Fatec Mogi Mirim 2019

Transcript

1. Conhecendo os princípios S.O.L.I.D.
2. Roger Albino
3. Roger Albino • Engenheiro de Software e Líder Técnico de JavaScript na Kazap Tecnologia.
4. Roger Albino • Engenheiro de Software e Líder Técnico de JavaScript na Kazap Tecnologia. • React, React Native, NodeJS, Graphql…
5. Roger Albino • Engenheiro de Software e Líder Técnico de JavaScript na Kazap Tecnologia. • React, React Native, NodeJS, Graphql… • Sou músico
6. Roger Albino • Engenheiro de Software e Líder Técnico de JavaScript na Kazap Tecnologia. • React, React Native, NodeJS, Graphql… • Sou músico • Curto uma cerveja .
7. Roger Albino • Engenheiro de Software e Líder Técnico de JavaScript na Kazap Tecnologia. • React, React Native, NodeJS, Graphql… • Sou músico • Curto uma cerveja . • @rogeralbinoi
8. Roger Albino • Engenheiro de Software e Líder Técnico de JavaScript na Kazap Tecnologia. • React, React Native, NodeJS, Graphql… • Sou músico • Curto uma cerveja . • @rogeralbinoi
9. • Temos mais de 11 anos de mercado, hoje estamos no Reino Unido, Portugal e sede em Mogi Guaçu. • Nosso objetivo é facilitar a transformação digital nas organizações. • Desenvolvemos aplicações personalizadas para Web, Dispositivos moveis, interfaces conversacionais (Assistentes pessoais e Chatbots) • Ruby on Rails, JavaScript, Java, Python, machine learning… • www.kazap.com.br
10. POO (Programação Orientada a Objetos)
11. POO (Programação Orientada a Objetos) • Paradigma de programação (forma de organizar o código)
12. POO (Programação Orientada a Objetos) • Paradigma de programação (forma de organizar o código) • Funcional
13. POO (Programação Orientada a Objetos) • Paradigma de programação (forma de organizar o código) • Funcional • Procedural
14. POO (Programação Orientada a Objetos) • Paradigma de programação (forma de organizar o código) • Funcional • Procedural • Outras…
15. Mundo perfeito
16. • O cliente pede uma alteração; Mundo perfeito
17. • O cliente pede uma alteração; • A pessoa desenvolvedora encontra facilmente e aplica a mudança em poucos lugares; Mundo perfeito
18. • O cliente pede uma alteração; • A pessoa desenvolvedora encontra facilmente e aplica a mudança em poucos lugares; • Não há propagação de problemas; Mundo perfeito
19. • O cliente pede uma alteração; • A pessoa desenvolvedora encontra facilmente e aplica a mudança em poucos lugares; • Não há propagação de problemas; • Tudo tranquilo Mundo perfeito
20. • O cliente pede uma alteração; • A pessoa desenvolvedora encontra facilmente e aplica a mudança em poucos lugares; • Não há propagação de problemas; • Tudo tranquilo Mundo perfeito
21. • O cliente pede uma alteração; • A pessoa desenvolvedora encontra facilmente e aplica a mudança em poucos lugares; • Não há propagação de problemas; • Tudo tranquilo Mundo perfeito
22. • O cliente pede uma alteração; • A pessoa desenvolvedora encontra facilmente e aplica a mudança em poucos lugares; • Não há propagação de problemas; • Tudo tranquilo Mundo perfeito
23. Realidade
24. • O cliente pede uma alteração; Realidade
25. • O cliente pede uma alteração; • A pessoa desenvolvedora demora um bom tempo para encontrar onde alterar, pesquisa e altera vários lugares no código Realidade
26. • O cliente pede uma alteração; • A pessoa desenvolvedora demora um bom tempo para encontrar onde alterar, pesquisa e altera vários lugares no código • Essa pessoa esquece de alterar em alguns lugares; Realidade
27. • O cliente pede uma alteração; • A pessoa desenvolvedora demora um bom tempo para encontrar onde alterar, pesquisa e altera vários lugares no código • Essa pessoa esquece de alterar em alguns lugares; • E aí massa? Realidade
28. • O cliente pede uma alteração; • A pessoa desenvolvedora demora um bom tempo para encontrar onde alterar, pesquisa e altera vários lugares no código • Essa pessoa esquece de alterar em alguns lugares; • E aí massa? Realidade
29. • O cliente pede uma alteração; • A pessoa desenvolvedora demora um bom tempo para encontrar onde alterar, pesquisa e altera vários lugares no código • Essa pessoa esquece de alterar em alguns lugares; • E aí massa? Realidade
30. • O cliente pede uma alteração; • A pessoa desenvolvedora demora um bom tempo para encontrar onde alterar, pesquisa e altera vários lugares no código • Essa pessoa esquece de alterar em alguns lugares; • E aí massa? Realidade
31. S.O.L.I.D
32. S.O.L.I.D • Acrônimo para 5 Princípios do Design Orientado a Objetos. (que vão te ajudar a organizar melhor seu código)
33. S.O.L.I.D • Acrônimo para 5 Princípios do Design Orientado a Objetos. (que vão te ajudar a organizar melhor seu código) • Criado por Robert C. Martin (Uncle Bob), apresentado em seu artigo "The Principles of OOD” e Identificado depois por Michael Feathers;
34. S.O.L.I.D • Acrônimo para 5 Princípios do Design Orientado a Objetos. (que vão te ajudar a organizar melhor seu código) • Criado por Robert C. Martin (Uncle Bob), apresentado em seu artigo "The Principles of OOD” e Identificado depois por Michael Feathers; • http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
35. S.O.L.I.D • Acrônimo para 5 Princípios do Design Orientado a Objetos. (que vão te ajudar a organizar melhor seu código) • Criado por Robert C. Martin (Uncle Bob), apresentado em seu artigo "The Principles of OOD” e Identificado depois por Michael Feathers; • http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod • Não está ligado diretamente a um linguagem de programação.
36. S.O.L.I.D • Acrônimo para 5 Princípios do Design Orientado a Objetos. (que vão te ajudar a organizar melhor seu código) • Criado por Robert C. Martin (Uncle Bob), apresentado em seu artigo "The Principles of OOD” e Identificado depois por Michael Feathers; • http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod • Não está ligado diretamente a um linguagem de programação. • Java, C#, PHP, Typescript, Javascript…
37. S.O.L.I.D • Acrônimo para 5 Princípios do Design Orientado a Objetos. (que vão te ajudar a organizar melhor seu código) • Criado por Robert C. Martin (Uncle Bob), apresentado em seu artigo "The Principles of OOD” e Identificado depois por Michael Feathers; • http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod • Não está ligado diretamente a um linguagem de programação. • Java, C#, PHP, Typescript, Javascript…
38. Exemplos
39. OOP vs OOD
40. OOP - Object Oriented Programming Programação orientado a objetos
41. OOD - Object Oriented Design Design orientado a objetos
42. POO (Programação Orientada a Objetos) class Pessoa { nome: string idade: number constructor(nome: string, idade: number) { this.nome = nome this.idade = idade } falar() {/* ... */} andar() {/* ... */ } } const cliente = new Pessoa('Roger', 18)
43. POO (Programação Orientada a Objetos) • Classes • Atributos • Métodos • Objetos class Pessoa { nome: string idade: number constructor(nome: string, idade: number) { this.nome = nome this.idade = idade } falar() {/* ... */} andar() {/* ... */ } } const cliente = new Pessoa('Roger', 18)
44. Pilares da POO
45. Pilares da POO • Abstração (focar no que é importante)
46. Pilares da POO • Abstração (focar no que é importante) • Encapsulamento (esconder características e comportamentos)
47. Pilares da POO • Abstração (focar no que é importante) • Encapsulamento (esconder características e comportamentos) • Herança (herdar características e comportamentos)
48. Pilares da POO • Abstração (focar no que é importante) • Encapsulamento (esconder características e comportamentos) • Herança (herdar características e comportamentos) • Polimorfismo (através de abstrações, classes com métodos de mesmo nome podem fazer coisas diferentes)
49. SRP -The Single Responsibility Principle A class should have one, and only one, reason to change. OCP -The Open Closed Principle You should be able to extend a classes behavior, without modifying it. LSP -The Liskov Substitution Principle Derived classes must be substitutable for their base classes. ISP -The Interface Segregation Principle Make fine grained interfaces that are client specific. DIP -The Dependency Inversion Principle Depend on abstractions, not on concretions.
50. Coesão "coesão", in Dicionário Priberam da Língua Portuguesa [em linha], 2008-2013, https:// dicionario.priberam.org/coes%C3%A3o [consultado em 20-10-2019]. “Qualidade de uma coisa em que todas as partes estão ligadas umas às outras.”
51. Sinônimos de coesão https://www.sinonimos.com.br/coesao/ “acordo, coerência, concordância, conexão, harmonia, nexo, unidade.”
52. Classe coesa Uma classe coesa é aquela que possui uma única responsabilidade.
54. GOD Class
55. Fonte da imagem: http://collections.si.edu/search/record/nmah_1061776 GOD Class
56. SRP - The Single Responsibility Principle "A class should have one, and only one, reason to change." “Uma classe deve ter um, e apenas um motivo para mudar.” Princípio da responsabilidade única
57. Violação class Cart { private productList: string[] = [] public addProduct(productId: string) {/*...*/} public removeProduct(productId: string) {/*...*/} public getProductList() {/*...*/} public estimateShipping(cep: number) {/*...*/} }
58. Violação class Cart { private productList: string[] = [] public addProduct(productId: string) {/*...*/} public removeProduct(productId: string) {/*...*/} public getProductList() {/*...*/} public estimateShipping(cep: number) {/*...*/} }
59. Violação class Cart { private productList: string[] = [] public addProduct(productId: string) {/*...*/} public removeProduct(productId: string) {/*...*/} public getProductList() {/*...*/} public estimateShipping(cep: number) {/*...*/} }
60. Solução class Cart { private productList: string[] = [] public addProduct(productId: string) {/*...*/} public removeProduct(productId: string) {/*...*/} public getProductList() {/*...*/} } class Shipping { public estimateShipping(cep: number, cart: Cart) {/*...*/} }
61. Também vale para arquivos e métodos.
62. Também vale para arquivos e métodos.
63. OCP -The Open Closed Principle "You should be able to extend a classes behavior, without modifying it.” “Você deve ser capaz de estender o comportamento de uma classe sem modifica-la.” Princípio Aberto-Fechado
64. Violação
65. Violação class EbookEpub extends Ebook { public downloadEpub() { /* ... */ } } class EbookPdf extends Ebook { public downloadPdf() { /* ... */ } }
66. Violação class EbookEpub extends Ebook { public downloadEpub() { /* ... */ } } class EbookPdf extends Ebook { public downloadPdf() { /* ... */ } } class Ebook { public static downloadEbooks(arquivos: any[]) { arquivos.forEach((arquivo: any) => { if (arquivo.constructor.name === 'EbookEpub') { arquivo.downloadEpub() } else if (arquivo.constructor.name === 'EbookPdf') { arquivo.downloadPdf() } }) } }
68. E se eu adicionar mais um tipo de Ebook?
69. class EbookHtml extends Ebook { public downloadHtml() { /* ... */ } } E se eu adicionar mais um tipo de Ebook?
70. class EbookHtml extends Ebook { public downloadHtml() { /* ... */ } } class Ebook { public static downloadEbooks(arquivos: any[]) { arquivos.forEach((arquivo: any) => { if (arquivo.constructor.name === 'EbookEpub') { arquivo.downloadEpub() } else if (arquivo.constructor.name === 'EbookPdf') { arquivo.downloadPdf() } else if (arquivo.constructor.name === 'EbookHtml') { arquivo.downloadHtml() } }) } } E se eu adicionar mais um tipo de Ebook?
71. Solução
72. Solução class EbookEpub extends Ebook { public download() { /* ... */ } } class EbookPdf extends Ebook { public download() { /* ... */ } }
73. Solução abstract class Ebook { abstract download(): void public static downloadEbooks(arquivos: Ebook[]) { arquivos.forEach((arquivo: Ebook) => { arquivo.download() }) } } class EbookEpub extends Ebook { public download() { /* ... */ } } class EbookPdf extends Ebook { public download() { /* ... */ } }
74. Solução abstract class Ebook { abstract download(): void public static downloadEbooks(arquivos: Ebook[]) { arquivos.forEach((arquivo: Ebook) => { arquivo.download() }) } } class EbookEpub extends Ebook { public download() { /* ... */ } } class EbookPdf extends Ebook { public download() { /* ... */ } } class EbookHtml extends Ebook { public download() { /* ... */ } }
75. LSP -The Liskov Substitution Principle Princípio de substituição de Liskov • Apresentado por Barbara Liskov em 1987 Fontes: https://en.wikipedia.org/wiki/Barbara_Liskov, https://www.youtube.com/watch?v=_jTc1BTFdIo Barbara Liskov é Cientista da computação, vencedora do Turing Award e uma das primeiras mulheres a receber um doutorado em ciência da computação nos Estados Unidos. Barbara Liskov é Professora no MIT e head do PMG (Programming Methodology Group)
76. "Derived classes must be substitutable for their base classes.” “Classes derivadas devem ser substituíveis por suas classes base.” LSP -The Liskov Substitution Principle Princípio de substituição de Liskov
78. • Parece um pato
79. • Parece um pato • Faz Quack igual um pato
80. • Parece um pato • Faz Quack igual um pato • Mas precisa de pilhas para funcionar
81. • Parece um pato • Faz Quack igual um pato • Mas precisa de pilhas para funcionar • Algo está muito errado com a nossa abstração
82. Quadrado é um tipo de retângulo. Tem 4 lados, usa o mesmo calculo de área… Exemplo clássico do Quadrado e Retângulo
83. Quadrado é um tipo de retângulo. Tem 4 lados, usa o mesmo calculo de área… Exemplo clássico do Quadrado e Retângulo
84. Violação class Rectangle { constructor(width: number, height: number) { this._height = height this._width = width } protected _width: number protected _height: number get width(): number { return this._width } set width(width: number) { this._width = width } get height(): number { return this._height } set height(height: number) { this._height = height} public area() { return this._width * this._height } } class Square extends Rectangle { set height(height: number) { this._height = height this._width = height } set width(width: number) { this._height = width this._width = width } get width(): number { return this._width } get height(): number { return this._height } }
85. Violação class Foo { // BUG!! public FooBar(retangle: Rectangle) { retangle.width = retangle.width * 2 retangle.height = retangle.height * 2 } }
86. Violação Rectangle { _height: 200, _width: 400 } Rectangle { _height: 400, _width: 800 } class Foo { // BUG!! public FooBar(retangle: Rectangle) { retangle.width = retangle.width * 2 retangle.height = retangle.height * 2 } }
87. Violação Square { _height: 200, _width: 200 } Square { _height: 800, _width: 800 } class Foo { // BUG!! public FooBar(retangle: Rectangle) { retangle.width = retangle.width * 2 retangle.height = retangle.height * 2 } }
88. class Square { constructor(size) { this._size = size } protected _size: number get size() { return this._size } set size(size: number) { this._size = size } get width(): number { return this._size } get height(): number { return this._size } public area() { return this._size * this._size } } Conclusão
89. ISP -The Interface Segregation Principle "Make fine grained interfaces that are client specific.” “Crie interfaces refinadas e específicas para o cliente.” Princípio da Segregação da Interface
90. Violação
91. Violação interface Phone { accessTheInternet(): void takeAPicture(): void authWithBiometry(): void makeACall(): void sendSms(): void }
92. Violação interface Phone { accessTheInternet(): void takeAPicture(): void authWithBiometry(): void makeACall(): void sendSms(): void } class Smartphone implements Phone { accessTheInternet() {/*...*/ } takeAPicture() {/*...*/ } authWithBiometry() {/*...*/ } makeACall() {/*...*/ } sendSms() {/*...*/ } }
93. Violação interface Phone { accessTheInternet(): void takeAPicture(): void authWithBiometry(): void makeACall(): void sendSms(): void } class Smartphone implements Phone { accessTheInternet() {/*...*/ } takeAPicture() {/*...*/ } authWithBiometry() {/*...*/ } makeACall() {/*...*/ } sendSms() {/*...*/ } } class BasicPhone implements Phone { makeACall() {/*...*/ } sendSms() {/*...*/ } accessTheInternet() { throw new Error('this device can not make this') } takeAPicture() { throw new Error('this device can not make this') } authWithBiometry() { throw new Error('this device can not make this') } }
94. Solução
95. Solução interface Smartphone { accessTheInternet(): void takeAPicture(): void authWithBiometry(): void } interface Phone { makeACall(): void sendSms(): void }
96. Solução interface Smartphone { accessTheInternet(): void takeAPicture(): void authWithBiometry(): void } interface Phone { makeACall(): void sendSms(): void } class Smartphone implements Phone, Smartphone { accessTheInternet() {/*...*/} takeAPicture () {/*...*/} authWithBiometry() {/*...*/ } makeACall() {/*...*/} sendSms() {/*...*/} }
97. Solução interface Smartphone { accessTheInternet(): void takeAPicture(): void authWithBiometry(): void } interface Phone { makeACall(): void sendSms(): void } class Smartphone implements Phone, Smartphone { accessTheInternet() {/*...*/} takeAPicture () {/*...*/} authWithBiometry() {/*...*/ } makeACall() {/*...*/} sendSms() {/*...*/} } class BasicPhone implements Phone { makeACall() {/*...*/} sendSms() {/*...*/} }
98. DIP -The Dependency Inversion Principle "Depend on abstractions, not on concretions.” “Dependa de abstrações, não de implementações.” Princípio da inversão de dependências
99. Abstrações tendem a ser mais estáveis que implementações
100. Entidades devem depender de entidades mais estáveis que ela.
101. Violação
102. Violação class Lamp { public turnOn() {/*...*/} public turnOff() {/*...*/} }
103. Violação class Lamp { public turnOn() {/*...*/} public turnOff() {/*...*/} } class Button { constructor(lamp: Lamp) { this._lamp = lamp } private _lamp: Lamp public turnOn() { this._device.turnOn() } }
104. Solução
105. Solução interface Device { turnOn(): void turnOff(): void }
106. Solução interface Device { turnOn(): void turnOff(): void } class Button { constructor(device: Device) { this._device = device } private _device: Device public turnOn () { this._device.turnOn() } }
107. Solução interface Device { turnOn(): void turnOff(): void } class Button { constructor(device: Device) { this._device = device } private _device: Device public turnOn () { this._device.turnOn() } } class Lamp implements Device { public turnOn() {/*...*/} public turnOff() {/*...*/} }
108. Solução interface Device { turnOn(): void turnOff(): void } class Button { constructor(device: Device) { this._device = device } private _device: Device public turnOn () { this._device.turnOn() } } class Lamp implements Device { public turnOn() {/*...*/} public turnOff() {/*...*/} } class Fan implements Device { public turnOn() {/*...*/} public turnOff() {/*...*/} }
110. • SRP - Classes devem ter uma única responsabilidade
111. • SRP - Classes devem ter uma única responsabilidade
112. • SRP - Classes devem ter uma única responsabilidade • OCP - Classes devem estar abertas para extensão mas fechadas para modificação
113. • SRP - Classes devem ter uma única responsabilidade • OCP - Classes devem estar abertas para extensão mas fechadas para modificação
114. • SRP - Classes devem ter uma única responsabilidade • OCP - Classes devem estar abertas para extensão mas fechadas para modificação • LSP - Classes devem ser substituíveis pelas suas classes base
115. • SRP - Classes devem ter uma única responsabilidade • OCP - Classes devem estar abertas para extensão mas fechadas para modificação • LSP - Classes devem ser substituíveis pelas suas classes base
116. • SRP - Classes devem ter uma única responsabilidade • OCP - Classes devem estar abertas para extensão mas fechadas para modificação • LSP - Classes devem ser substituíveis pelas suas classes base • ISP -Evite interfaces gordas
117. • SRP - Classes devem ter uma única responsabilidade • OCP - Classes devem estar abertas para extensão mas fechadas para modificação • LSP - Classes devem ser substituíveis pelas suas classes base • ISP -Evite interfaces gordas
118. • SRP - Classes devem ter uma única responsabilidade • OCP - Classes devem estar abertas para extensão mas fechadas para modificação • LSP - Classes devem ser substituíveis pelas suas classes base • ISP -Evite interfaces gordas • DIP -Dependa de abstrações e não de implementações
119. Fique tranquilo.
120. Fique tranquilo.
121. Obrigado! @rogeralbinoi