"Lie on public display"가 아니라 창의 요소만 창 클래스 내부에 캡슐화해야 합니다. 아무도 실수로 "잘못된 곳"에 들어가는 일이 없도록 하기 위해서입니다. 하나의 변수를 변경하여 거대한 전역 배열 안에 잘못 배치하는 것은 쉽습니다. 원하는 인터페이스를 요청한 다음 필요한 객체에서 동일한 변수를 변경하면서 동시에 실수를 하는 것은 훨씬 더 어렵습니다.
아아, 예외. 전역 커널은 전역 가시성을 가정하므로 필요하지 않습니다.
(1) 코드 캡슐화에서. 모든 것이 어디에서나 사용 가능하다면 왜?
(2) 함수 오버로딩 . 하나에서 작업을 수행하는 것이 더 쉽고 결과를 어디에서나 볼 수 있고 액세스할 수 있도록 하는 이유는 무엇입니까?
(3) 다형성. 하나의 블록이 이러한 템플릿 변형의 작업을 수행할 수 있다면 왜 하나의 템플릿 아래에 다른 구현을 숨길까요? 코드의 양이 줄어들고 구문이 훨씬 간단해집니다.
OOP의 요점은 다음과 같습니다.
1. 인간의 기억을 언로드. (불량 언로드. 구문이 너무 많습니다.)
2. 팀 내 공통 작업 분배(모든 사람이 코드 조각을 알고 있으므로 어셈블리 및 디버깅 문제가 있음).
(2) 함수 오버로딩 . 하나에서 작업을 수행하는 것이 더 쉽고 결과를 어디에서나 볼 수 있고 액세스할 수 있도록 하는 이유는 무엇입니까?
(3) 다형성. 하나의 블록이 이러한 템플릿 변형의 작업을 수행할 수 있다면 왜 하나의 템플릿 아래에 다른 구현을 숨길까요? 코드의 양이 줄어들고 구문이 훨씬 간단해집니다.
OOP의 요점은 다음과 같습니다.
1. 인간의 기억을 언로드. (불량 언로드. 구문이 너무 많습니다.)
2. 팀 내 공통 작업 분배(모든 사람이 코드 조각을 알고 있으므로 어셈블리 및 디버깅 문제가 있음).
3. 코드 이식성. (이것은 정말 플러스입니다).
4. 마케팅. 각종 로션 광고를 통한 개발환경, 라이브러리 배포 및 판매.
당신은 누구이며 무엇을 증명하고 싶습니까? 그 OOP는 나쁜데 한곳에 다 모이면 좋은거야? 그것이 당신이 이 스레드를 만든 전부입니까? 아니면 슈퍼 메모리에 대한 칭찬으로 자존심을 다시 즐겁게 하시겠습니까? 나에게 당신의 분신처럼 들립니다. 그리고 더 이상. 또한 지점은 실용적인 의미를 잃습니다. 초점은 "내가 무엇인지"라는 제목이 될 수 있습니다. 혜택은 없습니다.
그들이 당신에게 대답하는 모든 것, 당신은 즉시 질문하고 당신이 누구인지, 모든 것이 당신과 함께 있고, 모든 것이 얼마나 좋고 더 나은지, 온 세상이 바보이며, 가르칠 수없는 것에 내재 된 다른 것들, 인간에게 가장 잘 나타난 허무주의.
당신은 누구이며 무엇을 증명하고 싶습니까? 그 OOP는 나쁜데 한곳에 다 모이면 좋은거야? 그것이 당신이 이 스레드를 만든 전부입니까? 아니면 슈퍼 메모리에 대한 칭찬으로 자존심을 다시 즐겁게 하시겠습니까? 나에게 당신의 분신처럼 들립니다. 그리고 더 이상. 또한 지점은 실용적인 의미를 잃습니다. 초점은 "내가 무엇인지"라는 제목이 될 수 있습니다. 혜택은 없습니다.
그들이 당신에게 대답하는 모든 것, 당신은 즉시 질문하고, 당신이 누구인지, 모든 것이 당신과 함께하는 방법, 모든 것이 얼마나 좋고 더 나은지, 그리고 온 세상이 바보 이며, 가르칠 수없는 것에 내재 된 다른 것들, 인간에게 가장 잘 나타난 허무주의.
당신은 다시 오래된 것입니까?)) 나는 이미 당신이 내 가지에서 트롤링을 중단했다고 생각했습니다. 당신은 도울 수 없지만 개인을 얻을 수 있습니다. 글쎄, 안돼 ...))
개인이 되면 그 사건에 대해 할 말이 없다는 뜻입니다. 분명히, 주장은 철근 콘크리트입니다.
(2) 함수 오버로딩 . 하나에서 작업을 수행하는 것이 더 쉽고 결과를 어디에서나 볼 수 있고 액세스할 수 있도록 하는 이유는 무엇입니까?
(3) 다형성. 하나의 블록이 이러한 템플릿 변형의 작업을 수행할 수 있다면 왜 하나의 템플릿 아래에 다른 구현을 숨길까요? 코드의 양이 줄어들고 구문이 훨씬 간단해집니다.
OOP의 요점은 다음과 같습니다.
1. 인간의 기억을 언로드. (불량 언로드. 구문이 너무 많습니다.)
2. 팀 내 공통 작업 분배(모든 사람이 코드 조각을 알고 있으므로 어셈블리 및 디버깅 문제가 있음).
3. 코드 이식성. (이것은 정말 플러스입니다).
4. 마케팅. 각종 로션 광고를 통한 개발환경, 라이브러리 배포 및 판매.
그래서 이것들은 다른 것입니다.
모든 Expert Advisor(동일한 리그)에는 전역 범위의 개체가 있습니다.
핵심은 결과적으로 getters-setter와 같은 많은 기능을 갖춘 클래스로 표시될 수 있지만 이는 "OOP"이지만 전역 액세스가 가능합니다. 물론 OOP의 주요 장점은 없지만 캡슐화, 상속 및 다형성.
OOP가 무엇을 기반으로 하는지에 관해서는 - 첫 번째는 메모리를 언로드(그리고 아주 잘 언로드)할 뿐만 아니라 코드 지원 및 수정을 언로드함으로써 보완되어야 합니다. 게다가 개발의 재사용으로 인해 OOP 디자인에서 OOP가 없는 것보다 훨씬 사용하기 쉽습니다. 그건 그렇고, "4 - 마케팅"은 이 훨씬 더 쉬운 사용의 결과일 뿐입니다.
가상 함수 는 기본 클래스에 작성된 일종의 함수 템플릿입니다. 상속인 클래스에서만 특정 구현을 획득합니다. 수업은 가상일 수도 있습니다. 가상 기능을 포함하는 가상 클래스를 "인터페이스"라고 합니다. 함께 그들은 주요 OOP 메커니즘 중 하나인 다형성을 구현합니다.
실제로는 어디에 넣어야할지 모르겠는데...
왜 그래?
글로벌 코어와 OOP는 전혀 상호 배타적이지 않습니다.
"Lie on public display"가 아니라 창의 요소만 창 클래스 내부에 캡슐화해야 합니다. 아무도 실수로 "잘못된 곳"에 들어가는 일이 없도록 하기 위해서입니다. 하나의 변수를 변경하여 거대한 전역 배열 안에 잘못 배치하는 것은 쉽습니다. 원하는 인터페이스를 요청한 다음 필요한 객체에서 동일한 변수를 변경하면서 동시에 실수를 하는 것은 훨씬 더 어렵습니다.
아아, 예외. 전역 커널은 전역 가시성을 가정하므로 필요하지 않습니다.
(1) 코드 캡슐화에서. 모든 것이 어디에서나 사용 가능하다면 왜?
(2) 함수 오버로딩 . 하나에서 작업을 수행하는 것이 더 쉽고 결과를 어디에서나 볼 수 있고 액세스할 수 있도록 하는 이유는 무엇입니까?
(3) 다형성. 하나의 블록이 이러한 템플릿 변형의 작업을 수행할 수 있다면 왜 하나의 템플릿 아래에 다른 구현을 숨길까요? 코드의 양이 줄어들고 구문이 훨씬 간단해집니다.
OOP의 요점은 다음과 같습니다.
1. 인간의 기억을 언로드. (불량 언로드. 구문이 너무 많습니다.)
2. 팀 내 공통 작업 분배(모든 사람이 코드 조각을 알고 있으므로 어셈블리 및 디버깅 문제가 있음).
3. 코드 이식성. (이것은 정말 플러스입니다).
4. 마케팅. 각종 로션 광고를 통한 개발환경, 라이브러리 배포 및 판매.
아아, 예외. 글로벌 커널은 글로벌 가시성을 제공하므로 필요하지 않습니다.
(1) 코드 캡슐화에서. 모든 것이 어디에서나 사용 가능하다면 왜?
(2) 함수 오버로딩 . 하나에서 작업을 수행하는 것이 더 쉽고 결과를 어디에서나 볼 수 있고 액세스할 수 있도록 하는 이유는 무엇입니까?
(3) 다형성. 하나의 블록이 이러한 템플릿 변형의 작업을 수행할 수 있다면 왜 하나의 템플릿 아래에 다른 구현을 숨길까요? 코드의 양이 줄어들고 구문이 훨씬 간단해집니다.
OOP의 요점은 다음과 같습니다.
1. 인간의 기억을 언로드. (불량 언로드. 구문이 너무 많습니다.)
2. 팀 내 공통 작업 분배(모든 사람이 코드 조각을 알고 있으므로 어셈블리 및 디버깅 문제가 있음).
3. 코드 이식성. (이것은 정말 플러스입니다).
4. 마케팅. 각종 로션 광고를 통한 개발환경, 라이브러리 배포 및 판매.
당신은 누구이며 무엇을 증명하고 싶습니까? 그 OOP는 나쁜데 한곳에 다 모이면 좋은거야? 그것이 당신이 이 스레드를 만든 전부입니까? 아니면 슈퍼 메모리에 대한 칭찬으로 자존심을 다시 즐겁게 하시겠습니까? 나에게 당신의 분신처럼 들립니다. 그리고 더 이상.
또한 지점은 실용적인 의미를 잃습니다. 초점은 "내가 무엇인지"라는 제목이 될 수 있습니다. 혜택은 없습니다.
그들이 당신에게 대답하는 모든 것, 당신은 즉시 질문하고 당신이 누구인지, 모든 것이 당신과 함께 있고, 모든 것이 얼마나 좋고 더 나은지, 온 세상이 바보이며, 가르칠 수없는 것에 내재 된 다른 것들, 인간에게 가장 잘 나타난 허무주의.
당신은 누구이며 무엇을 증명하고 싶습니까? 그 OOP는 나쁜데 한곳에 다 모이면 좋은거야? 그것이 당신이 이 스레드를 만든 전부입니까? 아니면 슈퍼 메모리에 대한 칭찬으로 자존심을 다시 즐겁게 하시겠습니까? 나에게 당신의 분신처럼 들립니다. 그리고 더 이상.
또한 지점은 실용적인 의미를 잃습니다. 초점은 "내가 무엇인지"라는 제목이 될 수 있습니다. 혜택은 없습니다.
그들이 당신에게 대답하는 모든 것, 당신은 즉시 질문하고, 당신이 누구인지, 모든 것이 당신과 함께하는 방법, 모든 것이 얼마나 좋고 더 나은지, 그리고 온 세상이 바보 이며, 가르칠 수없는 것에 내재 된 다른 것들, 인간에게 가장 잘 나타난 허무주의.
당신은 다시 오래된 것입니까?)) 나는 이미 당신이 내 가지에서 트롤링을 중단했다고 생각했습니다. 당신은 도울 수 없지만 개인을 얻을 수 있습니다. 글쎄, 안돼 ...))
개인이 되면 그 사건에 대해 할 말이 없다는 뜻입니다. 분명히, 주장은 철근 콘크리트입니다.OOP에 대한 주장은 간단합니다. 사람들이 OOP를 필요로 한다는 것입니다.
이것으로 주제를 끝낼 수 있습니다.
아아, 예외. 전역 커널은 전역 가시성을 가정하므로 필요하지 않습니다.
(1) 코드 캡슐화에서. 모든 것이 어디에서나 사용 가능하다면 왜?
(2) 함수 오버로딩 . 하나에서 작업을 수행하는 것이 더 쉽고 결과를 어디에서나 볼 수 있고 액세스할 수 있도록 하는 이유는 무엇입니까?
(3) 다형성. 하나의 블록이 이러한 템플릿 변형의 작업을 수행할 수 있다면 왜 하나의 템플릿 아래에 다른 구현을 숨길까요? 코드의 양이 줄어들고 구문이 훨씬 간단해집니다.
OOP의 요점은 다음과 같습니다.
1. 인간의 기억을 언로드. (불량 언로드. 구문이 너무 많습니다.)
2. 팀 내 공통 작업 분배(모든 사람이 코드 조각을 알고 있으므로 어셈블리 및 디버깅 문제가 있음).
3. 코드 이식성. (이것은 정말 플러스입니다).
4. 마케팅. 각종 로션 광고를 통한 개발환경, 라이브러리 배포 및 판매.
그래서 이것들은 다른 것입니다.
모든 Expert Advisor(동일한 리그)에는 전역 범위의 개체가 있습니다.
핵심은 결과적으로 getters-setter와 같은 많은 기능을 갖춘 클래스로 표시될 수 있지만 이는 "OOP"이지만 전역 액세스가 가능합니다. 물론 OOP의 주요 장점은 없지만 캡슐화, 상속 및 다형성.
OOP가 무엇을 기반으로 하는지에 관해서는 - 첫 번째는 메모리를 언로드(그리고 아주 잘 언로드)할 뿐만 아니라 코드 지원 및 수정을 언로드함으로써 보완되어야 합니다. 게다가 개발의 재사용으로 인해 OOP 디자인에서 OOP가 없는 것보다 훨씬 사용하기 쉽습니다. 그건 그렇고, "4 - 마케팅"은 이 훨씬 더 쉬운 사용의 결과일 뿐입니다.
그들이 당신에게 대답하는 모든 것, 당신은 즉시 질문하고 당신이 누구인지, 모든 것이 당신과 함께 있고, 모든 것이 얼마나 좋고 더 나은지, 온 세상이 바보이며, 가르칠 수없는 것에 내재 된 다른 것들, 인간에게 가장 잘 나타난 허무주의.
아르템, 피터의 기억이 부럽다...
결국 베드로가 몇 가지 실질적인 발전을 제공하려고 노력했다는 사실은 말할 것도 없습니다.
유익하지만 은유에서 topicstarter OOP 패턴으로 읽기에는 적합하지 않습니다.
순전히 주제 주제 콘텐츠: 안티 패턴이란 무엇입니까?
유익하지만 은유에서 topicstarter OOP 패턴으로 읽기에는 적합하지 않습니다.
순전히 주제 주제 콘텐츠: 안티 패턴이란 무엇입니까?
가상 함수 는 기본 클래스에 작성된 일종의 함수 템플릿입니다. 상속인 클래스에서만 특정 구현을 획득합니다. 수업은 가상일 수도 있습니다. 가상 기능을 포함하는 가상 클래스를 "인터페이스"라고 합니다. 함께 그들은 주요 OOP 메커니즘 중 하나인 다형성을 구현합니다.
실제로는 어디에 넣어야할지 모르겠는데...
가상 함수는 파생 클래스에서 재정의할 수 있는 함수입니다. 어떤 맥락에서든 패턴이 다릅니다.
구체적인 구현은 기본 클래스에 있을 수 있습니다. 또는 그렇지 않음(함수가 순전히 가상인 경우)
클래스는 가상일 수 없으며 추상화될 수 있습니다. 가상 상속이 있지만 이것으로 머리를 망치질 할 필요가 전혀 없습니다.
인터페이스(인터페이스)는 대략적으로 말하면 순수 가상 기능만 있는 추상 클래스입니다.
가상 기능은 다형성(동적 다형성)의 일부일 뿐입니다. 오버로딩 및 템플릿은 정적입니다.
당신은 그것을 어디에나 넣을 수 있습니다, 당신은 당신의 평면적 사고를 통해 그것을 모두 전달할 수 있습니다