• HOME

  • SOBRE MIM

  • More

    Use tab to navigate through the menu items.
    • Preto Ícone Facebook
    • Preto Ícone Twitter
    • Preto Ícone LinkedIn
    • github

    RAMON FERREIRA SILVA

    Software Engineer | Data Engineer
    • Tudo
    • Android
    • Desenvolvimento
    • Boas Práticas
    • Arquitetura de Software
    • Engenharia de Software
    • grails
    • Refatoração
    • Princípios SOLID
    • web
    • GRASP
    • Testes
    • Mobile
    • Coaching
    • Marketing
    • Entrepreneurship
    Buscar
    Ramon Ferreira Silva
    • 10 de jul. de 2019
    • 2 min

    Creator – Padrões GRASP

    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

    746 visualizações0 comentário
    Ramon Ferreira Silva
    • 9 de mai. de 2016
    • 2 min

    Controller – Padrões GRASP

    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çõ

    543 visualizações0 comentário
    Ramon Ferreira Silva
    • 11 de mar. de 2016
    • 3 min

    DIP: O Princípio da Inversão de Dependências

    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

    72 visualizações0 comentário
    Ramon Ferreira Silva
    • 6 de mar. de 2016
    • 3 min

    ISP: O Princípio da Segregação de Interfaces

    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çã

    50 visualizações0 comentário
    Ramon Ferreira Silva
    • 1 de mar. de 2016
    • 4 min

    LSP: Princípio da Substituição de Liskov

    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

    157 visualizações0 comentário
    Ramon Ferreira Silva
    • 26 de fev. de 2016
    • 4 min

    OCP: O Princípio Aberto/Fechado

    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

    206 visualizações0 comentário
    Ramon Ferreira Silva
    • 25 de fev. de 2016
    • 2 min

    SRP: Princípio da Responsabilidade Única

    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

    42 visualizações0 comentário
    Ramon Ferreira Silva
    • 23 de fev. de 2016
    • 2 min

    Como Melhorar o seu código : Os 5 Princípios SOLID

    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

    45 visualizações0 comentário
    Ramon Ferreira Silva
    • 10 de jun. de 2015
    • 4 min

    Refatoração de código

    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

    66 visualizações0 comentário