Acredita-se que a programação orientada a objetos seja baseada em três pilares que fornecem vantagens ao programador em relação à abordagem processual. Eles são encapsulamento, herança e polimorfismo.A herança permite que você se livre significativamente da duplicação de código ao usar a abordagem orientada a objetos. Porém, ao usá-lo, você deve sempre se lembrar de um dos princípios do SOLID, chamado Substituição de Liskov, que, a menos que você entre em detalhes, afirma que a herança deve ser usada apenas como uma implementação do relacionamento "is". Ou seja, a classe do descendente deve "ser" uma subespécie do pai. Por exemplo, você pode ter a classe Bird e suas subclasses Sparrow (pardal) e Raven (raven), que, por exemplo, herdam (e podem estender ou modificar) o método fly. No entanto, se você criar um descendente de Bird chamado Penguin (penguin) e seu método de voar, por exemplo, lançar uma exceção (porque os pingüins não voam), isso violará o princípio da Substituição de Liskov. Falando em herança,Também vale a pena mencionar um princípio importante que o Gangue dos Quatro (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides) adere em seu livro Design Patterns: Elements of Reusable Object-Oriented Software (1994), que afirma que você deve tentar use composição (quando um objeto "contiver" outro objeto) em vez de herdar o máximo possível. Na verdade, muitos dos padrões de design inventados pelo “Gangue dos Quatro” são precisamente baseados nesse princípio.Na verdade, muitos dos padrões de design inventados pelo “Gangue dos Quatro” são precisamente baseados nesse princípio.Na verdade, muitos dos padrões de design inventados pelo "Gangue dos Quatro" são precisamente baseados nesse princípio.Em geral, na prática, a herança é usada para não dizer com tanta frequência, apesar do fato de que, na maioria dos casos, bons programadores a substituem por uma composição. Com mais freqüência, existem várias implementações de uma interface, especificadas como dependências nas classes do cliente. O que, por sua vez, permite que você use o segundo pilar do POO - polimorfismo. O que permite passar diferentes implementações de dependência para o código do cliente. Devido ao fato de as dependências transmitidas terem a mesma interface, o cliente (dependendo da interface) não se importa com o objeto que veio a ele e isso permite que o programador altere, durante a execução do programa, de que maneira (qual implementação da interface) a tarefa final será resolvida. Falando em POO, não se pode deixar de mencionar o encapsulamento. Este é um elemento essencial da OOP,que fornece a capacidade de criar abstrações para ocultar detalhes de implementação de baixo nível e reduzir a complexidade do desenvolvimento. Os detalhes da implementação são ocultados pelos modificadores de acesso a métodos como privado e protegido. Ao criar classes, é necessário criá-las para que suas interfaces (métodos públicos acessíveis) forneçam uma abstração consistente,caso contrário, não será mais OOP (!) . Por exemplo, vamos supor que estamos desenvolvendo um programa que controla o sistema de refrigeração de um reator nuclear. Em seguida, a abstração acordada da interface pode ter a seguinte aparência.CoolingSystem::getTemperature()
CoolingSystem::SetCirculationRate($rate)
CoolingSystem::OpenValve($valveNumber)
CoolingSystem::CloseValve($valveNumber)
Graças a uma interface expressiva curta que forma uma abstração coerente, podemos trabalhar com o sistema de resfriamento do reator sem ter a menor idéia sobre os detalhes de implementação de baixo nível que são característicos da tecnologia escolhida. O uso de abstrações pode reduzir significativamente a complexidade do sistema desenvolvido. E a luta contra a complexidade é o principal imperativo técnico do desenvolvimento. Aqui estão mais alguns exemplos de abstrações consistentes:Sistema de controle de velocidade:- Definir velocidade
- Obter configurações atuais
- Restaurar o valor da velocidade anterior
- Desativar sistema
Moedor de café:- Habilitar
- Desligar
- Definir velocidade
- Comece a moer café
- Pare de moer café
Tanque de combustível:- Encha o tanque de combustível
- Drenar combustível
- Obter capacidade do tanque de combustível
- Obter status do tanque de combustível
Luminária:Ao projetar a interface de um objeto, declare público apenas os métodos que o cliente precisa gerenciar, ocultando todo o resto. Como resultado, você deve obter caixas pretas, cujo dispositivo você pode esquecer após a adição do código da classe. Essa abordagem pode reduzir significativamente a complexidade do sistema desenvolvido.