¿Cómo encuentras una aguja en un pajar?

De los tres, prefiero la opción #3.

El Principio de Responsabilidad Única hace que no quiera poner capacidades de búsqueda en mis DTO o modelos. Su responsabilidad es ser datos, no encontrarse a sí mismos, ni las agujas deben tener que saber acerca de los pajares, ni los pajares saben acerca de las agujas.

Por si sirve de algo, creo que la mayoría de los practicantes de OO tardan mucho tiempo en entender por qué #3 es la mejor opción. Hice OO durante una década, probablemente, antes de realmente groked se.

@wilhelmtell, C++ es uno de los pocos lenguajes con especialización en plantillas que hacen que un sistema de este tipo realmente funcione. Para la mayoría de los idiomas, un método de "encontrar" de propósito general sería una idea HORRIBLE.

Hay otra alternativa, que es el enfoque utilizado por el STL de C++:

find(haystack.begin(), haystack.end(), needle)

Creo que es un gran ejemplo de C++ gritando " ¡en tu cara!"to OOP. La idea es que OOP no es una bala de plata de ningún tipo; a veces las cosas se describen mejor en términos de acciones, a veces en términos de objetos, a veces ninguno y a veces ambos.

Bjarne Stroustrup dijo en TC++PL que cuando diseñas un sistema debes esforzarte por reflejar la realidad bajo las restricciones de código eficaz y eficiente. Para mí, esto significa que nunca debes seguir nada ciegamente. Piense en las cosas a mano (pajar, aguja) y el contexto en el que estamos (buscando, de eso se trata la expresión).

Si el énfasis está en la búsqueda, entonces se usa un algoritmo (acción) que enfatiza la búsqueda (es decir, es flexible para adaptarse a pajares, océanos, desiertos, listas vinculadas). Si el énfasis es sobre el haystack, encapsule el método find dentro del objeto haystack, y así en.

Dicho esto, a veces estás en duda y tienes dificultades para tomar una decisión. En este caso, estar orientado a objetos. Si cambias de opinión más tarde, creo que es más fácil extraer una acción de un objeto que dividir una acción en objetos y clases.

Siga estas pautas, y su código será más claro y, bueno, más hermoso.

Yo diría que la opción 1 está completamente fuera. El código debe leerse de una manera que le diga lo que hace. La opción 1 me hace pensar que esta aguja va a buscarme un pajar.

La opción 2 se ve bien si un pajar está destinado a contener agujas. ListCollections siempre va a contener ListItems, así que haciendo colección.find (item) es natural y expresivo.

Creo que la introducción de un objeto auxiliar es apropiada cuando:

1. Usted no controla la aplicación de los objetivos en cuestión
   IE: búsqueda.buscar (ObsecureOSObject, archivo)
2. No hay una relación regular o sensible entre los objetos
   IE: nameMatcher. find (casas,trees.name)

Estoy con Brad en este caso. Cuanto más trabajo en sistemas inmensamente complejos, más veo la necesidad de desacoplar realmente los objetos. Tiene razón. Es obvio que una aguja no debería saber nada sobre el pajar, así que 1 está definitivamente fuera. Pero un pajar no debería saber nada sobre una aguja.

Si yo fuera el modelado de un pajar, yo podría implementar como una colección-sino como una colección de heno o paja -- no es una colección de agujas! Sin embargo, me gustaría tomar en la consideración de que las cosas se pierden en un pajar, pero no sé nada acerca de qué exactamente esas cosas. Creo que es mejor no hacer que el pajar busque elementos en sí mismo (cómo smart es un pajar de todos modos). El enfoque correcto para mí es que el pajar presente una colección de cosas que están en él, pero no son paja o heno o lo que le da a un pajar su esencia.

class Haystack : ISearchableThingsOnAFarm {
   ICollection<Hay> myHay;
   ICollection<IStuffSmallEnoughToBeLostInAHaystack> stuffLostInMe;

   public ICollection<Hay> Hay {
      get {
         return myHay;
      }
   }

