당신이 몇 페이지 앞서 함수 포인터를 언급했다면 그렇지 않습니까? 이것은 다형성의 유사점이 아니며 동적으로 변경할 수 있기 때문에 훨씬 더 많은 기회가 있습니다.
어제는 야당에 대해 더 나은 의견을 갖고 있었습니다. 함수 포인터는 최근 MQL에 등장했지만, 오늘날 모든 토론자들에게 마치 존재하지 않는 것처럼 똑같다는 것이 밝혀졌습니다. 그들이 무엇에 대해 논쟁하는지 이해하지 못하는 것으로 나타났습니다. 확실히 " 다형성 "과 "포인터"라는 단어는 눈과 귀를 놓쳤습니다. 그들은 여기에서 1000건의 증거를 받았음에도 불구하고 "당신은 증거를 제공하지 않았습니다"라는 하나의 주장을 가지고 있습니다.
클래스에 대한 포인터도 동적으로 변경할 수 있으며, 함수를 사용하면 미리 생성할 필요가 없기 때문에 더 쉽습니다.
결정의 효율성이란 결정의 품질을 의미하며, 여기서 메커니즘(및 프로그램은 의심할 여지 없이 메커니즘)이 가장 안정적으로 작동합니다. 메커니즘은 명확하고 일관성 있고 생산적이어야 합니다. 메커니즘의 기능은 할당된 모든 작업을 구현해야 합니다. 메커니즘은 불필요한 것을 허용하지 않으며이 메커니즘의 개발에서 불필요한 것은 차단해야합니다.
귀하의 경우에만이 "불필요한"은 실수로 프로그래밍 오류로부터 코드를 보호하도록 설계된 유형 제어 및 기타 기본 사항입니다. 따라서 코드를 매우 신뢰할 수 없게 됩니다. 안정성은 말할 필요도 없습니다. 이제 디버깅하고 핥았지만 후속 수정으로 정렬하기 매우 어려운 미묘한 오류가 나타날 것이라고 가정합니다.
OOP에는 개발자가 사용할 수 있는 추가 도구가 많이 포함되어 있다는 사실은 부인할 수 없습니다. 그러나 이러한 도구를 사용하기 위해 지불해야 하는 비용을 이해해야 합니다. 즉, OOP 패러다임과 이에 상응 하는 코드 구조에 대한 완전한 몰입입니다. 전체 OOP 툴킷을 사용하고 많은 개체를 생성합니다. 주요 가격 - 코드의 날카로운 복잡성. 그러나 실습은 생성된 메커니즘의 효율성 관점에서 볼 때 단순해야 하며 그 안에 있는 엔터티의 존재는 효율성을 높이고 그 이상은 하지 않음으로써 절대적으로 정당화되어야 함을 보여줍니다.
귀하의 경우에만이 "불필요한"은 실수로 프로그래밍 오류로부터 코드를 보호하도록 설계된 유형 제어 및 기타 기본 사항입니다. 따라서 코드를 매우 신뢰할 수 없게 됩니다. 안정성은 말할 필요도 없습니다. 이제 디버깅하고 핥았지만 후속 수정으로 정렬하기 매우 어려운 미묘한 오류가 나타날 것이라고 가정합니다.
모든 현대 시스템이 OOP를 사용한다는 사실이 우월성의 증거가 아닙니까? 당신은 아직 이해할 준비가되지 않았습니다. 간단한 질문을하고 복잡한 답변을 수락 할 수 없습니다 .. 그리고 당신은 대답이 없다고 생각합니다 .. 글쎄, 이것은 옳지 않습니다 ..
생각이 변하고 있다는 사실은 그렇습니다. 처음에는 그렇게 보이지만 무엇을 위한 것입니까? 그러나 프로젝트가 수천 줄의 코드가 되면 보상을 받기 시작합니다.)) 왜 그리고 무엇에 대한 것인지 이해합니다)
프로젝트가 지원되고 업데이트되면 확장이 어렵고 비용이 많이 들고 다른 프로젝트는 빠르고 쉬우면 첫 번째 프로젝트가 죽습니다. 이것은 자연 선택입니다.
내 프로그램에는 수천 줄의 코드도 있습니다. 불필요한 존재가 없다는 것이 나의 구원이다. 그렇지 않으면 모든 것을 개발할 수 없습니다. 이것이 가장 순수한 실천입니다.
하지만 그것으로 충분합니다. 이 주제를 떠나겠습니다.
1. 현대의 모든 시스템이 OOP를 사용한다는 사실이 우월성의 증거가 아닌가?
2. 당신은 아직 이해할 준비가되지 않았습니다. 간단한 질문을하고 복잡한 답변을 수락하지 못하고 .. 당신은 대답이 없다고 생각합니다 .. 글쎄, 이것은 옳지 않습니다 ..
생각이 변하고 있다는 사실은 그렇습니다. 처음에는 그렇게 보이지만 무엇을 위한 것입니까? 그러나 프로젝트가 수천 줄의 코드가 되면 보상을 받기 시작합니다.)) 왜 그리고 무엇에 대한 것인지 이해합니다)
프로젝트가 지원되고 업데이트되면 확장이 어렵고 비용이 많이 들고 다른 프로젝트는 빠르고 쉬우면 첫 번째 프로젝트가 죽습니다. 이것은 자연 선택입니다.
1. 여기 모든 사람들이 너무 멋져서 그들에게 이것은 증거가 될 수 없지만 오히려 그들이 모두 자신에 대해 너무 멋지고 주위의 모든 사람들이 슬픈 새끼들이라는 확인이 될 것입니다. 그들은 OOP에 빠졌습니다.
2. 매우 일화적이지만 그들은 그것을 깨닫지 못합니다.
이 주제와 유사)) 아주 오래 전에 Popular Mechanics 잡지를 구독했는데 유머 페이지가 있었습니다.
일단 레오는 전쟁에 나섰습니다. 글쎄, 그것은 모두 헛소리입니다. 여우를 만납니다. 폭스, 누카 빨리, 짐승의 왕은 누구?
레오, 당신은 물론입니다!
만족, 진행
토끼를 만났어, 같은 결과
코끼리를 만났습니다. 그리고 코끼리는 뜨거웠고 그는 파리에서 몸통을 흔들었고 사자는 트위들디 속으로 날아갔습니다.
그리고 친구들이여, 그가 덤불 속에 앉아 떠나는 코끼리에게 뭐라고 말했는지 아십니까?
- 그리고 답을 모르면 화내지 않는다))
고슴도치 정보:
공터에 고슴도치가 있습니다, 포즈를 취하고, 팔뚝을 긴장시킵니다. - 나는 강하고, 용감하고, 기민하고, 강하고, 용감하고, 기민하다 ...
곰 한 마리가 지나가고 있었습니다. 발로 차면 고슴도치가 나무 뒤로 날아가 일어나서 몸을 닦습니다.
- 나는 강하고, 나는 용감하고, 나는 민첩하지만...
하지만 그것으로 충분합니다. 이 주제를 떠나겠습니다.
남을 믿지 않고 자신을 이해하고 싶은 것도 좋은데 남이 틀릴 수도 있고 스스로 다가가기 쉬운
1. 여기 모든 사람들이 너무 멋져서 그들에게 이것은 증거가 될 수 없지만 오히려 그들이 모두 자신에 대해 너무 냉정하다는 확인이 될 것입니다. 그들은 방법을 알고 있으며 주변의 모든 사람들이 슬픈 빨판입니다. 그들은 OOP에 빠졌습니다.
2. 매우 일화적이지만 그들은 그것을 깨닫지 못합니다.
))) 많은 것을 이해하지 못하는 사람들이 시장에서 어드바이저를 10,000달러에 팔거나 구독자 2,000명과 신호를 보내고 유치하지 않은 행 루팅을 하는 것은 일화))
이것은 주요 주장이 아닙니다.
글쎄요, 절차적 프로그래밍에는 다형성 의 유사점이 없습니다.
당신이 몇 페이지 앞서 함수 포인터를 언급했다면 그렇지 않습니까? 이것은 다형성의 유사점이 아니며 동적으로 변경할 수 있기 때문에 훨씬 더 많은 기회가 있습니다.
그들은 그것을 시트로 늘였습니다 :-) 그들은 holivars를 놓친 것처럼 보입니다. 중재자는 불꽃 주제를 짜내었습니다 ... 그리고 갑자기 OOP 대 비 OOP
그런데 @Peter Konow 가 OOP를 사용하는 99%, 그 사람만 그것에 대해 알지 못합니다 :-) OOP는 반드시 "클래스 및 템플릿"이 아닙니다.
그런데 그 반대도 마찬가지입니다. 프로그램에 개체와 클래스가 있다고 해서 OOP가 표시되지는 않습니다.
당신이 몇 페이지 앞서 함수 포인터를 언급했다면 그렇지 않습니까? 이것은 다형성의 유사점이 아니며 동적으로 변경할 수 있기 때문에 훨씬 더 많은 기회가 있습니다.
어제는 야당에 대해 더 나은 의견을 갖고 있었습니다. 함수 포인터는 최근 MQL에 등장했지만, 오늘날 모든 토론자들에게 마치 존재하지 않는 것처럼 똑같다는 것이 밝혀졌습니다. 그들이 무엇에 대해 논쟁하는지 이해하지 못하는 것으로 나타났습니다. 확실히 " 다형성 "과 "포인터"라는 단어는 눈과 귀를 놓쳤습니다. 그들은 여기에서 1000건의 증거를 받았음에도 불구하고 "당신은 증거를 제공하지 않았습니다"라는 하나의 주장을 가지고 있습니다.
클래스에 대한 포인터도 동적으로 변경할 수 있으며, 함수를 사용하면 미리 생성할 필요가 없기 때문에 더 쉽습니다.
결정의 효율성이란 결정의 품질을 의미하며, 여기서 메커니즘(및 프로그램은 의심할 여지 없이 메커니즘)이 가장 안정적으로 작동합니다. 메커니즘은 명확하고 일관성 있고 생산적이어야 합니다. 메커니즘의 기능은 할당된 모든 작업을 구현해야 합니다. 메커니즘은 불필요한 것을 허용하지 않으며이 메커니즘의 개발에서 불필요한 것은 차단해야합니다.
귀하의 경우에만이 "불필요한"은 실수로 프로그래밍 오류로부터 코드를 보호하도록 설계된 유형 제어 및 기타 기본 사항입니다. 따라서 코드를 매우 신뢰할 수 없게 됩니다. 안정성은 말할 필요도 없습니다. 이제 디버깅하고 핥았지만 후속 수정으로 정렬하기 매우 어려운 미묘한 오류가 나타날 것이라고 가정합니다.
OOP에는 개발자가 사용할 수 있는 추가 도구가 많이 포함되어 있다는 사실은 부인할 수 없습니다. 그러나 이러한 도구를 사용하기 위해 지불해야 하는 비용을 이해해야 합니다. 즉, OOP 패러다임과 이에 상응 하는 코드 구조에 대한 완전한 몰입입니다. 전체 OOP 툴킷을 사용하고 많은 개체를 생성합니다. 주요 가격 - 코드의 날카로운 복잡성. 그러나 실습은 생성된 메커니즘의 효율성 관점에서 볼 때 단순해야 하며 그 안에 있는 엔터티의 존재는 효율성을 높이고 그 이상은 하지 않음으로써 절대적으로 정당화되어야 함을 보여줍니다.
귀하의 경우에만이 "불필요한"은 실수로 프로그래밍 오류로부터 코드를 보호하도록 설계된 유형 제어 및 기타 기본 사항입니다. 따라서 코드를 매우 신뢰할 수 없게 됩니다. 안정성은 말할 필요도 없습니다. 이제 디버깅하고 핥았지만 후속 수정으로 정렬하기 매우 어려운 미묘한 오류가 나타날 것이라고 가정합니다.