Как Вы находите иголку в стоге сена?

Другой возможный путь может состоять в том, чтобы создать два интерфейса для Доступного для поиска объекта, например, стога сена и объекта ToBeSearched, например, иглы. Так, это может быть сделано таким образом

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

   }

}

Определенно третье, по моему скромному мнению.

вопросом иголки в стоге сена является пример попытки найти один объект в большом количестве других, которое указывает, что этому будет нужен сложный алгоритм поиска (возможно включающий магниты или (более вероятные) дочерние процессы), и не имеет большого количества смысла для стога сена, как ожидать, сделает управление потоком или реализует сложные поиски.

объект поиска А, однако, выделен поиску и, как могут ожидать, будет знать, как управлять дочерними потоками для быстрого двоичного поиска или свойствами использования разыскиваемого элемент для сужения области (т.е.: магнит для нахождения железных объектов).

Код пытается найти определенную иглу или просто какую-либо иглу? Это походит на глупый вопрос, но это изменяет проблему.

Поиск определенной иглы код в вопросе имеет смысл. Поиск любой иглы, на которую это было бы больше похоже

needle = haystack.findNeedle()

или

needle = searcher.findNeedle(haystack)

Так или иначе, я предпочитаю иметь искателя тот класс. Стог сена не знает, как искать. С точки зрения CS это - просто хранилище данных с большим количеством дерьма, которое Вы не хотите.

haystack.magnet().filter(needle);

Стог сена не должен знать об игле, и игла не должна знать о стоге сена. Искатель должен знать об обоих, но должен ли стог сена знать, как искать себя, основное назначение в конкуренции.

, Таким образом, я пошел бы с соединением 2 и 3; стог сена должен быть в состоянии сказать кому-то еще, как искать его, и искатель должен быть в состоянии использовать ту информацию для поиска стога сена.

Если у Вас есть ссылка на объект иглы, почему Вы ищете его?:) Проблемная область и примеры использования говорят Вам, что Вам не нужно точное положение иголки в стоге сена (как то, что Вы могли получить от list.indexOf (элемент)), Вам просто нужна игла. И у Вас еще нет его. Таким образом, мой ответ - что-то вроде этого

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

или

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

, или

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

я соглашаюсь, что существуют более возможные решения, которые основаны на различных поисковых стратегиях, таким образом, они представляют искателя. Было достаточно комментариев к этому, таким образом, я не плачу attentiont ему здесь. Моя точка является решениями выше, забывают о примерах использования - какой смысл для поиска чего-то, если у Вас уже есть ссылка на нее? В самом естественном примере использования у Вас еще нет иглы, таким образом, Вы не используете переменную иглу.

стог сена может содержать материалы, один тип материала является средством поиска иглы, что-то, что ответственно за поиск средства поиска материала, может принять груду материалов как источник того, где найти вещь, средство поиска может также принять описание материала вещи, которую это должно найти

так, предпочтительно, для гибкого решения, как которое Вы сделали бы что-то: интерфейс IStuff

Стог сена = IList< IStuff> Игла: средство поиска IStuff

.Find (IStuff stuffToLookFor, IList< IStuff> stuffsToLookIn)

В этом случае, Ваше решение не будет связано только с иглой и стогом сена, но это применимо для любого типа, которые реализуют интерфейс

поэтому, если Вы хотите найти Рыбу в Океане, Вы можете.

var заканчивается = Средство поиска. Найдите (рыба, океан)

Соединение 2 и 3, действительно.

Некоторые стога сена не имеют специализированной поисковой стратегии; примером этого является массив. Единственный способ найти что-то состоит в том, чтобы запуститься вначале и протестировать каждый объект, пока Вы не находите тот, который Вы хотите.

Для такого рода вещи, бесплатная функция является, вероятно, лучшей (как C++).

Некоторые стога сена могут иметь специализированную поисковую стратегию, наложенную на них. Массив может быть отсортирован, позволив Вам использовать двоичный поиск, например. Бесплатная функция (или пара бесплатных функций, например, вид и binary_search) является, вероятно, наилучшим вариантом.

Некоторые стога сена имеют интегрированную поисковую стратегию как часть их реализации; ассоциативные контейнеры (хешированные или упорядоченные множества и карты) все делают, например. В этом случае открытие является, вероятно, существенным методом поиска, таким образом, это должен, вероятно, быть метод, т.е. haystack.find (игла).

у Вас также есть четвертая альтернатива, что я думаю, было бы лучше, чем альтернативные 3:

haystack.find(needle, searcher)

я вижу Вашу точку, но что, если searcher реализации ищущий интерфейс, который допускает поиск других типов объектов, чем стога сена и нахождения других вещей, чем иглы в них?

интерфейс мог также быть реализован с различными алгоритмами, например:

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

