Principalmente para o início das aulas da nova vertente do curso "Arquitetura e Padrões de Design" preparei mais um material de autoria.
Introdução
Quando se trata de padrões de design clássicos, não se pode deixar de pensar na própria programação orientada a objetos. Afinal, os padrões GoF são exatamente padrões de programação orientados a objetos. A programação funcional tem seus próprios padrões.
Em geral, tudo está organizado da seguinte maneira: existe a própria programação orientada a objetos. Ele tem princípios. A partir dos princípios da programação orientada a objetos, seguem os padrões GRASP que analisamos (como uma opção - princípios SOLID), dos quais, por sua vez, seguem os padrões GoF. Uma série de coisas interessantes decorre deles, por exemplo, padrões corporativos.
Paradigma Orientado a Objetos
A definição afirma que "a programação orientada a objetos é um paradigma de programação em que o conceito básico é a noção de um objeto que é identificado com um domínio."
Assim, o sistema é representado como um conjunto de objetos da área disciplinar, que interagem entre si de alguma forma. Cada objeto possui três componentes: identidade, estado e comportamento.
O estado de um objeto é uma coleção de todos os seus campos e seus valores.
O comportamento de um objeto é a coleção de todos os métodos da classe de um objeto.
A identidade do objeto é o que distingue um objeto de classe de outro objeto de classe. De uma perspectiva Java, é por identidade que o método equals é definido.
Princípios de programação orientada a objetos
A programação orientada a objetos tem vários princípios. A ideia de seu número é diferente. Alguém afirma que são três (velha escola de programadores), alguém que há quatro (nova escola de programadores):
- Abstração
- Encapsulamento
- Herança
- Polimorfismo
Proponho falar sobre eles com mais detalhes. A única coisa é que sugiro não considerar a abstração, porque me considero pertencente à velha escola dos programadores.
Encapsulamento
Ao contrário da opinião de muitos entrevistados (e às vezes entrevistados), o encapsulamento não é "quando todos os campos são privados". O encapsulamento é o princípio mais fundamental do design de software, seus traços são observados apenas no nível micro, mas também no nível do macro design.
A definição científica diz que "Encapsulamento é o princípio de que qualquer classe e, em um sentido mais amplo, qualquer parte do sistema deve ser considerada como uma" caixa preta ": o usuário de uma classe ou subsistema deve ver apenas a interface (ou seja, uma lista de propriedades e métodos declarados ) e não se aprofundar na implementação interna. "
Assim, verifica-se que se a classe A se refere diretamente aos campos da classe B, isso não leva ao fato de que "a segurança da informação é violada", mas ao fato de que a classe A está ligada ao dispositivo interno da classe B, e uma tentativa de alteração da estrutura interna da classe B levará à mudança da classe A. Além disso, a classe A não trabalha apenas com os campos da classe B, ela funciona de acordo com alguma lógica de negócios. Ou seja, a lógica para trabalhar com o estado da classe B está na classe A, e quando queremos reutilizar a classe B, isso não pode ser feito, pois sem um pedaço da classe A a classe B pode ser inútil, o que levará ao fato de que a classe B terá que ser dada junto com classe A. Extrapolando isso para todo o sistema, verifica-se que apenas o sistema inteiro pode ser reutilizado.
O encapsulamento é o princípio mais esquecido e, infelizmente, poucas pessoas o interpretam corretamente. Ele permite que você minimize o número de links entre classes e subsistemas e, consequentemente, simplifique a implementação e modificação independente de classes e subsistemas.
Herança
Herança é a capacidade de derivar uma classe de outra enquanto preserva todas as propriedades e métodos da classe ancestral (superclasse), adicionando novas propriedades e
métodos, se necessário .
Herança é o princípio mais superestimado. Antigamente se acreditava que "Para um programador ideal, a árvore de herança vai ao infinito e termina em um objeto absolutamente vazio", porque antes as pessoas não entendiam muito bem que herança é uma forma de expressar tal propriedade do mundo real como hierarquia, e não uma forma reutilize o código herdando a máquina da geladeira, porque ambos os itens têm uma alça. É aconselhável evitar herança sempre que possível, porque herança é um relacionamento muito forte. Para reduzir o número de níveis de herança, é recomendado construir uma árvore “de baixo para cima”.
Polimorfismo
Polimorfismo é a capacidade de usar classes descendentes em um contexto que foi planejado para a classe ancestral.
Por trás da definição mais sádica está a capacidade da linguagem de programação de decompor uma tarefa e refatorar ifs e switches.
