여기에 모든 것이 명확하고 구체적이며 규범에 따릅니다. 책이 있습니다! 이 책은 이러한 패턴을 간략하게 설명합니다. 실제로 패턴과 대화에 관한 것입니다. 그 책의 이름은 "디자인 패턴" 또는 이와 유사한 것입니다. 그러나 책뿐만 아니라 인터넷과 Wikipedia에도 관련 사이트가 많이 있습니다. 가장 중요한 것은 주제가 정식화되어 있다는 것입니다)) ... 그리고 패턴을 더듬지 않는 사람은 평민이고 누구든지 그것들을 마스터한 것은 삶 자체를 마스터한 것입니다! 아멘!
여기에 있는 모든 것은 명확하고 구체적이며 규범에 따릅니다. 책이 있습니다! 이 책은 이러한 패턴을 간략하게 설명합니다. 실제로 패턴과 대화에 관한 것입니다. 그 책의 이름은 "디자인 패턴" 또는 이와 유사한 것입니다. 그러나 책뿐만 아니라 인터넷과 심지어 Wikipedia에도 이에 대한 많은 사이트가 있습니다. 가장 중요한 것은 주제가 정식화되었다는 것입니다))
모든 것이 정상입니다. 전역 변수 가 100개까지 있으면 함수 없이도 할 수 있습니다. 어드바이저가 50개 이상 있으면 클래스가 적절하고 개발자가 20명 이상, 메서드가 20개 이상인 경우 올바르게 이해합니다. 변수의 수를 알 수 없는 경우 패턴이 필요합니다. 개발자가 한 명뿐이라면 필요한 경우 많지 않습니까?
모든 것이 정상입니다. 전역 변수 가 100개까지 있으면 함수 없이도 할 수 있습니다. 어드바이저가 50개 이상 있으면 클래스가 적절하고 개발자가 20명 이상, 메서드가 20개 이상인 경우 올바르게 이해합니다. 변수의 수를 알 수 없는 경우 패턴이 필요합니다. 개발자가 한 명뿐이라면 필요한 경우 많지 않습니까?
뭐야"? 나는 OOP를 좋아한다. 그러나 이러한 악명 높은 패턴은 실제 OOP와 다소 거리가 있습니다.
여기서 다시 한 번 반복합니다. 아무도 패턴을 위해 기도하지 않습니다. 이들은 빌드할 템플릿일 뿐입니다.
그러나 그들이 OOP와 관련이 없다고 말하는 것은 사실이 아닙니다.
내 겸손한 경험에서 - 순수한 책 형태에서는 드문 예외를 제외하고는 거의 사용되지 않습니다. 일반적으로 패턴에 맞는 작업이 있으면 다른 패턴에 대해 최소한 몇 가지 다른 작업과 함께 진행됩니다. 여기에 2-3-10+ 패턴을 교차하는 방법이 있습니다. 이것은 이미 두뇌에 대한 작업입니다. 프로그래머/건축가.
당신은 세부 사항에 갇혀 있습니다. 관심이 없다. 여기에서 "키퍼" 패턴에 대한 논의의 요점은 일종의 캡슐화를 유지한다고 약속하지만 각 필드에 대해 한 쌍의 공개 메서드를 만들어 구현한다는 것입니다. 가장 중요한 메시지를 받지 못한 것이 웃기네요.
나는 막힌 것이 아니라 대화 상대인 당신을 존중하기 위해 당신의 말에서 의미를 찾고 자기 모순을 풀기 위해 노력하고 있습니다. 분명히 헛된 것입니다.
"거룩한 패턴"에 대한 당신의 거품은 여기 있는 누구에게도 관심이 없습니다.
여기에 모든 것이 명확하고 구체적이며 규범에 따릅니다. 책이 있습니다! 이 책은 이러한 패턴을 간략하게 설명합니다. 실제로 패턴과 대화에 관한 것입니다. 그 책의 이름은 "디자인 패턴" 또는 이와 유사한 것입니다. 그러나 책뿐만 아니라 인터넷과 Wikipedia에도 관련 사이트가 많이 있습니다. 가장 중요한 것은 주제가 정식화되어 있다는 것입니다)) ... 그리고 패턴을 더듬지 않는 사람은 평민이고 누구든지 그것들을 마스터한 것은 삶 자체를 마스터한 것입니다! 아멘!
당신은 광대 같은 아아. 너무 역겹다면 OOP 스레드를 남겨 두십시오)
여기에 있는 모든 것은 명확하고 구체적이며 규범에 따릅니다. 책이 있습니다! 이 책은 이러한 패턴을 간략하게 설명합니다. 실제로 패턴과 대화에 관한 것입니다. 그 책의 이름은 "디자인 패턴" 또는 이와 유사한 것입니다. 그러나 책뿐만 아니라 인터넷과 심지어 Wikipedia에도 이에 대한 많은 사이트가 있습니다. 가장 중요한 것은 주제가 정식화되었다는 것입니다))
모든 것이 정상입니다. 전역 변수 가 100개까지 있으면 함수 없이도 할 수 있습니다. 어드바이저가 50개 이상 있으면 클래스가 적절하고 개발자가 20명 이상, 메서드가 20개 이상인 경우 올바르게 이해합니다. 변수의 수를 알 수 없는 경우 패턴이 필요합니다. 개발자가 한 명뿐이라면 필요한 경우 많지 않습니까?
나는 막힌 것이 아니라 대화 상대인 당신을 존중하기 위해 당신의 말에서 의미를 찾고 자기 모순을 풀기 위해 노력하고 있습니다. 분명히 헛된 것입니다.
"거룩한 패턴"에 대한 당신의 거품은 여기 있는 누구에게도 관심이 없습니다.
나는 모순이 없습니다. 당신의 패턴에 모순이 있습니다. 나는 이미 그것에 대해 두 번 썼습니다. 나는 당신에게 상기시킵니다: "키퍼" 패턴은 캡슐화를 보존할 것을 약속하고 각 개인 필드에 대해 두 개의 공개 메소드를 생성하여 구현됩니다.
그리고 말해봐, 너는 내 어디에서 모순을 보았니?
모든 것이 정상입니다. 전역 변수 가 100개까지 있으면 함수 없이도 할 수 있습니다. 어드바이저가 50개 이상 있으면 클래스가 적절하고 개발자가 20명 이상, 메서드가 20개 이상인 경우 올바르게 이해합니다. 변수의 수를 알 수 없는 경우 패턴이 필요합니다. 개발자가 한 명뿐이라면 필요한 경우 많지 않습니까?
우선 개발자에게는 두뇌가 필요합니다.
당신은 광대 같은 아아. 너무 역겹다면 OOP 스레드를 남겨 두십시오)
뭐야"? 나는 OOP를 좋아한다. 그러나 이러한 악명 높은 패턴은 실제 OOP와 다소 거리가 있습니다.
나는 모순이 없습니다. 패턴에 모순이 있습니다. 이미 두 번 썼습니다. "키퍼" 패턴 은 캡슐화를 보존할 것을 약속하고 각 개인 필드에 대해 두 개의 공개 메서드를 생성하여 구현됩니다.
지금은 이해. 말의 의미를 상실한 모든 패턴에 감정을 쏟아부었다.
그러나 Snapshot은 Snapshot에 중첩 클래스를 사용하여 이 문제를 해결합니다.
이것이 언어에서 지원되지 않는다면 단점이 있다는 점에는 동의하지만, 참고로 목발 트릭으로 해결할 수 있습니다.
지금은 이해. 말의 의미를 상실한 모든 패턴에 감정을 쏟아부었다.
그러나 Snapshot은 Snapshot에 중첩 클래스를 사용하여 이 문제를 해결합니다.
이것이 언어에서 지원되지 않는다면 단점이 있다는 점에는 동의하지만, 참고로 목발 트릭으로 해결할 수 있습니다.
예, 당신은 아무것도 이해하지 못했습니다.
중첩 클래스를 작성하는 기능의 유무는 중요하지 않으며 차이가 크지 않습니다. 이 항목에는 비공개 필드에 중첩된 클래스와 두 개의 공개 메서드가 있는 코드 예제가 있습니다.
뭐야"? 나는 OOP를 좋아한다. 그러나 이러한 악명 높은 패턴은 실제 OOP와 다소 거리가 있습니다.
여기서 다시 한 번 반복합니다. 아무도 패턴을 위해 기도하지 않습니다. 이들은 빌드할 템플릿일 뿐입니다.
그러나 그들이 OOP와 관련이 없다고 말하는 것은 사실이 아닙니다.
내 겸손한 경험에서 - 순수한 책 형태에서는 드문 예외를 제외하고는 거의 사용되지 않습니다. 일반적으로 패턴에 맞는 작업이 있으면 다른 패턴에 대해 최소한 몇 가지 다른 작업과 함께 진행됩니다. 여기에 2-3-10+ 패턴을 교차하는 방법이 있습니다. 이것은 이미 두뇌에 대한 작업입니다. 프로그래머/건축가.
예, 당신은 아무것도 이해하지 못했습니다.
중첩 클래스를 작성하는 기능의 유무는 중요하지 않으며 차이가 크지 않습니다. 이 항목에는 비공개 필드에 중첩된 클래스와 두 개의 공개 메서드가 있는 코드 예제가 있습니다.
당신은 이미 내가 바보이고 아무것도 이해하지 못한다고, 오랫동안 당신에게 정당한 섹스를 보내지 않은 내 인내심이 자랑 스럽습니다.
사실, 중첩된 클래스는 비공개 필드에 대한 공개 메서드를 선택 사항으로 만듭니다. 이는 정확히 당신이 말하는 캡슐화 위반입니다. 다른 주장은 무엇입니까?