Dmitry, 아마도 이 경우 Guardian 및 Prototype 패턴의 작업과 가능한 모든 조합 및 표현을 혼동하고 있을 것입니다. 첫째, 스냅샷은 프로토타입과 달리 전체 개체를 복사할 필요가 없습니다.
그리고 예, 캡슐화의 필요성은 주로 많은 사람들이 참여하는 대규모 프로젝트에서 나타납니다. 대부분의 지역 문제와 같은 장난감의 경우 물론 과잉)
이제 와서 진지하게 스마트한 표정으로 변수 에 값을 할당 할 수 있고 그런 다음 사용할 수 있다고 논의하게 되었습니다. 오 예 - 무엇이든 프로그래밍할 때 여러 번 다른 변수에 다른 값이 할당된 다음 사용됩니다. 그런데 지금은 다르게 부르는데, 지금은 논할 때 눈썹을 찌푸리며 진지한 표정을 지어야 한다.
그리고 실수하지 않는 것이 중요합니다. 모든 필드가 저장되면 이것이 프로토타입이고 전부가 아니면 가디언입니다. 그렇지 않으면 소년들이 웃을 것입니다.
혹시 "Intyrnet이 넣은 Intyrnet, intyrnet, 우리는 필요하지 않습니다. 그것은 당신의 인터넷입니다..." ???
1. Keeper는 변경 사항이 하나가 아니라 수백 개일 때 변경 사항을 롤백하기 위해 변경 가능한 내용으로 입력할 때 상태를 저장하는 데 사용되는 패턴과 디자인이 유사합니다. 예를 들어 사진 편집기, 텍스트 편집기... 작성 후 발견 - https://refactoring.guru/en/design-patterns/memento 2. 사실 주제도 모르고 비판도 하지 않는 것은 나쁜 습관입니다... 3. 이미 이해할 수 없는 것이 어떻게 더 혼란스럽고 이해하기 어렵게 될 수 있습니까? 4. 다음 자신 ...
혹시 "Intyrnet이 넣은 Intyrnet, intyrnet, 우리는 필요하지 않습니다. 그것은 당신의 인터넷입니다..." ???
1. Keeper는 변경 사항이 하나가 아니라 수백 개일 때 변경 사항을 롤백하기 위해 변경 가능한 내용으로 입력할 때 상태를 저장하는 데 사용되는 패턴과 디자인이 유사합니다. 예를 들어 사진 편집기, 텍스트 편집기... 작성 후 발견 - https://refactoring.guru/en/design-patterns/memento 2. 사실 주제도 모르고 비판도 하지 않는 것은 나쁜 습관입니다... 3. 이미 이해할 수 없는 것이 어떻게 더 혼란스럽고 이해하기 어렵게 될 수 있습니까? 4. 다음 자신 ...
전적으로 지지합니다! 제 농담을 논해주셔서 감사합니다.. 너무 게을렀습니다))
단락 1에서는 스냅샷이 개체의 모든 데이터를 반드시 저장하는 것은 아니며 동일한 개체의 "서로 다른 면의 스냅샷"에 대한 수백 개의 스냅샷이 있는 분기가 여러 개 있을 수 있다고 덧붙였습니다. 이 경우 수백 개의 사용하지 않는 데이터 복사본을 유지하는 것은 정말 최악의 방법입니다.
이제 와서 진지하게 스마트한 표정으로 변수 에 값을 할당 할 수 있고 그런 다음 사용할 수 있다고 논의하게 되었습니다. 오 예 - 무엇이든 프로그래밍할 때 여러 번 다른 변수에 다른 값이 할당된 다음 사용됩니다. 그런데 지금은 다르게 부르는데, 지금은 논할 때 눈썹을 찌푸리며 진지한 표정을 지어야 한다.
그리고 실수하지 않는 것이 중요합니다. 모든 필드가 저장되면 이것이 프로토타입이고 전부가 아니면 가디언이, 그렇지 않으면 소년들이 웃을 것입니다.
드미트리, 나는 당신에게 기꺼이 웃을 것이라고 확신합니다. 글쎄, 나는이 사업을 사랑하지만이 경우 당신은 과장하고 특히 잘 웃었습니다.
당신은 정말로 혼란스러웠습니다. SHOT은 COPY OBJECT와 같지 않습니다.
차이점이 명확하지 않다면 예를 들어 구체적으로 설명하겠습니다. 개체는 1000바이트이고 스냅샷에는 200바이트가 필요합니다. 특히 많은 스냅샷을 저장해야 하는 경우에는 800개를 복사해야 합니다.
p / s / 예, 그리고 일반적으로. 사람들은 패턴이 기본적인 TYPICAL 작업을 해결하는 기본적인 예일 뿐이라는 것을 정말로 이해하지 못합니까? 그러나 실제로 작업은 기본이 아니라 더 복잡합니다. 그리고 실제 문제를 해결하기 위해 패턴이 필요합니다. 종종 순수한 책 형식이 아니라 특정 작업에 맞게 수정된 형식으로, 가능하면 서로 결합되고, 때로는 단순화로 표현되는 일종의 즉흥 연주가 추가될 수 있습니다. 작업이 허용하는 경우 또는 그 반대의 경우 "가중치" 구현.
다시 말하지만, 캡슐화 및 인터페이스가 필요한 이유 - 귀하의 아이큐가 Wasserman보다 낮은지 또는 실제 프로젝트에 참여하지 않은 경우 프로젝트의 다른 부분이 다른 사람에 의해 동시에 변경되는 경우 이해하기 어려울 수 있습니다. OO 디자인의 기본 원칙을 준수하지 않으면 버그를 잡는 데 막대한 비용이 듭니다. 사실, 왜 이 모든 것이 시장에 대한 스탬핑 어드바이저를 위한 것입니까?))
4. 우주선의 상태가 이전에 발행된 작업으로 정확히 실패한 경우 우주선을 다시 시작합니다.
5. CA를 데이터베이스에 저장하고 상태가 성공하면 스트림에서 제거합니다.
6. 우주선의 상태(저장된 ID)를 복원하고 스트림에 추가
7. CA 메시지 교환을 위한 공통 풀이 있고, 풀은 고무가 아니며, 원격 CA는 메시지를 수신하지 않지만 새로 생성된 CA는 새 메시지를 수신해야 하며 죽인 CA에서 남겨진 메시지가 아니라 스레드와 CA 사이에 동기화가 없습니다.
8. 전체 패턴 및 메시지 풀의 상태 저장 및 복원
* KA는 동일한 유형의 작업을 수행하지 않습니다.
** 메시지 풀이 주요 문제이지만 CA 또는 DB 또는 ?
*** 아마도 이 모든 것이 데이터베이스와 작동하고 패턴이 여기에 전혀 필요하지 않습니까?
1. 당신은 복잡한 작업을 가지고 있으므로, 당신의 질문에서 들릴 수 있다면 단어 패턴은 복수형으로만 사용됩니다 :)
2. 또한 흐름을 따라 균일하게 KA를 추가해야 합니다. singleton-idemaker 및 스레드 관리자로 구현된 팩토리의 문제점은 무엇입니까? 간단한 카운터가 이해할 수 없을 정도로 맞지 않는 이유는 무엇입니까? 우주선 chtoli의 생성을 관리하는 방법은 없나요? 다른 사람의 프로젝트나 자신의 프로젝트를 위해 애드온을 만들고 있습니까?
7. 우주선 생성 시점을 기준으로 필터링한 관찰자. MT에 대한 모든 구현.
데이터베이스의 모든 절약 - 데이터베이스 계층은 어렵지 않습니다.
데이터베이스에서 복원하여 공장을 연결하는 데 어려움이 없습니다.
일반적으로 - 질문에 대한 정답 - 최소한 모든 패턴이 필요합니다. 진지하게. 그것들을 모두 마스터 한 후에는 그러한 작업을 수행해야합니다. 그 과정에서 데코레이터와 파사드(데이터베이스용) 및 방문자가 종단 간 이벤트 및 기타를 구현해야 할 수 있기 때문입니다.
1. Keeper는 변경 사항이 하나가 아니라 수백 개일 때 변경 사항을 롤백하기 위해 변경 가능한 내용 으로 입력할 때 상태를 저장하는 데 사용되는 패턴과 디자인이 유사합니다. 예를 들어 사진 편집기, 텍스트 편집기...
2. 사실 주제도 모르고 비판도 하지 않는 것은 나쁜 습관입니다...
요점을 강조했습니다. 많은 OOP 오용 문제의 근본 원인은 변경 가능한 콘텐츠입니다. 나 역시 오래전부터 이것을 좋아했지만 경험을 통해 점차 이해하게 된다. 객체(포인터) 간에 많은 관계가 있고 동시에 객체가 변경 가능한 코드 - 이것은 악마가 나중에 다리를 부러뜨릴 지옥 같은 국수입니다. 따라서 참조 객체가 불변임을 확인하기 위해 노력해야 합니다 . 값 개체만 변경되어야 합니다. 구조와 단순 유형, 포인터.
저것들. 이 경우 원래 객체를 클래스가 아닌 구조체로 선언하는 것이 바람직합니다. 그런 다음 내용을 변경할 수 있습니다. 동시에, 당연히 논의 중인 패턴에서와 같이 더 이상 포인터를 가져 와서 저장할 수 없으며 이것이 맞습니다. 메서드를 명시적으로 참조하거나 함수에 대한 인수로 전달하여 개체를 변경해야 합니다. 저것들. 그래서:
memento.restoreState(myObject);
또는
myObject.restoreState(memento);
그리고 다음과 같이 하지 않습니다.
memento.restoreState();
이것은 우리가 memento 개체를 변경하는 것처럼 보이지만 실제로는 프로그램의 다른 곳에 있을 수 있는 다른 개체가 변경되고 있습니다. 부작용이 있습니다. 전역 변수 를 한 곳에서 변경하고 그 값을 다른 곳에서 사용하는 것과 같습니다.
저것들. memento는 원본 개체에 대한 참조를 저장해서는 안 됩니다. 그리고 콘텐츠만 저장합니다. 이것은 모두 제 생각입니다만, 사실과 크게 다르지 않다고 생각합니다)
1) 객체(포인터) 간에 많은 관계가 있고 동시에 객체가 변경 가능한 코드 - 이것은 악마가 나중에 다리를 부러뜨릴 지옥 같은 국수입니다. 따라서 참조 객체가 불변임을 확인하기 위해 노력해야 합니다 . 2)가치-객체만 변경되어야 합니다. 구조와 단순 유형, 포인터. 3)즉 이 경우 원래 객체를 클래스가 아닌 구조체로 선언하는 것이 바람직합니다. 그런 다음 내용을 변경할 수 있습니다. 동시에, 당연히 논의 중인 패턴에서와 같이 더 이상 포인터를 가져 와서 저장할 수 없으며 이것이 맞습니다. 4)객체의 메소드를 명시적으로 참조하거나 함수에 대한 인수로 전달하여 객체를 변경해야 합니다. 이것은 우리가 memento 개체를 변경하는 것처럼 보이지만 실제로는 프로그램의 다른 곳에 있을 수 있는 다른 개체가 변경되고 있습니다. 부작용이 있습니다.
1. 데이터 구조 는 나무가 모두 악한 것에서 나온 것으로 밝혀졌습니다 ... 2. class == private struct의 형편없는 C++, 무엇을 해야 하는지, 아마도 구조와 클래스를 포기할 가치가 있을 것입니다. 3. 그리고 당연히 그렇습니다. 패턴이 없고 포인터를 통한 정렬이 없으며 특히 큰 개체의 경우 메모리 절약이 없습니다. 4. 인터페이스 및 템플릿 기능의 사용을 금지하는 것을 잊지 말아야 합니다. 그렇지 않으면 작업이 수행되는 대상이 명확하지 않습니다.
Dmitry, 아마도 이 경우 Guardian 및 Prototype 패턴의 작업과 가능한 모든 조합 및 표현을 혼동하고 있을 것입니다. 첫째, 스냅샷은 프로토타입과 달리 전체 개체를 복사할 필요가 없습니다.
그리고 예, 캡슐화의 필요성은 주로 많은 사람들이 참여하는 대규모 프로젝트에서 나타납니다. 대부분의 지역 문제와 같은 장난감의 경우 물론 과잉)
이제 와서 진지하게 스마트한 표정으로 변수 에 값을 할당 할 수 있고 그런 다음 사용할 수 있다고 논의하게 되었습니다. 오 예 - 무엇이든 프로그래밍할 때 여러 번 다른 변수에 다른 값이 할당된 다음 사용됩니다. 그런데 지금은 다르게 부르는데, 지금은 논할 때 눈썹을 찌푸리며 진지한 표정을 지어야 한다.
그리고 실수하지 않는 것이 중요합니다. 모든 필드가 저장되면 이것이 프로토타입이고 전부가 아니면 가디언입니다. 그렇지 않으면 소년들이 웃을 것입니다.
혹시 "Intyrnet이 넣은 Intyrnet, intyrnet, 우리는 필요하지 않습니다. 그것은 당신의 인터넷입니다..." ???
1. Keeper는 변경 사항이 하나가 아니라 수백 개일 때 변경 사항을 롤백하기 위해 변경 가능한 내용으로 입력할 때 상태를 저장하는 데 사용되는 패턴과 디자인이 유사합니다. 예를 들어 사진 편집기, 텍스트 편집기...
작성 후 발견 - https://refactoring.guru/en/design-patterns/memento
2. 사실 주제도 모르고 비판도 하지 않는 것은 나쁜 습관입니다...
3. 이미 이해할 수 없는 것이 어떻게 더 혼란스럽고 이해하기 어렵게 될 수 있습니까?
4. 다음 자신 ...
그리고 OOP는 어떻습니까?
혹시 "Intyrnet이 넣은 Intyrnet, intyrnet, 우리는 필요하지 않습니다. 그것은 당신의 인터넷입니다..." ???
1. Keeper는 변경 사항이 하나가 아니라 수백 개일 때 변경 사항을 롤백하기 위해 변경 가능한 내용으로 입력할 때 상태를 저장하는 데 사용되는 패턴과 디자인이 유사합니다. 예를 들어 사진 편집기, 텍스트 편집기...
작성 후 발견 - https://refactoring.guru/en/design-patterns/memento
2. 사실 주제도 모르고 비판도 하지 않는 것은 나쁜 습관입니다...
3. 이미 이해할 수 없는 것이 어떻게 더 혼란스럽고 이해하기 어렵게 될 수 있습니까?
4. 다음 자신 ...
전적으로 지지합니다! 제 농담을 논해주셔서 감사합니다.. 너무 게을렀습니다))
단락 1에서는 스냅샷이 개체의 모든 데이터를 반드시 저장하는 것은 아니며 동일한 개체의 "서로 다른 면의 스냅샷"에 대한 수백 개의 스냅샷이 있는 분기가 여러 개 있을 수 있다고 덧붙였습니다. 이 경우 수백 개의 사용하지 않는 데이터 복사본을 유지하는 것은 정말 최악의 방법입니다.
이제 와서 진지하게 스마트한 표정으로 변수 에 값을 할당 할 수 있고 그런 다음 사용할 수 있다고 논의하게 되었습니다. 오 예 - 무엇이든 프로그래밍할 때 여러 번 다른 변수에 다른 값이 할당된 다음 사용됩니다. 그런데 지금은 다르게 부르는데, 지금은 논할 때 눈썹을 찌푸리며 진지한 표정을 지어야 한다.
그리고 실수하지 않는 것이 중요합니다. 모든 필드가 저장되면 이것이 프로토타입이고 전부가 아니면 가디언이, 그렇지 않으면 소년들이 웃을 것입니다.
드미트리, 나는 당신에게 기꺼이 웃을 것이라고 확신합니다. 글쎄, 나는이 사업을 사랑하지만이 경우 당신은 과장하고 특히 잘 웃었습니다.
당신은 정말로 혼란스러웠습니다. SHOT은 COPY OBJECT와 같지 않습니다.
차이점이 명확하지 않다면 예를 들어 구체적으로 설명하겠습니다. 개체는 1000바이트이고 스냅샷에는 200바이트가 필요합니다. 특히 많은 스냅샷을 저장해야 하는 경우에는 800개를 복사해야 합니다.
p / s / 예, 그리고 일반적으로. 사람들은 패턴이 기본적인 TYPICAL 작업을 해결하는 기본적인 예일 뿐이라는 것을 정말로 이해하지 못합니까? 그러나 실제로 작업은 기본이 아니라 더 복잡합니다. 그리고 실제 문제를 해결하기 위해 패턴이 필요합니다. 종종 순수한 책 형식이 아니라 특정 작업에 맞게 수정된 형식으로, 가능하면 서로 결합되고, 때로는 단순화로 표현되는 일종의 즉흥 연주가 추가될 수 있습니다. 작업이 허용하는 경우 또는 그 반대의 경우 "가중치" 구현.
다시 말하지만, 캡슐화 및 인터페이스가 필요한 이유 - 귀하의 아이큐가 Wasserman보다 낮은지 또는 실제 프로젝트에 참여하지 않은 경우 프로젝트의 다른 부분이 다른 사람에 의해 동시에 변경되는 경우 이해하기 어려울 수 있습니다. OO 디자인의 기본 원칙을 준수하지 않으면 버그를 잡는 데 막대한 비용이 듭니다. 사실, 왜 이 모든 것이 시장에 대한 스탬핑 어드바이저를 위한 것입니까?))
Sergey Dzyublik :
1. Keeper는 변경 사항이 하나가 아니라 수백 개일 때 변경 사항을 롤백하기 위해 변경 가능한 내용 으로 입력할 때 상태를 저장하는 데 사용되는 패턴과 디자인이 유사합니다. 예를 들어 사진 편집기, 텍스트 편집기...
2. 사실 주제도 모르고 비판도 하지 않는 것은 나쁜 습관입니다...
요점을 강조했습니다. 많은 OOP 오용 문제의 근본 원인은 변경 가능한 콘텐츠입니다. 나 역시 오래전부터 이것을 좋아했지만 경험을 통해 점차 이해하게 된다. 객체(포인터) 간에 많은 관계가 있고 동시에 객체가 변경 가능한 코드 - 이것은 악마가 나중에 다리를 부러뜨릴 지옥 같은 국수입니다. 따라서 참조 객체가 불변임을 확인하기 위해 노력해야 합니다 . 값 개체만 변경되어야 합니다. 구조와 단순 유형, 포인터.
저것들. 이 경우 원래 객체를 클래스가 아닌 구조체로 선언하는 것이 바람직합니다. 그런 다음 내용을 변경할 수 있습니다. 동시에, 당연히 논의 중인 패턴에서와 같이 더 이상 포인터를 가져 와서 저장할 수 없으며 이것이 맞습니다. 메서드를 명시적으로 참조하거나 함수에 대한 인수로 전달하여 개체를 변경해야 합니다. 저것들. 그래서:
또는
그리고 다음과 같이 하지 않습니다.
이것은 우리가 memento 개체를 변경하는 것처럼 보이지만 실제로는 프로그램의 다른 곳에 있을 수 있는 다른 개체가 변경되고 있습니다. 부작용이 있습니다. 전역 변수 를 한 곳에서 변경하고 그 값을 다른 곳에서 사용하는 것과 같습니다.
저것들. memento는 원본 개체에 대한 참조를 저장해서는 안 됩니다. 그리고 콘텐츠만 저장합니다. 이것은 모두 제 생각입니다만, 사실과 크게 다르지 않다고 생각합니다)
나는 내 자신의 의견을 가진 척하지 않고 어딘가에서 읽었을 수도 있지만 IMHO, 프로그래밍에는 두 가지 작업 만 있습니다. 프로그램의 올바른 구조와 신속하게 변수에 대한 좋은 이름을 선택하고 다른 모든 작업은 아주 잘 수행됩니다. 간단히
나도 심각해
감사합니다 패턴을 읽어보겠습니다
나는 기다릴 것입니다. 갑자기 다른 누군가가 나타날 것입니다. 그렇지 않으면 학술 개발자가 초보자와 트레이너 수준의 질문으로 날아갈 것입니다.)))
1) 객체(포인터) 간에 많은 관계가 있고 동시에 객체가 변경 가능한 코드 - 이것은 악마가 나중에 다리를 부러뜨릴 지옥 같은 국수입니다. 따라서 참조 객체가 불변 임을 확인하기 위해 노력해야 합니다 .
2) 가치-객체만 변경되어야 합니다. 구조와 단순 유형, 포인터.
3) 즉 이 경우 원래 객체를 클래스가 아닌 구조체로 선언하는 것이 바람직합니다. 그런 다음 내용을 변경할 수 있습니다. 동시에, 당연히 논의 중인 패턴에서와 같이 더 이상 포인터를 가져 와서 저장할 수 없으며 이것이 맞습니다.
4) 객체의 메소드를 명시적으로 참조하거나 함수에 대한 인수로 전달하여 객체를 변경해야 합니다.
이것은 우리가 memento 개체를 변경하는 것처럼 보이지만 실제로는 프로그램의 다른 곳에 있을 수 있는 다른 개체가 변경되고 있습니다. 부작용이 있습니다.
1. 데이터 구조 는 나무가 모두 악한 것에서 나온 것으로 밝혀졌습니다 ...
2. class == private struct의 형편없는 C++, 무엇을 해야 하는지, 아마도 구조와 클래스를 포기할 가치가 있을 것입니다.
3. 그리고 당연히 그렇습니다. 패턴이 없고 포인터를 통한 정렬이 없으며 특히 큰 개체의 경우 메모리 절약이 없습니다.
4. 인터페이스 및 템플릿 기능의 사용을 금지하는 것을 잊지 말아야 합니다. 그렇지 않으면 작업이 수행되는 대상이 명확하지 않습니다.