È brutto avere classi come proprietà di tutte le altre classi?

Question

È brutto avere classi come proprietà di tutte le altre classi?

#1 da (5 voti)

3

Ho realizzato programmi MVC per lavoro (sono uno stagista) e mi sento come se stessi facendo un buon lavoro all'astrazione, alla singola responsabilità, ecc. Ma ho questa sensazione di come continuo a creare oggetti proprietà di altri oggetti e non sono sicuro che sia una brutta cosa.

Esempio:

User
{
     String Username;
     Int32 UserID;
          .
          .
          .
     BusinessLogicClass Variable;
}

BusinessLogicClass 
{
    AnotherClass Variable;
    AndAnother Variable2;
}

AnotherClass
{
     IThinkYoureGetting ThePoint;
}

Tutte le mie classi sono proprietà degli altri in una massiccia gerarchia, è una specie di ciò che la logica aziendale richiede, ma non posso fare a meno di chiedermi se dovrei cercare di prevenire qualcosa di simile. Così finisco in modo efficace con una variabile che controllo i figli di, ma le classi sono separate.

È qualcosa di comune? È male? Se è cattivo, cosa dovrei fare al riguardo?

design design-patterns

posta Shelby115 04.03.2014 - 18:27

fonte

1 risposta

Leggi altre domande sui tag design design-patterns

SOA - I quattro principi Uso dei suoni sull'app distribuibile - Problema di copyright

score 5 · Accepted Answer

No, non è necessariamente negativo. Questa è la programmazione orientata agli oggetti: gli oggetti contengono altri oggetti. Ognuno è responsabile della propria parte del programma, che spesso significa incapsulare altri oggetti.

Ad esempio, un'auto contiene una trasmissione. Potrebbe essere una classe complessa contenente un mucchio di altri oggetti come ingranaggi, dischi frizione, ecc. Che potrebbero essere astratti come classi.

In un framework MVC, dovresti fare attenzione a tenere separati i diversi problemi. Ad esempio, una vista non dovrebbe in genere contenere oggetti del modello: normalmente la vista comunica gli aggiornamenti del modello richiesti attraverso eventi, disaccoppiando i due livelli. Ma un oggetto vista potrebbe sicuramente contenere altri oggetti vista, ad esempio un pannello contenente pulsanti, caselle di testo, ecc.

La logica aziendale che riguarda il flusso del programma è strettamente una preoccupazione per il livello Controller. La logica aziendale che riguarda l'aggiornamento del modello è un po 'più aperta alla discussione. Nell'esempio, potrebbe essere appropriato per inserire una logica aziendale limitata nel modello Utente, ma solo se tale logica riguarda attività come la convalida, l'aggiornamento di campi dipendenti, ecc. In altre parole, attività che sono strettamente connesso ai dati contenuti nell'Utente. Sarebbe non appropriato per l'utente a contenere la logica che interagisce con l'interfaccia utente o il flusso del programma.