학습에 관한 것이 아닙니다. TSB 31권의 모든 행을 알 필요는 없습니다. 그러나 당신은 당신이 필요로하는 것을 열고 당신이 관심을 갖는 것을 찾을 수 있습니다. 그리고 필요한 곳에 사용하세요.
이전에 다른 사람이 축적한 지식을 사용할 수 있습니다(일대일 코드 줄이 아니라 이전에 누군가가 말한 최적의 논리). 자신만의 자전거를 발명하여 자신만의 먼 길을 갈 수 있습니다. 그리고 당신은 또한 똑똑한 책을 읽을 수 있으며 거기에 명시된 가정을 엄격히 준수하지 않고는 한 발짝도 내딛을 수 없습니다. 그러나 이것은 지지자에 관한 것입니다.
학습에 관한 것이 아닙니다. TSB 31권의 모든 행을 알 필요는 없습니다. 그러나 당신은 당신이 필요로하는 것을 열고 당신이 관심을 갖는 것을 찾을 수 있습니다. 그리고 필요한 곳에 사용하세요.
이전에 다른 사람이 축적한 지식을 사용할 수 있습니다(일대일 코드 줄이 아니라 이전에 누군가가 말한 최적의 논리). 자신만의 자전거를 발명하여 자신만의 먼 길을 갈 수 있습니다. 그리고 당신은 또한 똑똑한 책을 읽을 수 있으며 거기에 명시된 가정을 엄격히 준수하지 않고는 한 발짝도 내딛을 수 없습니다. 그러나 이것은 숙련자에 관한 것입니다.
이러한 패턴을 백과사전과 비유하는 것은 완전히 부적절하며 실제가 아닙니다. 이러한 패턴과 관련하여 빈 헛간과 비문으로 잘 알려진 비유가 더 적절합니다.
"디자인 패턴"은 같은 공통적인 것을 같은 이름으로 부르는 배열일 뿐입니다. 그건 그렇고,이 용어는 아키텍처 (조각 / 다리 / 현관 / 포털에 관한 것)에서 왔습니다.
때론 비슷한 일들이 비슷한 방법으로 풀린다, 그게 항상 사실은 아니다.. 하지만 사물과 방법의 유사점에 대해 동의를 하면 서로를 이해하는 데 도움이 된다.
그러나 물론 사람들은 "바보에게 유리 남근을 주면 그 물건이 깨지고 자릅니다"
예, 변수에 값을 할당하는 것을 이제 Keeper 또는 Snapshot(변수의 수에 따라 다름)이라고 하며 코드의 일부를 함수로 가져오고 참조로 값을 반환하는 것을 이제 Factory라고 합니다. 에.
이러한 패턴은 OOP의 실제 사용 과 관련이 없으며 OOP에서 사용되는 실제 패턴과 관련이 없습니다.
배운 단어는 무엇을 의미합니까?
여러 포럼에서 설명을 읽으면 약 12개 정도는 확실합니다.
MQL에 적용되는 경우 하나는 전략입니다.
나는 공부했습니다. 읽기만 하는 것이 아니라 이해하기도 하고, 나 자신을 위한 훈련 예를 썼습니다.
그리고 이 "전략" 패턴을 어떻게 적용했습니까? 어딘가에서 그것에 대해 읽고 연구하고 적용한 적이 있습니까? 아니면 뭔가를 쓰고, 쓰고, 보고 나서, 보라, 내가 "전략" 패턴을 적용했다는 것이 밝혀졌다?
예, 변수에 값을 할당하는 것을 이제 Keeper 또는 Snapshot이라고 하며(변수의 수에 따라) 참조로 값을 반환하는 것을 이제 Factory 라고 합니다 .
이러한 패턴은 OOP의 실제 사용 과 관련이 없으며 OOP에서 사용되는 실제 패턴과 관련이 없습니다.
글쎄, 어딘가에서 그을린 코냑을 집어 든 것은 당신이었습니다 ..
아무것도 포함되어 있지 않습니다. 얼마나 많은 패턴을 배웠습니까?
학습에 관한 것이 아닙니다. TSB 31권의 모든 행을 알 필요는 없습니다. 그러나 당신은 당신이 필요로하는 것을 열고 당신이 관심을 갖는 것을 찾을 수 있습니다. 그리고 필요한 곳에 사용하세요.
이전에 다른 사람이 축적한 지식을 사용할 수 있습니다(일대일 코드 줄이 아니라 이전에 누군가가 말한 최적의 논리). 자신만의 자전거를 발명하여 자신만의 먼 길을 갈 수 있습니다. 그리고 당신은 또한 똑똑한 책을 읽을 수 있으며 거기에 명시된 가정을 엄격히 준수하지 않고는 한 발짝도 내딛을 수 없습니다. 그러나 이것은 지지자에 관한 것입니다.
나는 공부했습니다. 읽기만 하는 것이 아니라 이해하기도 하고, 나 자신을 위한 훈련 예를 썼습니다.
아니면 뭔가를 쓰고, 쓰고, 보고 나서, 보라, 내가 "전략" 패턴을 적용했다는 것이 밝혀졌다?
정반대, 처음에는 기적이있었습니다 - 내 코드 구조, 그런 다음 패턴을 연구하고 패턴에 따라 기적을 처음부터 완전히 다시 작성했습니다 - 추가 사용의 편리함을 얻었습니다
학습에 관한 것이 아닙니다. TSB 31권의 모든 행을 알 필요는 없습니다. 그러나 당신은 당신이 필요로하는 것을 열고 당신이 관심을 갖는 것을 찾을 수 있습니다. 그리고 필요한 곳에 사용하세요.
이전에 다른 사람이 축적한 지식을 사용할 수 있습니다(일대일 코드 줄이 아니라 이전에 누군가가 말한 최적의 논리). 자신만의 자전거를 발명하여 자신만의 먼 길을 갈 수 있습니다. 그리고 당신은 또한 똑똑한 책을 읽을 수 있으며 거기에 명시된 가정을 엄격히 준수하지 않고는 한 발짝도 내딛을 수 없습니다. 그러나 이것은 숙련자에 관한 것입니다.
이러한 패턴을 백과사전과 비유하는 것은 완전히 부적절하며 실제가 아닙니다. 이러한 패턴과 관련하여 빈 헛간과 비문으로 잘 알려진 비유가 더 적절합니다.
글쎄, 어디선가 그을린 코냑을 집어든 건 너였어..
예, 바로 이 스레드에서 몇 페이지 전입니다.
얼마나 많은 패턴을 배웠습니까?
정반대, 처음에는 기적이있었습니다 - 내 코드 구조, 그런 다음 패턴을 연구하고 패턴에 따라 기적을 처음부터 완전히 다시 작성했습니다 - 추가 사용의 편리함을 얻었습니다
조각 20-30, 완료 - 한숨. 그러다가 인터넷 뒤지다가 20장을 더 찾았는데 공부를 시작도 하지 않고 바로 한숨을 쉬었습니다.
얼마나 많은 패턴을 배웠습니까?
정반대, 처음에는 기적이있었습니다 - 내 코드 구조 , 그런 다음 패턴을 연구하고 패턴에 따라 기적을 처음부터 완전히 다시 작성했습니다 - 추가 사용의 편리함을 얻었습니다
항상 반대 논제가 있습니다. 받은 기적을 개선할 필요가 있었습니까?
프로그래밍을 위한 프로그래밍이 완전히 발생하고 동일한 계란을 받았지만 전면적으로
항상 반대 논제가 있습니다. 받은 기적을 개선할 필요가 있었습니까?
프로그래밍을 위한 프로그래밍이 완전히 발생하고 동일한 계란을 받았지만 전면적으로
그래 그럴 가치가 있었다
OOP가 절차적 프로그래밍에 대한 래퍼라는 강력한 의견이 있습니다. 실제로 포럼 참가자의 99%가 하고 있습니다.
그리고 OOP를 사용하면 디자인 단계에서 코드의 추가 구조를 설정할 수 있다는 1%의 의견이 있습니다. 나는 여전히 이 사실을 확인하고 있습니다.
그리고 전면과 프로필을 작성하십시오 .... 음, MACD 샘플을 최적화하는 것은 흥미롭지 않습니다.))))
조각 20-30, 완료 - 한숨. 그러다 인터넷 뒤지다가 20개 더 찾았는데 더 이상 공부하지 않고 바로 한숨을 쉬었다.
20~30? 일이 많아 IMHO 과제가 너무 많아
20-30 패턴을 적용했을 가능성이 있지만 음 ... 사무라이 검의 이름은 무엇입니까? - 하나는 생선 자르기, 다른 하나는 하라키리용, 점심으로 같은 칼로 생선을 청소하고 소시지를 자르셨나요? - 이건 선생님이 아닙니다!
)))