Forem: luanloose

Design Pattern: Singleton

luanloose — Mon, 25 Oct 2021 12:51:05 +0000

Permite que você garanta que uma classe tenha apenas uma instância, enquanto provê acesso global para ela.

O padrão Singleton resolve esses dois problemas de uma vez, mas por outro lado viola o princípio de responsabilidade única.

Explicando o problema

Permite que você garanta que uma classe tenha apenas uma instância.

Você deve estar se perguntando o motivo de alguém querer isso, mas um bom exemplo é quando precisamos usar em vários pontos da aplicação um recurso compartilhado, como por exemplo a conexão com o banco de dados. Quando criado um objeto, ao precisar usar ele novamente a aplicação irá te devolver o mesmo objeto criado anteriormente ao invés de criá-lo novamente.
Provê acesso global para uma instância.

Quem nunca criou aquela variável global no index para ser usado ao longo do projeto? Nunca fez? É, eu já fiz hehe

São bem úteis, não irei mentir pra você, mas são bem inseguras, pois o seu conteúdo pode ser alterado por qualquer código e criar um efeito colateral na sua aplicação.

Na mesma ideia de uma variável global, o Singleton permite que você acesse uma instância de uma classe globalmente em qualquer lugar da aplicação, mas previne que o seu conteúdo seja sobrescrito por outro código.

Como implementar

Crie um campo privado estático na classe para o guardar a instância.

<?php
class Database 
{
    private static $instance;
// Continuação da classe...

Declare um método de criação público e estático para obter a instância singleton Ex: getInstance.

// Inicio da classe...

public static function getInstance() 
{
    // Implementação da função 
}

// Continuação da classe...

Implemente a inicialização dentro do método estático. Ela deve criar um novo objeto na sua primeira chamada e colocá-lo no campo estático. O método deve sempre retornar aquela instância em todas as chamadas posteriores.

// Inicio da classe...

public static function getInstance() 
{
    if (is_null(self::$instance)) {
        echo 'Passou aqui uma só vez' . PHP_EOL;
        self::$instance = new self();
    }

    return self::$instance;
}

// Continuação da classe...

OBS: Se tiver trabalhando com multi thread, dever colocar um thread lock antes do operador new no método getInstance.

Pode parecer estranho, mas faça o construtor da classe ser privado. O método estático da classe vai conseguir chamar o construtor, mas irá previnir a criação através de outros objetos.

// Inicio da classe...

private function __construct() 
{
    $this->connection = 'conectado';
}

// Continuação da classe...

Vá para o código cliente e faça a chamada para o método estático do singleton.

$database = Database::getInstance();

Agora vamos ver todo o código da implementação.

<?php
class Database 
{
    private static $instance;
    private $connection;

    private function __construct() 
    {
        $this->connection = 'conectado';
    }

    public function query($sql) 
    {
        return 'Resultado da query: ' . $sql . PHP_EOL;
    }

    public static function getInstance() 
    {
        if (is_null(self::$instance)) {
            echo 'Passou aqui uma só vez' . PHP_EOL;
            self::$instance = new self();
        }
        return self::$instance;
    }
}

class User 
{
    public function getUser()
    {
        $database = Database::getInstance();
        return $database->query('SELECT * FROM Users;');
    }
}

class Transactions 
{
    public function getTransaction()
    {
        $database = Database::getInstance();
        return $database->query('SELECT * FROM Transactions;');
    }
}

// Case 1
$user = new User;
echo $user->getUser();

// Case 1
$transaction = new Transactions;
echo $transaction->getTransaction();

$database = new Database; //fatal error

Nas classes que representam as models User e Transactions a instância está dentro da função, mas numa implementação

Conclusão

Use o singleton quando você ver a necessidade de uma classe possuir apenas uma instância disponível e global em sua aplicação e tbm caso precise de um controle mais estrito sobre as variáveis globais.

É isso galera, chegamos no fim de mais um artigo inté o próximo!

Design Pattern: Factory Method

luanloose — Mon, 18 Oct 2021 16:15:52 +0000

Como o próprio nome já diz, ele é a nossa fábrica. De que? De objetos uai.

Este é um padrão criacional que fornece um interface de criação de objetos numa superclasse, mas que seja possível alternar o tipo do objeto que retorna dessa criação.

Explicando o problema

Vamos imaginar que você está desenvolvendo um e-commerce. No primeiro momento sua aplicação apenas aceitará cartão de crédito, portanto sempre que vier um pedido no seu sistema toda a regra de pagamentos e validações ficará dentro da classe CreditCard.

<?php
class Cart 
{
    public function checkout() 
    {
        $payment = new CreditCard;
        return $payment?->pay();
    }
}

class CreditCard 
{
    public function pay()
    {
        return 'Transação concluída com sucesso' . PHP_EOL;
    }
}

$cart = new Cart();
echo $cart->checkout(); //Transação concluída com sucesso

Agora sua loja está indo muito bem e crescendo, mas seus clientes começam a reclamar e pedem por mais meios de pagamento. Para evitar que o número de vendas caia, logo você começa a desenvolver melhorias adicionando um novo meio de pagamento Invoice (Boletos).

É uma boa noticia certo? Mas se você não tomar cuidado no inicio do desenvolvimento, é possível que tudo esteja acoplado a uma única classe, e adicionar qualquer coisa pode alterar toda a base de código. Além disso sempre que for criado um meio de pagamento novo, provavelmente passará por isso tudo novamente.

Vejamos um exemplo adicionando a classe Invoices num universo simplificado.

<?php
class Cart 
{
    private $cart;

    public function __construct ($cart) 
    {
        $this->cart = $cart;
    }

