1. 데이터 구조 는 나무가 모두 악한 것에서 나온 것으로 밝혀졌습니다 ... 2. class == private struct의 형편없는 C++, 무엇을 해야 하는지, 아마도 구조와 클래스를 포기할 가치가 있을 것입니다. 3. 그리고 당연히 그렇습니다. 패턴이 없고 포인터를 통한 정렬이 없으며 특히 큰 개체의 경우 메모리 절약이 없습니다. 4. 인터페이스 및 템플릿 기능의 사용을 금지하는 것을 잊지 말아야 합니다. 그렇지 않으면 작업이 수행되는 대상이 명확하지 않습니다.
1. 아니, 글쎄요. 상태를 변경하는 트리(또는 연결 목록)의 노드에 대해 이야기하고 있다면 해당 상태에 대한 액세스를 구성하는 문제일 뿐입니다. 코드의 기능적 깔끔함의 관점에서 사용자는 노드의 상태에 접근할 수 없어야 합니다. 노드를 통한 모든 반복은 myNode.NextNode() 또는 myNode.Parent()가 아니라 tree.NextNode(myNode) 또는 tree.Parent(myNode)와 같은 트리 자체에 대한 호출을 통해 수행되어야 합니다.
저것들. 변경 가능한 상태는 공개적으로 사용할 수 없어야 합니다.
2. 글쎄, 나는 Sharpe 구조를 택했는데, 왜냐하면 링크/포인터를 가져갈 수 없다는 보장이 있기 때문이다. 저것들. 모든 것은 컴파일러의 통제 하에 있습니다. 그러한 통제가 없다면 개인 통제가 제공되어야 합니다. 예를 들어 적절한 클래스 이름 지정을 통해. 이렇게 말해보자:
클래스 MyClass_mut; // 변경 가능
클래스 MyClass_immut; // 불변
3, 4. 당신은 틀렸습니다. 모든 것이 실현 가능) 모든 객체 데이터가 반드시 스택을 통해 복사된다고 생각하지 마십시오. 일반적으로 개체는 데이터에 대한 내부 포인터를 포함합니다. 스마트 포인터와 유사합니다. 변경 가능한 객체의 경우에만 이 포인터가 더 똑똑해야 합니다)
드미트리, 나는 당신에게 기꺼이 웃을 것이라고 확신합니다. 글쎄, 나는이 사업을 사랑하지만이 경우 당신은 과장하고 특히 잘 웃었습니다.
당신은 정말로 혼란스러웠습니다. SHOT은 COPY OBJECT와 같지 않습니다.
차이점이 명확하지 않다면 예를 들어 구체적으로 설명하겠습니다. 개체는 1000바이트이고 스냅샷에는 200바이트가 필요합니다. 특히 많은 스냅샷을 저장해야 하는 경우에는 800개를 복사해야 합니다.
p / s / 그리고 일반적으로. 사람들은 패턴이 기본적인 TYPICAL 작업을 해결하는 기본적인 예일 뿐이라는 것을 정말로 이해하지 못합니까? 그러나 실제로 작업은 기본이 아니라 더 복잡합니다. 그리고 실제 문제를 해결하기 위해 패턴이 필요합니다. 종종 순수한 책 형식이 아니라 특정 작업에 맞게 수정된 형식으로, 가능하면 서로 결합되고, 때로는 단순화로 표현되는 일종의 즉흥 연주가 추가될 수 있습니다. 작업이 허용하는 경우 또는 그 반대의 경우 "가중치" 구현.
다시 말하지만, 캡슐화 및 인터페이스가 필요한 이유 - 귀하의 아이큐가 Wasserman보다 낮은지 또는 실제 프로젝트에 참여하지 않은 경우 프로젝트의 다른 부분이 다른 사람에 의해 동시에 변경되는 경우 이해하기 어려울 수 있습니다. OO 디자인의 기본 원칙을 준수하지 않으면 버그를 잡는 데 막대한 비용이 듭니다. 사실, 왜 이 모든 것이 시장에 대한 스탬핑 어드바이저를 위한 것입니까?))
당신은 프로그래밍 문제를 해결하기 위한 알고리즘을 OOP만을 다루는 소위 유행하는 " 디자인 패턴"으로 혼동하고 있습니다. 그리고 당신이 혼동하고 부주의하게 읽는 많은 다른 것들. 조금 더 일찍 나는 구조를 사용하기 위해 썼습니다. 하지만 결국, 당신이 그 포스트를 읽고 내가 전체 클래스를 복사하는 기능에 대해 쓰지 않았다면, 당신은 우리가 성인이고 필요한 경우 추가 구조로 추가 작업을 수행해야 하는 지점에 도달할 것입니다. 모든 것을 성인 방식으로 수행하려면 전체 클래스를 복사할 수 있는 기능을 확인하십시오.
다시 말하지만, 캡슐화 및 인터페이스가 필요한 이유 - 귀하의 아이큐가 Wasserman보다 낮은지 또는 실제 프로젝트에 참여하지 않은 경우 프로젝트의 다른 부분이 다른 사람에 의해 동시에 변경되는 경우 이해하기 어려울 수 있습니다. OO 디자인의 기본 원칙을 준수하지 않으면 버그를 잡는 데 막대한 비용이 듭니다. 사실, 왜 이 모든 것이 시장에 대한 스탬핑 어드바이저를 위한 것입니까?))
.
세르게이 주블릭 :
... 4. 인터페이스 및 템플릿 기능의 사용을 금지하는 것을 잊지 말아야 합니다. 그렇지 않으면 작업이 수행되는 대상이 명확하지 않습니다.
어쨌든 어딘가에서 인터페이스가 무엇인지, 왜 필요한지 읽으십시오.
-
예, 그리고 이것은 ... 실행 취소 / 다시 실행 기능으로 개체의 전체 또는 일부 필드를 저장하는 기능을 진지하게 비교하고 있습니까? Photoshop에서 수행되는 방식을 알고 있으므로 Photoshop에 대해 논의해 보겠습니다.
-
그리고 여기 내 비누에 초콜릿 아래에 이렇게 쓰는 사람은 누구입니까?
-
그리고 일반적으로 무엇이 문제입니까? 내가 "Holy Patterns"에 대한 믿음의 기초를 흔들었습니까?
1. 데이터 구조 는 나무가 모두 악한 것에서 나온 것으로 밝혀졌습니다 ...
2. class == private struct의 형편없는 C++, 무엇을 해야 하는지, 아마도 구조와 클래스를 포기할 가치가 있을 것입니다.
3. 그리고 당연히 그렇습니다. 패턴이 없고 포인터를 통한 정렬이 없으며 특히 큰 개체의 경우 메모리 절약이 없습니다.
4. 인터페이스 및 템플릿 기능의 사용을 금지하는 것을 잊지 말아야 합니다. 그렇지 않으면 작업이 수행되는 대상이 명확하지 않습니다.
1. 아니, 글쎄요. 상태를 변경하는 트리(또는 연결 목록)의 노드에 대해 이야기하고 있다면 해당 상태에 대한 액세스를 구성하는 문제일 뿐입니다. 코드의 기능적 깔끔함의 관점에서 사용자는 노드의 상태에 접근할 수 없어야 합니다. 노드를 통한 모든 반복은 myNode.NextNode() 또는 myNode.Parent()가 아니라 tree.NextNode(myNode) 또는 tree.Parent(myNode)와 같은 트리 자체에 대한 호출을 통해 수행되어야 합니다.
저것들. 변경 가능한 상태는 공개적으로 사용할 수 없어야 합니다.
2. 글쎄, 나는 Sharpe 구조를 택했는데, 왜냐하면 링크/포인터를 가져갈 수 없다는 보장이 있기 때문이다. 저것들. 모든 것은 컴파일러의 통제 하에 있습니다. 그러한 통제가 없다면 개인 통제가 제공되어야 합니다. 예를 들어 적절한 클래스 이름 지정을 통해. 이렇게 말해보자:
클래스 MyClass_mut; // 변경 가능
클래스 MyClass_immut; // 불변
3, 4. 당신은 틀렸습니다. 모든 것이 실현 가능) 모든 객체 데이터가 반드시 스택을 통해 복사된다고 생각하지 마십시오. 일반적으로 개체는 데이터에 대한 내부 포인터를 포함합니다. 스마트 포인터와 유사합니다. 변경 가능한 객체의 경우에만 이 포인터가 더 똑똑해야 합니다)
드미트리, 나는 당신에게 기꺼이 웃을 것이라고 확신합니다. 글쎄, 나는이 사업을 사랑하지만이 경우 당신은 과장하고 특히 잘 웃었습니다.
당신은 정말로 혼란스러웠습니다. SHOT은 COPY OBJECT와 같지 않습니다.
차이점이 명확하지 않다면 예를 들어 구체적으로 설명하겠습니다. 개체는 1000바이트이고 스냅샷에는 200바이트가 필요합니다. 특히 많은 스냅샷을 저장해야 하는 경우에는 800개를 복사해야 합니다.
p / s / 그리고 일반적으로. 사람들은 패턴이 기본적인 TYPICAL 작업을 해결하는 기본적인 예일 뿐이라는 것을 정말로 이해하지 못합니까? 그러나 실제로 작업은 기본이 아니라 더 복잡합니다. 그리고 실제 문제를 해결하기 위해 패턴이 필요합니다. 종종 순수한 책 형식이 아니라 특정 작업에 맞게 수정된 형식으로, 가능하면 서로 결합되고, 때로는 단순화로 표현되는 일종의 즉흥 연주가 추가될 수 있습니다. 작업이 허용하는 경우 또는 그 반대의 경우 "가중치" 구현.
다시 말하지만, 캡슐화 및 인터페이스가 필요한 이유 - 귀하의 아이큐가 Wasserman보다 낮은지 또는 실제 프로젝트에 참여하지 않은 경우 프로젝트의 다른 부분이 다른 사람에 의해 동시에 변경되는 경우 이해하기 어려울 수 있습니다. OO 디자인의 기본 원칙을 준수하지 않으면 버그를 잡는 데 막대한 비용이 듭니다. 사실, 왜 이 모든 것이 시장에 대한 스탬핑 어드바이저를 위한 것입니까?))
당신은 프로그래밍 문제를 해결하기 위한 알고리즘을 OOP만을 다루는 소위 유행하는 " 디자인 패턴"으로 혼동하고 있습니다. 그리고 당신이 혼동하고 부주의하게 읽는 많은 다른 것들. 조금 더 일찍 나는 구조를 사용하기 위해 썼습니다. 하지만 결국, 당신이 그 포스트를 읽고 내가 전체 클래스를 복사하는 기능에 대해 쓰지 않았다면, 당신은 우리가 성인이고 필요한 경우 추가 구조로 추가 작업을 수행해야 하는 지점에 도달할 것입니다. 모든 것을 성인 방식으로 수행하려면 전체 클래스를 복사할 수 있는 기능을 확인하십시오.
...
다시 말하지만, 캡슐화 및 인터페이스가 필요한 이유 - 귀하의 아이큐가 Wasserman보다 낮은지 또는 실제 프로젝트에 참여하지 않은 경우 프로젝트의 다른 부분이 다른 사람에 의해 동시에 변경되는 경우 이해하기 어려울 수 있습니다. OO 디자인의 기본 원칙을 준수하지 않으면 버그를 잡는 데 막대한 비용이 듭니다. 사실, 왜 이 모든 것이 시장에 대한 스탬핑 어드바이저를 위한 것입니까?))
.
...
4. 인터페이스 및 템플릿 기능의 사용을 금지하는 것을 잊지 말아야 합니다. 그렇지 않으면 작업이 수행되는 대상이 명확하지 않습니다.
어쨌든 어딘가에서 인터페이스가 무엇인지, 왜 필요한지 읽으십시오.
-
예, 그리고 이것은 ... 실행 취소 / 다시 실행 기능으로 개체의 전체 또는 일부 필드를 저장하는 기능을 진지하게 비교하고 있습니까? Photoshop에서 수행되는 방식을 알고 있으므로 Photoshop에 대해 논의해 보겠습니다.
-
그리고 여기 내 비누에 초콜릿 아래에 이렇게 쓰는 사람은 누구입니까?
-
그리고 일반적으로 무엇이 문제입니까? 내가 "Holy Patterns"에 대한 믿음의 기초를 흔들었습니까?
책장을 통해 정렬됩니다.
우수한 발견: "BASIC의 삽화가 있는 인공 지능 및 전문가 시스템 이론 소개" 1987년 "객체 지향 프로그래밍 개념" 장 중 하나
날 믿어, 아무것도 변한게 없어...
책장을 통해 정렬됩니다.
우수한 발견: "BASIC의 삽화가 있는 인공 지능 및 전문가 시스템 이론 소개" 1987년 "객체 지향 프로그래밍 개념" 장 중 하나
날 믿어, 아무것도 변한게 없어...
많은 것이 바뀌었고 신성한 디자인 패턴을 숭배하는 교회는 없었습니다. 그리고 그 당시에는 C++ 피해자 클럽이 아직 형성되지 않았습니다.
Holy Design Patterns에 전념하는 교회가 없었기 때문에 많은 것이 변했습니다.
이것은 지금 거기에 없습니다. Runet을 검색할 수 있습니다. Runet의 패턴 주제에 대한 질문 수가 매우 적은 경우 이것은 대량 문자로 존재하지 않으며 학생의 "책" 질문은 계산되지 않습니다
읽을 것이 없지만 프로젝트 를 확장하려는 경우 편리합니다. 일반적으로 이것은 프로그램의 초기 올바른 구조입니다.
Holy Design Patterns에 전념하는 교회가 없었기 때문에 많은 것이 변했습니다.
" 디자인 패턴"은 자주 발생하는 동일한 것을 같은 이름으로 부르기로 한 합의일 뿐입니다. 그건 그렇고,이 용어는 아키텍처 (조각 / 다리 / 현관 / 포털에 관한 것)에서 왔습니다.
때론 비슷한 일들이 비슷한 방법으로 풀린다, 그게 항상 사실은 아니다.. 하지만 사물과 방법의 유사점에 대해 동의를 하면 서로를 이해하는 데 도움이 된다.
그러나 물론 사람들은 "바보에게 유리 남근을 주면 그 물건이 깨지고 자릅니다"
이것은 지금 거기에 없습니다. Runet을 검색할 수 있습니다. Runet의 패턴 주제에 대한 질문 수가 매우 적은 경우 이것은 대량 문자로 존재하지 않으며 학생의 "책" 질문은 계산되지 않습니다
읽을 내용은 없지만 프로젝트를 확장하려는 경우 편리합니다. 일반적으로 이것은 원래 설정된 프로그램의 올바른 구조입니다.
아무것도 포함되어 있지 않습니다. 얼마나 많은 패턴을 배웠습니까?
아무것도 포함되어 있지 않습니다. 얼마나 많은 패턴을 배웠습니까?
공부한다는 말은 무엇을 의미합니까?
여러 포럼에서 설명을 읽으면 약 12개 정도는 확실합니다.
MQL에 적용하면 문제 없는 전략, 작동, 확장, 리팩토링 - 테스터가 더 빠르게 최적화하고 데모로 바로 이동하도록 모든 것을 버리고 일반적으로 편리하고 실용적입니다.