   public ICollection<IStuffSmallEnoughToBeLostInAHayStack> LostAndFound {
      get {
        return stuffLostInMe;
      }
   }
}

class Needle : IStuffSmallEnoughToBeLostInAHaystack {
}

class Farmer {
  Search(Haystack haystack, 
                 IStuffSmallEnoughToBeLostInAHaystack itemToFind)
}

En realidad hay más que iba a escribir y abstraer en interfaces y luego me di cuenta de cómo me estaba volviendo loco. Me sentí como si estuviera en una clase de CS en la universidad... : P

Usted consigue la idea. Creo que ir tan libremente acoplado como sea posible es una buena cosa, pero tal vez me estaba dejando llevar un poco! :)

Si tanto la Aguja como el Pajar son DAOs, entonces las opciones 1 y 2 están fuera de discusión.

La razón de esto es que DAOs solo debería ser responsable de mantener las propiedades de los objetos del mundo real que están modelando, y solo tener métodos getter y setter (o simplemente acceso directo a la propiedad). Esto hace que la serialización de los DAOs en un archivo, o la creación de métodos para una comparación genérica / copia genérica sea más fácil de escribir, ya que el código no contendría un montón de instrucciones" if " para omitirlas métodos de ayuda.

Esto solo deja la opción 3, que la mayoría estaría de acuerdo en que es un comportamiento correcto.

La opción 3 tiene algunas ventajas, siendo la mayor de ellas las pruebas unitarias. Esto se debe a que tanto los objetos de Aguja como los de Pajar se pueden burlar fácilmente ahora, mientras que si se utilizaran las opciones 1 o 2, el estado interno de la Aguja o del Pajar tendría que modificarse antes de que se pudiera realizar una búsqueda.

En segundo lugar, con el buscador ahora en una clase separada, todas las búsquedas el código puede guardarse en un solo lugar, incluido el código de búsqueda común. Mientras que si el código de búsqueda se ponía en el DAO, el código de búsqueda común se almacenaría en una jerarquía de clases complicada, o con una clase Auxiliar de búsqueda de todos modos.

Esto depende completamente de lo que varía y lo que permanece igual.

Por ejemplo, estoy trabajando en un framework (non-OOP) donde el algoritmo find es diferente dependiendo tanto del tipo de la aguja como del pajar. Aparte del hecho de que esto requeriría doble envío en un entorno orientado a objetos, también significa que no es significativo escribir needle.find(haystack) o escribir haystack.find(needle).

Por otro lado, su solicitud podría felizmente delegar la búsqueda a cualquiera de las dos clases, o se adhieren a un algoritmo por completo en cuyo caso la decisión es arbitraria. En ese caso, preferiría la forma haystack.find(needle) porque parece más lógico aplicar el hallazgo al pajar.

Al implementar una búsqueda de aguja de un pajar orientado a objetos, usted esencialmente tiene tres alternativas:

1. Aguja.buscar (pajar)

2. Pajar.buscar (aguja)

3. Buscador.buscar (aguja, pajar)

¿Cuál prefieres y por qué?

Corrígeme si me equivoco, pero en los tres ejemplos ya tienes una referencia a la aguja que estás buscando, así que no es esto ¿como buscar tus gafas cuando están en tu nariz? : p

Juego de palabras aparte, creo que realmente depende de lo que consideres la responsabilidad del pajar de estar dentro del dominio dado. ¿Solo nos importa en el sentido de ser una cosa que contiene agujas (una colección, esencialmente)? Luego haystack.encontrar(needlePredicate) está bien. De lo contrario, Granjero.encontrar (predicado, pajar) podría ser más apropiado.

Para citar A los grandes autores de SICP,

Los programas deben estar escritos para que la gente los lea, y solo incidentalmente para que las máquinas los ejecuten

Prefiero tener ambos métodos 1 y 2 a mano. Usando ruby como ejemplo, viene con .include? que se usa así

