O documento discute o Princípio da Substituição de Liskov (LSP), um dos cinco princípios do SOLID para programação orientada a objetos. O LSP estabelece que classes derivadas devem ser substituíveis por suas classes base sem alterar o comportamento do programa. O documento ilustra uma violação do LSP ao herdar uma classe Quadrado de uma classe Retângulo, alterando inadvertidamente seu comportamento.
O documento discute os conceitos fundamentais da lógica de primeira ordem, incluindo sua linguagem, termos, fórmulas, variáveis, estruturas e semântica. É definido que uma linguagem de primeira ordem consiste em símbolos lógicos, variáveis, símbolos de igualdade, quantificadores, símbolos predicativos e de funções/constantes. Fórmulas são construídas a partir de termos usando quantificadores e conectivos lógicos. Estruturas fornecem interpretações dos quantificadores e símbolos na lingu
O documento discute o Princípio de Estabilidade e Abstração (SAP), que estabelece que pacotes mais estáveis devem ser mais abstratos, enquanto pacotes instáveis podem ser mais concretos. Ele fornece métricas como acoplamentos aferentes e eferentes para medir a estabilidade dos pacotes e recomenda que as dependências sigam a direção da estabilidade.
O documento discute o Princípio de Substituição de Liskov (LSP), no qual subclasses devem ser substituíveis por suas superclasses sem alterar a funcionalidade do programa. Ele apresenta um exemplo em que uma classe Quadrado herda de Retângulo, violando o LSP ao sobrescrever métodos e alterar o comportamento esperado.
O documento discute o Princípio de Substituição de Liskov (LSP), no qual subclasses devem ser substituíveis por suas superclasses sem alterar a funcionalidade do programa. Ele apresenta um exemplo em que uma classe Quadrado herda de Retângulo, violando o LSP ao sobrescrever métodos e alterar o comportamento esperado.
O documento descreve os 5 princípios do SOLID para desenvolvimento de software, sendo eles: SRP (responsabilidade única), OCP (aberto/fechado), LSP (substituição de Liskov), ISP (segregação de interfaces) e DIP (inversão de dependência), que visam evitar códigos complexos e difíceis de manter.
Os princípios SOLID descrevem cinco princípios da programação orientada a objetos: SRP (responsabilidade única), OCP (aberto/fechado), LSP (substituição de Liskov), ISP (segregação de interface) e DIP (inversão de dependência), que objetivam criar software flexível, reutilizável e de fácil manutenção.
1. O documento discute as características e modelos de dados do NoSQL, incluindo bancos de dados de chave-valor, documentos, famílias de colunas e grafos.
2. As principais características do NoSQL incluem a falta de uso do SQL, código aberto, clusterização, ausência de esquema e uso do padrão map-reduce.
3. Técnicas de escalabilidade como sharding e replicação mestre-escravo são discutidas no contexto de bancos de dados NoSQL.
Este documento apresenta os cinco princípios SOLID da programação orientada a objetos: Princípio da Responsabilidade Única (SRP), Princípio Aberto-Fechado (OCP), Princípio da Substituição de Liskov (LSP), Princípio da Segregação de Interface (ISP) e Princípio da Inversão de Dependência (DIP). Estes princípios promovem código mais extensível, manutenível e testável, com classes de responsabilidades bem definidas e baixo acoplamento entre elas.
O documento discute os conceitos fundamentais da lógica de primeira ordem, incluindo sua linguagem, termos, fórmulas, variáveis, estruturas e semântica. É definido que uma linguagem de primeira ordem consiste em símbolos lógicos, variáveis, símbolos de igualdade, quantificadores, símbolos predicativos e de funções/constantes. Fórmulas são construídas a partir de termos usando quantificadores e conectivos lógicos. Estruturas fornecem interpretações dos quantificadores e símbolos na lingu
O documento discute o Princípio de Estabilidade e Abstração (SAP), que estabelece que pacotes mais estáveis devem ser mais abstratos, enquanto pacotes instáveis podem ser mais concretos. Ele fornece métricas como acoplamentos aferentes e eferentes para medir a estabilidade dos pacotes e recomenda que as dependências sigam a direção da estabilidade.
O documento discute o Princípio de Substituição de Liskov (LSP), no qual subclasses devem ser substituíveis por suas superclasses sem alterar a funcionalidade do programa. Ele apresenta um exemplo em que uma classe Quadrado herda de Retângulo, violando o LSP ao sobrescrever métodos e alterar o comportamento esperado.
O documento discute o Princípio de Substituição de Liskov (LSP), no qual subclasses devem ser substituíveis por suas superclasses sem alterar a funcionalidade do programa. Ele apresenta um exemplo em que uma classe Quadrado herda de Retângulo, violando o LSP ao sobrescrever métodos e alterar o comportamento esperado.
O documento descreve os 5 princípios do SOLID para desenvolvimento de software, sendo eles: SRP (responsabilidade única), OCP (aberto/fechado), LSP (substituição de Liskov), ISP (segregação de interfaces) e DIP (inversão de dependência), que visam evitar códigos complexos e difíceis de manter.
Os princípios SOLID descrevem cinco princípios da programação orientada a objetos: SRP (responsabilidade única), OCP (aberto/fechado), LSP (substituição de Liskov), ISP (segregação de interface) e DIP (inversão de dependência), que objetivam criar software flexível, reutilizável e de fácil manutenção.
1. O documento discute as características e modelos de dados do NoSQL, incluindo bancos de dados de chave-valor, documentos, famílias de colunas e grafos.
2. As principais características do NoSQL incluem a falta de uso do SQL, código aberto, clusterização, ausência de esquema e uso do padrão map-reduce.
3. Técnicas de escalabilidade como sharding e replicação mestre-escravo são discutidas no contexto de bancos de dados NoSQL.
Este documento apresenta os cinco princípios SOLID da programação orientada a objetos: Princípio da Responsabilidade Única (SRP), Princípio Aberto-Fechado (OCP), Princípio da Substituição de Liskov (LSP), Princípio da Segregação de Interface (ISP) e Princípio da Inversão de Dependência (DIP). Estes princípios promovem código mais extensível, manutenível e testável, com classes de responsabilidades bem definidas e baixo acoplamento entre elas.
O documento discute o Princípio de Estabilidade e Abstração (SAP), que estabelece que pacotes mais estáveis devem ser mais abstratos, enquanto pacotes instáveis podem ser mais concretos. Ele fornece métricas como acoplamentos aferentes e eferentes para medir a estabilidade dos pacotes e recomenda que as dependências sigam a direção da estabilidade.
Pacotes que são maximamente ESTÁVEIS devem ser maximamente ABSTRATOS. PACOTES instáveis DEVEM SER CONCRETOS. A abstração de um pacote deve ser PROPORCIONAL a sua estabilidade.
O Common Closure Principle (CCP) propõe que classes que provavelmente mudarão juntas por uma mesma razão devem estar no mesmo pacote, de modo que uma mudança afete todas as classes desse pacote e nenhum outro. O CCP generaliza o Single Responsibility Principle defendendo que classes dependentes permaneçam juntas no código para facilitar a manutenção.
O Common Closure Principle (CCP) propõe que classes que provavelmente mudarão juntas devem ser agrupadas no mesmo pacote, de modo que uma mudança afete todas as classes desse pacote. O princípio visa manter classes dependentes juntas para facilitar a manutenção do código. Uma mudança deve ser restrita a um único pacote, evitando impactos em outros pacotes.
O documento descreve o Princípio da Dependência Acíclica (ADP), que define que as dependências entre pacotes ou componentes não devem formar ciclos, para que os pacotes sejam mais facilmente reutilizáveis e testáveis de forma independente. O documento explica como dividir um sistema em pacotes separados permite que equipes trabalhem de forma independente em cada pacote.
O documento descreve o princípio AcyclicDependenciesPrinciple (ADP), que define que as dependências entre pacotes ou componentes não devem formar ciclos, para que os pacotes sejam mais reutilizáveis e de fácil compreensão. A solução proposta é dividir o desenvolvimento em pacotes independentes, de modo que cada equipe trabalhe em seu pacote específico.
A unidade de reuso é a unidade da versão. Apenas componentes que possuem um
sistema de rastreamento de versão podem ter reuso efetivo. Esta unidade é o pacote.
A unidade de reuso é a unidade da versão. Apenas componentes que possuem um
sistema de rastreamento de versão podem ter reuso efetivo. Esta unidade é o pacote.
O documento descreve o Princípio Aberto/Fechado (OCP), que estabelece que entidades devem poder ser estendidas sem serem modificadas. O OCP encoraja adicionar novo código ao invés de modificar o existente, facilitando a manutenção. Ele é aplicado usando classes abstratas e subclasses concretas, permitindo estender o comportamento sem alterar o código original.
Este documento discute os Princípios das Dependências Estáveis, que estabelecem que as dependências entre pacotes devem seguir o sentido da estabilidade, de modo que um pacote dependa apenas de outros pacotes mais estáveis. Pacotes são definidos como estáveis ou instáveis e o princípio estabelece que pacotes instáveis não devem depender de pacotes igualmente ou mais instáveis. Métricas como acoplamentos aferentes e eferentes podem medir a estabilidade dos pacotes.
O documento discute o Princípio da Reutilização Comum (CRP), que estabelece que as classes dentro de um pacote são reutilizadas em conjunto, de modo que se uma classe em um pacote for utilizada, todas as outras classes desse pacote também serão utilizadas. O documento explica que apenas classes coesas devem ser empacotadas juntas e que a inadequada seleção de classes pode criar dependências indesejáveis. Ilustra como as classes dentro de um pacote estão interligadas e como uma alteração em uma classe requer a redistribuição de
O documento discute o Princípio da Lei de Demeter, que propõe que cada unidade de software deve ter conhecimento limitado sobre outras unidades. Isso promove baixo acoplamento entre as unidades e facilita a manutenção do código. O documento apresenta um exemplo de código que viola este princípio e como refatorá-lo para seguir a lei de Demeter.
O documento discute o Princípio da Lei de Demeter (LOD), que promove baixo acoplamento entre classes limitando o conhecimento de cada classe. O texto apresenta um exemplo de violação desse princípio e como corrigi-lo removendo a dependência direta entre as classes Jornaleiro e Carteira.
O documento discute o Princípio da Inversão de Dependência (DIP), que estabelece que módulos de alto nível não devem depender de módulos de baixo nível, mas sim de abstrações, e abstrações não devem depender de detalhes, mas sim os detalhes das abstrações. O documento apresenta um exemplo de cálculo de salário antes e depois da aplicação do DIP.
O documento descreve o Princípio da Inversão de Dependência e como ele pode ser implementado usando os padrões Template Method e Strategy. Antes as classes de alto nível dependiam diretamente das classes de baixo nível, agora elas dependem de abstrações que não dependem de detalhes implementados.
O documento discute o Princípio da Segregação de Interfaces (ISP), que afirma que classes não devem implementar interfaces que não são usadas. Isso ajuda a evitar interfaces poluídas com métodos desnecessários. O documento explica como separar interfaces poluídas em interfaces específicas para que classes dependam apenas dos métodos que realmente usam.
O documento explica o Princípio da Responsabilidade Única (SRP), que diz que cada classe deve ter apenas uma razão para mudar. Isso promove classes coesas e isola fontes de mudança. O documento fornece exemplos de como aplicar o SRP corretamente, dividindo classes com múltiplas responsabilidades em classes com responsabilidades únicas.
O documento discute o Princípio da Lei de Demeter (LOD), que promove baixo acoplamento entre classes limitando o conhecimento de cada classe. O texto apresenta um exemplo de violação desse princípio e como corrigi-lo removendo a dependência direta entre as classes Jornaleiro e Carteira.
Este certificado confirma que Gabriel de Mattos Faustino concluiu com sucesso um curso de 42 horas de Gestão Estratégica de TI - ITIL na Escola Virtual entre 19 de fevereiro de 2014 a 20 de fevereiro de 2014.
O documento discute o Princípio de Estabilidade e Abstração (SAP), que estabelece que pacotes mais estáveis devem ser mais abstratos, enquanto pacotes instáveis podem ser mais concretos. Ele fornece métricas como acoplamentos aferentes e eferentes para medir a estabilidade dos pacotes e recomenda que as dependências sigam a direção da estabilidade.
Pacotes que são maximamente ESTÁVEIS devem ser maximamente ABSTRATOS. PACOTES instáveis DEVEM SER CONCRETOS. A abstração de um pacote deve ser PROPORCIONAL a sua estabilidade.
O Common Closure Principle (CCP) propõe que classes que provavelmente mudarão juntas por uma mesma razão devem estar no mesmo pacote, de modo que uma mudança afete todas as classes desse pacote e nenhum outro. O CCP generaliza o Single Responsibility Principle defendendo que classes dependentes permaneçam juntas no código para facilitar a manutenção.
O Common Closure Principle (CCP) propõe que classes que provavelmente mudarão juntas devem ser agrupadas no mesmo pacote, de modo que uma mudança afete todas as classes desse pacote. O princípio visa manter classes dependentes juntas para facilitar a manutenção do código. Uma mudança deve ser restrita a um único pacote, evitando impactos em outros pacotes.
O documento descreve o Princípio da Dependência Acíclica (ADP), que define que as dependências entre pacotes ou componentes não devem formar ciclos, para que os pacotes sejam mais facilmente reutilizáveis e testáveis de forma independente. O documento explica como dividir um sistema em pacotes separados permite que equipes trabalhem de forma independente em cada pacote.
O documento descreve o princípio AcyclicDependenciesPrinciple (ADP), que define que as dependências entre pacotes ou componentes não devem formar ciclos, para que os pacotes sejam mais reutilizáveis e de fácil compreensão. A solução proposta é dividir o desenvolvimento em pacotes independentes, de modo que cada equipe trabalhe em seu pacote específico.
A unidade de reuso é a unidade da versão. Apenas componentes que possuem um
sistema de rastreamento de versão podem ter reuso efetivo. Esta unidade é o pacote.
A unidade de reuso é a unidade da versão. Apenas componentes que possuem um
sistema de rastreamento de versão podem ter reuso efetivo. Esta unidade é o pacote.
O documento descreve o Princípio Aberto/Fechado (OCP), que estabelece que entidades devem poder ser estendidas sem serem modificadas. O OCP encoraja adicionar novo código ao invés de modificar o existente, facilitando a manutenção. Ele é aplicado usando classes abstratas e subclasses concretas, permitindo estender o comportamento sem alterar o código original.
Este documento discute os Princípios das Dependências Estáveis, que estabelecem que as dependências entre pacotes devem seguir o sentido da estabilidade, de modo que um pacote dependa apenas de outros pacotes mais estáveis. Pacotes são definidos como estáveis ou instáveis e o princípio estabelece que pacotes instáveis não devem depender de pacotes igualmente ou mais instáveis. Métricas como acoplamentos aferentes e eferentes podem medir a estabilidade dos pacotes.
O documento discute o Princípio da Reutilização Comum (CRP), que estabelece que as classes dentro de um pacote são reutilizadas em conjunto, de modo que se uma classe em um pacote for utilizada, todas as outras classes desse pacote também serão utilizadas. O documento explica que apenas classes coesas devem ser empacotadas juntas e que a inadequada seleção de classes pode criar dependências indesejáveis. Ilustra como as classes dentro de um pacote estão interligadas e como uma alteração em uma classe requer a redistribuição de
O documento discute o Princípio da Lei de Demeter, que propõe que cada unidade de software deve ter conhecimento limitado sobre outras unidades. Isso promove baixo acoplamento entre as unidades e facilita a manutenção do código. O documento apresenta um exemplo de código que viola este princípio e como refatorá-lo para seguir a lei de Demeter.
O documento discute o Princípio da Lei de Demeter (LOD), que promove baixo acoplamento entre classes limitando o conhecimento de cada classe. O texto apresenta um exemplo de violação desse princípio e como corrigi-lo removendo a dependência direta entre as classes Jornaleiro e Carteira.
O documento discute o Princípio da Inversão de Dependência (DIP), que estabelece que módulos de alto nível não devem depender de módulos de baixo nível, mas sim de abstrações, e abstrações não devem depender de detalhes, mas sim os detalhes das abstrações. O documento apresenta um exemplo de cálculo de salário antes e depois da aplicação do DIP.
O documento descreve o Princípio da Inversão de Dependência e como ele pode ser implementado usando os padrões Template Method e Strategy. Antes as classes de alto nível dependiam diretamente das classes de baixo nível, agora elas dependem de abstrações que não dependem de detalhes implementados.
O documento discute o Princípio da Segregação de Interfaces (ISP), que afirma que classes não devem implementar interfaces que não são usadas. Isso ajuda a evitar interfaces poluídas com métodos desnecessários. O documento explica como separar interfaces poluídas em interfaces específicas para que classes dependam apenas dos métodos que realmente usam.
O documento explica o Princípio da Responsabilidade Única (SRP), que diz que cada classe deve ter apenas uma razão para mudar. Isso promove classes coesas e isola fontes de mudança. O documento fornece exemplos de como aplicar o SRP corretamente, dividindo classes com múltiplas responsabilidades em classes com responsabilidades únicas.
O documento discute o Princípio da Lei de Demeter (LOD), que promove baixo acoplamento entre classes limitando o conhecimento de cada classe. O texto apresenta um exemplo de violação desse princípio e como corrigi-lo removendo a dependência direta entre as classes Jornaleiro e Carteira.
Este certificado confirma que Gabriel de Mattos Faustino concluiu com sucesso um curso de 42 horas de Gestão Estratégica de TI - ITIL na Escola Virtual entre 19 de fevereiro de 2014 a 20 de fevereiro de 2014.
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...Faga1939
Este artigo tem por objetivo apresentar como ocorreu a evolução do consumo e da produção de energia desde a pré-história até os tempos atuais, bem como propor o futuro da energia requerido para o mundo. Da pré-história até o século XVIII predominou o uso de fontes renováveis de energia como a madeira, o vento e a energia hidráulica. Do século XVIII até a era contemporânea, os combustíveis fósseis predominaram com o carvão e o petróleo, mas seu uso chegará ao fim provavelmente a partir do século XXI para evitar a mudança climática catastrófica global resultante de sua utilização ao emitir gases do efeito estufa responsáveis pelo aquecimento global. Com o fim da era dos combustíveis fósseis virá a era das fontes renováveis de energia quando prevalecerá a utilização da energia hidrelétrica, energia solar, energia eólica, energia das marés, energia das ondas, energia geotérmica, energia da biomassa e energia do hidrogênio. Não existem dúvidas de que as atividades humanas sobre a Terra provocam alterações no meio ambiente em que vivemos. Muitos destes impactos ambientais são provenientes da geração, manuseio e uso da energia com o uso de combustíveis fósseis. A principal razão para a existência desses impactos ambientais reside no fato de que o consumo mundial de energia primária proveniente de fontes não renováveis (petróleo, carvão, gás natural e nuclear) corresponde a aproximadamente 88% do total, cabendo apenas 12% às fontes renováveis. Independentemente das várias soluções que venham a ser adotadas para eliminar ou mitigar as causas do efeito estufa, a mais importante ação é, sem dúvidas, a adoção de medidas que contribuam para a eliminação ou redução do consumo de combustíveis fósseis na produção de energia, bem como para seu uso mais eficiente nos transportes, na indústria, na agropecuária e nas cidades (residências e comércio), haja vista que o uso e a produção de energia são responsáveis por 57% dos gases de estufa emitidos pela atividade humana. Neste sentido, é imprescindível a implantação de um sistema de energia sustentável no mundo. Em um sistema de energia sustentável, a matriz energética mundial só deveria contar com fontes de energia limpa e renováveis (hidroelétrica, solar, eólica, hidrogênio, geotérmica, das marés, das ondas e biomassa), não devendo contar, portanto, com o uso dos combustíveis fósseis (petróleo, carvão e gás natural).
As classes de modelagem podem ser comparadas a moldes ou
formas que definem as características e os comportamentos dos
objetos criados a partir delas. Vale traçar um paralelo com o projeto de
um automóvel. Os engenheiros definem as medidas, a quantidade de
portas, a potência do motor, a localização do estepe, dentre outras
descrições necessárias para a fabricação de um veículo
Em um mundo cada vez mais digital, a segurança da informação tornou-se essencial para proteger dados pessoais e empresariais contra ameaças cibernéticas. Nesta apresentação, abordaremos os principais conceitos e práticas de segurança digital, incluindo o reconhecimento de ameaças comuns, como malware e phishing, e a implementação de medidas de proteção e mitigação para vazamento de senhas.
1. LSP – The Liskov Substitution Principle
Elias Rodrigues de Oliveira
Gabriela Borges Diniz Teixeira
Prof. Edgard Davidson
Centro Universitário UNA
Engenharia de Software Centrada em Métodos Ágeis – Programação Orientação a Objetos
11/06/2011
RESUMO
Liskov Substitution Principle (LSP) é um dos cinco princípios do SOLID (acróstico onde cada letra significa a
sigla de um princípio: SRP, OCP, LSP, ISP e DIP). O Princípio da Substituição de Liskov tem como resumo que
as classes derivadas devem ser substituíveis por sua classe base, assim como os outros princípios do SOLID,
foram formulados como linguagens estáticas e, por essa razão precisam ser “adaptados” para que sejam
aplicados em linguagens dinâmicas. Em suas formas originais, esses princípios em geral recorrem a técnicas
como herança para contornar as “amarras” dos sistema estático de tipos.
Palavras-chave: LSP; Liskov Substitution Principle; Princípio da Substituição de Liskov.
1 INTRODUÇÃO
Na programação orientada a objeto, o princípio da substituição de Liskov é uma
definição particular para o conceito de subtipo. Foi introduzido em 1993 por Barbara Liskov e
Jeannette Wing através de um artigo de nome Family Values: A Behavioral Notion of
Subtyping.
O princípio LSP foi definido de forma resumida como:
Se q(x) é uma propriedade demonstrável dos objetos x de tipo T. Então q(y) deve ser
verdadeiro para objetos y de tipo S onde S é um subtipo de T.
Nas entrelinhas, se você pode invocar um método q() de uma classe T (base), deve
poder também invocar o método q() de uma classe T’ (derivada) que é derivada com herança
de T (base).
De forma bem simples, o princípio de Liskov sugere que, sempre que uma classe
cliente esperar uma instância de uma classe base X, uma instância de uma subclasse Y de X
pode ser substituída e ser usada no seu lugar.
Em outras palavras, uma classe base pode ser substituída pela sua classe derivada. O
objetivo é ter certeza de que novas classes derivadas estão estendendo das classes base, mas
sem alterar seu comportamento.
2 ENTENDENDO O LSP NA PRÁTICA: VIOLANDO O LSP
Para ilustrar o princípio LSP, utilizaremos um exemplo clássico. Suponhamos um
projeto que implementa duas classes: Retângulo e Quadrado.
A classe Quadrado é um Retângulo que tem uma característica especial: a largura e a
altura são iguais.
2. 2
Definimos duas classes para representar ambas as contas.
A notação UML ao lado ilustra o relacionamento de herança
existente entre duas classes onde temos que Quadrado é a classe
derivada e Retângulo é a classe Base.
No entanto, esse tipo de pensamento pode levar a alguns
problemas sutis, mas significativos.
Como a classe Quadrado herda da classe Retângulo, ela também
herdará os métodos da classe Retângulo, o que para um quadrado não
faz muito sentido visto que a largura e a altura não são iguais. É por isso
que se sobscreve esses métodos na classe Quadrado e define a largura
igual a altura.
Se as definições do projeto estiverem de acordo com o princípio LSP, a utilização da
classe Quadrado() deverá poder ser usada sem problemas no lugar da classe base Retângulo.
Se o princípio LSP estivesse sendo corretamente aplicado o fato de usar a instância de
Quadrado não implicaria em mudança de comportamento.
Ao criar um novo Retângulo definindo altura 5 e largura 10, para obter a área, o
resultado deveria ser 50, mas obtemos 100.
Este problema acontece pois, ao definirmos a largura para 10, acabamos definindo a
altura 10, deixando a área com valor 100 e não 50, como era esperado.
Neste caso um Quadrado não é um Retângulo, e ao aplicarmos o princípio “É-Um”
(Is-A) da herança de forma automática, vimos que ele não funciona para todos os casos.
A instância da classe Quadrado quando usada, quebra o código produzindo um
resultado errado e isso viola o princípio de Liskov, onde uma classe filha (Quadrado) deve
poder substituir uma classe base (Retângulo).
Para obter o resultado correto, basta alterar o código do método estático.
Fazendo isso o método fica correto, mas mostra que não se pode usar a instância
Quadrado como Retângulo.
5 CONCLUSÃO
Este exemplo mostra uma violação clara do princípio LSP onde a inclusão da classe
Quadrado herdando de Retângulo, mudou o comportamento da classe base, violando assim o
princípio Open-Closed.
O princípio LSP é uma extensão do Princípio Open-Closed, isso significa que deve-se
ter certeza de que as novas classes derivadas estão estendendo as classes base, sem alterar seu
comportamento.
6 REFERÊNCIAS
http://davidhayden.com/blog/dave/archive/2005/06/10/1226.aspx
http://www.objectmentor.com/resources/articles/lsp.pdf
http://www.objectmentor.com/omSolutions/oops_what.html
http://javaboutique.internet.com/tutorials/JavaOO/
http://www.engr.mun.ca/~theo/Courses/ssd/pub/sd-principles-3.pdf