** Table des matières ** Est-ce ce modèle qui permet au parent et à l'enfant de déterminer de manière flexible l'objet à traiter dans l'objet qui a une relation parent-enfant?
Évitez de combiner des objets qui envoient et reçoivent des demandes en donnant à un ou plusieurs objets la possibilité de traiter la demande. Plusieurs objets récepteurs sont connectés dans une chaîne et les demandes sont transmises le long de la chaîne jusqu'à ce qu'un objet traite la demande.
-Handler Classe abstraite de la classe parent et enfant -ConcreteHandler Handler classe de béton ・ Utilisateur client
Si vous comparez les parties qui composent l'écran, je pense qu'elles ont la relation parent-enfant suivante.
fenêtre
----Boîte de dialogue à afficher dans la fenêtre
--------Boutons dans la boîte de dialogue
----Bouton dans la fenêtre
Implémentez un exemple de code qui vous permet de décider librement quel objet gérer lorsqu'un problème se produit en manipulant l'un des objets.
Classe commune Une superclasse de tous les objets. Si le messageType est défini sur quelque chose d'autre que Normal lorsque la vue est instanciée, le traitement du défaut sera exécuté dans l'objet. La vue pour laquelle Normal est défini laisse le traitement à la vue parent. Et la vue parent ... à plusieurs reprises
View.kt
package chainofresponsibility
abstract class View(private val parent: View?, private val messageType: MessageType) {
enum class MessageType {
Normal,
Warning,
Danger
}
protected fun handleHelp() {
if (hasMessage()) {
helpLogic()
} else {
parent?.handleHelp()
}
}
abstract fun helpLogic()
private fun hasMessage(): Boolean {
val ret = MessageType.Normal != messageType
if (ret) {
createDialog()
}
return ret
}
private fun createDialog() {
when (messageType) {
MessageType.Warning -> {
print("Boîte de dialogue d'avertissement:")
}
MessageType.Danger -> {
print("Boîte de dialogue d'erreur:")
}
}
}
}
Fenêtre
Window.kt
package chainofresponsibility
class Window(parent: View?, messageType: View.MessageType): View(parent, messageType) {
override fun helpLogic() {
println("Problèmes causés par Windows!")
}
}
dialogue
Dialog.kt
package chainofresponsibility
class Dialog(parent: View?, messageType: View.MessageType): View(parent, messageType) {
override fun helpLogic() {
println("Bogues causés par le dialogue!")
}
}
bouton Si vous transmettez une valeur différente de zéro à la méthode d'action, un problème se produira.
Button.kt
package chainofresponsibility
class Button(parent: View?, messageType: View.MessageType): View(parent, messageType) {
fun action(arg: Int) {
if (arg == 0) {
println("Réussite")
} else {
handleHelp()
}
}
override fun helpLogic() {
println("Problèmes causés par les boutons!")
}
}
Un problème survient en action (1). Dans l'exemple de code ci-dessous, la fenêtre intercepte le bogue qui s'est produit dans button1 et la boîte de dialogue intercepte le bogue qui s'est produit dans button2. Si vous modifiez le type de message de la boîte de dialogue sur Normal, la fenêtre le rattrapera.
Client.kt
package chainofresponsibility
class Client {
init {
//Fenêtre
val window = Window(null, View.MessageType.Danger)
//Boutons situés directement sous la fenêtre
val button1 = Button(window, View.MessageType.Normal)
//Boîte de dialogue située directement sous la fenêtre
val dialog = Dialog(window, View.MessageType.Warning)
//Boutons placés dans la boîte de dialogue
val button2 = Button(dialog, View.MessageType.Normal)
button1.action(0)
button1.action(1)
button1.action(0)
button2.action(0)
button2.action(1)
button2.action(0)
}
}
[out-put]
Réussite
Boîte de dialogue d'erreur: bug causé par la fenêtre!
Réussite
Réussite
Boîte de dialogue d'avertissement: bug causé par la boîte de dialogue!
Réussite
Que diriez-vous de ce modèle ...
À première vue, il semble qu'il devienne impossible de gérer quel objet parent le gère et crée finalement un bogue, mais en premier lieu, c'est un modèle qui rend inutile la connaissance de l'objet qui reçoit le message, est-ce que ça va? .. Hmm.
Recommended Posts