Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Roger Albino

October 26, 2019
Tweet

More Decks by Roger Albino

Other Decks in Programming

Transcript

  1. Roger Albino • Engenheiro de Software e Líder Técnico de

    JavaScript na Kazap Tecnologia. • React, React Native, NodeJS, Graphql…
  2. Roger Albino • Engenheiro de Software e Líder Técnico de

    JavaScript na Kazap Tecnologia. • React, React Native, NodeJS, Graphql… • Sou músico
  3. 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 .
  4. 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
  5. 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
  6. • 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
  7. POO (Programação Orientada a Objetos) • Paradigma de programação (forma

    de organizar o código) • Funcional • Procedural
  8. POO (Programação Orientada a Objetos) • Paradigma de programação (forma

    de organizar o código) • Funcional • Procedural • Outras…
  9. • O cliente pede uma alteração; • A pessoa desenvolvedora

    encontra facilmente e aplica a mudança em poucos lugares; Mundo perfeito
  10. • 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
  11. • 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
  12. • 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
  13. • 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
  14. • 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
  15. • 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
  16. • 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
  17. • 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
  18. • 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
  19. • 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
  20. • 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
  21. 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)
  22. 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;
  23. 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
  24. 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.
  25. 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…
  26. 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…
  27. 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)
  28. 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)
  29. Pilares da POO • Abstração (focar no que é importante)

    • Encapsulamento (esconder características e comportamentos)
  30. Pilares da POO • Abstração (focar no que é importante)

    • Encapsulamento (esconder características e comportamentos) • Herança (herdar características e comportamentos)
  31. 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)
  32. 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.
  33. 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.”
  34. 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
  35. Violação class Cart { private productList: string[] = [] public

    addProduct(productId: string) {/*...*/} public removeProduct(productId: string) {/*...*/} public getProductList() {/*...*/} public estimateShipping(cep: number) {/*...*/} }
  36. Violação class Cart { private productList: string[] = [] public

    addProduct(productId: string) {/*...*/} public removeProduct(productId: string) {/*...*/} public getProductList() {/*...*/} public estimateShipping(cep: number) {/*...*/} }
  37. Violação class Cart { private productList: string[] = [] public

    addProduct(productId: string) {/*...*/} public removeProduct(productId: string) {/*...*/} public getProductList() {/*...*/} public estimateShipping(cep: number) {/*...*/} }
  38. 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) {/*...*/} }
  39. 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
  40. Violação class EbookEpub extends Ebook { public downloadEpub() { /*

    ... */ } } class EbookPdf extends Ebook { public downloadPdf() { /* ... */ } }
  41. 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() } }) } }
  42. class EbookHtml extends Ebook { public downloadHtml() { /* ...

    */ } } E se eu adicionar mais um tipo de Ebook?
  43. 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?
  44. Solução class EbookEpub extends Ebook { public download() { /*

    ... */ } } class EbookPdf extends Ebook { public download() { /* ... */ } }
  45. 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() { /* ... */ } }
  46. 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() { /* ... */ } }
  47. 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)
  48. "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
  49. • Parece um pato • Faz Quack igual um pato

    • Mas precisa de pilhas para funcionar
  50. • Parece um pato • Faz Quack igual um pato

    • Mas precisa de pilhas para funcionar • Algo está muito errado com a nossa abstração
  51. Quadrado é um tipo de retângulo. Tem 4 lados, usa

    o mesmo calculo de área… Exemplo clássico do Quadrado e Retângulo
  52. Quadrado é um tipo de retângulo. Tem 4 lados, usa

    o mesmo calculo de área… Exemplo clássico do Quadrado e Retângulo
  53. 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 } }
  54. Violação class Foo { // BUG!! public FooBar(retangle: Rectangle) {

    retangle.width = retangle.width * 2 retangle.height = retangle.height * 2 } }
  55. 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 } }
  56. 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 } }
  57. 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
  58. 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
  59. Violação interface Phone { accessTheInternet(): void takeAPicture(): void authWithBiometry(): void

    makeACall(): void sendSms(): void } class Smartphone implements Phone { accessTheInternet() {/*...*/ } takeAPicture() {/*...*/ } authWithBiometry() {/*...*/ } makeACall() {/*...*/ } sendSms() {/*...*/ } }
  60. 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') } }
  61. 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() {/*...*/} }
  62. 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() {/*...*/} }
  63. 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
  64. Violação class Lamp { public turnOn() {/*...*/} public turnOff() {/*...*/}

    } class Button { constructor(lamp: Lamp) { this._lamp = lamp } private _lamp: Lamp public turnOn() { this._device.turnOn() } }
  65. Solução interface Device { turnOn(): void turnOff(): void } class

    Button { constructor(device: Device) { this._device = device } private _device: Device public turnOn () { this._device.turnOn() } }
  66. 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() {/*...*/} }
  67. 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() {/*...*/} }
  68. • SRP - Classes devem ter uma única responsabilidade •

    OCP - Classes devem estar abertas para extensão mas fechadas para modificação
  69. • SRP - Classes devem ter uma única responsabilidade •

    OCP - Classes devem estar abertas para extensão mas fechadas para modificação
  70. • 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
  71. • 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
  72. • 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
  73. • 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
  74. • 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