OOP 대 절차 프로그래밍 - 페이지 41

 
George Merts :

교통 체증에 빠진 차에 다가가 작동 방식을 살펴보고 운전자에게 "더 갑자기 문제를 혼란스럽게 하고 백 미터를 걸어갈 수 있는 방법이 없을까요?"라고 말하는 것은 바로 당신입니다.

내 경험에서 알 수 있듯이 모든 전역 변수 가 포함된 단일 템플릿에서 복사-붙여넣기를 사용하여 만든 "문제 없는" Expert Advisors보다 "엉킨 문제"를 파악하는 것이 훨씬 쉽습니다.


Georges, 저는 최근 이곳에서 오랜 친구를 만났습니다. 그녀는 회계사이고 1C를 마스터하려고 노력하고 있습니다. 2007년에 그녀는 핸디캡을 알아내려고 노력했고, 사실 그 때 제가 MQL4에 대해 배웠습니다.

나는이 1C를보고 기분이 나빴다))

 
Реter Konow :

2년 연속 작업.

그래픽 인터페이스의 핵심(그런데 요소 프로토타입을 포함하는 proto-core도 있습니다. 2MB가 필요합니다. 내가 제공한 것과 같은 테이블로 구성됨)에는 수천 개의 변수가 포함되어 있습니다. 커널을 센터로 사용하지 않고 클래스와 구조에 변수를 흩뿌리고 다양한 액세스 제어를 통해 연결을 설정했다면 내 작업을 처리했을 것이라고 생각하십니까? - 절대 혼자가 아닙니다. 프로그램 엔터티의 수는 몇 배 증가했을 것입니다. 함수와 클래스 간의 코드 내 링크는 너무 복잡해져서 혼자서 작업을 계속할 수 없을 것입니다. 전체 메커니즘의 효율성은 전체적으로 떨어질 것입니다.

훨씬 더 빨리 한계에 도달하고 멈췄을 것입니다.

"내가 OOP를 사용 한다면 무엇을 얻을 수 있을까?"라는 질문을 스스로에게 여러 번 했습니다. 그리고 매번 매일의 연습에 의지하여 나는 지금까지 혼자 갈 수 없다는 것을 깨달았습니다.

또한 내 생각은 이미 구조화되어 있으므로 이와 관련하여 OOP가 필요하지 않습니다.


내 기사에 그래픽 컨트롤 라이브러리가 있습니다(물론 결함도 있습니다). 기사를 작성하는 데 2주, 2주 만에 만들어졌습니다. 몇 년 후 다른 기사를 작성할 때 사용했습니다. 기사와 코드를 살펴보지 않고 메소드의 드롭다운 목록을 보고 거의 즉시 모든 것을 기억했습니다.

 
Dmitry Fedoseev :

내 기사에 그래픽 컨트롤 라이브러리가 있습니다(물론 결함도 있습니다). 이 라이브러리는 기사를 작성하는 데 2주와 2주 만에 만들어졌습니다. 몇 년 후 다른 기사를 작성할 때 사용했습니다. 기사와 코드를 살펴보지 않고 메소드의 드롭다운 목록을 보고 거의 즉시 모든 것을 기억했습니다.

나는 당신의 일을 얕잡아 보거나 당신의 일을 강조하고 싶지 않지만 당신은 코끼리와 퍼그를 비교하고 있습니다. 저울이 다릅니다. 난이도가 다릅니다. 나는 단지 일련의 컨트롤을 가지고 있지 않습니다. 이것은 고유한 마크업 언어로 구축할 수 있는 전체 그래픽 환경입니다. 또한 대상이 아닌 그린 것입니다.
 
Реter Konow :
나는 당신의 일을 얕잡아 보거나 당신의 일을 강조하고 싶지 않지만 당신은 코끼리와 퍼그를 비교하고 있습니다. 저울이 다릅니다. 난이도가 다릅니다. 나는 단지 일련의 컨트롤을 가지고 있지 않습니다. 이것은 마크업 언어로 구축할 수 있는 전체 그래픽 환경입니다. 또한 대상이 아닌 그린 것입니다.

