이 와일드 마인드 게임의 의미는 어떻습니까? 패턴의 "목적"(인용 부호, 왜냐하면... 글라디올러스)은 " 캡슐화 를 위반하지 않고객체의 내부 상태를 캡처하고 저장하는 "(인용 부호로 인해 인용 부호)입니다. 그러나 setState() 메서드는 필수 불가결합니다. 글쎄, 캡슐화의 보존은 어디에 있습니까? 각 개인 필드에 대해 두 가지 방법을 더 작성하십시오 ... 예 ... 멋진 캡슐화가 유지됩니다.
솔직히 말해서 이 접근 방식을 실제로 적용하시겠습니까? 나는 의심한다. 실제로는 이를 명시적이고 투명하게 만들 것입니다. 예를 들어, 동일한 필드 집합과 저장 및 복원을 위한 몇 가지 방법이 있는 구조입니다. 그러면 캡슐화가 실제로 유지되고 상태 저장과 복원이라는 두 가지 새로운 방법만 나타납니다.
알겠습니다. 저장하겠습니다. 작동 원리를 테스트해야 했습니다. 아마도 이것이 제가 찾던 것입니다. 테스터와 상태를 저장할 수 있는 작업 EA용 코드 하나, 테스터에서는 반대로 , "추가 제스처"에 리소스를 낭비하지 마십시오. 이러한 패턴의 일부는 #ifdef -ami가 될 수 있습니다. ;)
골키퍼와 함께 이 쓰레기의 의미를 이해하려고 노력하고 있지만 큰 이점을 보지 못합니다. 사실, 이것은 부작용 생성을 통한 프로그래밍의 나쁜 습관입니다. 한 개체를 변경하면 다른 개체도 변경됩니다. 결과적으로 코드는 혼란스럽고 이해하기 어려워집니다. 코드 순도, IMHO를 위해 노력하는 것이 좋습니다.
단순히 개체를 다른 개체에 복사한 다음 다시 복사하는 것을 방지하는 것은 무엇입니까? 본질적으로 더 정확하고 이해하기 쉬운 것뿐입니다.
싱글톤도 마찬가지입니다. 이 싱글톤에 setter와 getter가 동시에 있으면(즉, 상태를 변경하고 읽을 수 있음) 전역 변수 로 작업하는 것과 같습니다. 동시에 모든 프로그래머는 전역 상태를 변경하는 작업이 나쁘다는 것을 알고 있습니다. 그러나 어떤 이유로 싱글 톤은 계산되지 않습니다)
골키퍼와 함께 이 쓰레기의 의미를 이해하려고 노력하고 있지만 큰 이점을 보지 못합니다. 사실, 이것은 부작용 생성을 통한 프로그래밍의 나쁜 습관입니다. 한 개체를 변경하면 다른 개체도 변경됩니다. 결과적으로 코드가 혼란스럽고 이해하기 어려워집니다. 코드 순도, IMHO를 위해 노력하는 것이 좋습니다.
모든 것이 더 쉽습니다. 기술적 가능성을 연구하고 있습니다.
글쎄요, 아마도 사고 방식은 흔적을 남길 것입니다. 저는 유한 상태 기계의 위치에서 자동화된 시스템의 상태를 평가하는 데 더 익숙합니다. 예비 시스템의 상태)))
골키퍼와 함께 이 쓰레기의 의미를 이해하려고 노력하고 있지만 큰 이점을 보지 못합니다. 사실, 이것은 부작용 생성을 통한 프로그래밍의 나쁜 습관입니다. 한 개체를 변경하면 다른 개체도 변경됩니다. 결과적으로 코드는 혼란스럽고 이해하기 어려워집니다. 코드 순도, IMHO를 위해 노력하는 것이 좋습니다.
단순히 개체를 다른 개체에 복사한 다음 다시 복사하는 것을 방지하는 것은 무엇입니까? 본질적으로 더 정확하고 이해하기 쉬운 것뿐입니다.
싱글톤도 마찬가지입니다. 이 싱글톤에 setter와 getter가 동시에 있으면(즉, 상태를 변경하고 읽을 수 있음) 전역 변수 로 작업하는 것과 같습니다. 동시에 모든 프로그래머는 전역 상태를 변경하는 작업이 나쁘다는 것을 알고 있습니다. 그러나 어떤 이유로 싱글 톤은 계산되지 않습니다)
이것은 심각한 대규모 프로젝트와 관련이 없는 프로그래머의 전형적인 관점이라고 생각합니다. 직접적으로 죄송합니다만 기본의 기초를 나쁜 습관이라고 부르는 다른 설명은 보이지 않습니다)
1) 골키퍼와 함께 이 쓰레기의 의미를 이해하려고 노력하고 있지만 큰 이점을 보지 못합니다. 2) 사실, 이것은 부작용을 만들어내는 프로그래밍의 나쁜 습관입니다. 3) 하나의 개체를 변경할 때 다른 개체를 변경합니다. 결과적으로 코드는 혼란스럽고 이해하기 어려워집니다. 코드 순도, IMHO를 위해 노력하는 것이 좋습니다. 4) 단순히 객체를 다른 객체에 복사한 다음 다시 복사하는 것을 방지하는 것은 무엇입니까? 본질적으로 더 정확하고 이해하기 쉬운 것뿐입니다.
싱글톤도 마찬가지입니다. 이 싱글톤에 setter와 getter가 동시에 있으면(즉, 상태를 변경하고 읽을 수 있음) 전역 변수 로 작업하는 것과 같습니다. 동시에 모든 프로그래머는 전역 상태를 변경하는 작업이 나쁘다는 것을 알고 있습니다. 그러나 어떤 이유로 싱글 톤은 계산되지 않습니다)
혹시 "Intyrnet이 넣은 Intyrnet, intyrnet, 우리는 필요하지 않습니다. 그것은 당신의 인터넷입니다..." ???
1. Keeper는 변경 사항이 하나가 아니라 수백 개일 때 변경 사항을 롤백하기 위해 변경 가능한 내용으로 입력할 때 상태를 저장하는 데 사용되는 패턴과 디자인이 유사합니다. 예를 들어 사진 편집기, 텍스트 편집기... 작성 후 발견 - https://refactoring.guru/en/design-patterns/memento 2. 사실 주제도 모르고 비판도 하지 않는 것은 나쁜 습관입니다... 3. 이미 이해할 수 없는 것이 어떻게 더 혼란스럽고 이해하기 어렵게 될 수 있습니까? 4. 다음 자신 ...
이 와일드 마인드 게임의 의미는 어떻습니까? 패턴의 "목적"(인용 부호, 왜냐하면... 글라디올러스)은 " 캡슐화 를 위반하지 않고 객체의 내부 상태를 캡처하고 저장하는 "(인용 부호로 인해 인용 부호)입니다. 그러나 setState() 메서드는 필수 불가결합니다. 글쎄, 캡슐화의 보존은 어디에 있습니까? 각 개인 필드에 대해 두 가지 방법을 더 작성하십시오 ... 예 ... 멋진 캡슐화가 유지됩니다.
솔직히 말해서 이 접근 방식을 실제로 적용하시겠습니까? 나는 의심한다. 실제로는 이를 명시적이고 투명하게 만들 것입니다. 예를 들어, 동일한 필드 집합과 저장 및 복원을 위한 몇 가지 방법이 있는 구조입니다. 그러면 캡슐화가 실제로 유지되고 상태 저장과 복원이라는 두 가지 새로운 방법만 나타납니다.
알겠습니다. 저장하겠습니다. 작동 원리를 테스트해야 했습니다. 아마도 이것이 제가 찾던 것입니다. 테스터와 상태를 저장할 수 있는 작업 EA용 코드 하나, 테스터에서는 반대로 , "추가 제스처"에 리소스를 낭비하지 마십시오. 이러한 패턴의 일부는 #ifdef -ami가 될 수 있습니다. ;)
골키퍼와 함께 이 쓰레기의 의미를 이해하려고 노력하고 있지만 큰 이점을 보지 못합니다. 사실, 이것은 부작용 생성을 통한 프로그래밍의 나쁜 습관입니다. 한 개체를 변경하면 다른 개체도 변경됩니다. 결과적으로 코드는 혼란스럽고 이해하기 어려워집니다. 코드 순도, IMHO를 위해 노력하는 것이 좋습니다.
단순히 개체를 다른 개체에 복사한 다음 다시 복사하는 것을 방지하는 것은 무엇입니까? 본질적으로 더 정확하고 이해하기 쉬운 것뿐입니다.
싱글톤도 마찬가지입니다. 이 싱글톤에 setter와 getter가 동시에 있으면(즉, 상태를 변경하고 읽을 수 있음) 전역 변수 로 작업하는 것과 같습니다. 동시에 모든 프로그래머는 전역 상태를 변경하는 작업이 나쁘다는 것을 알고 있습니다. 그러나 어떤 이유로 싱글 톤은 계산되지 않습니다)
골키퍼와 함께 이 쓰레기의 의미를 이해하려고 노력하고 있지만 큰 이점을 보지 못합니다. 사실, 이것은 부작용 생성을 통한 프로그래밍의 나쁜 습관입니다. 한 개체를 변경하면 다른 개체도 변경됩니다. 결과적으로 코드가 혼란스럽고 이해하기 어려워집니다. 코드 순도, IMHO를 위해 노력하는 것이 좋습니다.
모든 것이 더 쉽습니다. 기술적 가능성을 연구하고 있습니다.
글쎄요, 아마도 사고 방식은 흔적을 남길 것입니다. 저는 유한 상태 기계의 위치에서 자동화된 시스템의 상태를 평가하는 데 더 익숙합니다. 예비 시스템의 상태)))
나는 유한 상태 기계의 위치에서 자동화 시스템의 상태를 평가하는 데 더 익숙하며, 이것은 항상 시스템 상태의 "캐스트"를 예비로 저장할 수 있기를 원하게 만듭니다.)))
네, 목표는 분명합니다. 내 생각에는 그러한 구현이 불필요하게 복잡하고 혼란스럽다는 것뿐입니다.
네, 목표는 분명합니다. 내 생각에는 그러한 구현이 불필요하게 복잡하고 혼란스럽다는 것뿐입니다.
아아, 이것이 사람들이 배열되는 방식입니다-내가 직접 막대기를 부수고 원뿔을 모을 때까지 올 것 같지 않습니다)))
아아, 이것이 사람들이 배열되는 방식입니다-스틱을 스스로 부수고 원뿔을 모을 때까지 올 것 같지 않습니다)))
이 패턴을 연구하는 사람에게는 아무런 문제가 없습니다. 두뇌 체조 등은 훌륭합니다. 등. 그래서 결국 자세히 들여다보면 콘솔 애플리케이션을 작성하여 비주얼 베이직을 배우는 것과 같은 일종의 지옥 같은 가짜, 빨갱이를 현실에서 멀어지게 하는 일종의 맴버임이 밝혀졌습니다.
적어도 누군가의 바퀴벌레를 연구하는 관점에서 이러한 패턴을 연구하는 것은 흥미 롭습니다.
그리고 객체의 상태를 저장하는 작업에 실제로 접근하는 경우 방법은 단순히 메서드를 통해 또는 =의 오버로드를 통해 원하는 대로 한 객체를 다른 객체로 복사하는 기능을 제공하는 것입니다. 그러면 이 가능성을 캡슐화하려는 욕구가 사라질 수 있습니다.
그리고 객체의 상태를 저장하는 작업에 실제로 접근하는 경우 방법은 단순히 메서드를 통해 또는 =의 오버로드를 통해 원하는 대로 한 객체를 다른 객체로 복사하는 기능을 제공하는 것입니다. 그러면 이 가능성을 캡슐화하려는 욕구가 사라질 수 있습니다.
실제로라면 모든 기술 시스템은 3가지 기본 원칙에 따라 설계할 수 있습니다.
- 최신 표준 준수
- 우리 할아버지들은 이런 식으로 만들었습니다. 바퀴를 재발명할 필요가 없습니다.
- 곰나와 막대기로 빠른 것을 조립한 다음 다시 해보겠습니다.
)))
농담입니다. 저는 머리 속 옵션을 읽고 뒤틀릴 시간이 있습니다. 포럼에서 이해할 수 없는 순간에 대한 설명을 빠르게 얻을 수 있을 뿐만 아니라 이것을 사용합니다.)
골키퍼와 함께 이 쓰레기의 의미를 이해하려고 노력하고 있지만 큰 이점을 보지 못합니다. 사실, 이것은 부작용 생성을 통한 프로그래밍의 나쁜 습관입니다. 한 개체를 변경하면 다른 개체도 변경됩니다. 결과적으로 코드는 혼란스럽고 이해하기 어려워집니다. 코드 순도, IMHO를 위해 노력하는 것이 좋습니다.
단순히 개체를 다른 개체에 복사한 다음 다시 복사하는 것을 방지하는 것은 무엇입니까? 본질적으로 더 정확하고 이해하기 쉬운 것뿐입니다.
싱글톤도 마찬가지입니다. 이 싱글톤에 setter와 getter가 동시에 있으면(즉, 상태를 변경하고 읽을 수 있음) 전역 변수 로 작업하는 것과 같습니다. 동시에 모든 프로그래머는 전역 상태를 변경하는 작업이 나쁘다는 것을 알고 있습니다. 그러나 어떤 이유로 싱글 톤은 계산되지 않습니다)
이것은 심각한 대규모 프로젝트와 관련이 없는 프로그래머의 전형적인 관점이라고 생각합니다. 직접적으로 죄송합니다만 기본의 기초를 나쁜 습관이라고 부르는 다른 설명은 보이지 않습니다)
이 패턴을 연구하는 사람에게는 아무런 문제가 없습니다. 두뇌 체조 등은 훌륭합니다. 등. 그래서 결국 자세히 들여다보면 콘솔 애플리케이션을 작성하여 비주얼 베이직을 배우는 것과 같은 일종의 지옥 같은 가짜, 빨갱이를 현실에서 멀어지게 하는 일종의 맴버임이 밝혀졌습니다.
적어도 누군가의 바퀴벌레를 연구하는 관점에서 이러한 패턴을 연구하는 것은 흥미 롭습니다.
그리고 실제로 객체의 상태를 저장하는 작업에 접근하는 경우 방법은 단순히 메서드를 통해 또는 =의 오버로드를 통해 원하는 대로 한 객체를 다른 객체로 복사하는 기능을 제공하는 것입니다. 그러면 이 가능성을 캡슐화하려는 욕구가 사라질 수 있습니다.
Dmitry, 아마도 이 경우 Guardian 및 Prototype 패턴의 작업과 가능한 모든 조합 및 표현을 혼동하고 있을 것입니다. 첫째, 스냅샷은 프로토타입과 달리 전체 개체를 복사할 필요가 없습니다.
그리고 예, 캡슐화의 필요성은 주로 많은 사람들이 참여하는 대규모 프로젝트 에서 나타납니다. 대부분의 지역 문제와 같은 장난감의 경우 물론 과잉)
1) 골키퍼와 함께 이 쓰레기의 의미를 이해하려고 노력하고 있지만 큰 이점을 보지 못합니다.
2) 사실, 이것은 부작용을 만들어내는 프로그래밍의 나쁜 습관입니다.
3) 하나의 개체를 변경할 때 다른 개체를 변경합니다. 결과적으로 코드는 혼란스럽고 이해하기 어려워집니다. 코드 순도, IMHO를 위해 노력하는 것이 좋습니다.
4) 단순히 객체를 다른 객체에 복사한 다음 다시 복사하는 것을 방지하는 것은 무엇입니까? 본질적으로 더 정확하고 이해하기 쉬운 것뿐입니다.
싱글톤도 마찬가지입니다. 이 싱글톤에 setter와 getter가 동시에 있으면(즉, 상태를 변경하고 읽을 수 있음) 전역 변수 로 작업하는 것과 같습니다. 동시에 모든 프로그래머는 전역 상태를 변경하는 작업이 나쁘다는 것을 알고 있습니다. 그러나 어떤 이유로 싱글 톤은 계산되지 않습니다)
혹시 "Intyrnet이 넣은 Intyrnet, intyrnet, 우리는 필요하지 않습니다. 그것은 당신의 인터넷입니다..." ???
1. Keeper는 변경 사항이 하나가 아니라 수백 개일 때 변경 사항을 롤백하기 위해 변경 가능한 내용으로 입력할 때 상태를 저장하는 데 사용되는 패턴과 디자인이 유사합니다. 예를 들어 사진 편집기, 텍스트 편집기...
작성 후 발견 - https://refactoring.guru/en/design-patterns/memento
2. 사실 주제도 모르고 비판도 하지 않는 것은 나쁜 습관입니다...
3. 이미 이해할 수 없는 것이 어떻게 더 혼란스럽고 이해하기 어렵게 될 수 있습니까?
4. 다음 자신 ...