동일한 경험과 지능을 가진 두 명의 프로그래머가 경쟁하면 유사한 대규모 프로젝트가 생성됩니다. 그러나 첫 번째는 함수만 사용하고 두 번째는 함수와 클래스를 사용합니다. 확실히 승리는 두 번째 것입니다. 그러나 반복합니다. 이것이 방대한 프로젝트라면 그는 단순히 더 빨리 만들 것입니다. 더 적은 버그와 더 많은 주문이 있을 것입니다. 그리고 두 번째 제품은 더 읽기 쉽고 유지 관리가 쉬우며 더 쉽게 업데이트되고 보충될 것입니다. 제 의견도 아니고 그냥 사실대로 말한겁니다. 삽보다 삽으로 구멍을 파는 것이 더 쉽습니다. 기능뿐만 아니라 클래스에서도 메커니즘을 구현하면 더 효율적일 것입니다. 여기 내 IMHO입니다.
대규모 메커니즘 구현에 클래스가 필요한지에 대한 질문부터 시작하겠습니다. 클래스는 일부 기능 집합에 대한 래퍼이고 "큰 메커니즘"은 작업 집합을 구현하는 코드 블록입니다. 내 구현에서 "큰 메커니즘"은 거의 항상 하나의 매우 큰 기능과 이를 제공하는 작은 기능의 집합입니다. 이른바 "엔진". 서비스 기능과 함께 한 클래스에 넣으면 아무것도 바뀌지 않지만 다른 클래스에 있으면 액세스가 더 복잡해지고 메커니즘의 효율성이 떨어집니다.
메커니즘의 크기가 커지면 코드를 최적화하거나 기능을 파일로 분리해야 합니다. 충분하지 않습니까? 또한, 한 블록 의 코드를 주기적으로 최적화하면 효율성의 기적이 일어납니다. 지속적으로 축소되고 구현되는 기능의 수가 증가하고 있습니다. 즉, 반대로 기능의 수가 감소합니다. 그것들은 하나의 블록으로 요약되며 코드는 지속적으로 개선되고 있습니다. 이것은효율성에 대한 직접적인 경로입니다.
또한 중요한 변수를 전역적으로 만들면 메커니즘 내부의 모든 곳에서 볼 수 있어 작업하기 쉽고, 범위를 정의하면 메커니즘의 효율성 측면에서 추가 작업. 다시 말하지만 접근하기가 더 어렵습니다. 클래스 객체 생성 등... 메커니즘을 많은 기능으로 분할하는 경향은 효율성뿐만 아니라 코드 블록의 보편성을 파괴합니다. 특정 작업마다 별도의 기능이 필요하고 코드 블록의 보편성이 단순히 개발되지 않는 것으로 나타났습니다. 호출 및 전달된 매개변수의 수도 증가하고 있습니다. 이것은 메커니즘의 효율성을 향상시키지 않지만 이러한 경향은 실제로 PLO에 의해 촉진됩니다.
OOP는 프로그래머 그룹이 프로젝트에서 작업할 때 더 효율적입니다. 그런 다음 그는 어디에도 없습니다. 생각해보면 여기도 돌아다닐 수 있는 방법이 있긴 하지만...
그러나 물론 이것은 모두 단어입니다. 실제로, 나는 내가 말하는 것을 빨리 증명할 것입니다.
그리고 Peter, 나는 당신의 코드를 간략하게 보았고 당신이 힘과 주와 함께 캔버스를 사용하고 있다는 것을 깨달았습니다 (CCanvas 클래스는 아니지만 차이점은 무엇입니까). 그렇다면 왜 캔버스에 대한 이 모든 질문과 내가 왜 여기에 십자가에 못 박혔습니까? :)).
))), 캔버스에 그리는 원리에 대한 설명에 약간 놀랐습니다. 이전에 제가 모든 것을 그린다고 말하고 보여줬기 때문입니다.)) (글쎄, 거의 모든 것입니다. :))
왜 아무도 내 것과 같은 버튼을 아직 그리지 않았는지 이해할 수 없기 때문에 주제를 시작했습니다. 결국, 당신에 따르면, 그것은 간단합니다.
당신이 그것을 보지 않았다면 그것은 당신이 그것을 할 수 있다는 것을 의미하지는 않습니다. 당신이 최고이기 때문이 아니라 코드를 게시하기 위해 게시할 필요조차 없을 정도로 미미한 것입니다 - 너무 미미한 이벤트 - 버튼만 생성 -
당신은 모두 풍차와 경쟁하고 있으며 Anatoly는 올바르게 지적했습니다.
진정해, 아르템. 나는 당신이 나를 좋아하지 않는다는 것을 이미 알고 있습니다. 분명히이 자원에 대한 많은 다른 사람들. 이것은 정당화될 수 있지만 기술적인 문제가 논의될 때 너무 솔직하고 "이유 없이" 개인적인 문제가 되는 것은 너무 많습니다.
관심이 있는 사람이 있으면 MT4용 프로젝트 를 구현하지 않을 것입니다. 내 말을 전합니다. 아마도 MT5도 마찬가지일 것입니다. 일종의 매우 비우호적 인 분위기가 발전하고 있습니다 ... 나는 이것을 위해 전혀 노력하지 않았습니다. 내 기질이 탓인지도 모른다. 아마. 모두 행운을 빌어 요.
Реter Konow : 진정해, 아르템. 나는 당신이 나를 좋아하지 않는다는 것을 이미 알고 있습니다. 분명히이 자원에 대한 많은 다른 사람들. 이것은 정당화될 수 있지만 기술적인 문제가 논의될 때 너무 솔직하고 "이유 없이" 개인적인 문제가 되는 것은 너무 많습니다.
관심이 있는 사람이 있으면 MT4용 프로젝트를 구현하지 않을 것입니다. 내 말을 전합니다. 아마도 MT5도 마찬가지일 것입니다. 일종의 매우 비우호적 인 분위기가 발전하고 있습니다 ... 나는 이것을 위해 전혀 노력하지 않았습니다. 내 기질이 탓인지도 모른다. 아마. 모두 행운을 빌어 요.
난 침착해, 왜 반대를 했어?
사람을 좋아하거나 싫어함 - 이것은 기술 포럼에서 논의되지 않습니다. 당신은 나에게 중립적입니다. 더 이상은 아닙니다. 나머지도 마찬가지입니다.
하지만 '아아아아아...이건 돈키호테야...기억,기억...'의 스타일로 언급되지 않기 위해서는 최소한 유용한 일을 해야 한다.
당신은 할 수 있습니다, 당신은 당신이 염두에두고있는 것을 할 수 없습니다 - 당신의 권리, 그리고 아무도 그것에 대해 이의를 제기하지 않습니다. 아무도 여기에 당신의 말을 필요로하지 않습니다 - 당신은 무엇보다도 먼저 자신에게 그것을 제공해야합니다;)
분위기는 매우 친절합니다. 사람들은 어떤 상황에서 OOP를 사용 하는 것의 아름다움이 무엇인지 말해주고, 한 사람이 당신 앞에서 자신을 십자가에 못 박고, 무언가를 도우려고 하고, 당신에게 보여주고 더 쉽게 접근할 수 있도록 코드를 만듭니다. 그러나 당신 자신의 말로는 당신이 그것을 필요로하지 않았다는 것이 밝혀졌습니다. 당신은 단순히 경쟁해야 할 다른 사람을 모르고 사람들에게 "약하게"도전하려고합니다.
그리고 한 가지 더, 모든 것을 평가하고 절차적 프로그래밍을 사용하여 몇 배나 더 좋고 최적화된 코드를 작성한다는 것을 깨달았기 때문에 OOP를 작성하지 않고 공부하지 않기로 결정한 것이 아닌 것 같습니다. ), 그러나 단지 그들이 거기에서 아무것도 이해하지 못했고, 그들이 모두에게 목소리를 낸 스스로의 변명을 생각해냈고, 그것을 말로 뒷받침하고 "나는 나를 이기는 사람만 믿겠다"고 도전했다.
대규모 메커니즘 구현에 클래스가 필요한지에 대한 질문부터 시작하겠습니다. 클래스는 일부 기능 집합에 대한 래퍼이고 "큰 메커니즘"은 작업 집합을 구현하는 코드 블록입니다. 내 구현에서 "큰 메커니즘"은 거의 항상 하나의 매우 큰 기능과 이를 제공하는 작은 기능의 집합입니다. 이른바 "엔진". 서비스 기능과 함께 한 클래스에 넣으면 아무것도 바뀌지 않지만 다른 클래스에 있으면 액세스가 더 복잡해지고 메커니즘의 효율성이 떨어집니다.
메커니즘의 크기가 커지면 코드를 최적화하거나 기능을 파일로 분리해야 합니다. 충분하지 않습니까? 또한, 한 블록 의 코드를 주기적으로 최적화하면 효율성의 기적이 일어납니다. 지속적으로 축소되고 구현되는 기능의 수가 증가하고 있습니다. 즉, 반대로 기능의 수가 감소합니다. 그것들은 하나의 블록으로 요약되며 코드는 지속적으로 개선되고 있습니다. 이것은효율성에 대한 직접적인 경로입니다.
또한 중요한 변수를 전역적으로 만들면 메커니즘 내부의 모든 곳에서 볼 수 있어 작업하기 쉽고, 범위를 정의하면 메커니즘의 효율성 측면에서 추가 작업. 다시 말하지만 접근하기가 더 어렵습니다. 클래스 객체 생성 등... 메커니즘을 많은 기능으로 분할하는 경향은 효율성뿐만 아니라 코드 블록의 보편성을 파괴합니다. 특정 작업마다 별도의 기능이 필요하고 코드 블록의 보편성이 단순히 개발되지 않는 것으로 나타났습니다. 호출 및 전달된 매개변수의 수도 증가하고 있습니다. 이것은 메커니즘의 효율성을 향상시키지 않지만 이러한 경향은 실제로 PLO에 의해 촉진됩니다.
OOP는 프로그래머 그룹이 프로젝트에서 작업할 때 더 효율적입니다. 그런 다음 그가 없이는 어디에도 없습니다. 생각해보면 여기도 돌아다닐 수 있는 방법이 있긴 하지만...
그러나 물론 이것은 모두 단어입니다. 실제로, 나는 내가 말하는 것을 빨리 증명할 것입니다.
Peter, 내가 예전에 함수로만 프로그래밍하고 지금과 거의 같은 방식으로 추론하고 거의 강제로 (습관의 힘이 믿기지 않기 때문에) 클래스를 사용하여 프로그래밍을 시작했습니다. 이제 이 두 상태를 비교할 수 있습니다. 클래스를 사용하려고 할 때까지는 아닙니다. 범죄가 없습니다. 다른 상황이 생각나네요. 나는 수년 동안 채식주의자였습니다. 그리고 부러워할 정도로 규칙적으로 채식주의자가 된 적이 없고 단백질, 필수 아미노산 등에 대해 나에게 무언가를 문지르려고 하는 사람들이 있습니다. 나는 그들에게 말합니다. 우리는 동등한 입장에 있지 않습니다. 저는 육식주의자였고 지금은 채식주의자였습니다. 그래서 저는 이 두 가지 조건을 연습의 관점에서 비교할 수 있습니다. 그러나 당신은 그렇지 않으며 당신의 지식은 실천과 아무 관련이 없는 이론적인 것뿐입니다. 시간을 낭비하지 마십시오 - OOP를 배우십시오. 그들은 이 포럼에서 당신을 완전히 쪼아먹었습니다, 친구. :)) 나를 포함해서. :( 절망하지 마십시오 - 우리를 죽이지 않는 것은 우리를 더 강하게 만듭니다. 나는 당신을 믿습니다!!! :))
대규모 메커니즘 구현에 클래스가 필요한지에 대한 질문부터 시작하겠습니다. 클래스는 일부 기능 집합에 대한 래퍼이고 "큰 메커니즘"은 작업 집합을 구현하는 코드 블록입니다. 내 구현에서 "큰 메커니즘"은 거의 항상 하나의 매우 큰 기능과 이를 제공하는 작은 기능의 집합입니다. 이른바 "엔진". 서비스 기능과 함께 한 클래스에 넣으면 아무것도 바뀌지 않지만 다른 클래스에 있으면 액세스가 더 복잡해지고 메커니즘의 효율성이 떨어집니다.
메커니즘의 크기가 커지면 코드를 최적화하거나 기능을 파일로 분리해야 합니다. 충분하지 않습니까? 또한, 한 블록 의 코드를 주기적으로 최적화하면 효율성의 기적이 일어납니다. 지속적으로 축소되고 구현되는 기능의 수가 증가하고 있습니다. 즉, 반대로 기능의 수가 감소합니다. 그것들은 하나의 블록으로 요약되며 코드는 지속적으로 개선되고 있습니다. 이것은효율성에 대한 직접적인 경로입니다.
또한 중요한 변수를 전역적으로 만들면 메커니즘 내부의 모든 곳에서 볼 수 있어 작업하기 쉽고, 범위를 정의하면 메커니즘의 효율성 측면에서 추가 작업. 다시 말하지만 접근하기가 더 어렵습니다. 클래스 객체 생성 등... 메커니즘을 많은 기능으로 분할하는 경향은 효율성뿐만 아니라 코드 블록의 보편성을 파괴합니다. 특정 작업마다 별도의 기능이 필요하고 코드 블록의 보편성이 단순히 개발되지 않는 것으로 나타났습니다. 호출 및 전달된 매개변수의 수도 증가하고 있습니다. 이것은 메커니즘의 효율성을 향상시키지 않지만 이러한 경향은 실제로 PLO에 의해 촉진됩니다.
OOP는 프로그래머 그룹이 프로젝트에서 작업할 때 더 효율적입니다. 그런 다음 그가 없이는 어디에도 없습니다. 생각해보면 여기도 돌아다닐 수 있는 방법이 있긴 하지만...
그러나 물론 이것은 모두 단어입니다. 실제로, 나는 내가 말하는 것을 빨리 증명할 것입니다.
그리고 그 안에 무언가가 있습니다. OOP의 창시자인 Alan Kay는 실제로 오늘날 OOP가 의미하는 것과 매우 다른 의미를 가지고 있었습니다. 이것은 당신의 비전과 훨씬 더 유사합니다. 아이디어 자체는 하나 또는 다른 기능을 위해 액세스하는 하나의 코어와 서비스가 있는 프로젝트를 만드는 것입니다. 이 경우 요소 간의 통신은 메시지 이벤트를 통해서만 발생합니다. 데이터가 포함된 이벤트 요청 전송 - 결과와 함께 이벤트 응답을 수신했습니다. 동시에 상속, 다형성 및 포함이 없습니다.
그건 그렇고, 이 접근 방식을 사용하면 멀티스레딩을 구성하기가 더 쉽습니다. 정의상 모든 요소는 서로 독립적으로 작동합니다.
Если вы никогда не слышали про Алана Кэя, то как минимум слышали его знаменитые цитаты. Например, это высказывание 1971 года: The best way to predict the future is to invent it. Лучший способ предсказать будущее это изобрести его. У Алана очень яркая карьера в информатике. Он получил Премию Киото и Премию Тьюринга за работу над парадигмой...
그리고 그 안에 무언가가 있습니다. OOP의 창시자인 Alan Kay는 실제로 오늘날 OOP가 의미하는 것과 매우 다른 의미를 가지고 있었습니다. 이것은 당신의 비전과 훨씬 더 유사합니다. 아이디어 자체는 하나 또는 다른 기능을 위해 액세스하는 하나의 코어와 서비스가 있는 프로젝트를 만드는 것입니다. 이 경우 요소 간의 통신은 메시지 이벤트를 통해서만 발생합니다. 데이터와 함께 이벤트 요청 전송 - 결과와 함께 이벤트 응답을 수신했습니다. 동시에 상속, 다형성 및 포함이 없습니다.
그건 그렇고, 이 접근 방식을 사용하면 멀티스레딩을 구성하기가 더 쉽습니다. 정의상 모든 요소는 서로 독립적으로 작동합니다.
나는 당신이 내 아이디어를 지지할 것이라고 기대하지 않았습니다. )) 그러나 물론 이것은 내 생각만이 아닙니다. 글쎄, 좋아.)
동일한 경험과 지능을 가진 두 명의 프로그래머가 경쟁하면 유사한 대규모 프로젝트가 생성됩니다. 그러나 첫 번째는 함수만 사용하고 두 번째는 함수와 클래스를 사용합니다. 확실히 승리는 두 번째 것입니다. 그러나 반복합니다. 이것이 방대한 프로젝트라면 그는 단순히 더 빨리 만들 것입니다. 더 적은 버그와 더 많은 주문이 있을 것입니다. 그리고 두 번째 제품은 더 읽기 쉽고 유지 관리가 쉬우며 더 쉽게 업데이트되고 보충될 것입니다. 제 의견도 아니고 그냥 사실대로 말한겁니다. 삽보다 삽으로 구멍을 파는 것이 더 쉽습니다. 기능뿐만 아니라 클래스에서도 메커니즘을 구현하면 더 효율적일 것입니다. 여기 내 IMHO입니다.
대규모 메커니즘 구현에 클래스가 필요한지에 대한 질문부터 시작하겠습니다. 클래스는 일부 기능 집합에 대한 래퍼이고 "큰 메커니즘"은 작업 집합을 구현하는 코드 블록입니다. 내 구현에서 "큰 메커니즘"은 거의 항상 하나의 매우 큰 기능과 이를 제공하는 작은 기능의 집합입니다. 이른바 "엔진". 서비스 기능과 함께 한 클래스에 넣으면 아무것도 바뀌지 않지만 다른 클래스에 있으면 액세스가 더 복잡해지고 메커니즘의 효율성이 떨어집니다.
메커니즘의 크기가 커지면 코드를 최적화하거나 기능을 파일로 분리해야 합니다. 충분하지 않습니까? 또한, 한 블록 의 코드를 주기적으로 최적화하면 효율성의 기적이 일어납니다. 지속적으로 축소되고 구현되는 기능의 수가 증가하고 있습니다. 즉, 반대로 기능의 수가 감소합니다. 그것들은 하나의 블록으로 요약되며 코드는 지속적으로 개선되고 있습니다. 이것은 효율성에 대한 직접적인 경로입니다.
또한 중요한 변수를 전역적으로 만들면 메커니즘 내부의 모든 곳에서 볼 수 있어 작업하기 쉽고, 범위를 정의하면 메커니즘의 효율성 측면에서 추가 작업. 다시 말하지만 접근하기가 더 어렵습니다. 클래스 객체 생성 등... 메커니즘을 많은 기능으로 분할하는 경향은 효율성뿐만 아니라 코드 블록의 보편성을 파괴합니다. 특정 작업마다 별도의 기능이 필요하고 코드 블록의 보편성이 단순히 개발되지 않는 것으로 나타났습니다. 호출 및 전달된 매개변수의 수도 증가하고 있습니다. 이것은 메커니즘의 효율성을 향상시키지 않지만 이러한 경향은 실제로 PLO에 의해 촉진됩니다.
OOP는 프로그래머 그룹이 프로젝트에서 작업할 때 더 효율적입니다. 그런 다음 그는 어디에도 없습니다. 생각해보면 여기도 돌아다닐 수 있는 방법이 있긴 하지만...
그러나 물론 이것은 모두 단어입니다. 실제로, 나는 내가 말하는 것을 빨리 증명할 것입니다.
Nikolai Semko :
그리고 Peter, 나는 당신의 코드를 간략하게 보았고 당신이 힘과 주와 함께 캔버스를 사용하고 있다는 것을 깨달았습니다 (CCanvas 클래스는 아니지만 차이점은 무엇입니까). 그렇다면 왜 캔버스에 대한 이 모든 질문과 내가 왜 여기에 십자가에 못 박혔습니까? :)).
))), 캔버스에 그리는 원리에 대한 설명에 약간 놀랐습니다. 이전에 제가 모든 것을 그린다고 말하고 보여줬기 때문입니다.)) (글쎄, 거의 모든 것입니다. :))
왜 아무도 내 것과 같은 버튼을 아직 그리지 않았는지 이해할 수 없기 때문에 주제를 시작했습니다. 결국, 당신에 따르면, 그것은 간단합니다.
))), 캔버스에 그리는 원리에 대한 설명에 약간 놀랐습니다. 이전에 제가 모든 것을 그린다고 말하고 보여줬기 때문입니다.)) (글쎄, 거의 모든 것입니다. :))
왜 아무도 내 것과 같은 버튼을 아직 그리지 않았는지 이해할 수 없기 때문에 주제를 시작했습니다. 결국, 당신에 따르면 그것은 간단합니다.
당신이 그것을 보지 않았다면 그것은 당신이 그것을 할 수 있다는 것을 의미하지는 않습니다. 당신이 최고이기 때문이 아니라 코드를 게시하기 위해 게시할 필요조차 없을 정도로 미미한 것입니다 - 너무 미미한 이벤트 - 버튼만 생성 -
당신은 모두 풍차와 경쟁하고 있으며 Anatoly는 올바르게 지적했습니다.
당신이 그것을 보지 않았다면 그것은 당신이 그것을 할 수 있다는 것을 의미하지는 않습니다. 당신이 최고이기 때문이 아니라 코드를 게시하기 위해 게시할 필요조차 없을 정도로 미미한 것입니다 - 너무 미미한 이벤트 - 버튼만 생성 -
당신은 모두 풍차와 경쟁하고 있으며 Anatoly는 올바르게 지적했습니다.
진정해, 아르템. 나는 당신이 나를 좋아하지 않는다는 것을 이미 알고 있습니다. 분명히이 자원에 대한 많은 다른 사람들. 이것은 정당화될 수 있지만 기술적인 문제가 논의될 때 너무 솔직하고 "이유 없이" 개인적인 문제가 되는 것은 너무 많습니다.
난 침착해, 왜 반대를 했어?
사람을 좋아하거나 싫어함 - 이것은 기술 포럼에서 논의되지 않습니다. 당신은 나에게 중립적입니다. 더 이상은 아닙니다. 나머지도 마찬가지입니다.
하지만 '아아아아아...이건 돈키호테야...기억,기억...'의 스타일로 언급되지 않기 위해서는 최소한 유용한 일을 해야 한다.
당신은 할 수 있습니다, 당신은 당신이 염두에두고있는 것을 할 수 없습니다 - 당신의 권리, 그리고 아무도 그것에 대해 이의를 제기하지 않습니다. 아무도 여기에 당신의 말을 필요로하지 않습니다 - 당신은 무엇보다도 먼저 자신에게 그것을 제공해야합니다;)
분위기는 매우 친절합니다. 사람들은 어떤 상황에서 OOP를 사용 하는 것의 아름다움이 무엇인지 말해주고, 한 사람이 당신 앞에서 자신을 십자가에 못 박고, 무언가를 도우려고 하고, 당신에게 보여주고 더 쉽게 접근할 수 있도록 코드를 만듭니다. 그러나 당신 자신의 말로는 당신이 그것을 필요로하지 않았다는 것이 밝혀졌습니다. 당신은 단순히 경쟁해야 할 다른 사람을 모르고 사람들에게 "약하게"도전하려고합니다.
그리고 한 가지 더, 모든 것을 평가하고 절차적 프로그래밍을 사용하여 몇 배나 더 좋고 최적화된 코드를 작성한다는 것을 깨달았기 때문에 OOP를 작성하지 않고 공부하지 않기로 결정한 것이 아닌 것 같습니다. ), 그러나 단지 그들이 거기에서 아무것도 이해하지 못했고, 그들이 모두에게 목소리를 낸 스스로의 변명을 생각해냈고, 그것을 말로 뒷받침하고 "나는 나를 이기는 사람만 믿겠다"고 도전했다.
Elusive Joe 농담을 기억합니까?
...
Elusive Joe 농담을 기억합니까?
절대적으로 동의합니다.
애매한 작사자/철학자... :-) "Joe"와 같은 헛소리, "다른 쪽"에서만... :-)
대규모 메커니즘 구현에 클래스가 필요한지에 대한 질문부터 시작하겠습니다. 클래스는 일부 기능 집합에 대한 래퍼이고 "큰 메커니즘"은 작업 집합을 구현하는 코드 블록입니다. 내 구현에서 "큰 메커니즘"은 거의 항상 하나의 매우 큰 기능과 이를 제공하는 작은 기능의 집합입니다. 이른바 "엔진". 서비스 기능과 함께 한 클래스에 넣으면 아무것도 바뀌지 않지만 다른 클래스에 있으면 액세스가 더 복잡해지고 메커니즘의 효율성이 떨어집니다.
메커니즘의 크기가 커지면 코드를 최적화하거나 기능을 파일로 분리해야 합니다. 충분하지 않습니까? 또한, 한 블록 의 코드를 주기적으로 최적화하면 효율성의 기적이 일어납니다. 지속적으로 축소되고 구현되는 기능의 수가 증가하고 있습니다. 즉, 반대로 기능의 수가 감소합니다. 그것들은 하나의 블록으로 요약되며 코드는 지속적으로 개선되고 있습니다. 이것은 효율성에 대한 직접적인 경로입니다.
또한 중요한 변수를 전역적으로 만들면 메커니즘 내부의 모든 곳에서 볼 수 있어 작업하기 쉽고, 범위를 정의하면 메커니즘의 효율성 측면에서 추가 작업. 다시 말하지만 접근하기가 더 어렵습니다. 클래스 객체 생성 등... 메커니즘을 많은 기능으로 분할하는 경향은 효율성뿐만 아니라 코드 블록의 보편성을 파괴합니다. 특정 작업마다 별도의 기능이 필요하고 코드 블록의 보편성이 단순히 개발되지 않는 것으로 나타났습니다. 호출 및 전달된 매개변수의 수도 증가하고 있습니다. 이것은 메커니즘의 효율성을 향상시키지 않지만 이러한 경향은 실제로 PLO에 의해 촉진됩니다.
OOP는 프로그래머 그룹이 프로젝트에서 작업할 때 더 효율적입니다. 그런 다음 그가 없이는 어디에도 없습니다. 생각해보면 여기도 돌아다닐 수 있는 방법이 있긴 하지만...
그러나 물론 이것은 모두 단어입니다. 실제로, 나는 내가 말하는 것을 빨리 증명할 것입니다.
Peter, 내가 예전에 함수로만 프로그래밍하고 지금과 거의 같은 방식으로 추론하고 거의 강제로 (습관의 힘이 믿기지 않기 때문에) 클래스를 사용하여 프로그래밍을 시작했습니다. 이제 이 두 상태를 비교할 수 있습니다. 클래스를 사용하려고 할 때까지는 아닙니다. 범죄가 없습니다. 다른 상황이 생각나네요. 나는 수년 동안 채식주의자였습니다. 그리고 부러워할 정도로 규칙적으로 채식주의자가 된 적이 없고 단백질, 필수 아미노산 등에 대해 나에게 무언가를 문지르려고 하는 사람들이 있습니다. 나는 그들에게 말합니다. 우리는 동등한 입장에 있지 않습니다. 저는 육식주의자였고 지금은 채식주의자였습니다. 그래서 저는 이 두 가지 조건을 연습의 관점에서 비교할 수 있습니다. 그러나 당신은 그렇지 않으며 당신의 지식은 실천과 아무 관련이 없는 이론적인 것뿐입니다.
시간을 낭비하지 마십시오 - OOP를 배우십시오.
그들은 이 포럼에서 당신을 완전히 쪼아먹었습니다, 친구. :)) 나를 포함해서. :( 절망하지 마십시오 - 우리를 죽이지 않는 것은 우리를 더 강하게 만듭니다. 나는 당신을 믿습니다!!! :))
시간을 낭비하지 마십시오 - OOP를 배우십시오.
그들은 이 포럼에서 당신을 완전히 쪼아먹었습니다, 친구. :)) 나를 포함해서. :( 절망하지 마십시오 - 우리를 죽이지 않는 것은 우리를 더 강하게 만듭니다. 나는 당신을 믿습니다!!! :))
대규모 메커니즘 구현에 클래스가 필요한지에 대한 질문부터 시작하겠습니다. 클래스는 일부 기능 집합에 대한 래퍼이고 "큰 메커니즘"은 작업 집합을 구현하는 코드 블록입니다. 내 구현에서 "큰 메커니즘"은 거의 항상 하나의 매우 큰 기능과 이를 제공하는 작은 기능의 집합입니다. 이른바 "엔진". 서비스 기능과 함께 한 클래스에 넣으면 아무것도 바뀌지 않지만 다른 클래스에 있으면 액세스가 더 복잡해지고 메커니즘의 효율성이 떨어집니다.
메커니즘의 크기가 커지면 코드를 최적화하거나 기능을 파일로 분리해야 합니다. 충분하지 않습니까? 또한, 한 블록 의 코드를 주기적으로 최적화하면 효율성의 기적이 일어납니다. 지속적으로 축소되고 구현되는 기능의 수가 증가하고 있습니다. 즉, 반대로 기능의 수가 감소합니다. 그것들은 하나의 블록으로 요약되며 코드는 지속적으로 개선되고 있습니다. 이것은 효율성에 대한 직접적인 경로입니다.
또한 중요한 변수를 전역적으로 만들면 메커니즘 내부의 모든 곳에서 볼 수 있어 작업하기 쉽고, 범위를 정의하면 메커니즘의 효율성 측면에서 추가 작업. 다시 말하지만 접근하기가 더 어렵습니다. 클래스 객체 생성 등... 메커니즘을 많은 기능으로 분할하는 경향은 효율성뿐만 아니라 코드 블록의 보편성을 파괴합니다. 특정 작업마다 별도의 기능이 필요하고 코드 블록의 보편성이 단순히 개발되지 않는 것으로 나타났습니다. 호출 및 전달된 매개변수의 수도 증가하고 있습니다. 이것은 메커니즘의 효율성을 향상시키지 않지만 이러한 경향은 실제로 PLO에 의해 촉진됩니다.
OOP는 프로그래머 그룹이 프로젝트에서 작업할 때 더 효율적입니다. 그런 다음 그가 없이는 어디에도 없습니다. 생각해보면 여기도 돌아다닐 수 있는 방법이 있긴 하지만...
그러나 물론 이것은 모두 단어입니다. 실제로, 나는 내가 말하는 것을 빨리 증명할 것입니다.
그리고 그 안에 무언가가 있습니다. OOP의 창시자인 Alan Kay는 실제로 오늘날 OOP가 의미하는 것과 매우 다른 의미를 가지고 있었습니다. 이것은 당신의 비전과 훨씬 더 유사합니다. 아이디어 자체는 하나 또는 다른 기능을 위해 액세스하는 하나의 코어와 서비스가 있는 프로젝트를 만드는 것입니다. 이 경우 요소 간의 통신은 메시지 이벤트를 통해서만 발생합니다. 데이터가 포함된 이벤트 요청 전송 - 결과와 함께 이벤트 응답을 수신했습니다. 동시에 상속, 다형성 및 포함이 없습니다.
그건 그렇고, 이 접근 방식을 사용하면 멀티스레딩을 구성하기가 더 쉽습니다. 정의상 모든 요소는 서로 독립적으로 작동합니다.
그리고 그 안에 무언가가 있습니다. OOP의 창시자인 Alan Kay는 실제로 오늘날 OOP가 의미하는 것과 매우 다른 의미를 가지고 있었습니다. 이것은 당신의 비전과 훨씬 더 유사합니다. 아이디어 자체는 하나 또는 다른 기능을 위해 액세스하는 하나의 코어와 서비스가 있는 프로젝트를 만드는 것입니다. 이 경우 요소 간의 통신은 메시지 이벤트를 통해서만 발생합니다. 데이터와 함께 이벤트 요청 전송 - 결과와 함께 이벤트 응답을 수신했습니다. 동시에 상속, 다형성 및 포함이 없습니다.
그건 그렇고, 이 접근 방식을 사용하면 멀티스레딩을 구성하기가 더 쉽습니다. 정의상 모든 요소는 서로 독립적으로 작동합니다.