Slide 1
Slide 1 text
Conhecendo os princípios S.O.L.I.D.
Slide 2
Slide 2 text
Roger Albino
Slide 3
Slide 3 text
Roger Albino
• Engenheiro de Software e Líder Técnico de
JavaScript na Kazap Tecnologia.
Slide 4
Slide 4 text
Roger Albino
• Engenheiro de Software e Líder Técnico de
JavaScript na Kazap Tecnologia.
• React, React Native, NodeJS, Graphql…
Slide 5
Slide 5 text
Roger Albino
• Engenheiro de Software e Líder Técnico de
JavaScript na Kazap Tecnologia.
• React, React Native, NodeJS, Graphql…
• Sou músico
Slide 6
Slide 6 text
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 .
Slide 7
Slide 7 text
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
Slide 8
Slide 8 text
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
Slide 9
Slide 9 text
• 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
Slide 10
Slide 10 text
POO (Programação Orientada a Objetos)
Slide 11
Slide 11 text
POO (Programação Orientada a Objetos)
• Paradigma de programação
(forma de organizar o código)
Slide 12
Slide 12 text
POO (Programação Orientada a Objetos)
• Paradigma de programação
(forma de organizar o código)
• Funcional
Slide 13
Slide 13 text
POO (Programação Orientada a Objetos)
• Paradigma de programação
(forma de organizar o código)
• Funcional
• Procedural
Slide 14
Slide 14 text
POO (Programação Orientada a Objetos)
• Paradigma de programação
(forma de organizar o código)
• Funcional
• Procedural
• Outras…
Slide 15
Slide 15 text
Mundo perfeito
Slide 16
Slide 16 text
• O cliente pede uma alteração;
Mundo perfeito
Slide 17
Slide 17 text
• O cliente pede uma alteração;
• A pessoa desenvolvedora encontra facilmente e aplica a mudança
em poucos lugares;
Mundo perfeito
Slide 18
Slide 18 text
• 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
Slide 19
Slide 19 text
• 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
Slide 20
Slide 20 text
• 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
Slide 21
Slide 21 text
• 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
Slide 22
Slide 22 text
• 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
Slide 23
Slide 23 text
Realidade
Slide 24
Slide 24 text
• O cliente pede uma alteração;
Realidade
Slide 25
Slide 25 text
• 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
Slide 26
Slide 26 text
• 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
Slide 27
Slide 27 text
• 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
Slide 28
Slide 28 text
• 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
Slide 29
Slide 29 text
• 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
Slide 30
Slide 30 text
• 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
Slide 31
Slide 31 text
S.O.L.I.D
Slide 32
Slide 32 text
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)
Slide 33
Slide 33 text
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;
Slide 34
Slide 34 text
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
Slide 35
Slide 35 text
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.
Slide 36
Slide 36 text
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…
Slide 37
Slide 37 text
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…
Slide 38
Slide 38 text
Exemplos
Slide 39
Slide 39 text
OOP vs OOD
Slide 40
Slide 40 text
OOP - Object Oriented Programming
Programação orientado a objetos
Slide 41
Slide 41 text
OOD - Object Oriented Design
Design orientado a objetos
Slide 42
Slide 42 text
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)
Slide 43
Slide 43 text
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)
Slide 44
Slide 44 text
Pilares da POO
Slide 45
Slide 45 text
Pilares da POO
• Abstração (focar no que é importante)
Slide 46
Slide 46 text
Pilares da POO
• Abstração (focar no que é importante)
• Encapsulamento (esconder características e
comportamentos)
Slide 47
Slide 47 text
Pilares da POO
• Abstração (focar no que é importante)
• Encapsulamento (esconder características e
comportamentos)
• Herança (herdar características e comportamentos)
Slide 48
Slide 48 text
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)
Slide 49
Slide 49 text
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.
Slide 50
Slide 50 text
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.”
Slide 51
Slide 51 text
Sinônimos de coesão
https://www.sinonimos.com.br/coesao/
“acordo, coerência, concordância, conexão, harmonia,
nexo, unidade.”
Slide 52
Slide 52 text
Classe coesa
Uma classe coesa é aquela que possui uma única
responsabilidade.
Slide 53
Slide 53 text
No content
Slide 54
Slide 54 text
GOD Class
Slide 55
Slide 55 text
Fonte da imagem: http://collections.si.edu/search/record/nmah_1061776
GOD Class
Slide 56
Slide 56 text
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
Slide 57
Slide 57 text
Violação
class Cart {
private productList: string[] = []
public addProduct(productId: string) {/*...*/}
public removeProduct(productId: string) {/*...*/}
public getProductList() {/*...*/}
public estimateShipping(cep: number) {/*...*/}
}
Slide 58
Slide 58 text
Violação
class Cart {
private productList: string[] = []
public addProduct(productId: string) {/*...*/}
public removeProduct(productId: string) {/*...*/}
public getProductList() {/*...*/}
public estimateShipping(cep: number) {/*...*/}
}
Slide 59
Slide 59 text
Violação
class Cart {
private productList: string[] = []
public addProduct(productId: string) {/*...*/}
public removeProduct(productId: string) {/*...*/}
public getProductList() {/*...*/}
public estimateShipping(cep: number) {/*...*/}
}
Slide 60
Slide 60 text
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) {/*...*/}
}
Slide 61
Slide 61 text
Também vale para arquivos e métodos.
Slide 62
Slide 62 text
Também vale para arquivos e métodos.
Slide 63
Slide 63 text
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
Slide 64
Slide 64 text
Violação
Slide 65
Slide 65 text
Violação
class EbookEpub extends Ebook {
public downloadEpub() { /* ... */ }
}
class EbookPdf extends Ebook {
public downloadPdf() { /* ... */ }
}
Slide 66
Slide 66 text
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()
}
})
}
}
Slide 67
Slide 67 text
No content
Slide 68
Slide 68 text
E se eu adicionar mais um tipo de Ebook?
Slide 69
Slide 69 text
class EbookHtml extends Ebook {
public downloadHtml() { /* ... */ }
}
E se eu adicionar mais um tipo de Ebook?
Slide 70
Slide 70 text
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?
Slide 71
Slide 71 text
Solução
Slide 72
Slide 72 text
Solução
class EbookEpub extends Ebook {
public download() { /* ... */ }
}
class EbookPdf extends Ebook {
public download() { /* ... */ }
}
Slide 73
Slide 73 text
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() { /* ... */ }
}
Slide 74
Slide 74 text
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() { /* ... */ }
}
Slide 75
Slide 75 text
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)
Slide 76
Slide 76 text
"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
Slide 77
Slide 77 text
No content
Slide 78
Slide 78 text
• Parece um pato
Slide 79
Slide 79 text
• Parece um pato
• Faz Quack igual um pato
Slide 80
Slide 80 text
• Parece um pato
• Faz Quack igual um pato
• Mas precisa de pilhas para funcionar
Slide 81
Slide 81 text
• Parece um pato
• Faz Quack igual um pato
• Mas precisa de pilhas para funcionar
• Algo está muito errado com a nossa abstração
Slide 82
Slide 82 text
Quadrado é um tipo de retângulo.
Tem 4 lados, usa o mesmo calculo de
área…
Exemplo clássico do Quadrado e Retângulo
Slide 83
Slide 83 text
Quadrado é um tipo de retângulo.
Tem 4 lados, usa o mesmo calculo de
área…
Exemplo clássico do Quadrado e Retângulo
Slide 84
Slide 84 text
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 }
}
Slide 85
Slide 85 text
Violação
class Foo {
// BUG!!
public FooBar(retangle: Rectangle) {
retangle.width = retangle.width * 2
retangle.height = retangle.height * 2
}
}
Slide 86
Slide 86 text
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
}
}
Slide 87
Slide 87 text
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
}
}
Slide 88
Slide 88 text
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
Slide 89
Slide 89 text
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
Slide 90
Slide 90 text
Violação
Slide 91
Slide 91 text
Violação
interface Phone {
accessTheInternet(): void
takeAPicture(): void
authWithBiometry(): void
makeACall(): void
sendSms(): void
}
Slide 92
Slide 92 text
Violação
interface Phone {
accessTheInternet(): void
takeAPicture(): void
authWithBiometry(): void
makeACall(): void
sendSms(): void
}
class Smartphone implements Phone {
accessTheInternet() {/*...*/ }
takeAPicture() {/*...*/ }
authWithBiometry() {/*...*/ }
makeACall() {/*...*/ }
sendSms() {/*...*/ }
}
Slide 93
Slide 93 text
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')
}
}
Slide 94
Slide 94 text
Solução
Slide 95
Slide 95 text
Solução
interface Smartphone {
accessTheInternet(): void
takeAPicture(): void
authWithBiometry(): void
}
interface Phone {
makeACall(): void
sendSms(): void
}
Slide 96
Slide 96 text
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() {/*...*/}
}
Slide 97
Slide 97 text
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() {/*...*/}
}
Slide 98
Slide 98 text
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
Slide 99
Slide 99 text
Abstrações tendem a ser mais
estáveis que implementações
Slide 100
Slide 100 text
Entidades devem depender de
entidades mais estáveis que ela.
Slide 101
Slide 101 text
Violação
Slide 102
Slide 102 text
Violação
class Lamp {
public turnOn() {/*...*/}
public turnOff() {/*...*/}
}
Slide 103
Slide 103 text
Violação
class Lamp {
public turnOn() {/*...*/}
public turnOff() {/*...*/}
}
class Button {
constructor(lamp: Lamp) {
this._lamp = lamp
}
private _lamp: Lamp
public turnOn() {
this._device.turnOn()
}
}
Slide 104
Slide 104 text
Solução
Slide 105
Slide 105 text
Solução
interface Device {
turnOn(): void
turnOff(): void
}
Slide 106
Slide 106 text
Solução
interface Device {
turnOn(): void
turnOff(): void
}
class Button {
constructor(device: Device) {
this._device = device
}
private _device: Device
public turnOn () {
this._device.turnOn()
}
}
Slide 107
Slide 107 text
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() {/*...*/}
}
Slide 108
Slide 108 text
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() {/*...*/}
}
Slide 109
Slide 109 text
No content
Slide 110
Slide 110 text
• SRP - Classes devem ter uma única responsabilidade
Slide 111
Slide 111 text
• SRP - Classes devem ter uma única responsabilidade
Slide 112
Slide 112 text
• SRP - Classes devem ter uma única responsabilidade
• OCP - Classes devem estar abertas para extensão mas
fechadas para modificação
Slide 113
Slide 113 text
• SRP - Classes devem ter uma única responsabilidade
• OCP - Classes devem estar abertas para extensão mas
fechadas para modificação
Slide 114
Slide 114 text
• 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
Slide 115
Slide 115 text
• 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
Slide 116
Slide 116 text
• 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
Slide 117
Slide 117 text
• 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
Slide 118
Slide 118 text
• 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
Slide 119
Slide 119 text
Fique tranquilo.
Slide 120
Slide 120 text
Fique tranquilo.
Slide 121
Slide 121 text
Obrigado!
@rogeralbinoi