haystack.include? needle
=> returns true if the haystack includes the needle

A veces, sin embargo, puramente por razones de legibilidad, quiero darle la vuelta. Ruby no viene con un método in?, pero es de una sola línea, así que a menudo hago esto:

needle.in? haystack
=> exactly the same as above

Si es "más importante" para enfatizar el pajar, o la operación de búsqueda, prefiero escribir include?. A menudo, sin embargo, ni el pajar o la búsqueda es realmente lo que te importa, solo que el objeto esté presente - en este caso encuentro que in? transmite mejor el significado del programa.

Depende de sus requisitos.

Por ejemplo, si no te importan las propiedades del buscador (por ejemplo, fuerza del buscador, visión, etc.), entonces yo diría pajar.encontrar(aguja) sería la solución más limpia.

Pero, si te importan las propiedades del buscador (o cualquier otra propiedad para el caso), inyectaría una interfaz ISearcher en el constructor haystack o en la función para facilitar eso. Esto soporta tanto el diseño orientado a objetos (un pajar tiene agujas) e inversión de la inyección de control / dependencia (facilita la prueba unitaria de la función "find").

Puedo pensar en situaciones donde cualquiera de los dos primeros sabores tiene sentido:

1. Si la aguja necesita preprocesamiento, como en el algoritmo Knuth-Morris-Pratt, needle.findIn(haystack) (o pattern.findIn(text))tiene sentido, porque el objeto needle contiene las tablas intermedias creadas para que el algoritmo funcione eficazmente

2. Si el pajar necesita pre-procesamiento, como por ejemplo en un trie, el haystack.find(needle) (o words.hasAWordWithPrefix(prefix)) funciona mejor.

En ambos casos, uno de aguja o haystack está al tanto de la búsqueda. Además, ambos son conscientes el uno del otro. Si desea que la aguja y el pajar no sean conscientes el uno del otro o de la búsqueda, searcher.find(needle, haystack) sería apropiado.

Fácil: ¡Quema el pajar! Después, solo quedará la aguja. Además, puedes probar con imanes.

Una pregunta más difícil: ¿Cómo encontrar una aguja en particular en un charco de agujas?

Respuesta: enhebrar cada uno y unir el otro extremo de cada hilo de hilo a un índice ordenado (es decir, punteros)

La respuesta a esta pregunta en realidad debería depender del dominio para el que se implementa la solución.
Si le sucede a simular una búsqueda física en un pajar físico, es posible que tenga las clases

• Espacio
• Paja
• Aguja
• Buscador

Espacio
sabe qué objetos se encuentran en qué coordenadas
implementa las leyes de la naturaleza (convierte energía, detecta colisiones, etc.)

Aguja, Paja
se encuentran en el Espacio
reaccionar a las fuerzas

Buscador
interactúa con el espacio:
     mueve la mano, aplica campo magnético, quema heno, aplica rayos X, busca aguja...

Por lo tanto seeker.find(needle, space) o seeker.find(needle, space, strategy)

El pajar simplemente está en el espacio donde usted está buscando la aguja. Cuando abstrae el espacio como una especie de máquina virtual (piense en: la matriz), podría obtener lo anterior con haystack en lugar de espacio (solución 3 / 3b):

seeker.find(needle, haystack) o seeker.find(needle, haystack, strategy)

Pero la matriz era el Dominio, que solo debería ser reemplazado por haystack, si su aguja no podía estar en ningún otro lugar.

Y otra vez, era solo una anología. Curiosamente esto abre la mente a direcciones totalmente nuevas:
1. ¿Por qué perdiste la aguja en primer lugar? ¿Puedes cambiar el proceso para no perderlo?
2. ¿Tienes que encontrar la aguja perdida o puedes simplemente conseguir otra y olvidarse de la primera? (Entonces sería bueno, si la aguja se disolviera después de un tiempo)
3. Si pierde sus agujas regularmente y necesita encontrarlas de nuevo, es posible que desee

