2 Classi che condividono comportamenti simili ma non correlati.

Question

2 Classi che condividono comportamenti simili ma non correlati.

#1 da (1 voti)

0

Sto lavorando a qualcosa al momento e sono un po 'confuso.

Sto lavorando su un sistema di richiesta in PHP (è basato su Opencart, quindi MVC).

Arriva un'inchiesta e, a seconda della forma da cui è stata inviata, dipende dalla cartella in cui si trova, le cartelle rispecchiano le categorie, quindi un'indagine proveniente da TeeShirts, ad esempio, si troverebbe in una cartella chiamata TeeShirts. Le cartelle non sono configurate in modo dinamico, sono impostate manualmente dall'amministratore.

Ho qualcosa di molto simile al momento, una classe per "Status", la classe può aggiungere / rimuovere / modificare lo stato, tagare lo stato su richiesta, contare lo stato ecc.

Quindi .. La classe di stato fa quasi esattamente ciò che voglio fare la classe di cartelle, ma la classe di cartelle è parte integrante del programma, dove la classe di richiesta può essere scartata o sostituita. Le due cose condividono molte somiglianze, abbastanza, che sto pensando di creare una classe base.

È il fatto che le cartelle sono praticamente al centro della mia applicazione, sto pensando a legarle insieme.

Sto cercando qualche consiglio solo per iniziare, dato che sono abbastanza nuovo alla programmazione, specialmente OOP, quindi QUALCHE consiglio è benvenuto.

object-oriented design php

posta Kelvin Harris 09.03.2015 - 05:59

fonte

1 risposta

Leggi altre domande sui tag object-oriented design php

Complessità ciclica per 2 IF: perché non solo FF o TT? programmazione dinamica con memoization

score 1 · Answer 1

La domanda è un po 'oscura, ma sembra che tu debba rivisitare il tuo design di classe. La mia analisi è che stai vendendo Prodotto che appartengono a una Categoria e sono memorizzati in un inventario (nel tuo caso un file flat dati memorizzare).

Avrai anche bisogno di una classe ProductStatus per conservare i contenuti interrogati dall'inventario, ad es. Numero in magazzino, isCurrentProduct () e forse dettagli delle varianti (ad esempio taglie T-shirt).

Una volta che la gerarchia delle classi è stata pulita, il codice dovrebbe avere automaticamente una posizione corretta in cui vivere. Alcune aspettative:

L'inventario deve conoscere i prodotti, ma i prodotti non dovrebbero sapere come vengono memorizzati. Se sei fortunato, il tuo negozio può espandersi e ha bisogno di un database SQL adeguato per contenere l'inventario. Se lo progettate correttamente, è sufficiente sostituire l'implementazione dell'inventario. In Java vorrei rinforzarlo definendo un'interfaccia IInventory, ma non sono sicuro di quali siano le opzioni in PHP - forse una classe di base astratta di Inventory?
È probabile che la classe ProductStatus non abbia quasi metodi comportamentali. Il suo compito nella vita è agire come un contenitore di dati che trasporta i dati tra l'inventario e la GUI.
La classe Cartella potrebbe esistere all'interno dell'implementazione di Inventory, ma non dovrebbe trapelare nella GUI, in quanto è un dettaglio di implementazione.

Buona fortuna - spero che questo ti dia qualcosa su cui riflettere.