하지만 아직 2년 차 직업은 아니다. 작업량은 그래픽 개체의 사용과 비슷하지만 물론 유능한 접근 방식입니다. 하지만 이걸로 죽이려면 2년이... 죄송합니다, 이만 가세요.

캔버스 생성이 추가되었지만 이것은 부모 클래스에 있으며 직사각형을 그리는 방법이 만들어지고 가장 단순한 기하학적 모양을 그리는 몇 가지 방법이 더 있습니다. 다른 모든 것은 완전히 동일합니다.

그리고 여러분 모두가 저의 이 작업을 모욕하기를 원한다는 사실 - 저는 오랫동안 이해했으므로 서문은 필요하지 않습니다. 여기 이 도서관은 군중을 집단 히스테리로 몰아넣는 논쟁의 돌과 같습니다.

 
Dmitry Fedoseev :

하지만 아직 2년 차 직업은 아니다. 작업량은 그래픽 개체의 사용과 비슷하지만 물론 유능한 접근 방식입니다. 하지만 이걸로 죽이려면 2년이... 죄송합니다, 이만 가세요.

그리고 여러분 모두가 저의 이 작업을 모욕하기를 원한다는 사실 - 저는 오랫동안 이해했으므로 서문은 필요하지 않습니다. 여기 이 도서관은 군중을 집단 히스테리로 몰아넣는 논쟁의 돌과 같습니다.

그런 식으로 사람들을 모욕하는 것은 제 성격이 아닙니다. 말하지마 당신은 규모를 이해하지 못합니다. 나는 아마 설명할 수 없다. 따라서 자신을 더 "뱀 산"이라고 생각하십시오.)
 
Реter Konow :
그런 식으로 사람들을 모욕하는 것은 제 성격이 아닙니다. 말하지마 당신은 저울을 이해하지 못합니다. 나는 아마 설명할 수 없다. 따라서 자신을 더 "뱀 산"이라고 생각하십시오.)

스스로 생각하되 2년 동안 쓰는 것이 아니라 한 달에 할 수 있는 일을 쓴다.

 
Dmitry Fedoseev :

스스로 생각하되 2년 동안 쓰는 것이 아니라 한 달에 할 수 있는 일을 쓴다.

그럼 해봐, 뭐가 문제야?
 
Реter Konow :
그럼 해봐, 뭐가 문제야?
난 필요 없어.
 
George Merts :


SanSanych는 OOP를 문서로 대체할 것을 제안합니다.

당신은 이것을 생각해 냈습니다. 나는 제안하지 않습니다.

내 연습에서.

  • TK - 약 400페이지 분량의 문서. ToR 검토 및 승인
  • 추가 기술 프로젝트. 이 문서는 40~50명이 작성했습니다. 전문 분야별로는 다양한 전문 분야의 경제학자, 수학자, 알고리즘 학자, 현재 용어의 시스템 관리자, 전자 엔지니어입니다.
  • 다음은 작업 초안입니다. 여기에서 기능 프로그램으로의 분류가 나타납니다. 실제 코딩 및 디버깅에 의해 생성됩니다. 문서가 생성되고 있습니다: 개발자, CC의 다른 사용자, 다른 애플리케이션 사용자(관리, 중간 링크, 디스패처 ..).
  • 추가 실험 작업. 주요 지표는 실패 시간입니다. 모든 것이 올바르게 수행되고 문서화되면 기본 원칙이 코딩의 기초이므로 다음 버그 포착 후 실패 사이의 시간은 기하급수적 으로 감소해야 합니다. 선형이면 거의 작동하지 않습니다.

OOP는 어디에 있습니까? OOP는 일부 기업 개발 요구 사항입니다. 또한 최종 결과에는 거의 영향을 미치지 않지만 매우 유용할 수 있습니다. 프로젝트의 최종 목표부터 자연스럽게 ....

 
주제에서 벗어나지 마십시오.