, Но, как другие уже указали, я также думаю, что это только полезно, если у Вас на самом деле есть несколько алгоритмов поиска или несколько доступных для поиска или findable классов. В противном случае я соглашаюсь haystack.find(needle), лучше из-за его простоты, таким образом, я готов пожертвовать некоторой "правильностью" за него.

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();

@Peter Meyer

Вы получаете идею. Я думаю, идя максимально слабо связанный, хорошая вещь, но возможно я немного увлекался!:)

Errr... да... Я думаю IStuffSmallEnoughToBeLostInAHaystack, отчасти красный флаг:-)

Это полностью зависит от того, что варьируется и что остается таким же.

, Например, я работаю над (не-ООП) платформа , где алгоритм находки отличается зависящий и на типе иглы и на стоге сена. Кроме того, что это потребовало бы двойной отправки в объектно-ориентированной среде, это также означает, что это не значимо, чтобы записать или needle.find(haystack) или записать haystack.find(needle).

, С другой стороны, Ваше приложение могло счастливо делегировать открытие или к обоих классов или придерживаться одного алгоритма в целом, в этом случае, решение произвольно. В этом случае я предпочел бы haystack.find(needle) путь, потому что кажется более логичным применить открытие к стогу сена.

Легкий: Запишите стог сена! Позже, только игла останется. Кроме того, Вы могли попробовать магниты.

А более трудный вопрос: Как Вы находите одну конкретную иглу в пуле игл?

Ответ: распараллельте каждого и присоедините другой конец каждой скрутки потока к отсортированному индексу (т.е. указатели)

Я могу думать о ситуациях, где любой из первых двух ароматов имеет смысл:

1. , Если игла нуждается в предварительной обработке, как в Knuth-Morris-Pratt алгоритме, needle.findIn(haystack) (или pattern.findIn(text)) имеет смысл, потому что объект иглы содержит промежуточные таблицы, составленные для алгоритма для работы эффективно

2. , Если стогу сена нужна предварительная обработка, как говорят в trie, haystack.find(needle) (или words.hasAWordWithPrefix(prefix)) работы лучше.

В обоих вышеупомянутые случаи, одна из иглы или стога сена знает о поиске. Кроме того, они оба знают друг о друге. Если бы Вы хотите иглу, и стог сена для не знания друг о друге или поиска, searcher.find(needle, haystack) был бы соответствующим.

Чтобы заключить великим авторам в кавычки SICP,

, Программы должны быть записаны для людей для чтения, и только случайно для машин для выполнения

я предпочитаю иметь оба метода 1 и 2 под рукой. Используя рубин как пример, это идет .include?, который используется как это

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

Иногда, хотя, просто по причинам удобочитаемости, я хочу зеркально отразить его вокруг. Ruby не идет in? метод, но это - острота, таким образом, я часто делаю это:

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

, Если "более важно" подчеркнуть стог сена или операцию поиска, я предпочитаю писать include?. Часто, хотя, ни один стог сена или поиск действительно, о чем Вы заботитесь о, просто что объект присутствует - в этом случае я нахожу in?, лучше передает значение программы.

haystack.find (игла), но должно быть поле искателя.

я знаю, что внедрение зависимости является всем гневом, таким образом, меня не удивляет, что haystack.find @Mike Stone (игла, искатель) был принят. Но я не соглашаюсь: выбор того, какой искатель используется, кажется мне решением для стога сена.

Рассматривают два ISearchers: MagneticSearcher выполняет итерации по объему, перемещаясь и ступая магнит в способ, согласовывающийся с силой магнита. QuickSortSearcher делит стек на два, пока игла не очевидна в одной из подгруд. Надлежащий выбор искателя может зависеть от того, насколько большой стог сена (относительно магнитного поля, например), как игла вошла в стог сена (т.е. положение иглы действительно случайно, или это это сместило?), и т.д.

, Если у Вас есть haystack.find (игла, искатель), Вы говорите "выбор, которого лучшая поисковая стратегия, лучше всего сделан вне контекста стога сена". Я не думаю, что это, вероятно, будет корректно. Я думаю, что более вероятно, что "стога сена знают, как лучше всего искать себя". Добавьте метод set, и можно все еще вручную ввести искателя, если необходимо переопределить или для тестирования.

Лично, мне нравится второй метод. Мое обоснование состоит в том, потому что главные API, я работал с использованием этот подход, и я нахожу, что это имеет большую часть смысла.

, Если бы у Вас есть список вещей (стог сена), Вы искали бы (найдите ()), игла.

При реализации поиска иглы стога сена объектно-ориентированным способом, у Вас по существу есть три альтернативы:

1. needle.find (стог сена)

2. haystack.find (игла)

