Dúvida no princípio OCP

[Manoel Barros 1]

Beleza galera do imasters

Estou estudando este princípio OCP, e me deparei com um exemplo que encontrei na net.. e para resolver ele estou com uma dúvida

O exemplo é esse

class Debito
{

    /** 
     * @param $valor int
     * @param $tipo  TipoDebito
     */
    public function Debitar($valor, TipoDebito $tipo)
    {
        if ($tipo instanceOf Poupanca)
        {
            // Debita Poupanca
        }
        if ($tipo instanceOf ContaCorrente)
        {
            // Debita ContaCorrente
        }
    }
}

Onde para corrigir o problema da violação OCP, foi feito a seguinte refatoração:

abstract class Debito
{
    public abstract function Debitar($valor);
}

class DebitoContaCorrente extends Debito
{
    public function Debitar($valor)
    {
        // Debita Conta Corrente
    }
}

class DebitoContaPoupanca extends Debito
{
    public function Debitar($valor)
    {
        // Debita Conta Poupança
    }
}

class DebitoContaInvestimento extends Debito
{
    public function Debitar($valor)
    {
        // Debita Conta Investimento
    }
}

Ok.. foi feito a refatoração e agora está bunitinho.. mas agora para realizar este debito como seria ?

eu pensei na seguinte maneira.

class ContaPoupanca
{
    public function realizarDebito($valor)
    {
	$debito = new DebitoContaPoupanca;
	$debito->debitar($valor);
    }

    public function sacar()
    {
        // realizar saque
    }

    // ...
}


#### para usar uma classe conta poupança
$conta = new ContaPoupanca;
$conta->realizarDebito();

Então fiquei meu confuso nisto tudo, pois tive que criar uma classe ContaPoupanca, para realizar um debito que somente a classe DebitoContaPoupanca poderia realizar..

resumindo um participante consumindo o outro..

Estamos falando de um exemplo simples. Mas se fosse algo mais complexo, onde vários participantes um consumindo o outro, para somente para realizar um processo?

Algum perito em POO poderia ajudar nesta Dúvida, desde já agradeço

[Gabriel Heming 766]

Nesse momento, você está indo um pouco além do que o princípio define.

Open Close Principle define que uma entidade (classe, módulo, função, etc..) deve ser fechada para alterações mas aberta para extensão. Ou seja, adicionar uma nova funcionalidade com nenhuma, ou ao menos o mínimo, de alterações necessárias nas implementações existentes.

O seja, refatoração da implementação da classe Debito condiz com que o princípio define. Agora, pode-se adicionar quantas novas implementações de débito forem necessárias, sem alterar as implementações existentes.

A forma de utilizar os objetos tem haver com outras questões, por exemplo:

- tipo de associação (simples, agregação, composição);

- Single Responsibility Principle;

- Dependency Inversion Principle;

- Princípios de pacotes (são outros seis além do S.O.L.I.D.);

- Implementação*.

O último acima de tudo.

Basicamente, você precisa verificar se a sua implementação está com a relação adequada e/ou se fere algum princípio. Se em algum momento sua ContaPoupanca irá realizar um débito em conta corrente, sua implementação está errando no tipo de associação/relacionamento, ferindo SRP (pois possui mais de um motivo para mudar).

No momento que tiver que mudar o relacionamento, você precisará utilizar a injeção de dependência, nesse instante, terá de averiguar sobre DIP. Assim por diante...

[Manoel Barros 1]

Ententi .. você tem razão, a classe ContaPoupanca pode está ferindo o PSR.. caso tenha que debitar em outra tipo de conta, terei que modificar ela..

são detalhes que a gente não presta atenção, mas com o tempo a gente vai aprendendo.

obrigado pelo esclarecimento

Agora esse principio de pacotes não sabia da sua existência. Mas algum principio alem de pacote e solid?

[Gabriel Heming 766]

Princípios existem aos milhares. O importante não é conhecer todos, e sim abstrair de todos a melhor abordagem possível.

Eu diria para conhecer todos do link que lhe passei (agora que o PHP possui um suporte melhor a pacotes);

Object Calisthenics (o Guilherme Blanco tem uns slides no slideshare);

Clean Code (do Robert C. Martin também);

Refactoring: Improving the Design of Existing Code (Martin Fowler).

Também há os sites abaixo que possuem bons conteúdos:

https://sourcemaking.com/

http://www.oodesign.com/