Procedura consigliata per popolare una classe 'contenitore'

Question

Procedura consigliata per popolare una classe 'contenitore'

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)
#4 da (0 voti)

0

diciamo che ho diversi oggetti Object A , Object B , Object C in diverse parti del mio progetto. Ho definito un Object X che viene utilizzato solo per memorizzare alcuni valori specifici dagli oggetti sopra menzionati più alcuni altri dati di contesto, solo le funzioni getter e setter e passarlo su un altro livello o servizio. Quale sarebbe la procedura migliore per creare un metodo per riempire il mio Object X .

Opzione 1

Definisci in un unico pacchetto tutti i metodi necessari per spostare i valori.

Class FillObject{
   public static ObjectX fill(ObjectA a, contextVariableA ctx){
      ObjectX x = new ObjectX;
      x.setName(a.getName());
      x.setPlate(ctx)
      return x;
   }

   public static ObjectX fill(ObjectB b,contextVariableB ctx1, contextVariableB ctx2){
      ObjectX x = new ObjectX;
      x.setName(b.getName());
      x.setOrigin(ctx1)
      x.setPlate(ctx2)
      return x;
   }
}

In questo modo quando ho bisogno di riempire ObjectX nel pacchetto in cui ObjectA esiste, posso solo fare:

// ObjectA myA was define prior to this line
ObjectX myX = FillObject.fill(myA,ctxVar);
anotherService.doSomething(myX);

Posso usare lo stesso approccio in un altro pacchetto in cui ObejectB esiste.

Opzione 2

Definisci diversi costruttori per ObjectX per gestire la creazione dell'oggetto in base al tipo di argomenti.

object-oriented clean-code programming-practices

posta IDev01 24.05.2018 - 14:53

fonte

4 risposte

Leggi altre domande sui tag object-oriented clean-code programming-practices

Motivo di progettazione per il dominio di spedizione / ricezione Gestire oggetti di valore complessi

score 1 · Answer 1

X conosce A, B e C? Puoi sempre creare un metodo factory statico all'interno di X per creare se stesso dagli altri. Spesso vedi questo modello di fabbrica autonomo nelle classi .NET. Rimuove la necessità per le classi di fabbrica.

class ClassX
{
    public static ClassX FromA(A a, Settings settings)
    {
        var x = new ClassX();
        // do setup with variables
        return x;
    }
}

var a = new A();
a.Stuff = 'Things';
var settings = new Settings('something', 123);

var x = ClassX.FromA(a, settings);

Dove potresti aver bisogno di una classe factory è dove la classe di output non conosce le sue classi di input, ad esempio se stai riunendo due librerie non correlate.

SomeLibrary.A a = new SomeLibrary.A(); // some other library
OtherLibrary.X x = MyFactory.XFromA(a); // my code using A and X libraries.

score 0 · Answer 2

Esclusivamente, dal punto di vista del design, non sono troppo "accogliente" con la nozione di " Object X che sa di Objects A, B, C ", perché ... beh, "che dire di Object D , quando definiamo tra sei mesi? " Preferirei che Object X fosse abbastanza agnostico.

Preferirei invece mettere questa funzionalità negli oggetti A,B,C - cioè in una superclasse che è comune a tutti e tre. Questo metodo di superclasse potrebbe essere, ad esempio, insertIntoObjectX(ObjectX foo) . Questa classe è un "amico" di Object X e quindi in grado di accedere a un metodo in Object X che viene messo da parte per questo scopo. E poi, come ulteriore controllo, questo metodo (di Object X ) verificherà che l'oggetto chiamante "è un" membro della superclasse specificata (eredità multipla).

Ora, ho un'architettura flessibile estendibile: tutto ciò che è un membro della superclasse specificata può essere inserito in Object X , e, se Object X ha bisogno di aiuto speciale da qualunque oggetto viene inserito in esso, sa che può avvalersi dei metodi (protetti ...) di quella superclasse. So che ho solo due parti del codice sorgente da considerare - la definizione di Object X e la definizione della superclasse.

Questa è un'architettura che potrei vivere a lungo termine.

score 0 · Answer 3

Il tuo esempio suggerisce alcuna differenza tra come vengono utilizzati A e B. In realtà sembra più una singola funzione di riempimento, con A e B che implementano un'interfaccia denominata e altre due variabili di contesto (l'ultima è facoltativa).

In generale però questo tipo di funzione è una trasformazione. Dovrebbe vivere come una funzione di supporto vicino al suo utilizzo. Se è più generale, prova a tenerlo separato dalle classi A e B e dalla classe X. L'unica eccezione è quando A o B sono dominio relativi a X.

Il dominio correlato è nel senso di una ruota di una macchina. Non nel senso di una persona a una macchina. Il primo è integrale, è difficile separare i due. Il secondo va e viene, è persino possibile averne uno completamente senza l'altro.

score 0 · Answer 4

Dici di voler passare l'Oggetto X su un altro livello. Quindi l'oggetto X non dovrebbe conoscere l'oggetto a, boc. Questo perché se cambi mai qualcosa con l'oggetto a, boc, potresti benissimo finire con il cambiare l'oggetto X, che potrebbe quindi finire col passare in quell'altro livello.

Di norma, se si passa un oggetto a diversi livelli nella propria architettura, dovrebbe avere il minor numero possibile di dipendenze.

La classe FillObject nel tuo esempio va bene. Suggerirei di rinominarlo in qualcosa che contiene Factory.