    public function checkout() 
    {

        $payment = null;

        if ($this->cart->payment === 'boleto') {
            $payment = new Invoice;
        } 

        if ($this->cart->payment === 'credit') {
            $payment = new CreditCard;
        }

        return $payment?->pay() ?? 'Erro';
    }
}

class Invoice 
{
    public function pay()
    {
        return 'Boleto para ser pago'. PHP_EOL;
    }
}

class CreditCard 
{
    public function pay()
    {
        return 'Transação concluída com sucesso' . PHP_EOL;
    }
}

//Case 1
$myCart = ['payment' => 'boleto'];
$cart = new Cart((object) $myCart);
echo $cart->checkout(); //Boleto para ser pago

//Case 2
$myCart = ['payment' => 'credit'];
$cart = new Cart((object) $myCart);
echo $cart->checkout(); //Transação concluída com sucesso

//Case 3 - Método de pagamento não implementado
$myCart = ['payment' => 'Outro meio de pagamento'];
$cart = new Cart((object) $myCart);
echo $cart->checkout(); //Erro

Nesse pequeno exemplo parece até simples (só adicionar uns ifs e já era), mas nem sempre é assim, adicionar uma nova classe num código que depende de classes concretas pode dar uma certa dor de cabeça.

Pense comigo, como ficaria esse código com 5 meios de pagamentos? Terão 5 ifs? Um Switch? Parece meio ruim né, além de deixar o sódigo bastante sujo, ficará cheio de condicionais que mudam o comportamento da aplicação, podendo até criar um erro inesperado.

Solução

O padrão Factory sugere que você não chame diretamente o operador new. Você pode estar se perguntando como irá criar os objetos, mas calma, ainda será com o operador new, mas ele será chamado dentro desse método chamado de fábrica, esses objetos gerados e retornados por esse método serão chamados de produtos.

Usando nosso exemplo anterior, vamos aplicar o conceito para entender a ideia dele:

<?php
class Cart 
{
    private $factoryPayment;
    private $cart;

    public function __construct ($cart) 
    {
        $this->factoryPayment = new FactoryPayment;
        $this->cart = $cart;
    }

    public function checkout() 
    {
        $payment = $this->factoryPayment->createPayment($this->cart->payment);
        return $payment?->pay() ?? 'Erro';
    }
}

class FactoryPayment 
{
    public function createPayment($payment) : Payment|null
    {
        return match ($payment) {
            'boleto' => new Invoice,
            'credit' => new CreditCard,
            default => null
        };
    }
}

interface Payment {
    public function pay();
}

class Invoice implements Payment
{
    public function pay()
    {
        return 'Boleto para ser pago'. PHP_EOL;
    }
}

class CreditCard implements Payment
{
    public function pay()
    {
        return 'Transação concluída com sucesso' . PHP_EOL;
    }
}

//Case 1
$myCart = ['payment' => 'boleto'];
$cart = new Cart((object) $myCart);
echo $cart->checkout(); //Boleto para ser pago

//Case 2
$myCart = ['payment' => 'credit'];
$cart = new Cart((object) $myCart);
echo $cart->checkout(); //Transação concluída com sucesso

//Case 3 - Método de pagamento não implementado
$myCart = ['payment' => 'Outro meio de pagamento'];
$cart = new Cart((object) $myCart);
echo $cart->checkout(); //Erro

Olhando de início pode parecer sem sentido, pois apenas mudamos a chamada de criação para outra classe. Mas isso ajuda bastante na hora de incluir novos meios de pagamento por exemplo, basta implementar a interface Payment com o método pay e se tiver tudo correto com a nova classe vai funcionar tudo corretamente sem precisar de alterar nada no código principal, pois está tudo abstraído.

Outro caso muito maneiro é a possibilidade de criar outro factory antes do FactoryPayment, para criar gateways de pagamento. Suponha que vc decida pagar boletos (Invoice) com o gateway X e o cartão de crédito com o Y (CreditCard) com esse padrão isso é possível, irei explicar no código cada ponto, veja:

<?php

//Classe principal que será o código cliente que receberá os produtos
class Cart 
{
    private $factoryGateway;
    private $cart;

    public function __construct ($cart) 
    {
        $this->factoryGateway = new FactoryGateway;
        $this->cart = $cart;
    }

    public function checkout() 
    {
        $payment = $this->factoryGateway->createGateway($this->cart->payment);
        return $payment?->pay() ?? 'Erro';
    }
}

// Classe fábrica de gateways que será chamada pelo código cliente
// usando o método de pagamento para decisão.
class FactoryGateway 
{
    public function createGateway($payment) : Payment|null
    {
        $gateway = match ($payment) {
            'boleto' => new GatewayX,
            'credit' => new GatewayY,
            default => null
        };
        return $gateway?->createPayment();
    }
}

// Classe abstrata que será usada como fábrica de pagamentos
abstract class AbstractPayment 
{
    abstract public function createPayment(): Payment;

