RAMON FERREIRA SILVA

O segundo padrão do catálogo GRASP, é o Creator, este padrão é responsável por atribuir a responsabilidade de criação de objetos. Atribuições do Creator O paradigma da orientação a objetos trata-se de uma coleção de objetos que interagem entre si, mas a quem cabe a atribuição de criar esses objetos? Afinal se qualquer  classe sair criando objetos, podemos ter graves violações de encapsulamento, responsabilidades e  alto acoplamento. O padrão Creator veio para dar ordem a esse

O primeiro padrão do catalogo GRASP, é o Controller, este padrão é responsável por atribuir eventos do sistema a classes que que não estão relacionadas com interface com o usuário. Atribuições da Controller Determina quais objetos são responsáveis por tratar eventos gerados na camada de interface com o usuário. Delega responsabilidades a outras classes e coordena a interação dos principais objetos. Funciona como uma fachada para interação com o sistema Determina quais operaçõ

O princípio da Inversão de Dependências é o último dos Princípios SOLID e corresponde a letra “D”. Definição Este princípio trata de uma maneira específica para desacoplar as dependências entre os objetos, modificando a maneira tradicional como estabelecemos as dependências entre nossos objetos. Sua definição formal é : Componentes de mais alto nível não devem depender de componentes de níveis mais baixos, mas ambos devem depender de abstrações. Abstrações não devem depender

O Princípio da Segregação de Interfaces é o quarto princípio SOLID, e corresponde a letra “I”. Definição Este princípio nos diz que uma classe consumidora não deve conhecer (depender) métodos que não necessitam. Para ter uma classe coesa e reutilizável, devemos atribuir  a ela uma única responsabilidade . Mas as vezes, mesmo essa única responsabilidade pode ser quebrada em responsabilidades menores ainda, tornando sua interface mais amigável. Violando o Princípio da Segregaçã

O Princípio da Substituição de Liskov é o terceiro princípio, e representa a letra ‘L’ do SOLID. Esse método mais do que qualquer outro nos diz: Programe para a interface e não para sua implementação! Teoria Esse princípio tem esse nome pois foi proposto por Barbara Liskov em um de sues artigos em 1988. A teoria diz : “Dado um Tipo T, todos os seus subtipos S podem ser usados como seus substitutos sem que haja impactos no sistema.” Ou seja, caso você possua uma classe qualque

Calma, esse não é um post sobre Rocobop. OCP (Open/Closed Principle) é o segundo princípio do SOLID, e diz que uma classe deve ser aberta para extensão e fechada para modificação. Mas o que isso significa ? Simples, você a sua classe deve ser projetada de modo que não haja necessidade de fazer alterações no seu código cada vez que um novo comportamento for necessário, e como fazer isso? Separando todo o comportamento mutável da sua classes e manter nela somente aquilo que nun

Responsabilidade Única é o primeiro princípio SOLID da orientação a objetos, representa a letra ´S´. Este princípio diz que uma classe deve possuir apenas uma responsabilidade, sendo uma classe coesa e simples. Porém esse parece ser o princípio mais difícil de ser seguido, um pouco de distração e nossa classe já está fazendo login, acessando o saldo da conta e fazendo transferências entre usuários. Outra situação clássica, é quando colocamos nossa lógica de negócios na camada

Programação é uma mistura de arte com ciência, pois demanda do programador uma doses de criatividade e lógica, sem uma metodologia concreta, essa tarefa torna-se passível de falha, por isso ao longo dos anos o mercado começou a padronizar alguns conceitos, criando os Princípios SOLID. O que ele quis dizer com isso? Simples: você não vai conseguir criar uma roda melhor do que a que  já foi criada, então use-a, foque nos problemas reais dos seus clientes, e não em criar um códi

A Refatoração de código é uma prática que surgiu na década de 80, entre os membros da comunidade de programadores de Smalltalk, logo ganhou força e atingiu outras comunidades de programadores. Os programadores tinham consciência que não escreviam o código mais correto logo na primeira tentativa, e que precisavam ler, reler e modificar os seus códigos com uma frequência maior do que escreviam novas linhas de código. Logo alguns termos se tornaram populares entre os programador