OOP 자체가 제공해야 하는 메커니즘 앞에 서 있다는 인상을 받습니다. 즉, 메커니즘은 무결성을 위해 노력해야 하므로 가장 적은 수의 블록에 대해 노력해야 합니다. 그리고 OOP는 어떤 이유로든 이러한 블록을 강제로 생성합니다. 이 때문에 메커니즘의 구조가 찢어지고 제대로 작동하지 않습니다. 그리고 그들은 더욱 악화됩니다.
...
아니면 OOP에 대해 환상을 가질 필요는 없지만 적어도 조금은 연구합니까? 환상조차 갖지 말고 열광하십시오.
Nikolai, OOP에 대한 당신의 사랑이 추상적인 이유를 제외하고는 거의 어떤 것으로도 정당화되지 않는다는 생각을 해본 적이 있습니까?
이 OOP를 사용하여 거대한 메커니즘을 만들었다면 왜 그렇게 많이 필요한지 분명할 것입니다. OOP가 필요한 이유를 구체적으로 입증해야 합니다. 그러나 상대적으로 작은 메커니즘을 만듭니다. 하나 또는 다른 접근 방식의 단점과 장점에 대한 결론을 도출하기에 충분한 코드가 없습니다. 그러나 당신은 여전히 OOP에 대해 이야기하고 있습니다. OOP는 단지 도구일 뿐이며 그 자체로는 의미가 없습니다. 즉, 수행할 메커니즘이 없으면 OOP가 필요하지 않습니다. 그리고 메커니즘이 있다면 생성 시 OOP가 필요할 정도로 심각해야 합니다.
대부분의 PLO 옹호자들은 진지한 행동을 하지 않습니다. 작은 품목만. 그러나 PLO에 대한 그들의 믿음은 흔들리지 않습니다. 훨씬 더 심각한 메커니즘을 만드는 다른 사람들은 OOP의 위대함에 대해 훨씬 덜 외칩니다. 일부는 비판적인 목소리를 내기도 합니다(몇 번이었습니다).
즉, 당신의 주장은 이론만이 아니라 실천에 의해 뒷받침되어야 합니다. 예를 들어, Anatoly를 사용하여 GUI 개발에서 OOP의 이점에 대해 논쟁할 수 있습니다. 왜냐하면 우리는 실제로 솔루션과 뉘앙스를 비교할 수 있기 때문입니다. 그러나 당신이 그것을 이해하지 못할 것이기 때문에 나는 당신과 함께 논쟁에서 돌아설 수 없습니다. 당신은 듣겠지만 이해하지 못할 것입니다(공격하지 않음). 그리고 반대로 Anatoly는 아주 잘 이해할 수 있습니다. 글로벌 메커니즘을 만드는 경험의 차이가 오해의 주요 원인입니다.
추신. 실무자로서 다음과 같이 말할 것 입니다. 접근 방식은 특정 프로그래머의 두뇌 잠재력을 극대화하는 방식이어야 합니다. 나 자신을 위해 그러한 접근 방식을 찾았습니다.
Peter, 당신은 OOP 사용과 관련하여 뭔가를 잘못 이해했습니다.
Nikolai, HIERARCHY를 구축하고 있습니까 아니면 그리기 메커니즘을 만들고 있습니까?
HIERARCHY(그리기에 신경 쓰지 않음)를 구축하는 경우 모든 곳에서 OOP가 필요한 이유가 분명합니다.
하나의 클래스를 기반으로 작동 하는 드로잉 엔진을 생성하는 경우 클래스 자체는 필요하지 않습니다.
클래스, - 단어 분류에서. 분류는 특성에 따른 분류입니다. 클래스는 분류에서 파생됩니다. 클래스가 하나인 경우 분류가 없습니다.
이 경우 클래스는 추상적 인 쓰레기를 의미합니다. 무의미한 말.
...
OOP 자체가 제공해야 하는 메커니즘 앞에 서 있다는 인상을 받습니다. 즉, 메커니즘은 무결성을 위해 노력해야 하므로 가장 적은 수의 블록에 대해 노력해야 합니다. 그리고 OOP는 어떤 이유로든 이러한 블록을 강제로 생성합니다. 이 때문에 메커니즘의 구조가 찢어지고 제대로 작동하지 않습니다. 그리고 그들은 더욱 악화됩니다.
...
아니면 OOP에 대해 환상을 가질 필요는 없지만 적어도 조금은 연구합니까? 환상조차 갖지 말고 열광하십시오.
Nikolai, OOP에 대한 당신의 사랑이 추상적인 이유를 제외하고는 거의 어떤 것으로도 정당화되지 않는다는 생각을 해본 적이 있습니까?
이 OOP를 사용하여 거대한 메커니즘을 만들었다면 왜 그렇게 많이 필요한지 분명할 것입니다. OOP가 필요한 이유를 구체적으로 입증해야 합니다. 그러나 상대적으로 작은 메커니즘을 만듭니다. 하나 또는 다른 접근 방식의 단점과 장점에 대한 결론을 도출하기에 충분한 코드가 없습니다. 그러나 당신은 여전히 OOP에 대해 이야기하고 있습니다. OOP는 단지 도구일 뿐이며 그 자체로는 의미가 없습니다. 즉, 수행할 메커니즘이 없으면 OOP가 필요하지 않습니다. 그리고 메커니즘이 있다면 생성 시 OOP가 필요할 정도로 심각해야 합니다.
대부분의 PLO 옹호자들은 진지한 행동을 하지 않습니다. 작은 품목만. 그러나 PLO에 대한 그들의 믿음은 흔들리지 않습니다. 훨씬 더 심각한 메커니즘을 만드는 다른 사람들은 OOP의 위대함에 대해 훨씬 덜 외칩니다. 일부는 비판적인 목소리를 내기도 합니다(몇 번이었습니다).
즉, 당신의 주장은 이론만이 아니라 실천에 의해 뒷받침되어야 합니다. 예를 들어, Anatoly를 사용하여 GUI 개발에서 OOP의 이점에 대해 논쟁할 수 있습니다. 왜냐하면 우리는 실제로 솔루션과 뉘앙스를 비교할 수 있기 때문입니다. 그러나 당신이 그것을 이해하지 못할 것이기 때문에 나는 당신과 함께 논쟁에서 돌아설 수 없습니다. 당신은 듣겠지만 이해하지 못할 것입니다(공격하지 않음). 그리고 반대로 Anatoly는 아주 잘 이해할 수 있습니다. 글로벌 메커니즘을 만드는 경험의 차이가 오해의 주요 원인입니다.
추신. 실무자로서 다음과 같이 말할 것 입니다. 접근 방식은 특정 프로그래머의 두뇌 잠재력을 극대화하는 방식이어야 합니다. 나 자신을 위해 그러한 접근 방식을 찾았습니다.
OOP에 대한 환상은 점점 더 거칠어지고 있습니다...
작업의 심각성은 보낸 연수가 아니라 결과에 따라 결정됩니다.
아아, 넌센스가 아닙니다.
캔버스에 그리기에는 클래스 래퍼가 필요하지 않습니다. 기능 목록으로 충분합니다. 그리기에 메소드 접근 권한이 필요하지 않습니다. 그리고 당신은 그것을 알고 있습니다. 그러나 당신은 이 사실을 부정합니다. 명백한 것을 부정합니다.
오! 네. 바나나를 먹으려면 껍질을 벗겨야 합니다. 그러나 소에게 뿔이 있다면 뿔이 있는 것은 모두 소이다.
뭐, 그런 사람은 많지 않습니다. 나는 아마 그들 중 하나입니다. 하지만, 내 목표는 당신을 가르치는 것이 아닙니다. 그리고 명쾌한 대답만 듣습니다. 하나의 클래스만 사용한다면 왜 그림을 그릴 때 객체를 통해 클래스 함수를 호출할까요?
그러면 캔버스에 그리는 기능은 캔버스에 그리는 일만 참조하고 따로 바구니에 담을 필요가 없기 때문에 한 클래스에 모아두는 것입니다. 그러나 당신은 여전히 이해하지 못할 것입니다.
Nikolai, HIERARCHY를 구축하고 있습니까 아니면 그리기 메커니즘을 만들고 있습니까?
HIERARCHY(그리기에 신경 쓰지 않음)를 구축하는 경우 모든 곳에서 OOP가 필요한 이유가 분명합니다.
하나의 클래스를 기반으로 작동 하는 드로잉 엔진을 생성하는 경우 클래스 자체는 필요하지 않습니다.
클래스, - 단어 분류에서. 분류는 특성에 따른 분류입니다. 클래스는 분류에서 파생됩니다. 클래스가 하나인 경우 분류가 없습니다.
이 경우 클래스는 추상적 인 쓰레기를 의미합니다. 무의미한 말.
계층 구조는 어떻습니까? OOP는 상속을 광범위하게 사용합니다... 그리고 또 다른 엄청난 환상...
...그리고 케이크 위의 체리:
돌로 불을 지피고 또 천 년 동안 돌로 두드리라)
나는 다른 다소 비싼 특수 소프트웨어에 대한 유사한 프로젝트를 가지고 있었고, 대안으로 아이디어를 구현하기도 했습니다(추가 모듈을 구매하지 않기 위해). 효과가 있었지만 일부 고객에게는 막다른 골목에 있었고 시간이 낭비되었습니다.
하지만 영역이 완전히 다르기 때문에 고객을 쉽게 찾을 수 있습니다.