    protected function authenticate()
    {
        echo 'Autenticado no ' . get_class($this) . PHP_EOL;
    }
}

// Agora temos que implementar os gateways e os métodos que retornarão os produtos
// que no nosso caso são meios de pagamento
class GatewayX extends AbstractPayment
{
    public function createPayment(): Payment
    {
        $this->authenticate();
        return new Invoice;
    }
}

class GatewayY extends AbstractPayment
{
    public function createPayment() : Payment
    {
        $this->authenticate();
        return new CreditCard;
    }
}

// Abaixo temos a interface e os produtos que a implementam. 
interface Payment {
    public function pay();
}

class Invoice implements Payment
{
    public function pay()
    {
        //cria boleto
        return 'Boleto para ser pago'. PHP_EOL;
    }
}

class CreditCard implements Payment
{
    public function pay()
    {
        //valida dados do cartão, limite e etc
        return 'Transação concluída com sucesso' . PHP_EOL;
    }
}

//Case 1
$myCart = ['payment' => 'boleto'];
$cart = new Cart((object) $myCart);
echo $cart->checkout(); //Boleto para ser pago com sucesso no GatewayX

//Case 2
$myCart = ['payment' => 'credit'];
$cart = new Cart((object) $myCart);
echo $cart->checkout(); //Transação concluída com sucesso no GatewayY

//Case 3 - Método de pagamento não implementado
$myCart = ['payment' => 'Outro meio de pagamento'];
$cart = new Cart((object) $myCart);
echo $cart->checkout(); //Erro

OBS: Ele fica bem similar ao próximo padrão que vou mostrar em um artigo futuro, que é o Abstract Factory.

Pontos de atenção

Todos os produtos devem implementar a mesma classe ou interface.

Ex: Payment é implementado em todos os produtos.
Produtos concretos são implementações diferentes da mesma interface.

Ex: Invoice , CreditCard.
Na classe criador, deve ser declarado o método fábrica que retornará os novos objetos produto. Esse retorno deve corresponder à interface do produto.

Ex: Criador AbstractPayment possui o método fábrica createPayment e é retornado um produto do tipo Payment.
Apesar de ter criador no nome, essa não é a principal responsabilidade dela, é possível ter alguma regra de negócio relacionada aos seus produtos.

Ex: Método authenticate da classe criadora AbstractPayment.
Criadores concretos sobrescrevem o método fábrica base para criar um tipo diferente de produto.

Ex: GatewayX e GatewayY.

SOLID

Aqui temos menção a 2 itens do SOLID:

Princípio de responsabilidade única (S): Você pode mover o código criador para um único ponto, facilitando a manutenção.

Principio aberto/fechado (O): Você pode adicionar novos produtos na aplicação sem quebrar o código cliente.

Conclusão

Use esse padrão sempre que você não souber os tipos e dependências dos objetos que seu código irá utilizar, ele separa o código construtor de produtos do código principal. Isso deixa o código de construção do produto mais simples de ser extendido e independente do resto.

Por exemplo, caso queira adicionar mais métodos de pagamento ou gateways, basta implementar as classes correspondentes, adicionar nos métodos fábrica e pronto, seu código está com a nova funcionalidade.

É isso pessoal, chegamos ao fim de mais um artigo, até o próximo.

Design Pattern: SOLID

luanloose — Thu, 14 Oct 2021 17:31:22 +0000

Introdução

Agora que já falamos sobre alguns princípios básicos de projetos, vamos dar uma olhada em cinco deles que são mais conhecidos como os príncipios SOLID.

O SOLID é uma sigla em inglês para cinco princípios de projetos destinados a fazer dos projetos de software algo mais compreensivo, plexível e sustentável.

Mas devemos ter cautela ao usar esses princícios, pois o uso sem o devido cuidado pode dar muita dor de cabeça. O custo de aplicar esses princípios na arquitetura pode deixa-lo muito mais complicado do que deveria ser.

Será que existe algum produto de sucesso no mercado que use todos eles ao mesmo tempo? 🤔

Agora vamos fazer um deep dive em cada letrinha desse tal de SOLID.

S → Single Responsibility Principle ou Princípio de responsabilidade única

Uma classe deve ter apenas uma razão para ser alterada.

Como o próprio nome já diz, o objetivo é fazer com que a classe seja responsável por apenas uma única parte da funcionalidade fornecida pelo seu projeto, faça essa responsabilidade ser totalmente encapsulada pela classe.

O objetivo principal desse princípio é reduzir a complexidade, tanto do entendimento, quanto de manutenção. Os verdadeiros problemas só começam a aparecer quando um projeto começa a crescer e ser modificado com frequência. Em certo ponto, as classes se tornarão tão grandes que vc nem vai lembrar mais as regras que ela possui.

Ao tentar realizar qualquer correção ou implementar uma feature, a navegação pelo código se torna mais um engatinhar, pois terá que olhar quase que com uma lupa para olhar cada classe para encontrar certas coisas dentro do código. As vezes o número de entidades é tão grande, a regra é tão complexa, que vc se sentirá perdido e sem controle sobre o código.

Análise as responsabilidades de sua classe, pois quanto mais coisas ela faz, maior a chance de causar um efeito colateral.

Se vc sente que está complicado, que ao mexer num ponto pode quebrar outro, talvez seja a hora de dividir em algumas classes em partes menores, de contexto reduzido.

Vamos fazer um exemplo e ajustar conforme o princípio:

<?php
class Cart 
{
    public function checkout(){/*Do Code*/}
    public function calculateTotalSum(){/*Do Code*/}
    public function getItems(){/*Do Code*/}
    public function calculatePromotion(){/*Do Code*/}
    public function calculateShipping(){/*Do Code*/}
    public function showOrder(){/*Do Code*/}
}

Temos uma classe Cart com todas essas responsabilidades, que vai desde o checkout até o mostrar o pedido no final, isso fere o princípio pois ele tem muitas responsabilidades e não queremos isso.

Vamos refatorar deixando cada classe com seu papel:

<?php
class Cart 
{
    public function checkout(){/*Do Code*/}
        // Other functions
}

class Promotion 
{
    public function getPromotions(){/*Do Code*/}
    public function calculatePromotion(){/*Do Code*/}
}

class Shipping
{
    public function getAddress(){/*Do Code*/}
    public function calculateShipping(){/*Do Code*/}
}

class Order
{
    public function getItems(){/*Do Code*/}
    public function showOrder(){/*Do Code*/}
}

Agora cada classe está cuidado de sua responsabilidade.

O → Open/Closed Principle ou Princípio aberto/fechado

As classes devem ser abertas para extensão, mas fechadas para modificação.

O objetivo desse princípio é prevenir que o código existente quebre quando vc implementa novas funcionalidades.

Uma classe é aberta quando é possível extende-la, criar subclasses e ser livre para modificar como quiser, criar novos métodos ou campos e até mesmo sobrescrever o comportamento padrão. A classe é fechada (ou completa) se ela estiver 100% pronta para uso em outras, sendo assim ela está claramente definida com suas interfaces e não sofrerá modificações em seu comportamento.

Os termos aberto/fechado não são exclusivos, uma classe pode ser tanto aberta (extensão) e fechada (modificação) ao mesmo tempo.

Se a sua classe foi desenvolvida, testada, passou por todo o fluxo de revisão e já está sendo usada pela aplicação, tentar mexer no código pode ser arriscado. Ao invés de alterar o código da classe diretamente, crie subclasses e sobrescreva as partes da classe original que vc quer que tenha um comportamento diferente. O seu objetivo será alcançado sem correr o risco de quebrar os códigos que já estão usando a classe original.

Se vc ver um bug na classe mãe vc deve corrigi-lo nela e não criar uma subclasse para isso, a filha não deve se responsabilizar pelos problemas da mãe.

Lembra do gato que só come salmão (se não sabe do que eu to falando te convido a ler o artigo anterior), digamos que ele começa a experimentar outro tipo de comida, agora ele gosta de atum, o código ficará dessa forma:

<?php
class Salmon {/*Do Code*/}

class Atum {/*Do Code*/}

class Cat 
{
    public function eat( $food ) : string
    {
        if ($food instanceof Atum) {
            return 'The cat is was fed with atum';
        } 
        if ($food instanceof Salmon) {
            return 'The cat is was fed with salmon';
        } 
    }
}

$cat = new Cat;
echo $cat->eat(new Salmon);
echo "<br>";
echo $cat->eat(new Atum);

// Output
// The cat is was fed with salmon
// The cat is was fed with atum

Agora iremos aplicar o princípio:

<?php
abstract class Food {/*Do Code*/}

class Salmon extends Food {/*Do Code*/}

class Atum extends Food {/*Do Code*/}

class OtherFood extends Food {/*Do Code*/}

class Cat 
{
    public function eat( Food $foodName ) : string
        {
        return 'The cat was fed with: '.get_class($foodName);
    }
}

$cat = new Cat;
echo $cat->eat(new Salmon);
echo "<br>";
echo $cat->eat(new Atum );
echo "<br>";
echo $cat->eat(new OtherFood);

// Output
// The cat is was fed with salmon
// The cat is was fed with atum

L → Liskov Substitution Principle ou Princípio de substituição de Lisk

Quando extenter uma classe, devemos ser capazes de passar objetos da subclasse no lugar de objetos da classe mãe sem quebrar o código cliente.

Mas oq isso quer dizer? Significa que a subclasse deverá ser compatível com o comportamento da superclasse. Sempre que sobrescrever um método, primeiramente analise o comportamento base ao invés de implementar algo completamente diferente.

O princípio da substituição é um conjunto de checagens que ajudam a prever se uma subclasse permanece compatível com o código da superclasse. O conceito é bem rígido quando o projeto são bibliotecas e frameworks, pois suas classes serão usadas por outras pessoas cujo código vc não terá acesso para acessar ou mudar.

Os outros princípios são amplamente abertos a interpretação, já esse tem um conjunto de requerimentos formais para as subclasses, e especificamente para os seus métodos, vamos ver cada um deles com mais detalhes.

Os métodos das subclasses devem ter seus parâmetros similares ou mais abstratos q que os da superclasse.

Vamos ao exemplo, vc tem uma classe que implementa o método fed(Cat $cat) , o código cliente sempre passa objetos do tipo Cat.

Você resolve estender essa classe para alimentar qualquer animal usando fed(Animal $animal).

<?php
abstract class Food 
{
    public function fed(Cat $cat ) : string
    {
         return 'The cat was fed';
    }
}

class Salmon extends Food 
{
    public function fed(Animal $animal ) : string
    {
         return 'The animal was fed';
    }
}

Os retornos das subclasses devem ser do mesmo tipo ou serem iguais aos retornos da superclasse.

Vamos ao exemplo, vc tem uma classe que implementa o método buyACat(Cat $cat) : Cat, o código cliente sempre espera como retorno objetos do tipo Cat.

Você resolve estender essa classe para poder vender uma raça específica de gatos buyACat(PersianCat $persianCat) : PersianCat

<?php
abstract class SellACat 
{
    public function buyACat(Cat $cat ) : Cat
    {
        return New Cat;
    }
}

class SellAPersianCat extends Food 
{
    public function buyAPersianCat(PersianCat $persianCat ) : PersianCat
    {
        return New PersianCat;
    }
}

Um exemplo que NÃO deve ser seguido vem das linguagens com tipagem dinâmica: o método base retorna um boleano, mas o método sobrescrito retorna uma string.

Um método de uma subclasse NÃO deve lançar tipos de excessões que não são esperados que o método base lançaria.

Ou seja, novamente dizendo, os tipos dessas excessões devem ser SEMELHANTES ou de SUBTIPO daqueles que o método base já é capaz de lançar.

Caso vc lançe algo que não é contemplado pelo bloco try-catch do cliente, a excessão inesperada pode escapar, não ser capturada e o código cliente irá quebrar, afetando assim toda aplicação.

Uma subclasse não deve alterar as pré-condições ou fortalece-las.

Exemplo: Se o método base de uma classe tem como parâmetro um número inteiro. Caso uma subclasse sobrescreva essa método e precisa que o valor seja apenas positivo, lançando uma excessão caso seja negativo, isso torna a pré-condição forte e caso o cliente passe a usar os objetos fornecidos pela subclasse, o código que antes funcionava perfeitamente com números negativos, agora irá quebrar.

Uma subclasse não deveria enfraquecer pós-condições.

Exemplo: Você tem no seu método base que trabalhe com uma base de dados. O método base sempre fecha as conexões ao retornar o valor desejado ou ao final da escrita.

Vc estendeu essa classe mas resolveu sobrescrever esse método alterando seu comportamento para deixar a conexão aberta para alguma reutilização futura. O código cliente pode não saber nada sobre isso, pois ele espera pelo comportamento padrão, que é o método encerrar todas as conexões, poluindo o sistema com conexões fantasmas para a base de dados.

As constantes de uma superclasse não devem ser alteradas.

Essa regra pode ser a mais fácil de se quebrar pois pode ser que vc não entenda ou não perceba todas as constantes de uma classe muito complexa. Sendo assim, o modo mais seguro é incluir novos campos e métodos ao estender a superclasse. e não mexer com qualquer coisa existente na superclasse, nem sempre isso é viável no mundo real.

Uma subclasse não deve mudar diretamente os valores de variáveis privadas da superclasse.

Exemplo: Atributos privados, só devem ser alterados com métodos setters.

<?php
abstract class Food 
{
    private $nutricion;

