PHP - Compartimentando e organizando em objeto as minhas funções

[nandoLima]

class Funcoes {

    ### VAR
    public $sis, $ini, $txt, $arr, $url, $js, $fmt, $val;
    
    ### CONSTRUCT
    function __construct () {
    

        // Tratamento de texto e arrays
        require_once 'func/func.texto.php';
        $this->txt      = new FuncTexto(); 

        // Tratamento de texto e arrays
        require_once 'func/func.arr.php';
        $this->arr      = new FuncArr(); 

        // Tratamento de url e javascript
        require_once 'func/func.url.js.php';
        $this->url      = new FuncUrl(); 
        $this->js       = new FuncJs();

        // Funções do sistema 
        require_once 'func/func.sis.php';
        $this->sis      = new FuncSis(); 
        require_once 'func/func.ini.php';
        $this->ini      = new FuncIni(); // Inicialização, erros e saídas
        
        // Funções de formatação
        require_once 'func/func.formatacao.php';
        $this->fmt      = new FuncFormata(); 

        // Funcões de validação de dados
        require_once 'func/func.validacao.php';
        $this->val      = new FuncValida(); 

    }
...

Fica muito feio, ou errado, organizar a classe de funções assim?

Uso, hoje:

Na versão anterior da minha base usava funções normais, mas os arquivos ficaram muito grandes…

[romulopb]

Depende… Não é que fique feio ou errado… O problema é que não é um design robusto, escalável, com baixo acoplamento, etc… Eu diria, mais pelo uso de globais, embora o acesso indireto de funções também não seja legal.

Essas escolhas podem dificultar sua vida e a de seus colegas no futuro, por n motivos:

• Não existe nada garantindo que headTitle não vai conseguir acessar $f antes do mesmo ser construído.
• Você está dando espaço para erros que antes não seriam possíveis ao tornar mais difícil garantir quais métodos estão disponíveis a qualquer momento, assim como dando mais espaço para incerteza no estado de $sis, $ini, $txt, etc.
• Erros em situações assim podem acabar ficando menos claros, já que agora $txt é uma entidade indireta, o que dificulta garantir o seu estado em todo e qualquer momento.
• Essa forma de resolver o problema, pode gerar atritos na hora de testar o código. As dependências do seu código não estão claras e portanto cada componente está mal isolado, não tem seus limites bem definidos. O que depende do que, etc.

O tamanho de um arquivo, ao meu ver, é um problema menor diante desses que apontei. Um designs mais robustos para resolver esse tipo de problema seria injeção de dependência, por exemplo.

[nandoLima]

@romulopb

Essas escolhas podem dificultar sua vida e a de seus colegas no futuro, por n motivos:

Obrigado.

@romulopb

Não existe nada garantindo que headTitle não vai conseguir acessar $f antes do mesmo ser construído

Não entendi.

@romulopb

Você está dando espaço para erros que antes não seriam possíveis ao tornar mais difícil garantir quais métodos estão disponíveis a qualquer momento, assim como dando mais espaço para incerteza no estado de $sis, $ini, $txt, etc.

Percebo, abri mais buracos.
O “ganho” na economia de linhas de código não me parece compensar mais.

@romulopb

Essa forma de resolver o problema, pode gerar atritos na hora de testar o código. As dependências do seu código não estão claras e portanto cada componente está mal isolado, não tem seus limites bem definidos. O que depende do que, etc.

Sim, ninguém poderá testar sem acesso as dependências.

@romulopb

O tamanho de um arquivo, ao meu ver, é um problema menor diante desses que apontei. Um designs mais robustos para resolver esse tipo de problema seria injeção de dependência, por exemplo

Obrigado @romulopb! Vou estudar sobre.

injeção de dependência at DuckDuckGo

[romulopb]

@nandoLima

@romulopb

Não existe nada garantindo que headTitle não vai conseguir acessar $f antes do mesmo ser construído

Não entendi.

Dependendo de onde você ou seus colegas forem usar headTitle, pode ser que você ainda não tenha instanciado $f, e não ha nada no seu código explicitando essa dependência, ou seja ela existe e é implícita, obscura, e isso não é bom.

headTitle neste caso está fortemente acoplado a $f, especialmente, por $f ser global. Variáveis globais, referências indiretas, má delimitação de dependências, tudo isso contribui para forte acoplamento entre objetos e componentes no seu código.

Idealmente seria bom que você construísse seu código, de forma que alguém, ao tentar utilizar headTitle, se deparasse com a necessidade de obter $f de algum lugar ou instanciá-lo, ou que fosse inevitável resolver essa questão (explicito), injeção de dependência resolve isso.

Ao ter um serviço dono de $f e uma classe dona de headTitle, se headTitle for obrigada a estar em uma instância cujo construtor precisa receber uma instância de um serviço dono de $f, a classe dona de headTitle ficará melhor isolada, pois será mais fácil compreender e fazer headTitle, funcionar, pois o mesmo pertence a uma classe fracamente acoplado ao resto do sistema, ou seja, é uma classe que podemos entender melhor sozinha, saber bem suas dependências e minimizar efeitos colaterais, incluindo validações especiais na classe durante a instanciação, etc.