En toda nuestra base de código tenemos este patrón repetido donde hay una interfaz con un método. ¿Es este un patrón de diseño real? Si es así, ¿qué es y cuáles serían los beneficios?¿Es este un patrón de diseño?
Éstos son algunos ejemplos:
public interface IRunnable
{
void Run();
}
public interface IAction
{
void Perform();
}
public interface ICommand
{
void Execute(ActionArgs _actionargs);
}
que he visto esta referenciado como el Command pattern.
Lo aprendí por primera vez leyendo Agile Principles, Patterns, and Practices in C# de Uncle Bob.
Creo que su elegancia es su simplicidad. Lo he usado cuando escribí un servicio de procesamiento de archivos. El servicio realizó toda la administración de lectura/eliminación de archivos. Cuando se debe procesar un archivo, se carga el plugin respectivo. Cada complemento implementó un método Process e hizo lo que fuera necesario para procesar ese tipo de archivo. (Principalmente, analizar el contenido e insertar en una base de datos.)
Cada vez que tenía que procesar un nuevo tipo de archivo con un nuevo diseño, todo lo que tenía que hacer era crear un nuevo complemento que implementara Process.
Esto funcionó para mí porque necesitaba una solución simple. Si necesita tomar más de un parámetro, probablemente este no sea el patrón a usar.
Cualquiera de estos podría ser casos específicos del Command Pattern, dependiendo de cómo se usa y el contexto. Parte de esto dependerá de por qué y cómo estás configurando esto.
El patrón de comando también incluye normalmente un concepto de estado y de varios objetos. Normalmente, este tipo de interfaz sugeriría eso, así que supongo que esto es lo que estás pensando como un patrón de diseño aquí, pero sin la persona que llama o los objetivos múltiples es difícil saber si este es un ejemplo clásico o no. ..
Sin embargo, esto, en sí mismo, es solo una abstracción de interfaz básica para mí, y no algo que clasifique como un patrón de diseño.
No estoy seguro de si podría llamarlo un patrón de diseño, ya que las interfaces que proporcionó no proporcionan soluciones a problemas comúnmente experimentados, sino más bien la solución a problemas muy específicos en el proyecto que está desarrollando.
La razón por la que está utilizando correctamente las interfaces se debe al hecho de que no puede tener todas las clases que necesitan estos métodos ampliar una clase base que las contiene, sin embargo, necesita saber que las clases específicas prometen implementarlas.
podría ser, ya que algunos de los críticos anteriores sugirieron: http://en.wikipedia.org/wiki/Command_pattern
Puede eliminar esta repetición (o prevenirlo de futuro código) mediante el uso de expresiones lambda. Las expresiones Lambda son exactamente para esta situación.
En todo caso, entonces es un functor. Se usa en lenguajes sin función de primera clase (puntero) s para el tipo de cosas que se usan para la función (puntero), como la función principal para un hilo.
Existen aplicaciones para interfaces con un solo método. Quiero decir, en .NET hay muchos - INotifyPropertyChanged, para uno (el evento PropertyChanged). Simplemente garantiza que un objeto tiene un método determinado (independientemente del tipo de objeto que sea en realidad), por lo que puede llamarlo (de nuevo, independientemente del tipo).
Dim runnableObjects As List(Of Object)
runnableObjects.Add(New MyRunnableObject1)
runnableObjects.Add(New MyRunnableObject2)
For Each o As IRunnable In runnableObjects
o.Run()
Next
Como se ha dicho es un Command Design Pattern. Pero es (en mi opinión) más una forma Java de lograr el resultado. En C# puede usar delegados y en los punteros y funtores de la función C++.
No tiene sentido crear más y más clases si ya tiene alguna implementación de la reacción en algún método de clase. Que puede enlazar en C++ o configurar para delegar en C#. En Java, supongo que no tienes más remedio que escribir el código que has encontrado.
Tal vez me falta algo, pero las dos primeras parecen que podrían ser parte del strategy pattern. Básicamente, un objeto tiene un miembro de tipo IAction, y ese miembro se asigna/reasigna en el tiempo de ejecución en función de las necesidades del sistema para realizar una tarea de una manera particular (es decir, utilizando una estrategia particular).