• Hacer agujas que son capaces de encontrarse a sí mismos, por ejemplo, que regularmente se preguntan: ¿Estoy perdido? Si la respuesta es sí, envían su posición calculada por GPS a alguien o comienzan a sonar o lo que sea:
  needle.find(space) o needle.find(haystack) (solución 1)

• Instalar un pajar con una cámara en cada pajita, después puede preguntarle a la mente de la colmena de pajar si vio la aguja últimamente:
  pajar.buscar (aguja) (solución 2)

• Coloque etiquetas RFID en sus agujas, para que pueda triangularlas fácilmente

Todo eso solo para decir que en su implementación usted hizo la aguja y el pajar y la mayoría de las veces la matriz en algún tipo de nivel.

Así que decide según tu dominio:

• ¿Es el propósito del pajar contener agujas? A continuación, vaya a la solución 2.
• ¿Es natural que la aguja se pierda en cualquier lugar? A continuación, vaya a la solución 1.
• ¿La aguja se pierde en el pajar por accidente? A continuación, vaya a la solución 3. (o considere otra estrategia de recuperación)

Pajar.buscar (aguja), pero debe haber un campo de búsqueda.

Sé que la inyección de dependencia está de moda, así que no me sorprende que el pajar de @Mike Stone.find (aguja, buscador) ha sido aceptado. Pero no estoy de acuerdo: la elección de qué buscador se utiliza me parece una decisión para el pajar.

Considere dos iSearch: MagneticSearcher itera sobre el volumen, moviendo y pisando el imán de una manera consistente con la fuerza del imán. Búsqueda rápida divide la pila en dos hasta que la aguja sea evidente en uno de los subpiles. La elección adecuada del buscador puede depender de cuán grande es el pajar (en relación con el campo magnético, por ejemplo), cómo la aguja entró en el pajar (es decir, ¿es la posición de la aguja verdaderamente aleatoria o sesgada?), sucesivamente.

Si tiene pajar.find (needle, searcher), estás diciendo "la elección de cuál es la mejor estrategia de búsqueda se hace mejor fuera del contexto del pajar."No creo que eso sea probablemente sea correcto. Creo que es más probable que " haystacks saben la mejor manera de buscar a sí mismos."Agrega un setter y aún puedes inyectar manualmente el buscador si necesitas anular o para probar.

Personalmente, me gusta el segundo método. Mi razonamiento se debe a que las principales API con las que he trabajado utilizan este enfoque, y me parece que tiene más sentido.

Si tienes una lista de cosas (pajar) buscarías (find()) la aguja.

@Peter Meyer

Usted consigue la idea. Creo que ir tan libremente acoplado como sea posible es una buena cosa, pero tal vez me estaba dejando llevar un poco! :)

Errr... sí... Creo que el IStuffSmallEnoughToBeLostInAHaystack es una bandera roja: -)

También tienes una cuarta alternativa que creo que sería mejor que la alternativa 3:

haystack.find(needle, searcher)

Veo tu punto, pero ¿qué pasa si searcher implementa una interfaz de búsqueda que permite buscar otros tipos de objetos que no sean pajares, y encontrar otras cosas que no sean agujas en ellos?

La interfaz también podría implementarse con diferentes algoritmos, por ejemplo:

binary_searcher.find(needle, haystack)
vision_searcher.find(pitchfork, haystack)
brute_force_searcher.find(money, wallet)

Pero, como otros ya han señalado, también creo que esto solo es útil si en realidad, tiene múltiples algoritmos de búsqueda o múltiples clases que se pueden buscar o encontrar. Si no, estoy de acuerdo en que haystack.find(needle) es mejor debido a su simplicidad, por lo que estoy dispuesto a sacrificar algo de "corrección" por ello.

class Haystack {//whatever
 };
class Needle {//whatever
 }:
class Searcher {
   virtual void find() = 0;
};

class HaystackSearcher::public Searcher {
public:
   HaystackSearcher(Haystack, object)
   virtual void find();
};

