Nikolai Semko : 글쎄, 내가 큰 것을 게시하지 않는다고해서 내가 큰 것이 없다는 것을 의미하지는 않습니다. 나는 단지 작은 것들을 공유하고 있습니다.
나도 OOP 패러다임에 오랫동안 저항했다. 아직 OOP가 없을 때 프로그래밍을 배웠습니다. 그리고 OOP는 내가 대규모 프로젝트의 절차 코드에 질식하기 시작했을 때 강제로 필요했습니다. 그리고 실제로 OOP의 모든 아름다움과 힘을 깨달았을 때 절차적 프로그래밍에서 잃어버린 시간에 대해 매우 유감스럽게 생각했습니다.
놀라시겠지만 저도 절차적인 스타일에 목이 막히는 순간이 있었습니다. 처음 GUI 개발을 시작했을 때. 몇 개월의 작업 후에 코드가 커져서 더 이상 개발할 수 없을 정도로 혼란스러워졌습니다. 막다른 골목이었다.
그러나 그때 나는 내 자신의 접근 방식을 생각해 냈습니다. 커널과 커널을 중심으로 엔진을 만드십시오. 즉, 커널과 함께 작동하는 코드입니다. 그리고 모든 것이 잘되었습니다.
그래서 내 접근 방식은 당신이 생각하는 절차적인 스타일이 아닙니다.
나는 OOP를 시도했다. 어느 순간 마음에 들었다. 그러나 코드를 가진 솔직하고 무분별한 추방자를 본 순간까지만. 나는 내가 단지 내 두뇌를 비틀고 있다는 것을 깨닫고 그것에서 벗어나기 시작했습니다.
과소비가 많았습니다. 분류를 위한 분류, 단편화를 위한 코드의 단편화, 래핑을 위한 코드 래핑... 이 모든 것은 메커니즘이 요구하는 합리적 필요성에 맞지 않았습니다. 그래서 OOP에서 벗어나기 시작했습니다.
글쎄, 내가 큰 것을 게시하지 않는다고해서 내가 큰 것이 없다는 것을 의미하지는 않습니다. 나는 단지 작은 것들을 공유하고 있습니다.
놀라시겠지만 저도 절차적인 스타일에 목이 막히는 순간이 있었습니다. 처음 GUI 개발을 시작했을 때. 몇 개월의 작업 후에 코드가 커져서 더 이상 개발할 수 없을 정도로 혼란스러워졌습니다. 막다른 골목이었다.
그러나 그때 나는 내 자신의 접근 방식을 생각해 냈습니다. 커널과 커널을 중심으로 엔진을 만드십시오. 즉, 커널과 함께 작동하는 코드입니다. 그리고 모든 것이 잘되었습니다.
그래서 내 접근 방식은 당신이 생각하는 절차적인 스타일이 아닙니다.
나는 OOP를 시도했다. 어느 순간 마음에 들었다. 그러나 코드를 가진 솔직하고 무분별한 추방자를 본 순간까지만. 나는 내가 단지 내 두뇌를 비틀고 있다는 것을 깨닫고 그것에서 벗어나기 시작했습니다.
과소비가 많았습니다. 분류를 위한 분류, 단편화를 위한 코드의 단편화, 래핑을 위한 코드 래핑... 이 모든 것은 메커니즘이 요구하는 합리적 필요성에 맞지 않았습니다. 그래서 OOP에서 벗어나기 시작했습니다.
과소비가 많았습니다. 분류를 위한 분류, 단편화를 위한 코드의 단편화... 이 모든 것은 메커니즘이 요구하는 합리적 필요성에 맞지 않았습니다. 그래서 OOP에서 벗어나기 시작했습니다.
날뛰다!
아아, 넌센스가 아닙니다.
캔버스에 그리기에는 클래스 래퍼가 필요하지 않습니다. 기능 목록으로 충분합니다. 그리는 데 메소드 접근 권한이 필요하지 않습니다. 그리고 당신은 그것을 알고 있습니다. 그러나 당신은 이 사실을 부정합니다. 명백한 것을 부정합니다.
날뛰다!
이런 건 없습니다. 나는 단순한 논리에 근거하여 추론한다.
클래스 함수를 직접 호출할 수 있는데 왜 클래스 함수를 호출할 때 객체를 생성해야 합니까?
나는 당신이 거대하고 혼란스러운 수업 시스템을 가지고 있는지 이해합니다. 그러나 당신은 그것을 만들지 않았지만 여전히 객체를 통해 함수에 대한 호출을 사용합니다. 무엇 때문에?
실질적인 필요성은 어디에 있습니까? 그녀는 아니다. 그것이 필요하다는 추상적 믿음이 있고 그것이 전부입니다.
아아, 넌센스가 아닙니다.
캔버스에 그리기에는 클래스 래퍼가 필요하지 않습니다. 기능 목록으로 충분합니다. 그리기에 메소드 접근 권한이 필요하지 않습니다. 그리고 당신은 그것을 알고 있습니다. 그러나 당신은 이 사실을 부정합니다. 명백한 것을 부정합니다.
이런 건 없습니다. 나는 단순한 논리에 근거하여 추론한다.
클래스 함수를 직접 호출할 수 있는데 왜 클래스 함수를 호출할 때 객체를 생성해야 합니까?
나는 당신이 거대하고 혼란스러운 수업 시스템을 가지고 있는지 이해합니다. 그러나 당신은 그것을 만들지 않았지만 여전히 객체를 통해 함수에 대한 호출을 사용합니다. 무엇 때문에?
실질적인 필요성은 어디에 있습니까? 그녀는 아니다. 그것이 필요하다는 추상적 믿음이 있고 그것이 전부입니다.
이런 말도 안되는 소리를 할 필요는 없습니다. 이 포럼에서 나에게 캔버스를 가르칠 수 있는 사람이 적어도 한 명 있을 것 같지 않습니다(불행히도 ..., 나는 틀렸다면 기쁠 것입니다)
뭐, 그런 사람은 많지 않습니다. 나는 아마 그들 중 하나입니다. 하지만, 내 목표는 당신을 가르치는 것이 아닙니다. 그리고 명쾌한 대답만 듣습니다. 하나의 클래스만 사용한다면 왜 그림을 그릴 때 객체를 통해 클래스 함수를 호출할까요?
왜 하나의 클래스만 사용하는 경우 그림을 그릴 때 객체를 통해 클래스 함수를 호출하는 것을 사용합니까?
번역하다
당신은 CCanvas 클래스로 작업하고 있습니다. 그는 당신의 발전에 혼자입니다.
클래스는 시스템의 일부입니다. 그가 하나라면 시스템이 없습니다.
그렇다면 왜 OOP 규칙에 따라 클래스 객체 를 만들고 해당 기능에 액세스해야 할까요?
실제로 한 클래스에서 작업하는 데 OOP가 필요하지 않습니다.
하지만 ONE 클래스와 함께 작업할 때는 OOP를 사용합니다. 하지만 이것은 넌센스입니다.
당신은 CCanvas 클래스로 작업하고 있습니다. 그는 당신의 발전에 혼자입니다.
클래스는 시스템의 일부입니다. 그가 하나라면 시스템이 없습니다.
그렇다면 왜 OOP 규칙에 따라 클래스 객체 를 만들고 해당 기능에 액세스해야 할까요?
실제로 한 클래스에서 작업하는 데 OOP가 필요하지 않습니다.