O Princípio da Segregação de Interfaces é a quarta boa prática de programação que forma o SOLID. A recomendação diz que:
“Clientes não devem ser forçados a depender de interfaces que eles não usam.”
Esses clientes não são os seres humanos que utilizam o software final, mas sim os algoritmos que dependem da interface de alguma outra classe. Por exemplo, quando nosso script conecta numa base utilizando a biblioteca PDO do PHP, esse nosso script é o cliente que consome a interface da classe PDO.
Além disso, Robert Martin não se refere apenas àquelas interfaces que criamos com a palavra-chave interface no PHP, mas sim ao conjunto de todos os métodos públicos de uma classe. …
Por Jessie Young.
Esta é uma tradução do artigo escrito por Jessie Young e publicado em: https://18f.gsa.gov/2016/06/24/5-lessons-in-object-oriented-design-from-sandi-metz/
A primeira vez em que ouvi Sandi Metz falando foi em um meetup em San Francisco em 2012. Uma coisa que ela disse naquela noite teve um profundo impacto sobre mim: “O código precisa funcionar só uma vez hoje, mas precisa ser fácil de mudar para sempre”.
Naquele tempo, eu já havia escrito código por alguns anos e entendia que “refatoração” era uma coisa boa. Mas, assim como tantas outras lições que aprendi como uma iniciante, eu não entendia realmente porquê refatorar. …
O SC Dev Summit foi um seminário sobre desenvolvimento de software que ocorreu em Joinville, Santa Catarina, nos dias 20 e 21 de maio de 2016. Ele foi dividido em duas partes: o dia do back-end e o dia do front-end. Apesar dessa divisão, parece que isso mais uniu do que dividiu o público.
A seguir eu listei os tópicos das informações que achei mais importantes e reuni todos os slides que consegui encontrar.
Docker, Kubernetes & Openshift
Palestra de Mateus Caruccio
- Apresentou uma introdução a essas tecnologias.
- Docker = containers. Kubernetes = deploy e escala desses containers
- Rolling deployment = levanta as novas imagens conforme as antigas deixam de ser usadas e vão sendo derrubadas (ou seja, não dá kill all pra levantar as imagens novas). …
Utilizando objetos mais significativos para representar a ausência de valor.
O Null Pattern, também conhecido como Active Nothing, é um padrão onde criamos classes para representar a ausência de valor, ou seja, utilizamos objetos ao invés de null.
Antes de discutirmos esse padrão, precisamos entender o que há de errado com passar e retornar null em nossos códigos.
Qual é o problema do null?
Toda vez que passamos ou retornamos null, precisamos espalhar vários testes pelo nosso sistema para checar se o valor contém alguma coisa antes de ser utilizado:
Isso aumenta consideravelmente a quantidade de trabalho para manter um sistema, pois em todos os lugares onde usamos ou aceitamos null, precisamos checar pelo valor recebido como um argumento ou retornado por um método. …
Uma explicação simples sobre o uso de interfaces na linguagem de programação PHP.
As interfaces são utilizadas quando você precisa ter certeza de que um objeto responde a determinados métodos, independente de que tipo ele seja.
Elas funcionam como uma espécie de contrato: você cria uma interface com o esqueleto dos métodos que serão obrigatórios, então qualquer classe que implemente essa interface será obrigada a escrever esses métodos.
Neste exemplo, qualquer classe que implementa a interface Arrayable precisará implementar um método toArray():
Exemplo: garantindo que um objeto possa ser tributado
No artigo sobre o Princípio do Aberto/Fechado, vimos uma classe chamada de impostômetro, que é responsável por somar o valor dos impostos dos objetos que ela recebe (remédios, cosméticos, serviços diversos, etc.). …
Dicas de organização para programadores back-end que não manjam muito de front-end.
Eu não sou um programador de front-end, mas acompanhei a área por algum tempo e vejo meus colegas cometendo erros básicos que tornam um inferno a manutenção de um sistema. Falarei sobre alguns dos problemas mais recorrentes que vejo nas views dos projetos.
Nós nos preocupamos muito em seguir as melhores práticas de programação, aprender padrões de projeto, manter o código limpo, etc., mas às vezes deixamos a desejar no front-end.
O grande problema em não organizar o front-end é a dificuldade exponencial de mantê-lo a médio prazo. Caso você desenvolva páginas com conteúdo público, também existe o problema de sofrer penalidades no ranqueamento de ferramentas de busca (Google, Bing, etc.) …
Fast and compiled games written in a Ruby-like syntax, with all the great libraries C has to offer.
One of the things that always set me apart from game development was the complexity of most compiled languages. C, C++, C#, they all seem to be the most used programming languages in enterprise game development, but they are too verbose and complex compared to scripting languages I use daily.
There is a lot of visual game development tools like Unity3D, GameMaker, Stencyl, etc., but sometimes you want fine-grain control over how your game behaves.
Since I just intended to play around making games, I started writing them in Ruby, because it's a pleasure to write Ruby code and it was enough to grasp the basics of game development. …
Garantindo que instâncias de uma classe possam ser substituídas por instâncias de sub-classes sem quebrar o sistema.
Esse artigo continua a série sobre os cinco princípios do SOLID aplicados ao PHP. Agora veremos o terceiro deles, que é chamado de “Princípio da Substituição de Liskov”.
Esse conceito foi criado em 1974 por Barbara Liskov, que o definiu como:
Se para cada objeto O1 do tipo S existe um objeto O2 do tipo T de tal modo que para todos os programas P definidos em termos de T, o comportamento de P não muda quando O2 é substituído por O1, então S é um subtipo de T.
Essa definição é bastante técnica, mas Uncle Bob nos explica de uma forma mais…
Como manter classes abertas para extensão e fechadas para modificação.
No artigo anterior vimos que uma classe só deveria ter uma única responsabilidade ou um único motivo para mudar. Hoje veremos a segunda recomendação do SOLID, chamada de “Princípio do Aberto/Fechado”.
Uncle Bob pegou esse conceito emprestado de Bertrand Meyer, que o define da seguinte maneira:
Entidades de software (classes, módulos, funções, etc.) devem ser abertas para extensão, mas fechadas para modificação.
Em outras palavras, isso significa que:
- O comportamento deve estar aberto para mudanças, para atender a novos requisitos do software.
- No entanto, o código fonte deve estar fechado para alteração, ou seja, não deveria ser tocado para introduzir esses novos comportamentos. …
O primeiro dos cinco princípios que compõe o SOLID, um conjunto de boas práticas de design orientado a objetos de Robert Martin (Uncle Bob).
Uma classe só deveria ter um motivo para mudar — Uncle Bob
Segundo Bob, isso significa que uma classe só deveria ter um eixo de mudança. “Motivo para mudar”, “eixo de mudança”, esses termos não ajudam muito, não é?
Existe uma maneira mais fácil de pensar nisso: apenas leia a sua classe e escreva uma lista de tudo o que ela faz. Se a sua lista tiver mais do que um único item, quer dizer que a sua classe tem mais do que uma responsabilidade.
Exemplos em PHP
Neste primeiro exemplo temos uma classe “Pedido”, que implementa o padrão ActiveRecord. Não entrarei na discussão sobre o uso de ActiveRecord versus o uso de Repositórios segundo o Domain-Driven Design, então apenas assuma que a classe herda métodos para persistência de dados de sua classe-mãe. …
About
