Metodi comuni nella classe genitore

Question

Metodi comuni nella classe genitore

#1 da (0 voti)

0

Immagina questa semplice classe PHP:

<?php
class MyParent
{
    // this is our common method, we don't use this method anywhere in parent class
    // but we may or may not use this method in some child classes.
    protected function helperMethod()
    {
        // code
    }
}

Come è avere metodi come quello più importante nelle nostre classi? È questo OOP? Non ho buone sensazioni a riguardo, perché se non usassimo questi metodi nei nostri corsi per bambini saranno completamente inutili e possono confondere le persone. per favore dimmi la tua idea.

Un altro esempio:

abstract class Package
{
    // We will never use this method in this class
    protected function getAConfigParam()
    {
        ConfigHolder->getParam('myconfig');
    }

    public function register()
    {
        [...]
        this->registerPackage();
        [...]
    }

    abstract public function registerPackage();
}

class PackageForCli extends Package
{
    public function registerPackage()
    {
        // We will use getAConfigParam method here.
    }
}

class PackageForWeb extends Package
{
    public function registerPackage()
    {
        // We will use getAConfigParam method here.
    }
}

Nell'esempio in alto abbiamo anche accesso a ConfigHolder nelle classi figlie, ma quale dovremmo usare? metodo getAConfigParam o ConfigHolder?

object-oriented object-oriented-design

posta Sina 15.07.2017 - 23:00

fonte

1 risposta

Leggi altre domande sui tag object-oriented object-oriented-design

Come dovrei codificare un modello di osservatore di più tipi? C # usa lo stesso database mysql con il mio sito web

score 0 · Accepted Answer

Se ho ragione, stai facendo qualcosa chiamato metodo template . È un modello di progettazione OOP. Fin qui tutto bene.

In the template method of this design pattern, one or more algorithm steps can be overridden by subclasses to allow differing behaviors while ensuring that the overarching algorithm is still followed

Ciò che ci manca nel tuo caso è se la configurazione è richiesta per assicurare che il processo di registrazione sia sovrascritto.

Se è richiesto, è necessario inserirlo nel metodo template.

abstract class Package
{

    public function register()
    {
        [...]
        this->registerPackage(ConfigHolder->getParam('myconfig'));
        [...]
    }

    abstract public function registerPackage(ConfigParam cfgParam);
}

class PackageForCli extends Package
{
    public function registerPackage(ConfigParam cfgParam)
    {
        // We will use getAConfigParam method here.
    }
}

class PackageForWeb extends Package
{
    public function registerPackage(ConfigParam cfgParam)
    {
        // We will use getAConfigParam method here.
    }
}

Ora, nessun metodo comune nella super classe è necessario. Almeno non quello di cui stiamo parlando.

La soluzione di cui sopra, non impedisce a uno sviluppatore di fare questo:

   class PackageForMobile extends Package
    {
        public function registerPackage(ConfigParam cfgParam)
        {
            //ignoring ConfigParam
            ConfigHolder->getParam('myconfig');
        }
    }

O ignora totalmente ConfigParam se lo ritieni necessario o meno.

Se trovi che le classi figlie ignorino sistematicamente il ConfigParam, allora rimuovi l'accesso al param. YAGNI .

Se trovi che le classi figlie alla fine accedono a ConfigParam, valuta se consentire loro di accedervi tramite DI e rimuovere ConfigParam dal modello. YAGNI di nuovo. Solo una considerazione in più, iniettare il ConfigParam nei bambini invece di chiamare direttamente il configHolder. È più facile eseguire il test dell'unità con DI.

Non hai detto se getAConfigurationParam() è richiesto dai consumatori dei bambini. Se i consumatori hanno bisogno di accedere a ConfigParam, il metodo è ancora necessario. Questo dipende dai tuoi bisogni e requisiti. Ma non dovrebbe influire sul processo di registrazione globale .