Metodi di interfaccia rispetto agli oggetti dati

2

Costruire un editor dell'interfaccia utente per Android e fondamentalmente ci sono interfacce come questa:

interface Item {
    fun decorate()
    fun translate(x: Int, y: Int)
    fun rotate(rotation: Float)
    fun scale(scale: Float)
    fun select(value: Boolean)
}

è stato esteso anche con interfacce come queste:

interface Removable {
    fun remove()
}

Significa che il View che è un Item che può essere rimosso implementa sia Item (ovviamente) che Removable .

Ma oltre a questi, per View s che hanno proprietà uniche, come le proprietà del testo, questo è stato creato:

interface Updatable {
    fun update(data: Any)
}

Ciò richiede alcune classi di dati che possono essere interpretate dopo il controllo dei tipi per aggiornare / modificare View .

Per essere più chiari, l'implementazione di Item , BasicItem avrà il target View impostato tramite un metodo setter.

Questo significa che un RemovableTextItem implementerà Item , Removable e Updatable tramite delega dove una delle classi delegate per Item interfaccia sarebbe BasicItem e per le altre interfacce implementazioni simili sarebbero delegato a.

Il problema in questo approccio è la verbosità e l'aggiunta di alcuni metodi a Item ora sembra un peso. Si noti che l'ereditarietà qui, viene evitata deliberatamente nella pratica di prestito della composizione più a questo problema.

Suggeriresti di ridurre tutto a un'interfaccia Item con il metodo update che accetta solo ItemProperties data class che verrebbe interpretata dalla classe che la implementa?

    
posta razzledazzle 17.08.2016 - 16:35
fonte

0 risposte

Leggi altre domande sui tag