Haystack H;
Needle N;
HaystackSearcher HS(H, N);
HS.find();

Una mezcla de 2 y 3, realmente.

Algunos pajares no tienen una estrategia de búsqueda especializada; un ejemplo de esto es un array. La única manera de encontrar algo es comenzar por el principio y probar cada elemento hasta que encuentre el que desea.

Para este tipo de cosas, una función libre es probablemente la mejor (como C++).

Algunos pajares pueden tener una estrategia de búsqueda especializada impuesta sobre ellos. Se puede ordenar una matriz, lo que le permite usar la búsqueda binaria, por ejemplo. A libre la función (o par de funciones libres, por ejemplo, sort y binary_search) es probablemente la mejor opción.

Algunos haystacks tienen una estrategia de búsqueda integrada como parte de su implementación; los contenedores asociativos (conjuntos y mapas hash u ordenados) lo tienen, por ejemplo. En este caso, la búsqueda es probablemente un método de búsqueda esencial, por lo que probablemente debería ser un método, es decir, haystack.buscar (aguja).

El pajar puede contener materias un tipo de cosas es la aguja finder es algo que se encarga de buscar cosas finder puede aceptar un montón de cosas como la fuente de dónde encontrar la cosa finder también puede aceptar una descripción de cosas que necesita encontrar

Así que, preferiblemente, para una solución flexible que haría algo como: Interfaz IStuff

Haystack = IList Aguja: IStuff

Buscador .Buscar (IStuff stuffToLookFor, IList stuffsToLookIn)

En este caso, su solución no se atará solo a la aguja y al pajar, sino que se puede usar para cualquier tipo que implemente la interfaz

Así que si quieres encontrar un Pez en el Océano, puedes.

Var results = Finder.Buscar (pescado, océano)

Si tiene una referencia a un objeto de aguja, ¿por qué lo busca? :) El dominio del problema y los casos de uso le dicen que no necesita la posición exacta de la aguja en un pajar (como lo que podría obtener de la lista.indexOf (elemento)), solo necesita una aguja. Y aún no lo tienes. Así que mi respuesta es algo como esto

Needle needle = (Needle)haystack.searchByName("needle");

O

Needle needle = (Needle)haystack.searchWithFilter(new Filter(){
    public boolean isWhatYouNeed(Object obj)
    {
        return obj instanceof Needle;
    }
});

O

Needle needle = (Needle)haystack.searchByPattern(Size.SMALL, 
                                                 Sharpness.SHARP, 
                                                 Material.METAL);

Estoy de acuerdo en que hay más soluciones posibles que se basan en diferentes estrategias de búsqueda, por lo que introducen Buscador. Se han hecho bastantes comentarios al respecto, por lo que no voy a prestarle atención aquí. Mi punto es que las soluciones anteriores se olvidan de los casos de uso: ¿cuál es el punto para buscar algo si ya tiene referencia a él? En el caso de uso más natural, aún no tiene una aguja, por lo que no usa una aguja variable.

Brad Wilson señala que los objetos deben tener una sola responsabilidad. En el caso extremo, un objeto tiene una responsabilidad y ningún Estado. Entonces puede convertirse... función.

needle = findNeedleIn(haystack);

O podrías escribirlo así:

SynchronizedHaystackSearcherProxyFactory proxyFactory =
    SynchronizedHaystackSearcherProxyFactory.getInstance();
StrategyBasedHaystackSearcher searcher =
    new BasicStrategyBasedHaystackSearcher(
        NeedleSeekingStrategies.getMethodicalInstance());
SynchronizedHaystackSearcherProxy proxy =
    proxyFactory.createSynchronizedHaystackSearcherProxy(searcher);
SearchableHaystackAdapter searchableHaystack =
    new SearchableHaystackAdapter(haystack);