    public function setNutricion($nutricionValue)
    {
        $this->nutricion = $nutricionValue;
    }

}

class Salmon extends Food 
{
    public function __construct()
    {
        //Errado
        $this->nutricion = 10;

    //Correto
    $this->setNutricion(10);
    }
}

I → Interface Segregation Principle ou Princípio de segregação de interface

A classe não deve ser forçada a depender de métodos que não usam.

Ao criar interfaces, se preocupe em reduzi-las o suficiente para que classe não implemente algo só por implementar, certifique que será usado.

Esse princípio sugere que vc deve quebrar interfaces que são muito genéricas para mais específicas. Os clientes devem implementar oq realmente faz sentido ser implementado. Caso contrário, se acontecer uma mudança na interface genérica, o código cliente que nem usa o método será afetado pela alteração, podendo até quebrar a aplicação.

A herança permite uma e apenas uma superclasse, mas não existe limitação para interfaces que uma classe pode implementar ao mesmo tempo. Assim não existe a necessidade de uma só interface com toneladas de métodos que não fazem sentido para todos. Caso isso aconteça, faça um refinamento dessa interface e quebre-a em menores. É possível que vc implemente TODAS em uma única classe, mas a classe que precisa de apenas UMA, ficará bem melhor implementando apenas essa.

Exemplo do que não fazer:

<?php
interface Roles
{
    abstract public function frontend();
    abstract public function backend();
    abstract public function devops();
    abstract public function teamManager();
}

class BackEnd implements Roles
{
    public function backend(){/*Do some code*/}