3. searcher.find (игла, стог сена)

, Который Вы предпочитаете, и почему?

Исправляют меня, если я неправ, но во всех трех примерах Вы уже имеете ссылка на иглу, которую Вы ищете, так не это отчасти как поиск Ваших стекол, когда они находятся на Вашем носу?: Игра слов p

в стороне, я думаю, что она действительно зависит от того, что Вы рассматриваете обязанностью стога сена быть в данном домене. Мы просто заботимся об этом в смысле того, чтобы быть вещью, которая содержит иглы (набор, по существу)? Тогда haystack.find (needlePredicate) прекрасен. Иначе, farmBoy.find (предикат, стог сена) могло бы быть более соответствующим.

Это зависит от Ваших требований.

, Например, если Вы не заботитесь о свойствах искателя (например, сила искателя, видение, и т.д.), тогда я сказал бы, что haystack.find (игла) будет самым чистым решением.

, Но, если бы Вы действительно заботитесь о свойствах искателя (или каких-либо других свойствах в этом отношении), я ввел бы интерфейс ISearcher или в конструктора стога сена или в функцию для упрощения этого. Это поддерживает оба объектно-ориентированного проектирования (стог сена имеет иглы), и инверсия управления / внедрение зависимости (облегчает модульному тесту функция "находки").

Я с Brad на этом. Чем больше я работаю над очень сложными системами, тем больше я вижу потребность действительно разъединить объекты. Он прав. Очевидно, что игла ничего не должна знать о стоге сена, таким образом, 1 определенно отсутствует. Но, стог сена ничего не должен знать об игле.

, Если я моделировал стог сена, я мог бы реализовать его как набор - но как набор шаг скрутки или солома - не набор игл! Однако я учел бы, что материал действительно теряется в стоге сена, но я ничего не знаю о какой точно тот материал. Я думаю, что лучше не заставить стог сена искать объекты сам по себе (как умный стог сена так или иначе). Правильный подход ко мне должен иметь стог сена, существующий набор вещей, которые находятся в нем, но не являются соломой или шагом скрутки или независимо от того, что дает стогу сена его сущность.

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)
}

существует на самом деле больше, я собирался ввести и абстрагировать в интерфейсы, и затем я понял, как сумасшедший я добирался. Чувствовавший себя подобно я был в классе CS в колледже...: P

Вы получаете идею. Я думаю, идя максимально слабо связанный, хорошая вещь, но возможно я немного увлекался!:)

Я сказал бы, что опция 1 полностью отсутствует. Код должен считать способом, что говорит Вам, что он делает. Опция 1 заставляет меня думать, что эта игла собирается пойти, находят меня стогом сена.

Опция 2 выглядит хорошей, если стог сена предназначен для содержания игл. ListCollections всегда собираются содержать ListItems, таким образом делание collection.find (объект) является естественным и выразительным.

я думаю, что введение объекта помощника является approproiate когда:

1. Вы не управляете реализацией рассматриваемых объектов
   IE: search.find (ObsecureOSObject, файл)
2. нет регулярных или разумных отношений между объектами
   IE: nameMatcher.find (здания, trees.name)

Существует другая альтернатива, которая является подходом, используемым STL C++:

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

я думаю, что это - яркий пример C++, кричащего "в Вашей поверхности!" к ООП. Идея состоит в том, что ООП не является серебряной пулей никакого вида; иногда вещи лучше всего описаны с точки зрения действий, иногда с точки зрения объектов, иногда ни один и иногда оба.

Bjarne Stroustrup сказал в TC ++ МН, что при разработке системы необходимо стремиться отразить действительность при ограничениях эффективного и эффективного кода. Для меня это означает, что Вы ни за чем никогда не должны следовать вслепую. Думайте о вещах под рукой (стог сена, игла) и контекст, в котором мы находимся (поиск, это - то, что выражение о).

, Если акцент о поиске, то с помощью алгоритма (действие), которое подчеркивает поиск (т.е. должен гибко соответствовать стогам сена, океанам, пустыням, связанным спискам). Если акцент о стоге сена, инкапсулируйте метод находки в объекте стога сена и так далее.

Однако иногда Вы вызываете сомнение и имеете трудные времена, делая выбор. В этом случае будьте объектно-ориентированы. Если Вы передумали позже, я думаю, что легче извлечь действие из объекта затем для разделения действия к объектам и классам.

Следуют этим инструкциям, и Ваш код будет более ясным и, ну, в общем, более красивым.

Из этих трех я предпочитаю опцию № 3.

, Единственный Принцип Ответственности заставляет меня не хотеть помещать ищущие возможности на свой DTOs или модели. Их ответственность состоит в том, чтобы быть данными, для не нахождения, и при этом иглы не должны должны быть знать о стогах сена, ни стога сена знают об иглах.

