$30 off During Our Annual Pro Sale. View Details »

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. Conhecendo os princípios S.O.L.I.D.

    View Slide

  2. Roger Albino

    View Slide

  3. Roger Albino
    • Engenheiro de Software e Líder Técnico de
    JavaScript na Kazap Tecnologia.

    View Slide

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

    View Slide

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

    View Slide

  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 .

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  10. POO (Programação Orientada a Objetos)

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  15. Mundo perfeito

    View Slide

  16. • O cliente pede uma alteração;
    Mundo perfeito

    View Slide

  17. • O cliente pede uma alteração;
    • A pessoa desenvolvedora encontra facilmente e aplica a mudança
    em poucos lugares;
    Mundo perfeito

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  23. Realidade

    View Slide

  24. • O cliente pede uma alteração;
    Realidade

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  31. S.O.L.I.D

    View Slide

  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)

    View Slide

  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;

    View Slide

  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

    View Slide

  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.

    View Slide

  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…

    View Slide

  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…

    View Slide

  38. Exemplos

    View Slide

  39. OOP vs OOD

    View Slide

  40. OOP - Object Oriented Programming
    Programação orientado a objetos

    View Slide

  41. OOD - Object Oriented Design
    Design orientado a objetos

    View Slide

  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)

    View Slide

  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)

    View Slide

  44. Pilares da POO

    View Slide

  45. Pilares da POO
    • Abstração (focar no que é importante)

    View Slide

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

    View Slide

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

    View Slide

  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)

    View Slide

  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.

    View Slide

  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.”

    View Slide

  51. Sinônimos de coesão
    https://www.sinonimos.com.br/coesao/
    “acordo, coerência, concordância, conexão, harmonia,
    nexo, unidade.”

    View Slide

  52. Classe coesa
    Uma classe coesa é aquela que possui uma única
    responsabilidade.

    View Slide

  53. View Slide

  54. GOD Class

    View Slide

  55. Fonte da imagem: http://collections.si.edu/search/record/nmah_1061776
    GOD Class

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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) {/*...*/}
    }

    View Slide

  61. Também vale para arquivos e métodos.

    View Slide

  62. Também vale para arquivos e métodos.

    View Slide

  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

    View Slide

  64. Violação

    View Slide

  65. Violação
    class EbookEpub extends Ebook {
    public downloadEpub() { /* ... */ }
    }
    class EbookPdf extends Ebook {
    public downloadPdf() { /* ... */ }
    }

    View Slide

  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()
    }
    })
    }
    }

    View Slide

  67. View Slide

  68. E se eu adicionar mais um tipo de Ebook?

    View Slide

  69. class EbookHtml extends Ebook {
    public downloadHtml() { /* ... */ }
    }
    E se eu adicionar mais um tipo de Ebook?

    View Slide

  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?

    View Slide

  71. Solução

    View Slide

  72. Solução
    class EbookEpub extends Ebook {
    public download() { /* ... */ }
    }
    class EbookPdf extends Ebook {
    public download() { /* ... */ }
    }

    View Slide

  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() { /* ... */ }
    }

    View Slide

  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() { /* ... */ }
    }

    View Slide

  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)

    View Slide

  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

    View Slide

  77. View Slide

  78. • Parece um pato

    View Slide

  79. • Parece um pato
    • Faz Quack igual um pato

    View Slide

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

    View Slide

  81. • Parece um pato
    • Faz Quack igual um pato
    • Mas precisa de pilhas para funcionar
    • Algo está muito errado com a nossa abstração

    View Slide

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

    View Slide

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

    View Slide

  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 }
    }

    View Slide

  85. Violação
    class Foo {
    // BUG!!
    public FooBar(retangle: Rectangle) {
    retangle.width = retangle.width * 2
    retangle.height = retangle.height * 2
    }
    }

    View Slide

  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
    }
    }

    View Slide

  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
    }
    }

    View Slide

  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

    View Slide

  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

    View Slide

  90. Violação

    View Slide

  91. Violação
    interface Phone {
    accessTheInternet(): void
    takeAPicture(): void
    authWithBiometry(): void
    makeACall(): void
    sendSms(): void
    }

    View Slide

  92. Violação
    interface Phone {
    accessTheInternet(): void
    takeAPicture(): void
    authWithBiometry(): void
    makeACall(): void
    sendSms(): void
    }
    class Smartphone implements Phone {
    accessTheInternet() {/*...*/ }
    takeAPicture() {/*...*/ }
    authWithBiometry() {/*...*/ }
    makeACall() {/*...*/ }
    sendSms() {/*...*/ }
    }

    View Slide

  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')
    }
    }

    View Slide

  94. Solução

    View Slide

  95. Solução
    interface Smartphone {
    accessTheInternet(): void
    takeAPicture(): void
    authWithBiometry(): void
    }
    interface Phone {
    makeACall(): void
    sendSms(): void
    }

    View Slide

  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() {/*...*/}
    }

    View Slide

  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() {/*...*/}
    }

    View Slide

  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

    View Slide

  99. Abstrações tendem a ser mais
    estáveis que implementações

    View Slide

  100. Entidades devem depender de
    entidades mais estáveis que ela.

    View Slide

  101. Violação

    View Slide

  102. Violação
    class Lamp {
    public turnOn() {/*...*/}
    public turnOff() {/*...*/}
    }

    View Slide

  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()
    }
    }

    View Slide

  104. Solução

    View Slide

  105. Solução
    interface Device {
    turnOn(): void
    turnOff(): void
    }

    View Slide

  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()
    }
    }

    View Slide

  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() {/*...*/}
    }

    View Slide

  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() {/*...*/}
    }

    View Slide

  109. View Slide

  110. • SRP - Classes devem ter uma única responsabilidade

    View Slide

  111. • SRP - Classes devem ter uma única responsabilidade

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  119. Fique tranquilo.

    View Slide

  120. Fique tranquilo.

    View Slide

  121. Obrigado!
    @rogeralbinoi

    View Slide