    public function frontend(){/*I'm not a front end developer*/}

    public function devops(){/*I'm not a devops*/}

    public function teamManager(){/*I'm not a Team Manager*/}
}

Temos uma classe BackEnd que só fará a função backend(), mas por ele implementar a interface Roles, ele é obrigado a implementar todas as outras funções mesmo sem necessidade.

Jeito certo de resolver isso:

<?php
interface TMInterface
{
    abstract public function teamManager();
}

interface FrontEndInterface
{
    abstract public function frontend();
}

interface BackEndInterface
{
    abstract public function backend();
}

interface DevOpsInterface
{
    abstract public function devops();
}

class BackEnd implements BackEndInterface
{
    public function backend(){/*Do some code*/}
}

class FrontEnd implements FrontEndInterface
{
    public function frontend(){/*Do some code*/}
}

Aqui quebramos a interface Roles para deixar mais segmentado, caso vc tenha um BackEnd que seja devops por exemplo, basta implementar essa interface, assim fica muito melhor e só será implementado o necessário.

Assim como nos outros princípios, vc pode acabar exagerando, não divida demais uma interface que já é específica, encontre um equilíbrio, pois é importante lembrar que quanto mais interfaces, mais complexo fica o seu código.

D → Dependency Inversion Principle ou Princípio de inversão de dependência

Classes de alto nível não deveriam depender de classes de baixo nível, ambas devem depender de abstrações. As abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.

Num projeto de software, podemos distinguir dois níveis de classe:

Classes de baixo nível ⇒ Implementam operações básicas, gravam em disco, conexão a banco de dados, etc.
Classes de alto nível ⇒ Implementam a regra de negócio complexa que direcionam as classes de baixo nível para fazerem algo.

Em alguns projetos é comum ver o início da implementação ser nas classes de baixo nível e só depois de tudo definido seguir nas de alto nível. Isso é muito comum em protótipos, pois não sabemos oq será possivel realizar em alto nível, sendo que as classes de baixo nível ainda não foram implementadas ou ainda não estão claras. Com essa abordagem, classes da regra de negócio tendem a ter uma certa dependência das classes de baixo nível.

Esse princípio sugere a troca dessas dependências.

Mas como faremos isso? Vejamos.

Para o início, é necessário desenvolver as interfaces para as operações de baixo nível que as de alto nível dependem, de preferência o mais próximo da regra de negócio. Por exemplo, a lógica de negócio deve chamar um método insertDataBase($query) e não uma série de métodos connectDatabase(), insert($query) e por fim closeConnection($connection) . Essas interfaces contam como alto nível.
Agora vc pode fazer a classe de alto nível depender dessas interfaces, ao invés de classe concretas de baixo nível. Essa abstração ajudará na flixibilidade do seu código.
As classes dependendo dessa interface, elas se tornam dependentes a nível da regra de negócio, fazendo assim a inversão da depêndencia.

Exemplo do princípio usando o (Spoiler) desing pattern Repository.

<?php
interface DataBaseInterface
{
    abstract public function connect($serverName, $userName, $password);
    abstract public function closeConnection($connection);
}

abstract class DataBaseAbstract
{
    public $dbConnection;
    public function __construct() 
    {
        $this->dbConnection = $this->connect(config('database.server'), config('database.user'), config('database.password'));
    }
}

class MySQL extends DataBaseAbstract implements DataBaseInterface
{
    public function connect($serverName, $userName, $password){/* Connect */}

