Ejemplo con el patrón de Visitantes

Question

public class Song { 
    public string Genre { get; protected set; } 
    public string Name { get; protected set; } 
    public string Band { get; protected set; } 

    public Song(string name, string band, string genre) { 
     Name = name; 
     Genre = genre; 
     Band = band; 
    } 
} 

public interface IMusicVisistor 
{ 
    void Visit(List<Song> items); 
} 

public class MusicLibrary { 
    List<Song> _songs = new List<Song> { ...songs ... }; 

    public void Accept(IMusicVisitor visitor) { 
     visitor.Visit(_songs); 
    } 
} 

y ahora aquí está uno de los visitantes que hice:

public class RockMusicVisitor : IMusicVisitor { 
    public List<Song> Songs { get; protected set; } 

    public void Visit(List<Song> items) { 
     Songs = items.Where(x => x.Genre == "Rock").ToList(); 
    } 
} 

¿Por qué es mejor que simplemente poner una canción de propiedad pública y luego dejar cualquier tipo de clase hacer con ella todo lo que se ¿quiere?

Este ejemplo procede de este post.

Answer 1

Es principalmente porque el ejemplo es un mal ejemplo del patrón de visitante. El propósito del patrón de visitante es agregar funcionalidad común a un grupo de objetos sin tener que derivar de la misma clase. Le permite seguir agregando funcionalidad a las clases sin tener que cambiar las clases. El ejemplo de fruto más largo en la respuesta que citó es una mejor explicación del patrón de visitante.

Lea el artículo de la wikipedia citado, para que el visitante pague debe tener un grupo de clases. En su caso, las diferentes clases no están garantizadas por lo que no es necesario el patrón de visitante. Dada una estructura de clase más heterogénea, el patrón del visitante podría ser útil.

Answer 2

En mi opinión, la utilidad de este patrón tiene que ver con la implementación de MusicLibrary. Como se muestra arriba en su forma más simple, solo está pasando la lista de canciones al método Visitor.Visit. En una aplicación más compleja puede que no exista una lista en la memoria para exponer: por ejemplo, podría tener que recorrer las bibliotecas de diferentes máquinas solo para crear la lista. Lo que quiero decir, sin importar qué tan mal esté hecho, es que a medida que aumenta la complejidad de iterar Canciones, esa lógica se puede mantener centralmente en MusicLibrary, y los objetos IMusicVisitor solo pueden tratar con colecciones de Canciones.