건초더미에서 바늘을 어떻게 찾나요?
https://stackoverflow.com/questions/23755
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
객체 지향 방식으로 건초 더미에 대한 바늘 검색을 구현할 때 기본적으로 세 가지 대안이 있습니다.
1. needle.find(haystack)
2. haystack.find(needle)
3. searcher.find(needle, haystack)어느 쪽을 선호하시나요? 그 이유는 무엇인가요?
어떤 사람들은 세 번째 개체를 도입하지 않기 때문에 두 번째 대안을 선호한다는 것을 알고 있습니다.그러나 적어도 목표가 "실제 세계"를 모델링하는 것이라면 세 번째 접근 방식이 개념적으로 "올바르다"는 느낌을 지울 수 없습니다.
이 예의 검색기와 같은 도우미 개체를 도입하는 것이 어떤 경우에 정당하다고 생각하며, 언제 피해야 합니까?
해결책
일반적으로 작업은 작업을 수행하는 대상에 적용되어야 합니다.이 경우에는 건초 더미이므로 옵션 2가 가장 적절하다고 생각합니다.
또한 대안 3보다 더 나을 것이라고 생각되는 네 번째 대안도 있습니다.
haystack.find(needle, searcher)
이 경우 작업의 일부로 검색하려는 방식을 제공할 수 있으므로 작업 중인 개체에 대한 작업을 유지할 수 있습니다.
다른 팁
세 가지 중에서 나는 옵션 #3을 선호합니다.
그만큼 단일 책임 원칙 DTO나 모델에 검색 기능을 추가하고 싶지 않습니다.그들의 책임은 데이터가 되는 것이지 자신을 찾는 것이 아닙니다. 바늘이 건초 더미에 대해 알 필요도 없고 건초 더미가 바늘에 대해 알 필요도 없습니다.
그만한 가치가 있기 때문에 대부분의 OO 실무자가 왜 #3이 최선의 선택인지 이해하는 데 오랜 시간이 걸린다고 생각합니다.나는 OO를 10년 동안 했고, 아마 그게 정말 괴로웠을 겁니다.
@wilhelmtell, C++는 그러한 시스템을 실제로 작동하게 만드는 템플릿 전문화 기능을 갖춘 극소수의 언어 중 하나입니다.대부분의 언어에서 일반적인 목적의 "찾기" 방법은 끔찍한 아이디어입니다.
C++의 STL에서 사용하는 접근 방식인 또 다른 대안이 있습니다.
find(haystack.begin(), haystack.end(), needle)
나는 그것이 "당신의 얼굴에!"라고 외치는 C ++의 훌륭한 예라고 생각합니다. OOP에.OOP는 어떤 종류의 만능 무기도 아니라는 생각입니다.때로는 사물이 행동의 관점에서 가장 잘 설명될 때도 있고, 때로는 사물의 관점에서, 때로는 둘 다 또는 둘 다의 관점에서 설명되는 경우도 있습니다.
Bjarne Stroustrup은 TC++PL에서 시스템을 설계할 때 효과적이고 효율적인 코드의 제약 하에 현실을 반영하도록 노력해야 한다고 말했습니다.나에게 이것은 맹목적으로 어떤 것도 따라해서는 안 된다는 것을 의미합니다.손에 있는 것(건초 더미, 바늘)과 우리가 처한 상황(검색, 이것이 바로 표현의 내용입니다)에 대해 생각해 보세요.
검색이 강조되는 경우 검색을 강조하는 알고리즘(작업)을 사용합니다(예:건초 더미, 바다, 사막, 연결된 목록에 유연하게 맞습니다.haystack에 중점을 두는 경우 haystack 객체 내부에 find 메소드를 캡슐화합니다.
하지만 때로는 의심이 들고 선택을 하는 데 어려움을 겪을 때도 있습니다.이 경우에는 객체 지향적이어야 합니다.나중에 생각이 바뀌면 객체에서 액션을 추출하는 것보다 객체와 클래스로 액션을 분할하는 것이 더 쉽다고 생각합니다.
이 지침을 따르면 코드가 더 명확해지고 더 아름다워질 것입니다.
옵션 1이 완전히 종료되었다고 말하고 싶습니다.코드는 코드가 수행하는 작업을 알려주는 방식으로 읽어야 합니다.옵션 1을 사용하면 이 바늘이 나를 건초 더미로 찾아갈 것이라는 생각이 들게 됩니다.
건초 더미에 바늘이 들어 있으면 옵션 2가 좋아 보입니다.ListCollections에는 항상 ListItem이 포함되므로 collection.find(item)을 수행하는 것은 자연스럽고 표현력이 뛰어납니다.
다음과 같은 경우 도우미 개체를 도입하는 것이 적절하다고 생각합니다.
- 문제의 객체 구현을 제어하지 않습니다.
즉:search.find(ObsecureOSObject, 파일) - 개체 사이에 규칙적이거나 합리적인 관계가 없습니다.
즉:nameMatcher.find(집,나무.이름)
나는 이것에 대해 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 수업을 듣는 것 같은 느낌..:피
당신은 아이디어를 얻습니다.가능한 한 느슨하게 결합하는 것이 좋은 일이라고 생각하지만 어쩌면 조금 흥분하고 있었을 수도 있습니다!:)
Needle과 Haystack이 모두 DAO라면 옵션 1과 2는 불가능합니다.
그 이유는 DAO가 모델링하는 실제 객체의 속성만 보유해야 하며 getter 및 setter 메서드(또는 직접적인 속성 액세스)만 가져야 하기 때문입니다.이렇게 하면 DAO를 파일로 직렬화하거나 일반 비교/일반 복사본을 위한 메서드를 작성하기가 더 쉬워집니다. 코드에 이러한 도우미 메서드를 건너뛰기 위한 "if" 문 전체가 포함되어 있지 않기 때문입니다.
이는 옵션 3만 남기고 대부분의 사람들이 올바른 행동이라고 동의할 것입니다.
옵션 3에는 몇 가지 장점이 있으며 가장 큰 장점은 단위 테스트입니다.이는 이제 Needle 및 Haystack 객체 모두 쉽게 모형화할 수 있는 반면, 옵션 1 또는 2를 사용하는 경우 검색을 수행하기 전에 Needle 또는 Haystack의 내부 상태를 수정해야 하기 때문입니다.
둘째, 이제 검색자가 별도의 클래스에 있으므로 일반 검색 코드를 포함하여 모든 검색 코드를 한 곳에 보관할 수 있습니다.반면 검색 코드가 DAO에 추가되면 일반 검색 코드는 복잡한 클래스 계층 구조에 저장되거나 어쨌든 Searcher Helper 클래스와 함께 저장됩니다.
이것은 전적으로 변화하는 것과 동일하게 유지되는 것에 달려 있습니다.
예를 들어, 저는 (OOP가 아닌) 작업을 하고 있습니다. 뼈대 여기서 찾기 알고리즘은 바늘 유형과 건초 더미에 따라 다릅니다.객체 지향 환경에서 이중 디스패치가 필요하다는 사실 외에도 다음 중 하나를 작성하는 것이 의미가 없음을 의미합니다. needle.find(haystack) 아니면 글을 쓰려고 haystack.find(needle).
반면에 애플리케이션은 두 클래스 중 하나에 결과를 위임하거나 결정이 임의적인 경우 하나의 알고리즘을 모두 사용할 수 있습니다.그런 경우에는 다음을 선호합니다. haystack.find(needle) 그 결과를 건초 더미에 적용하는 것이 더 논리적인 것처럼 보이기 때문입니다.
객체 지향 방식으로 건초 더미의 바늘 검색을 구현할 때는 본질적으로 세 가지 대안이 있습니다.
needle.find(건초더미)
haystack.find(바늘)
searcher.find(바늘, 건초더미)
어느 쪽을 선호하시나요? 그 이유는 무엇인가요?
내가 틀렸다면 정정하십시오. 그러나 세 가지 예 모두에서 이미 가지다 당신이 찾고 있는 바늘에 대한 언급입니다. 그러면 이것은 안경이 코 위에 있을 때 안경을 찾는 것과 비슷하지 않나요?:피
말장난은 제쳐두고, 주어진 도메인 내에서 건초 더미의 책임이 무엇이라고 생각하는지에 달려 있다고 생각합니다.바늘을 포함하는 것(본질적으로 컬렉션)이라는 의미에서 우리는 그것에 관심을 가집니까?그렇다면 haystack.find(needlePredicate)는 괜찮습니다.그렇지 않으면 farmBoy.find(predicate, haystack)가 더 적합할 수 있습니다.
위대한 작가들의 말을 인용하자면 SICP,
프로그램은 사람들이 읽을 수 있도록 작성되어야 하며, 기계가 실행할 수 있도록 부수적으로만 작성되어야 합니다.
나는 방법 1과 2를 모두 사용하는 것을 선호합니다.Ruby를 예로 사용하면 다음과 같습니다. .include? 이것은 이렇게 사용됩니다
haystack.include? needle
=> returns true if the haystack includes the needle
하지만 때로는 순전히 가독성 때문에 뒤집어보고 싶을 때가 있습니다.루비에는 in? 방법이지만 한 줄로 작성되므로 다음과 같이 자주 수행합니다.
needle.in? haystack
=> exactly the same as above
건초 더미나 검색 작업을 강조하는 것이 "더 중요"하다면 다음과 같이 쓰는 것을 선호합니다. include?.하지만 실제로는 건초 더미나 검색 중 어느 것도 관심을 두지 않고 단지 개체가 존재한다는 사실만 고려하는 경우가 많습니다. 이 경우에는 in? 프로그램의 의미를 더 잘 전달합니다.
귀하의 요구 사항에 따라 다릅니다.
예를 들어 검색자의 속성(예:검색기 강도, 비전 등), 그렇다면 haystack.find(needle)이 가장 깨끗한 솔루션이 될 것이라고 말하고 싶습니다.
그러나 검색자의 속성(또는 해당 문제에 대한 다른 속성)에 관심이 있다면 ISearcher 인터페이스를 건초 더미 생성자나 함수에 삽입하여 이를 용이하게 할 것입니다.이는 객체 지향 설계(건초 더미에 바늘이 있음)와 제어 반전/종속성 주입("찾기" 기능에 대한 단위 테스트를 더 쉽게 만듭니다)을 모두 지원합니다.
처음 두 가지 맛 중 하나가 의미가 있는 상황을 생각해 볼 수 있습니다.
Knuth-Morris-Pratt 알고리즘처럼 바늘에 전처리가 필요한 경우,
needle.findIn(haystack)(또는pattern.findIn(text)) 바늘 개체는 알고리즘이 효과적으로 작동하도록 생성된 중간 테이블을 보유하므로 의미가 있습니다.트라이처럼 건초 더미에 전처리가 필요한 경우
haystack.find(needle)(또는words.hasAWordWithPrefix(prefix)) 더 잘 작동합니다.
위의 두 경우 모두 needle 또는 haystack 중 하나가 검색을 인식합니다.게다가 두 사람은 서로를 알고 있다.바늘과 건초더미가 서로를 인식하지 못하게 하거나 검색을 하지 않게 하려면, searcher.find(needle, haystack) 적절할 것입니다.
쉬운:건초더미를 태워라!그러면 바늘만 남게 됩니다.또한 자석을 사용해 볼 수도 있습니다.
더 어려운 질문:바늘 웅덩이에서 특정한 바늘 하나를 어떻게 찾나요?
답변:각각에 실을 꿰고 각 실 가닥의 다른 쪽 끝을 정렬된 색인에 연결합니다(예:포인터)
이 질문에 대한 대답은 실제로 솔루션이 구현되는 도메인에 따라 달라집니다.
실제 건초 더미에서 물리적 검색을 시뮬레이션한다면 다음과 같은 클래스가 있을 수 있습니다.
- 공간
- 빨대
- 바늘
- 시커
공간
어떤 객체가 어떤 좌표에 있는지 알고 있습니다.
자연의 법칙을 구현합니다(에너지 변환, 충돌 감지 등).
바늘, 빨대
우주에 위치해 있어요
힘에 반응하다
시커
공간과 상호작용:
손을 움직이고, 자기장을 가하고, 건초를 태우고, 엑스레이를 조사하고, 바늘을 찾습니다....
따라서seeker.find(needle, space) 또는 seeker.find(needle, space, strategy)
건초더미는 당신이 바늘을 찾고 있는 공간에 우연히 있을 뿐입니다.공간을 일종의 가상 머신으로 추상화하는 경우(다음을 생각해 보세요.매트릭스) 공간 대신 건초 더미를 사용하여 위의 내용을 얻을 수 있습니다. (해결책 3/3b):
seeker.find(needle, haystack) 또는 seeker.find(needle, haystack, strategy)
그러나 매트릭스는 도메인이었고 바늘이 다른 곳에 있을 수 없는 경우에만 건초 더미로 대체되어야 합니다.
그리고 다시 말하지만 그것은 단지 비유일 뿐이었습니다.흥미롭게도 이는 완전히 새로운 방향에 대한 마음을 열어줍니다.
1.애초에 왜 바늘을 풀었나요?프로세스를 변경하여 잃어버리지 않도록 할 수 있습니까?
2.잃어버린 바늘을 찾아야 합니까, 아니면 단순히 다른 바늘을 구하고 첫 번째 바늘을 잊어버릴 수 있습니까?(그럼 시간이 좀 지나면 바늘이 녹으면 좋겠지만)
삼.정기적으로 바늘을 잃어서 다시 찾아야 하는 경우 다음을 수행할 수 있습니다.
자신을 찾을 수 있는 바늘을 만드세요.그들은 정기적으로 스스로에게 묻습니다.내가 길을 잃었나요?대답이 '예'이면 GPS로 계산된 위치를 누군가에게 보내거나 신호음이 울리기 시작합니다.
needle.find(space)또는needle.find(haystack)(해결책 1)각 빨대에 카메라가 달린 건초 더미를 설치한 후 최근에 바늘을 봤는지 건초 더미 하이브 마인드에 물어볼 수 있습니다.
haystack.find(바늘) (해결책 2)RFID 태그를 바늘에 부착하면 쉽게 삼각측량을 할 수 있습니다.
구현에서 말하는 것은 모두 너 바늘과 건초더미를 만들었고 대부분의 경우 일종의 매트릭스를 일종의 수준으로 만들었습니다.
따라서 귀하의 도메인에 따라 결정하십시오.
- 바늘을 담는 것이 건초더미의 목적인가요?그런 다음 해결 방법 2로 이동합니다.
- 바늘이 아무 데나 없어지는 것은 당연한 일인가요?그런 다음 해결 방법 1로 이동합니다.
- 바늘이 건초더미에서 우연히 사라지나요?그런 다음 해결 방법 3으로 이동합니다.(또는 다른 복구 전략을 고려)
haystack.find(needle), 그러나 검색자 필드가 있어야 합니다.
나는 의존성 주입이 대세라는 것을 알고 있으므로 @Mike Stone의 haystack.find(needle, searcher)가 승인된 것은 놀라운 일이 아닙니다.그러나 나는 동의하지 않습니다:검색기가 사용되는 선택은 건초 더미에 대한 결정인 것 같습니다.
두 개의 ISearcher를 고려하십시오.MagneticSearcher는 볼륨을 반복하면서 자석의 강도에 맞춰 자석을 움직이고 밟습니다.QuickSortSearcher는 하위 파일 중 하나에 바늘이 분명해질 때까지 스택을 두 개로 나눕니다.검색자의 적절한 선택은 건초 더미의 크기(예: 자기장에 비해), 바늘이 건초 더미에 어떻게 들어가는지(예: 바늘의 위치가 실제로 무작위인지 아니면 편향되어 있는지) 등에 따라 달라질 수 있습니다.
Haystack.find (바늘, 검색 자)가 있다면 "최고의 검색 전략은 Haystack의 맥락에서 가장 잘 수행됩니다."라고 말합니다. 나는 그것이 옳다고 생각하지 않습니다."건초 더미는 자신을 검색하는 것이 가장 좋은 방법을 알고 있습니다." 세터를 추가하면 재정의 또는 테스트를 위해 검색자를 수동으로 주입 할 수 있습니다.
개인적으로 저는 두 번째 방법을 좋아합니다.내 추론은 내가 작업한 주요 API가 이 접근 방식을 사용하고 이것이 가장 합리적이라고 생각하기 때문입니다.
사물 목록(건초 더미)이 있으면 바늘을 검색(find())합니다.
@피터 메이어
당신은 아이디어를 얻습니다.가능한 한 느슨하게 결합하는 것이 좋은 일이라고 생각하지만 어쩌면 조금 흥분하고 있었을 수도 있습니다!:)
어...응...내 생각 엔 IStuffSmallEnoughToBeLostInAHaystack 일종의 위험 신호입니다 :-)
또한 대안 3보다 더 나을 것이라고 생각되는 네 번째 대안도 있습니다.
haystack.find(needle, searcher)
나는 당신의 요점을 알지만, 만약에 searcher 건초 더미가 아닌 다른 유형의 개체를 검색하고 바늘이 아닌 다른 개체를 찾을 수 있는 검색 인터페이스를 구현합니까?
인터페이스는 다음과 같은 다양한 알고리즘으로 구현될 수도 있습니다.
binary_searcher.find(needle, haystack)
vision_searcher.find(pitchfork, haystack)
brute_force_searcher.find(money, wallet)
그러나 다른 사람들이 이미 지적했듯이 이는 실제로 여러 검색 알고리즘이 있거나 검색 가능하거나 찾을 수 있는 클래스가 여러 개 있는 경우에만 도움이 된다고 생각합니다.그렇지 않다면 동의합니다. 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();
정말 2와 3이 섞여있습니다.
일부 건초 더미에는 전문적인 검색 전략이 없습니다.이에 대한 예는 배열입니다.무언가를 찾는 유일한 방법은 처음부터 시작하여 원하는 것을 찾을 때까지 각 항목을 테스트하는 것입니다.
이런 종류의 경우 C++와 같은 무료 함수가 가장 좋습니다.
일부 건초더미에는 특별한 검색 전략이 적용될 수 있습니다.예를 들어 이진 검색을 사용할 수 있도록 배열을 정렬할 수 있습니다.자유 함수(또는 자유 함수 쌍, 예:sort 및 bin_search)가 아마도 가장 좋은 옵션일 것입니다.
일부 건초 더미에는 구현의 일부로 통합 검색 전략이 있습니다.예를 들어 연관 컨테이너(해시되거나 순서가 지정된 세트 및 맵)는 모두 그렇습니다.이 경우 찾기는 아마도 필수적인 조회 방법이므로 방법이어야 할 것입니다.haystack.find(바늘).
Haystack은 물건을 포함 할 수 있습니다. 한 가지 유형의 물건은 바늘 파인더입니다. 물건 파인더를 검색하는 데 도움이되는 것입니다. 파인더는 물건을 찾을 수있는 곳의 출처로서 찾아야 할 사항에 대한 물건에 대한 설명을 받아 들일 수있는 것입니다.
따라서 유연한 솔루션을 위해서는 다음과 같은 작업을 수행하는 것이 좋습니다.IStuff 인터페이스
Haystack = ilistu003CIStuff> 바늘 :IStuff
Finder .Find (ISTUFF StuffTolookfor, Ilistu003CIStuff> Stuffstolookin)
이 경우 솔루션은 바늘과 건초 더미에만 국한되지 않고 인터페이스를 구현하는 모든 유형에 사용할 수 있습니다.
그러니 바다에서 물고기를 찾고 싶다면 그렇게 할 수 있습니다.
var 결과 = Finder.Find(물고기, 바다)
바늘 개체에 대한 참조가 있다면 왜 검색합니까?:) 문제 도메인 및 사용 사례는 건초 더미에서 바늘의 정확한 위치가 필요하지 않다고 말합니다 (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);
다양한 검색 전략을 기반으로 하는 더 많은 가능한 솔루션이 있다는 데 동의하므로 검색기를 도입합니다.이에 대한 댓글이 너무 많아서 여기서는 신경 쓰지 않습니다.내 요점은 위의 솔루션이 사용 사례를 잊어버린다는 것입니다. 이미 참조가 있는 경우 검색할 요점은 무엇입니까?가장 자연스러운 사용 사례에서는 아직 바늘이 없으므로 가변 바늘을 사용하지 않습니다.
브래드 윌슨(Brad Wilson)은 객체가 단일 책임을 져야 한다고 지적합니다.극단적인 경우 객체에는 하나의 책임만 있고 상태는 없습니다.그러면 그것은 될 수 있습니다 ...기능.
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());
건초더미는 바늘에 대해 알면 안 되고 바늘도 건초더미에 대해 알면 안 됩니다.검색자는 두 가지 모두에 대해 알아야 하지만, 건초 더미가 자체적으로 검색하는 방법을 알아야 하는지 여부가 논쟁의 실제 요점입니다.
그래서 저는 2와 3을 혼합해서 사용하겠습니다.건초 더미는 다른 사람에게 검색 방법을 알려줄 수 있어야 하며, 검색자는 해당 정보를 사용하여 건초 더미를 검색할 수 있어야 합니다.
haystack.magnet().filter(needle);
코드가 특정 바늘을 찾으려고 합니까, 아니면 아무 바늘이나 찾으려고 합니까?어리석은 질문처럼 들리지만 문제가 달라집니다.
특정 바늘을 찾으려면 질문의 코드가 의미가 있습니다.바늘을 찾는 것은 더 비슷할 것입니다
needle = haystack.findNeedle()
또는
needle = searcher.findNeedle(haystack)
어느 쪽이든, 나는 그 클래스의 검색자를 갖는 것을 선호합니다.건초더미는 검색하는 방법을 모릅니다.CS 관점에서 볼 때 이는 원하지 않는 쓰레기가 많이 포함된 데이터 저장소일 뿐입니다.
확실히 세 번째, IMHO.
건초 더미에 있는 바늘에 대한 질문은 다른 객체의 대규모 모음에서 하나의 객체를 찾으려는 시도의 예입니다. 이는 복잡한 검색 알고리즘(아마도 자석 또는 (더 가능성이 높은) 하위 프로세스가 포함될 수 있음)이 필요함을 나타냅니다. 건초 더미가 스레드 관리를 수행하거나 복잡한 검색을 구현한다고 기대하는 것은 의미가 없습니다.
그러나 검색 개체는 검색 전용이며 빠른 이진 검색을 위해 하위 스레드를 관리하는 방법이나 검색 대상 요소의 속성을 사용하여 영역을 좁히는 방법(예:철 항목을 찾기 위한 자석).
또 다른 가능한 방법은 검색 가능한 개체에 대해 두 개의 인터페이스를 만드는 것입니다.haystack 및 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
}
}
haystack.iterator.findFirst(/* pass here a predicate returning
true if its argument is a needle that we want */)
iterator 불변 컬렉션에 대한 인터페이스가 될 수 있으며 컬렉션에는 공통이 있습니다. findFirst(fun: T => Boolean) 일을 하는 방법.건초 더미가 변경 불가능한 한 "외부"에서 유용한 데이터를 숨길 필요가 없습니다.물론, 사용자 정의 중요 컬렉션 구현과 다른 기능을 함께 묶는 것은 좋지 않습니다. haystack.나누어서 정복해라, 알았지?