    public function closeConnection($connection){/* Disconnect */}
}

class Mongo extends DataBaseAbstract implements DataBaseInterface
{
    public function connect($serverName, $userName, $password){/* Connect */}

    public function closeConnection($connection){/* Disconnect */}
}

class UserController
{
    private $dataBase;
    public function __construct(DataBaseInterface $db) 
    {
        $this->dataBase = $db;
    }
    // Do a insert.
}

A classe UserController não precisa se preocupar com qual banco de dados a aplicação irá utilizar. Dessa forma, não estamos mais violando o princípio, ambas as classes estão desacopladas e dependendo de uma abstração.

Além disso, estamos favorecendo a reusabilidade do código e também estamos respeitando o princípio S e O.

Um coisa que vc deve ter em mente, Inversão de Dependência não é a mesma coisa que Injeção de Dependência. A Inversão de Dependência é um conceito e a Injeção de Dependência é um design pattern.

Por hoje é isso pessoal, até o próximo artigo.

Notion - Por que usar?

luanloose — Thu, 14 Oct 2021 17:27:44 +0000

Introdução

O Notion é uma ferramenta muito usada para anotações de todos os tipos, eu uso MUITO para criar documentações, organizar projetos pessoais, principalmente quando estou estudando.

Para quem já é acostumado com a escrita do Markdown, se sentirá em casa pois o Notion usa a mesma sintaxe com alguns temperos a mais, caso não conheça vc pode pegar umas dicas.

Ele é um app muito simples de instalar e de começar a usar, não se assuste com a quantidade de informações ao abrir, pois de inicio parece complicado, mas vou te mostrar que não é.

Baixe e instale aqui

Por que usar?

Sou suspeito para dizer pois uso a muito tempo e recomendo a todos.

Com o Notion é possível criar todo tipo de base de conhecimento, banco de dados, boads kanban, wikis, calendário, lembretes, anotações, documentações e escrever artigos para blog (que é oq estou fazendo hehe).

Hello World

Ao terminar a instalação, faça o login, essa é a primeira página que irá aparecer

Com ela vc já consegue ter uma noção dos comandos que pode usar nas suas anotações, não se preocupe em decorar tudo de uma vez, aos poucos vc consegue.

Tá, como vou usar isso para documentar algo?

Que bom que vc perguntou, vou te mostrar oq vc consegue fazer com o Notion, daí provavelmente as ideias fluirão com o tempo.

Vou deixar um print abaixo com meu "caderno" para vcs terem como exemplo.

Criando sua sua primeira doc

Para iniciar basta clicar no Add a page no menu lateral, irá abrir uma página com algumas opções, não se preocupe com elas, vc pode olhar com calma posteriormente, ao criar a página nova vc dê ENTER para deixar ela em branco, digite o título "Minha primeira doc", a partir de agora é sua imaginação que dirá como sua doc ficará, não se preocupe se nada vier a mente de inicio, aos poucos você vai aprendendo e incrementando suas anotações.

Dica de organização

A primeira coisa é decidir oq vc fará, estudar um conceito? Tecnologia? é um projeto pessoal?

Após isso, é possível criar um template com o que vc espera de resultado e depois ir aprofundando cada item, podemos criar desde tópicos até cards num board kanban, vou mostrar como eu faço em cara item das perguntas.

Estudando uma linguagem/tecnologia

Começo com um título de introdução e escrevo sobre o conteúdo, dizendo do que se trata e oq vamos ver pela frente.
Links úteis, aqui terão links que ao seu ver são pertinentes, links de downloads, da doc oficial ou de alguma referência.
Setup inicial, esse aqui é mais para quando estou aprendendo alguma tecnologia, se não for o caso pode pular.
Agora é hora de iniciar o assunto mais aprofundado que eu iniciei na introdução.
Cheat Sheet, isso aqui nada mais nada menos que anotações rápidas para fazer vc lembrar de um comando ou um trecho de código que faça vc lembrar de um conceito, tenho uns exemplos disso nesse [repo](https://github.com/luanloose/Examples).
Resultado:

É possível colocar trechos de códigos com o seguinte comando /code

Estudando algum conceito

Esse aqui provavelmente será oq vc mais tem de familiaridade, pois nada mais é que um resumo do conteúdo, no meu caso oq eu faço, dos itens que estou estudando no momento, se eu já conheço e estou revisitando o tema, começo escrevendo:

Introdução sobre o tema.
Os tópicos conhecidos.
Os tópicos que quero abordar.

A partir daí só evoluir o tema e no final teremos um material novinho em folha.

Exemplo de página de um estudo meu sobre Design Patterns:

Criando um projeto

Está fazendo aquele projeto para portfólio e não tem ideia de como por em prática? Que tal por todas as ideias antes no "papel"?

Após criar o hábito de anotar mais, fiz o teste, antes de começar a codar, anotei todas as regras de negócio, fiz o planejamento do que eu queria mais ou menos na estrutura projeto, sempre pensando no escopo que foi me dado, isso ajuda demais para seguir com o próximo passo, mas não é obrigatório.

Uma coisa muito irada do Notion é poder criar diversos tipos de estrutura de dados, focarei no kanban, mas vc poderá ver os outros e usar todos que tiver vontade.

Temos 2 formas de criar o kanban, uma página só pra ele ou criar um kanban dentro de uma página, para criar qualquer um deles, basta colocar o comando /board:

Exemplo de cada um:

Kanban inline

Essa opção é caso queira incorporar o board dentro de um pedaço da página.

Kanban página

Aqui vc transforma uma página no quadro, nela temos inúmeros jeito de se organizar, deixarei o jeito que eu gosto, use o que mais fizer sentido para vc.

Quais os benefícios?

Nesse momento vc deve se perguntar:

Tá, mas oq isso me trás de benefício?

Além de te ajudar na organização dos conteúdos que estuda, dos projetos e fixar os conhecimentos estudados, é possível gerar conteúdo para a comunidade, garanto que muita gente vai querer ler sobre o assunto que vc está estudando, tem muita gente nova entrando na área, quanto mais conteúdo tiver disponível, melhor.

O mais importante de tudo é o hábito criado, começar é o mais complicado, parece que vai tomar um tempo enorme criando página, estilizando para ficar agradável de se ler, mas se feito um pouquinho a cada dia o hábito virará uma rotina e sem que vc perceba, estará passando isso para mais pessoas, o mais legal é passar conhecimento, todos saem ganhando.

Eu não sou tão fera na escrita, caso vc tbm não seja, está tudo bem, não deixe de compartilhar algo por isso, todos temos algo para aprender, peça ajuda dos amigos para opinar sobre seu texto. Fico a disposição para ajudar tbm 😁.

Conclusão

Acho a ferramenta ótima e muito prática, uso muito no dia a dia. Quando vc começar, vai querer colocar sua vida ali kkkkkkkkkk.

Caso queiram ver alguns comandos ou alguma coisa com mais detalhes, só me avisar que eu trarei algo bacana pra vcs, valeu galera!!

Design Pattern: Introdução e características

luanloose — Thu, 14 Oct 2021 17:23:41 +0000

Introdução

Design Patterns (padrões de projeto) são soluções típicas para problemas comuns, são como plantas baixa de um prédio por exemplo. Um padrão de projeto não é algo que pode ser copiado para dentro do seu contexto, não funciona como exemplos de funções de documentações, libs ou aquele código maroto do stackoverflow 😝. Pois o padrão é um conceito geral a ser usado para resolver um problema particular.

Temos 3 tipos de padrões:

Criacionais: Fornecem criação de objetos que aumentam a flexibilidade e a reutilização de código.
Estruturais: Mostram como é montado objetos e classes em estruturas mais robustas, mantendo-a flexível e eficiente.
Comportamentais: Cuidam da comunicação eficiente e da assinalação entre objetos.

Por que aprender sobre isso?

É possível trabalhar "tranquilamente" como desenvolvedor por anos sem saber nada sobre padrões, muita gente segue assim inclusive, masssss de um jeito ou de outro, no dia a dia vc acabará implementando um dos padrões existentes sem saber.

Sendo assim, pq não aprender sobre eles?

Os padrões de projeto resolvem diversos problemas comuns em projetos de software, pense neles como se fosse uma caixa de ferramentas, vc olha o problema, abre a caixa, analisa qual ferramenta vai precisar no momento, pega e usa.

Simples, não?

Além disso, eles propõem uma definição para tais implementações, vc se depara com um código, vê que se parece com algum padrão e diz, é possível resolver isso usando Strategy, caso o colega conheça o padrão, logo ele entenderá a sua sugestão.

Se não entender, é uma ótima oportunidade para ensinar e passar o conhecimento.

Características de um bom projeto

Antes de seguir vamos comentar sobre algumas características que são almejadas nos nossos projetos e algumas coisas que devemos evitar.

Reutilização de código

É um dos modos mais comuns para se reduzir custos no desenvolvimento. O objetivo é simples: Ao invés de copiar e colar o mesmo código dentro do mesmo projeto ou desenvolver algo do zero sempre, por que não reutilizar códigos já existentes nos seus novos projetos?

O objetivo parece muito simples, mas na prática, fazer um código que já existe e que funciona sozinho, funcionar em outro contexto, exige um esforço adicional.

Para conseguir reutilizar com êxito seus códigos, deve-se evitar dependências de classes concretas ao invés de interfaces e operações hardcoded. Essas coisas reduzem a flexibilidade do seu código e deixa ele cada vez mais difícil a sua reutilização.
Extensibilidade

Seu código está pronto para novos componentes? Novas regras?

Tendo um ecommerce, o cliente percebe a necessidade de adicionar um novo método de pagamento, seu código deve estar preparado e componentizado para suportar tais mudanças, caso contrário ele quebrará. Uma coisa temos que ter em mente, a única constante de um desenvolvedor é a mudança, esteja preparado para ela, implemente algo hoje para que não quebre se for mudado amanhã.

Existe um lado bom nisso: Se alguém pede novos recursos na sua aplicação, significa que ela ainda é importante para a empresa.

Estamos falando sobre um bom projeto, mas o que é um bom projeto? Como podemos deixar nossa arquitetura flexível, estável, escalável e de fácil entendimento?

Essas perguntas são boas, mas as respostas dependem de cada contexto. A boa notícia é que existem vários princípios universais de projeto de software que podem ajudar nessas respostas.

Encapsulamento

Identifique tudo que é variável e separe dos que permanecem os mesmos.

O objetivo desse princípio é minimizar o efeito causado por mudanças.

Imagine o seguinte, temos um supermercado, ao efetuar um pagamento, ele é recusado, oq vai acontecer com os produtos no caixa? Oq acontece com o cliente? Seu código deve estar encapsulado para poder tratar essas excessões. Você pode isolar cada parte que varia em módulos independentes, protegendo o restante da aplicação contra os efeitos indesejados, dessa forma é possível tratar os erros lançados e evitando complicações, como por exemplo um estoque que não volta ao seu estado original quando o pagamento não é efetuado.

Quanto menos tempo vc gasta fazendo mudanças, mais tempo ganha para implementar novas funcionalidades.

Encapsulamento nível método

Bom, suponha que vc tenha um ecommerce com o método checkout nele contém toda a regra de calcular os valores totais de acordo com o meio de pagamento, calcula frete, verifica se tem promoção e fecha o pedido tudo no mesmo código, como por exemplo:

<?php
class Cart {
    use Promotion;

    public function checkout(){

        $products = [1, 2, 3, 4];
        foreach ($arr as &$value) {
            $totalValue += $value;
        }

        // cálculo de promoção
        // cálculo de frete
        // fechar pedido
    }
}

Caso alguma regra dessas mude a função ficará cada vez mais extensa, mais complexa para manutenção e refatoração, vai precisar de muitos testes para garantir que nada quebre, a melhor estratégia é extrair certos trechos para contextos menores, deixando dessa forma:

<?php
class Cart {
    public function checkout(){

        $products = [1, 2, 3, 4];
        foreach ($arr as &$value) {
            $totalValue += $value;
        }

        $this->calculatePromotion();
        $this->calculateShipping();

        // fechar pedido
    }

    function calculatePromotion(){
        // cálculo de promoção
    } 

    function calculateShipping(){
        // cálculo de frete
    }
}

Agora usando dessa forma, cada função ficou isolada da principal, caso alguma se torne mais complexa, vc pode facilmente criar uma classe, a refatoração se torna menos onerosa.

Encapsulamento nível de classe

Seu método que antes era simples e tinha apenas uma responsabilidade, vem ganhando mais e mais recursos, se tornando mais complexo, e assim desfocando a responsabilidade primária da classe a qual ele pertence. Extrair tudo para uma nova classe pode deixar as coisas mais claras e simples.

Nosso exemplo se encontra dessa forma

Agora faremos um objeto especial receber todo o trabalho relacionado a promoções.

O código ficará algo assim:

<?php 
class Cart {
    use Promotion;

    public function checkout(){

        //calcula sub total
        $totalValue = $subTotal + Promotion::calculatePromotion(products);

        $this->calculateShipping();
        //fecha pedido
    }
}

O calculo das promoções ficará abstraído dentro da classe Promotion.

Desenvolva interfaces

Nunca dependa de classes concretas e sim abstrações.

Seu código precisa ser o mais flexível possível, para isso é preciso que seja possível extendê-lo facilmente sem que nada quebre no código existente. Para garantir que essa afirmação é correta vamos para mais um exemplo, saindo do contexto de ecommerce, usaremos gatos para simplificar.

Quem ai não ama gatinhos não é mesmo?

Se não ama, pode se retirar por favor, BRINKS

Um gato que come qualquer comida é mais flexível e fácil de satisfazer do que um que come apenas salmão, gato chique esse ein. Você ainda pode alimentar o primeiro gato com salmão para agrada-lo vez ou outra, mas não poderá alimentar o segundo com atum por exemplo quando chegar no fim do mês quando a grana esta curta, o cardápio do primeiro pode ser estendido para qualquer outra comida, sendo mais fácil para alimenta-lo.

Diagrama demonstrando os dois gatos

Mas como eu deixo meu código mais flexível??

Existem alguns meios de configurar uma colaboração entre objetos:

Determine o que exatamente um objeto precisa do outro, quais métodos ele irá executar.
Descreva esses métodos em uma nova interface ou classe abstrata.
Na classe que é um dependência, implemente essa interface.
Agora faça a segunda classe ser dependente dá interface ao invés da classe concreta. Ainda será possível fazer ela funcionar com objetos da classe original, só que a conexão é muito mais flexível.

Gato 1

<?php
class Salmon {

    public $nutrition;

    public function __construct()
    {
            $this->nutrition = 10;
    }
}

class Cat {

    public function eat( Salmon $salmon ) : string
        {
        return 'The cat is was fed with nutrition: '.$salmon->nutrition;
    }

}

$cat = new Cat;
echo $cat->eat(new Salmon);

// Output
// The cat was fed with nutrition: 10

Gato 2

<?php
abstract class Food {

    public $nutricion;

}

class Salmon extends Food {

    public function __construct()
    {
            $this->nutricion = 10;
    }

}

class Cat {

    public function eat( Food $foodName ) : string
        {
        return 'The cat is was with nutricion: '.$foodName->nutricion;
    }

}

$cat = new Cat;
echo $cat->eat(new Salmon);

// Output
// The cat was fed with nutricion: 10

Antes e depois de extrair a interface, o segundo código é mais flexível que o primeiro, pois quaisquer novas comidas serão "comidas" pelo gato e não somente uma.

Ufa, agora sim poderei economizar um pouco com meu gato.

Prefira composição sobre herança

A herança é provavelmente a maneira mais comum de se reutilizar código, é a mais óbvia né, temos duas classes com códigos em comum, a primeira coisa que vem na mente, vamos criar uma classe base, pegamos o código comum, joga nela e pronto, extende nas outras duas, sucesso.

Porém, a herança vem com um lado ruim que só é aparente quando seu projeto está com mais classes e mudar tudo fica muito difícil, aqui temos uma lista desses problemas:

Uma subclasse tem que implementar TODOS os métodos que possuem na interface da superclasse mesmo que não seja usado.
Quando sobrescrever métodos, vc precisa se certificar que o novo comportamento é compatível com o base, pois a subclasse pode ser passados para qualquer código do tipo da superclasse e vc não quer nada quebre.
A herança quebra o encapsulamento da superclasse, detalhes internos da classe mãe ficam disponíveis para a subclasse.
As subclasses estão firmemente acopladas as superclasses, caso tenha alguma mudança em uma superclasse pode gerar um efeito colateral e quebrar o código das subclasses.
Tentar reutilizar código através da herança pode levar a criação de uma cadeia de heranças paralelas, a herança acontece em uma dimensão.

Existe uma alternativa para a herança que tem o nome de composição. A herança representa a relação de "pipoca é um alimento", "cachorro é um animal" a composição representa a relação "cachorro tem 2 olhos", "pipoca tem temperos".

Sempre pense no seu código o mais desacoplado possível.

É isso galera, nos vemos no próximo artigo.