Come posso separare in modo pulito il primo codice tutorial aperto dal mio normale codice di visualizzazione in OOP?

Question

Come posso separare in modo pulito il primo codice tutorial aperto dal mio normale codice di visualizzazione in OOP?

#1 da (2 voti)

1

Ho un'architettura MVC e ho le viste di base completate. Ora ho bisogno di aggiungere la prima modalità tutorial utente nel progetto. Non voglio aggiungere controlli per il primo stato utente in tutte le viste che ne hanno bisogno, ma l'unica alternativa che posso pensare è di sottoclasse tutto e utilizzare quelle sottoclassi alla prima apertura. Esiste una pratica standard o ampiamente utilizzata per aggiungere supporto per tutorial, ecc. Senza creare confusione su tutto?

EDIT: non sono chiaro nella mia domanda.

Sto parlando di tutorial che un utente incontra quando usa l'app per la prima volta - nel nostro caso vogliamo aggiungere effetti visivi per indirizzare la loro attenzione sugli elementi dell'interfaccia utente chiave. Ho scritto "primo stato utente" per indicare che memorizziamo lo stato del numero di utilizzi su una macchina locale e lo usiamo per determinare se è necessaria la visualizzazione. Solitamente aggiungerei qualche tipo di codice maiuscolo alle viste, ad esempio, se User.firstUse () arrowView.show () ;, ma mi chiedevo se esistesse un modo più semplice per partizionare quel tipo di codice dal codice normale.

object-oriented separation-of-concerns

posta John Cartwright 25.02.2013 - 04:53

fonte

1 risposta

Leggi altre domande sui tag object-oriented separation-of-concerns

Convalidare gli oggetti tra loro - Modello di progettazione necessario qual è il nome del modello per la strategia descrittiva tra ricerca e sviluppo e servizi professionali

score 2 · Accepted Answer

La cosa principale qui è che vuoi disaccoppiare il contenuto del tutorial della "prima vista" dal resto del tuo programma, in modo che tu possa rimuovere quel contenuto in modo pulito dall'interfaccia utente dopo che l'utente l'ha visto una volta. Ci sono un certo numero di modelli di progettazione che ti consentono di farlo; eccone tre:

decoratore : Potenzia la funzionalità di un oggetto foo contenerne in un altro oggetto bar (il decoratore) che ha un'interfaccia simile e chiama fino a foo per ogni metodo. bar è utilizzato nel programma al posto di foo , quindi ogni volta che un metodo nell'interfaccia viene chiamato bar ha la possibilità di intervenire, compresa la modifica del modo in cui foo risponde al metodo.
delega : Un oggetto "helper" viene utilizzato per modificare il comportamento dell'oggetto / i delegante / i. Ad esempio, se stai seguendo MVC, il tuo oggetto visualizza potrebbe impiegare un delegato che inserisce il materiale del tutorial. Quando si verificano determinati eventi interessanti (la vista appare, l'utente fa clic su una sottoview, la vista scompare, ecc.) La vista può offrire al delegato la possibilità di rispondere. Una volta che l'utente ha visto il tutorial, puoi semplicemente saltare la creazione del delegato e il materiale del tutorial non verrà visualizzato.
osservatore : la tua vista invierebbe messaggi a qualsiasi oggetto dell'osservatore registrato su punti interessanti nel programma. Gli oggetti che usano lo schema dell'osservatore sono così strettamente accoppiati che di solito è difficile per l'osservatore modificare il comportamento dell'oggetto osservato, ma ciò potrebbe non essere necessario. Ad esempio, se puoi fornire una visualizzazione trasparente che si sovrappone all'interfaccia utente normale, quella vista potrebbe osservare cosa sta accadendo nell'interfaccia utente e visualizzare il contenuto del tutorial secondo necessità. Quando non vuoi il tutorial, non creare l'overlay.

Alcuni di questi pattern hanno il potenziale per aiutarti a fare di più che fornire semplicemente il contenuto del tutorial. Se dovessi implementare il mio esempio in observer , ad esempio, potresti utilizzare lo stesso meccanismo per visualizzare informazioni diagnostiche invece del contenuto del tutorial, in modo che il debug sia più semplice.