Если это имеет значение, я думаю, что большинству практиков OO требуется Долгое время для понимания, почему № 3 является лучшим выбором. Я сделал OO в течение десятилетия, вероятно, прежде чем я действительно grokked это.

@wilhelmtell, C++ является одним из очень немногих языков с шаблонной специализацией, которые заставляют такую систему на самом деле работать. Для большинства языков метод "находки" общего назначения был бы УЖАСНОЙ идеей.

Ответ на этот вопрос должен на самом деле зависеть от домена, для которого реализовано решение.
, Если Вы, оказывается, моделируете физический поиск в физическом стоге сена, у Вас могли бы быть классы

• Пространство
• Солома
• Игла
• Ищущий

, Пространство
знает, какие объекты расположены, в которых координатах
реализации законы природы (преобразовывает энергию, обнаруживает коллизии, и т.д.)

Игла , , Солома
расположена в Пространстве
, реагируют на силы

, Ищущий
взаимодействует с пространством:
        двигает рукой, применяет магнитное поле, шаг скрутки записей, применяет рентгеновские лучи, ищет иглу ...

Thus    seeker.find(needle, space)     or    seeker.find(needle, space, strategy)

стог сена просто, оказывается, находится в пространстве, где Вы ищете иглу. При абстракции далеко пространства как своего рода виртуальная машина (думайте: матрица), Вы могли получить вышеупомянутое со стогом сена вместо пространства (решение 3/3b) :

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

, Но матрица был Домен, который должен только быть заменен стогом сена, если Ваша игла не могла бы быть больше нигде.

И с другой стороны, это была просто энология. Интересно это открывает ум для полностью новых направлений:
1. Почему Вы освобождали иглу во-первых? Можно ли изменить процесс, таким образом, Вы не освободили бы его?
2. Необходимо ли найти потерянную иглу, или можно ли просто получить другой и забыть ли о первом? (Тогда это было бы хорошо, если игла, расторгнутая через некоторое время)
3. Если Вы регулярно освобождаете свои иглы, и необходимо найти их снова тогда, Вы могли бы хотеть к [1 141]

• , делают иглы, которые в состоянии оказаться, например, они регулярно спрашивают себя: я потерян? Если ответ да, они отправляют свое вычисленное на GPS положение кому-то или начинают подавать звуковой сигнал или безотносительно:
  needle.find(space) или needle.find(haystack)       (решение 1)

• устанавливают стог сена с камерой на каждой соломе, впоследствии можно попросить, чтобы улей стога сена возражал, если это видело иглу в последнее время:
  haystack.find (игла) (решение 2)

• , который RFID присоединения отмечает к Вашим иглам, таким образом, можно легко триангулировать их

, Что все только, чтобы сказать в реализации создание иглы и стога сена и большую часть времени матрицы на некотором уровне.

Так решают согласно Вашему домену:

• действительно ли это - цель стога сена содержать иглы? Тогда пойдите для решения 2.
• , естественно, что игла теряется просто где-нибудь? Тогда пойдите для решения 1.
• , игла теряется в стоге сена случайно? Тогда пойдите для решения 3. (или рассмотрите другую стратегию восстановления)

Если и Иглой и Стогом сена являются ДАО, то опции 1 и 2 вне рассмотрения.

причина этого состоит в том, что ДАО должны только быть ответственны за содержание свойств объектов реального мира, которые они моделируют, и только имеют методы получателя и методы установщика (или просто прямой доступ свойства). Это делает сериализацию ДАО в файл, или создание методов для дженерика выдерживает сравнение / универсальная копия, легче записать, поскольку код не содержал бы целый набор "если" операторы для пропуска этих вспомогательных методов.

Это просто оставляет опцию 3, которая большинство согласилось бы быть корректным поведением.

Опция 3 имеет несколько преимуществ с самым большим преимуществом, являющимся поблочным тестированием. Это вызвано тем, что и объекты Иглы и Стога сена могут легко копироваться теперь, тогда как, если бы опция 1 или 2 использовалась, внутреннее состояние или Иглы или Стога сена должно было бы быть изменено, прежде чем поиск мог быть выполнен.

, Во-вторых, с искателем теперь в отдельном классе, весь поисковый код может быть сохранен в одном месте, включая общий поисковый код. Принимая во внимание, что, если бы поисковый код был помещен в ДАО, общий поисковый код был бы или сохранен в сложной иерархии классов, или с классом Помощника Искателя так или иначе.

Брэд Уилсон указывает, что объекты должны нести единственную ответственность. В крайнем случае у объекта одна ответственность и нет состояния. Тогда это может стать ... функцией.

needle = findNeedleIn(haystack);

Или вы могли бы написать это так:

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());