Quando è ok istanziare tutti i miei oggetti in anticipo?

Va bene se non guadagna molte risorse. Il modo migliore per sapere se lo fa è farlo e vedere cosa succede. Questo è un problema di prestazioni. Non aggiustarlo finché non lo vedi.

Il motivo numero uno per non allocare lo spazio in anticipo, gli oggetti in questo caso, è quando non sai già quanto allocare. Questo è il motivo per cui le raccolte di heap sono preferibili rispetto agli array. Ti permettono di allocare solo ciò di cui hai bisogno quando ne hai bisogno.

Tuttavia, quando sai in anticipo quanto spazio è necessario è ragionevole tenere lo spazio anche quando non viene utilizzato. Perché? Poiché le allocazioni di memoria fisse non sono perdita .

Ogni volta che pianifichi di sbarazzarti di oggetti, prevedi di recuperare la loro memoria. Se lo pianifichi, ma in realtà non lo fai, hai bisogno di riavviare. Questo piccolo fastidio è ciò che fa la differenza tra il software di qualità del server e non il software di qualità del server. A nessuno piacciono i server che devono essere riavviati .

Ora certo, se stai molto attento puoi allocare e deallocare dinamicamente e aspettarti di riavere la memoria per altri usi. Ma stare attenti costa tempo, denaro e competenza.

Quindi, se non hai bisogno di allocare dinamicamente, perché dovresti?

Sembra un po 'come le variabili globali (cattive, cattive). O un mucchio di singleton, oggetti di utilità (cattivi, cattivi). Ma poi i moduli sono di nuovo considerati buoni. Normalmente si avrebbe una struttura gerarchica: applicazione - finestre di dialogo x documenti.

"Poichè ne hai bisogno" è il modo più efficiente in generale, quindi mi terrei con quello.

Tuttavia potrebbero esserci interdistanze modulari che richiedono una sequenza di caricamento. Questa gestione non sicura delle dipendenze significa che manca del codice strutturale proprio per questo.

In generale, a partire da un progetto precedente è meglio non iniziare a ridisegnare tutto. Sii critico come evidentemente, ma cerca di garantire la logica di business. Risolvi prima le cose.

Questo è quello che faccio spesso. Ma i miei oggetti sono pigri, non c'è lavoro svolto nei costruttori. Molto spesso è un'indicazione di puro DI in azione, il che è una buona cosa, credo. Mostra che il dominio è stato scomposto in molto modo componibile e che le astrazioni trovate sono altamente riutilizzabili , dal momento che esiste una piccola quantità di interfacce e una grande quantità di classi concrete che le implementano. Ad esempio, è così che potrebbe apparire la mia root di composizione:

try {
    (new WebFront(
        new Fallback(
            new RouteChain(
                [
                    new Route(
                        new Fixed('/registration'),
                        new RegisterUserCoordinator(
                            new PostgresUserDataStorage(RpgProdConnection::me())
                        )
                    ),
                    new Authenticated(
                        new Route(
                            new Fixed('/skill/buy'),
                            new BuySkillCoordinator(
                                new AnalystStorage(RpgProdConnection::me()),
                                new TestPayPalAccount(
                                    new FakeHttpProtocol()
                                )
                            )
                        ),
                        new PostgresUserDataStorage(RpgProdConnection::me())
                    )
                ]
            ),
            new UrlNotFoundResponse()
        )
    ))
        ->act(
            new HttpRequest(
                new HttpMethod($_SERVER['REQUEST_METHOD']),
                new URL("http://$_SERVER[HTTP_HOST]$_SERVER[REQUEST_URI]"),
                getallheaders(),
                new Data($_POST)
            )
        )
    ;
} catch (Exception $e) {
    echo json_encode(['code' => 666, 'message' => 'System failure. Come back later.']);
}