내 접근 방식. 코어 - 엔진. - 페이지 19

새 코멘트
 
Реter Konow :

좋은. 내가 확신하게 해줘.

  1. OOP는 프로그래머 팀이 대규모 프로젝트를 수행하는 데 필요합니다.
  2. OOP는 프로그램을 구성하고 구성합니다.
  3. OOP는 프로그래밍 가능성을 확장할 수 있는 많은 도구를 제공합니다.

원칙적으로 나는이 모든 것을 오랫동안 이해합니다. 그리고 나는 그것에 동의합니다. 그러나 동시에 나는 내 접근 방식을 선호합니다. 왜요?

한 가지 구체적인 이유가 있습니다.

프로그램 개발.

//----------------------------------------

OOP와 내 접근 방식을 사용하면 프로그램이 얼마나 빨리 개발됩니까? 메커니즘의 성장과 복잡성에 더 유리한 접근 방식은 무엇입니까?

나는 내 접근 방식 + 코드의 모국어(60% 러시아어 및 40% 영어)가 프로그램의 가장 빠른 성장을 제공한다고 결론지었습니다.

이 빠른 성장이 바로 나에게 필요한 것입니다. 세부 사항을 파고 들지 마십시오. 코드의 모든 줄을 가리키지 않습니다. 전문적인 접근 방식이 아닙니다.

빨리 개발하고 더 복잡해지는 프로그램이 필요했습니다. 할당된 기능을 구현하는 메커니즘을 생성합니다. 빠르고 쉽습니다.

몇 줄의 코드로 새로운 기능을 추가할 수 있습니다.

내 접근 방식은 이 특정 문제를 해결하는 데 OOP보다 우수합니다.

귀하의 방법론을 통해 빠르고 쉽게 개발할 수 있는 이유는 무엇이라고 생각합니까? 지금까지 나는 그 반대를 본다. 나는 복잡한 일에 동의합니다. 귀하의 코드는 정말 이해하기 어렵습니다.

 
Vitalii Ananev :

귀하의 방법론을 통해 빠르고 쉽게 개발할 수 있는 이유는 무엇이라고 생각합니까? 나는 복잡한 일에 동의합니다. 귀하의 코드는 정말 이해하기 어렵습니다. 지금까지 나는 그 반대를 본다.

그리고 가상 머신 (엔진) 생성의 복잡성을 어떻게 평가합니까? 마크 업 언어. 어리석은 접근 방식을 가진 한 사람이 이것을 만들 수 있습니까? OOP와도.

내 접근 방식으로 정확히 무엇을 만들었는지 이해하면 프로그램 개발에 어떤 기회가 제공되는지 이해하게 될 것입니다. (난 무례하게 굴고 싶지 않아요. 그렇지 않으면 당신이 이해하지 못할 뿐입니다.)

 
Реter Konow :

그리고 가상 머신 (엔진) 생성의 복잡성을 어떻게 평가합니까? 마크 업 언어. 어리석은 접근 방식을 가진 한 사람이 이것을 만들 수 있습니까? OOP와도.

내 접근 방식으로 정확히 무엇을 만들었는지 이해하면 프로그램 개발에 어떤 기회가 제공되는지 이해하게 될 것입니다. (난 무례하게 굴고 싶지 않아요. 그렇지 않으면 당신이 이해하지 못할 뿐입니다.)

좋아, 적어도 당신은 질문에 대답하지 않았습니다. 작동하는 코드를 기다리자. 당신의 열정이 얼마나 오래 지속되는지 봅시다.

 
Реter Konow :

내 접근 방식으로 정확히 무엇을 만들었는지 이해하면 프로그램 개발에 어떤 기회가 제공되는지 이해하게 될 것입니다.

그래서 역설은 아무도 당신이 만든 것을 이해할 수 없다는 것입니다) 글쎄, 당신을 제외하고는 물론)

 
Alexey Navoykov :

그래서 역설은 아무도 당신이 만든 것을 이해할 수 없다는 것입니다) 글쎄, 당신을 제외하고는 물론)

나는 많은 창을 그렸고, 생성자에 대한 많은 비디오를 촬영했으며, 기성품 엔진에 창을 제공하고, 코드에 익숙해지지 않고 엔진을 사용자 프로그램에 연결했습니다. 나는 고문의 기능을 맡을 계산 엔진을 만들 준비를 하고 있지만, 동시에 교육을 받은 포럼 프로그래머는 내가 한 일을 이해하지 못합니다.))

그것은 일종의 사악한 아이러니 일뿐입니다 ...))

 

그러나 스레드는 내가 만든 것이 아니라 . 하지만 성과를 내지 않고는 접근의 힘을 보여줄 수 없다 . 대중은 성과를 완전히 이해하지 못합니다. 이건 괜찮아.

성과를 이해하려면 원래 작업의 복잡성을 상상해야 합니다. 질문에 답해 보겠습니다 . 마크업 언어를 만드는 데 어떤 복잡성이 있습니까?

한 번도 해본 적이 없는 사람에게는 쉬워 보일 수 있지만 실제로 필요한 것은 무엇일까요?

아는 사람?

 
Реter Konow :

질문에 답해 보겠습니다 . 마크업 언어를 만드는 데 어떤 복잡성이 있습니까?

한 번도 해본 적이 없는 사람에게는 쉬워 보일 수 있지만 실제로 필요한 것은 무엇일까요?

아는 사람?

귀하의 언어에 대해 - 작습니다. 프로그래머에게 휴일의 작업이라고 할 수 있습니다.

 
Yury Kulikov :

귀하의 언어에 대해 - 작습니다. 프로그래머에게 휴일의 작업이라고 할 수 있습니다.

글쎄, 그것이 내가 예상했던 대답이다. 그런데 왜 마크업 언어를 만들지 않았습니까? 오랫동안 그래픽 작업을 하셨지만 주말에는 언어 작업을 하지 않으셨습니다.)

내가 이해하는 한 귀하의 창은 표준 그래픽 라이브러리를 사용합니다(외관으로 판단).

그래픽 라이브러리를 처음부터 구축하는 데 얼마나 걸릴 것이라고 생각하십니까?

예를 들어, Anatoly는 1년 반이 걸렸습니다. 그리고 그는 다른 사람의 코드도 사용했습니다. 예를 들어 , CCanvas 클래스 입니다.

그리고 그가 처음부터 모든 것을 하려면 얼마나 걸립니까? 적어도 2년은 생각합니다.

만 유의하십시오 . 마크업 언어가 아닙니다.

 
내가 알기로는 문제가 아직 검증 및 소스 코드에 도달하지 않았습니까?
 
TheXpert :
내가 알기로는 문제가 아직 검증 및 소스 코드에 도달하지 않았습니까?

아직 아님. 곧 알아보겠습니다. 먼저 접근 방식을 테스트해야 하는 작업의 규모를 간략하게 설명하고 싶습니다.

1...121314151617181920212223242526...184
새 코멘트