FindableSearchResultObject foundObject = null;
while (!HaystackSearcherUtil.isNeedleObject(foundObject)) {
    try {
        foundObject = proxy.find(searchableHaystack);
    } catch (GruesomeInjuryException exc) {
        returnPitchforkToShed();  // sigh, i hate it when this happens
        HaystackSearcherUtil.cleanUp(hay); // XXX fixme not really thread-safe,
                                           // but we can't just leave this mess
        HaystackSearcherUtil.cleanup(exc.getGruesomeMess()); // bug 510000884
        throw exc; // caller will catch this and get us to a hospital,
                   // if it's not already too late
    }
}
return (Needle) BarnyardObjectProtocolUtil.createSynchronizedFindableSearchResultObjectProxyAdapterUnwrapperForToolInterfaceName(SimpleToolInterfaces.NEEDLE_INTERFACE_NAME).adapt(foundObject.getAdaptable());

El pajar no debe saber sobre la aguja, y la aguja no debe saber sobre el pajar. El buscador necesita saber acerca de ambos, pero si el pajar debe saber o no cómo buscar en sí mismo es el verdadero punto en disputa.

Así que me gustaría ir con una mezcla de 2 y 3; el pajar debe ser capaz de decirle a alguien más cómo buscarlo, y el buscador debe ser capaz de utilizar esa información para buscar en el pajar.

haystack.magnet().filter(needle);

¿El código está tratando de encontrar una aguja específica o cualquier aguja? Suena como una pregunta estúpida, pero cambia el problema.

Buscando una aguja específica el código en la pregunta tiene sentido. Buscando cualquier aguja sería más como

needle = haystack.findNeedle()

O

needle = searcher.findNeedle(haystack)

De cualquier manera, prefiero tener un buscador de esa clase. Un pajar no sabe buscar. Desde la perspectiva de CS, es solo un almacén de datos con MUCHA basura que no quieres.

Definitivamente el tercero, EN mi Humilde opinión.

La cuestión de una aguja en un pajar es un ejemplo de un intento de encontrar un objeto en una gran colección de otros, lo que indica que necesitará un algoritmo de búsqueda complejo (posiblemente involucrando imanes o (más probablemente) procesos hijos) y no tiene mucho sentido que se espere que un pajar realice una gestión de subprocesos o implemente búsquedas complejas.

Un objeto de búsqueda, sin embargo, está dedicado a la búsqueda y se puede esperar saber cómo para administrar subprocesos secundarios para una búsqueda binaria rápida, o usar propiedades del elemento buscado para reducir el área (es decir, un imán para encontrar elementos ferrosos).

Otra forma posible puede ser crear dos interfaces para objeto de búsqueda, por ejemplo, haystack y objeto ToBeSearched, por ejemplo, needle. Por lo tanto, se puede hacer de esta manera

public Interface IToBeSearched
{}

public Interface ISearchable
{

    public void Find(IToBeSearched a);

}

Class Needle Implements IToBeSearched
{}

Class Haystack Implements ISearchable
{

    public void Find(IToBeSearched needle)

   {

   //Here goes the original coding of find function

   }

}

haystack.iterator.findFirst(/* pass here a predicate returning
                               true if its argument is a needle that we want */)

iterator puede ser interfaz a cualquier colección inmutable, con colecciones que tienen un método común findFirst(fun: T => Boolean) haciendo el trabajo. Mientras el pajar sea inmutable, no es necesario ocultar ningún dato útil del "exterior". Y, por supuesto, no es bueno vincular la implementación de una colección personalizada no trivial y algunas otras cosas que sí tienen haystack. Divide y vencerás, ¿vale?

En la mayoría de los casos prefiero poder realizar operaciones auxiliares simples como esta en el objeto principal, pero dependiendo del lenguaje, el objeto en cuestión puede no tener un método suficiente o sensible disponible.

Incluso en lenguajes como JavaScript ) que le permiten aumentar / extender objetos incorporados, me parece que puede ser conveniente y problemático (por ejemplo, si una versión futura del lenguaje introduce un método más eficiente que se anula por un método personalizado una).

Este artículo hace un buen trabajo al describir tales escenarios.