글쎄, 나는 똑같이한다 - 조금씩 ... 그리고 완전한 이해는 4-5 년 후에 만 온다 (그리고 이것은 평범한 사람에게 정상이다)
제 생각에는 "완전한 이해"가 필요하지 않습니다. 중요한 것은 "본질을 잡는 것"입니다. OOP 방법론을 알게 된 것은 1995년이었다.
나는 이미 K&R 분야에서 "일반 C"에 대한 약간의 경험이 있었고(oldfags는 기억해야 함) 어셈블러 기능도 꽤 자주 사용했습니다. 처음에는 프로그래머가 몇 가지 추가 작업을 수행해야 하기 때문이 아니라 순전히 프로세서 "오버헤드" 때문에 OOP의 아이디어에 대해 다소 회의적이었습니다. 그러나 이 기술의 이점을 매우 빨리 확신했습니다. 내 의견의 주요 "스위치" 는 CString 클래스 입니다.
뿐만 아니라 문자열 작업이 크게 간소화되었습니다. 그 당시 우리는 데이터 래퍼를 작성하고 있었고 내 역할은 입력 텍스트 파서였습니다. 따라서 CString 클래스를 기반으로 패커에 중요한 차이점이 있는 서로 다른 문자열의 계층 구조를 만드는 것이 매우 편리하다는 것이 밝혀졌습니다.
나는 특히 데이터 패커가 작성된 후 패커가 원래 설계되지 않은 많은 디지털 정보가 포함된 문자열에 대해 데이터 패커를 사용하는 작업이 발생했다는 사실을 좋아했습니다. 물론 그런 데이터도 패킹했지만, 입력한 알파벳을 기호에 불과한 것으로 생각하고 했지만, 문자열이 여러 개의 단어와 숫자로 구성되어 있다는 것을 알고 속도를 잃지 않고 패킹을 크게 향상시켰습니다. 따라서 이러한 문자열을 숫자로 나타내는 클래스(숫자에 대한 특정 압축기)가 작성되고 모든 것이 기존 클래스에 추가되었으며 패커는 새 데이터로 작업하기 시작했습니다. 이러한 기능은 원래 의도된 것이 아니었습니다.
그 때 코드를 수정하고 유지 관리하는 OOP의 기능을 확인했습니다. 물론 프로세서 오버 헤드가 있지만 이것은 프로그래머의 작업 감소로 상쇄 이상입니다.
따라서 OOP를 공부하기 시작하는 모든 사람은 OOP의 장점이 명확하고 명확하게 보일 수 있는 작업을 시작하는 것이 좋습니다. 즉, 공통 조상을 가진 클래스의 인스턴스를 나타내는 목록에서 다른 개체를 처리하는 작업에서.
철학적인 사람이고 추상화에 능한 내가 전문가들에게 사랑받는 프로그래밍 접근 방식을 필사적으로 거부하는 것이 이상합니다. 잉태된 실용성으로 OOP는 엔터티를 획득하고 작업에 중복이 되었습니다. 도구의 "중복성"은 솔루션과 부족을 방해합니다. 그리고 이러한 중복성은 의심할 여지 없이 마케팅의 결과입니다. 그것에 대해 생각해보십시오. 최소한의 OOP는 컴퓨터 문제 분야의 모든 것을 해결하기에 충분합니다. 모든 것이 간단한 기능과 적절한 메모리 작업으로 생성될 수 있는 것처럼. 초등학교 수준에서 나는 즉시 OOP를 수락했습니다. 그러다가 어떤 존재는 존재의 필요성을 정당화할 수 없고, 과업에서 추상화된 자신의 삶을 성장하는 개념 안에서 살 수 없다는 것을 알아차렸다. 예, 솔루션에 내장되어 있지만 개발자의 지능에 기생합니다. 작업 프로세스를 느리게 하여 효율성을 떨어뜨립니다. 그들은 혼란, 구문, 규칙을 방해합니다 ... 솔루션 내부의 이러한 선택 사항이 마음에 들지 않았습니다.
철학적인 사람이고 추상화에 능한 내가 전문가들에게 사랑받는 프로그래밍 접근 방식을 필사적으로 거부하는 것이 이상합니다. 잉태된 실용성으로 OOP는 엔터티를 획득하고 작업에 중복이 되었습니다. 도구의 "중복성"은 솔루션과 부족을 방해합니다. 그리고 이러한 중복성은 의심할 여지 없이 마케팅의 결과입니다. 그것에 대해 생각해보십시오. 최소한의 OOP는 컴퓨터 문제 분야의 모든 것을 해결하기에 충분합니다. 모든 것이 간단한 기능과 적절한 메모리 작업으로 생성될 수 있는 것처럼. 초등학교 수준에서 나는 즉시 OOP를 수락했습니다. 그러다가 어떤 존재는 존재의 필요성을 정당화할 수 없고, 과업에서 추상화된 자신의 삶을 성장하는 개념 안에서 살 수 없다는 것을 알아차렸다. 예, 솔루션에 내장되어 있지만 개발자의 지능에 기생합니다. 작업 프로세스를 느리게 하여 효율성을 떨어뜨립니다. 그들은 혼란, 구문, 규칙을 방해합니다 ... 솔루션 내부의 이러한 선택 사항이 마음에 들지 않았습니다.
따라서 가장 최소한의 OOP를 사용합니다. 마케팅이 시작되기 전에 생성된 것입니다.
응. 여기에서 파일 작업과 같은 클래스를 만들었습니다. 사용하기 시작하고 버그가 떨어지기 시작했습니다. 코드의 한 부분에서는 핸들이 닫혀 있고 다른 부분에서는 핸들로 무언가를 하려고 합니다. 2번으로 접근합니다. 첫 번째는 어디에서, 무엇을 했는지 항상 기억하려고 노력하는 것입니다. 한 명의 개발자라도 이것은 그다지 성공적이지 않습니다. 두 번째는 작업 전에 검증 작업을 수행하는 것입니다. 자, 다음 버그: 코드 전체에 흩어져 있는 검증 작업에서 여기 저기에 오타가 있고, 부호가 같지 않고, 한 곳에서 수정되고, 다른 곳에서 잊어 버렸습니다. 결과적으로 좋아하는 코드 효율성에서 우리는 진부하고 단순한 것으로 오고, 각 Read/Write 메서드 및 이와 유사한 다른 메서드에는 check 메서드에 대한 호출이 포함되며 호출될 때 취소할 가능성이 있습니다. 거의 사용하지 않습니다. 그런 다음 최신 하드웨어를 사용하면 해결 중인 작업의 98%에서 소모된 주기와 메모리 소모를 계산할 수 없기 때문에 이것이 좋은 것임을 이해하게 됩니다.
응. 여기에서 예를 들어 파일 작업과 같은 클래스를 만들었습니다. 사용하기 시작하고 버그가 떨어지기 시작했습니다. 코드의 한 부분에서는 핸들이 닫혀 있고 다른 부분에서는 핸들로 무언가를 하려고 합니다. 2번으로 접근합니다. 첫 번째는 어디에서, 무엇을 했는지 항상 기억하려고 노력하는 것입니다. 한 명의 개발자라도 이것은 그다지 성공적이지 않습니다.
피터는 그것을 얻는다.
그것이 문제입니다. Peter는 전체 프로그램에서 항상 사용할 수 있고 언제든지 필요한 것을 가져오는 모든 변수의 거대한 테이블을 사용하는 것이 편리합니다. 타이탄의 경우 암기가 매우 편리합니다.
OOP에서 캡슐화는 사용자가 코드의 어디에서나 필요한 변수에만 액세스할 수 있고 다른 변수에는 액세스할 수 없도록 하는 데 사용되는 필수 기능입니다. 그리고 Peter에게 이것은 마이너스이며, 그는 이미 어디서, 무엇을, 어떻게 사용했는지 기억합니다. 그는 언제든지 프로그램의 어느 부분에 있는 모든 변수에 액세스할 수 있기를 원합니다. 그는 내 접근 방식을 좋아하지 않습니다 . 변수에 액세스 하려면 먼저 인터페이스에 대한 포인터를 가져와야 하고, 인터페이스에서 원하는 기능을 가져와야 하며, 그런 다음 필요한 값을 반환해야 합니다. 그리고 이러한 단계에서 액세스 제한이 발생할 수 있습니다. 제한이 있기 때문에 이점이 있다고 생각합니다. 이유가 있기 때문에 도입된 것이므로 몇 가지 중요한 세부 사항을 고려하지 않았다는 의미입니다. 그리고 Peter에게는 항상 모든 것을 고려하기 때문에 이것이 방해입니다.
응. 여기에서 파일 작업과 같은 클래스를 만들었습니다. 사용하기 시작하면 버그가 나타나기 시작합니다. 코드의 한 부분에서는 핸들이 닫혀 있고 다른 부분에서는 핸들로 무언가를 하려고 합니다. 2번으로 접근합니다. 첫 번째는 어디에서, 무엇을 했는지 항상 기억하려고 노력하는 것입니다. 한 명의 개발자라도 이것은 그다지 성공적이지 않습니다. 두 번째는 작업 전에 검증 작업을 수행하는 것입니다. 자, 다음 버그: 코드 전체에 흩어져 있는 검증 작업에서 여기 저기에 오타가 있고, 부호가 같지 않고, 한 곳에서 수정되고, 다른 곳에서 잊어 버렸습니다. 결과적으로 좋아하는 코드 효율성에서 우리는 진부하고 단순한 것으로 오고, 각 Read/Write 메서드 및 이와 유사한 다른 메서드에는 check 메서드에 대한 호출이 포함되며 호출될 때 취소할 가능성이 있습니다. 거의 사용하지 않습니다. 그런 다음 최신 하드웨어를 사용하면 해결 중인 작업의 98%에서 소모된 주기와 메모리 소모를 계산할 수 없기 때문에 이것이 좋은 것임을 이해하게 됩니다.
반대의 상황을 상상해보자. 글쎄, 당신은 버그가 없습니다. 아니요, 거의 발생하지 않습니다. 모든 것을 기억하고 모든 것을 고려하기 때문입니다! "전문적인 의무" 때문에 OOP를 사용 하시겠습니까? 나는 아니라고 생각한다. 그러면 무엇이 당신을 걱정하게 합니까? - 코드의 효율성만. 코드가 가능한 한 빨리 실행되도록 모든 오버헤드를 제거하려고 합니다. 또한 빠르게 개발되는 방식으로 코드를 작성하려고 합니다.
여기 저기에 나타나는 버그에 대해 이야기하면 이해는 하지만 OOP의 사용 여부와 관련이 있는 경우에는 동의하지 않습니다. 버그의 수는 코드에 대한 지식과 이해도에 따라 다릅니다. 무엇보다 코드는 작성한 사람이 알고 연결하지 않습니다. 그 쪽은 항상 버그가 적습니다. 알다시피, OOP는 코드의 이식성을 촉진하는데, 그 반대는 다른 프로그래머가 잘 이해하지 못한다는 것입니다. 다음은 버그의 출처입니다.
모든 것을 직접 작성하고 프로파일러 및 검사 기능 없이 2000줄 블록에서 버그를 찾습니다. 그냥, 나는 내 코드를 알고 있습니다. 버그에 대한 최고의 치료법입니다.))
그것이 문제입니다. Peter는 전체 프로그램에서 항상 사용할 수 있고 언제든지 필요한 것을 가져오는 모든 변수의 거대한 테이블을 사용하는 것이 편리합니다. 타이탄의 경우 암기가 매우 편리합니다.
OOP에서 캡슐화는 사용자가 코드의 어디에서나 필요한 변수에만 액세스할 수 있고 다른 변수에는 액세스할 수 없도록 하는 데 사용되는 필수 기능입니다. 그리고 Peter에게 이것은 마이너스이며, 그는 이미 어디서, 무엇을, 어떻게 사용했는지 기억합니다. 그는 언제든지 프로그램의 어느 부분에서나 모든 변수에 액세스할 수 있기를 원합니다. 그는 내 접근 방식을 좋아하지 않습니다. 변수에 액세스하려면 먼저 인터페이스에 대한 포인터를 가져와야 하고, 인터페이스에서 원하는 기능을 가져와야 하며, 그런 다음 필요한 값을 반환해야 합니다. 그리고 이러한 단계에서 액세스 제한이 발생할 수 있습니다. 제한이 있기 때문에 이점이 있다고 생각합니다. 이유가 있기 때문에 도입된 것이므로 몇 가지 중요한 세부 사항을 고려하지 않았다는 의미입니다. 그리고 Peter에게는 항상 모든 것을 고려하기 때문에 이것이 장애물입니다.
조지, 그것은 단지 기억에 관한 것이 아닙니다. 나는 모국어와 영어를 사용하여 나 자신에게 편안한 개발 환경을 만들었습니다. 이중 언어 코드는 단일 언어 코드보다 훨씬 더 잘 기억됩니다. 특히 표준어에 집착하지 않고 원하는 대로 변수를 호출할 때. 확인했습니다. 나는 프로그래밍의 전문성에 대해 신경 쓰지 않고 편리하게 쓰기 시작했습니다. 그 결과 코드를 빠르게 탐색하기 시작했고 코드를 읽고 기억하고 개발하기가 쉬웠습니다. 다음은 아시죠...
추신. 내가 전문성에 대해 신경 쓰지 않으려고 부른 것이라고 생각하지 않도록 하십시오. 어떠한 경우에도. 나는 지나치게 부풀려진 자존심 때문에 신경도 쓰지 않았다. 이것은 나쁠 뿐만 아니라 좋은 것으로 밝혀졌습니다. :)
글쎄, 나는 똑같이한다 - 조금씩 ... 그리고 완전한 이해는 4-5 년 후에 만 온다 (그리고 이것은 평범한 사람에게 정상이다)
제 생각에는 "완전한 이해"가 필요하지 않습니다. 중요한 것은 "본질을 잡는 것"입니다. OOP 방법론을 알게 된 것은 1995년이었다.
나는 이미 K&R 분야에서 "일반 C"에 대한 약간의 경험이 있었고(oldfags는 기억해야 함) 어셈블러 기능도 꽤 자주 사용했습니다. 처음에는 프로그래머가 몇 가지 추가 작업을 수행해야 하기 때문이 아니라 순전히 프로세서 "오버헤드" 때문에 OOP의 아이디어에 대해 다소 회의적이었습니다. 그러나 이 기술의 이점을 매우 빨리 확신했습니다. 내 의견의 주요 "스위치" 는 CString 클래스 입니다.
뿐만 아니라 문자열 작업이 크게 간소화되었습니다. 그 당시 우리는 데이터 래퍼를 작성하고 있었고 내 역할은 입력 텍스트 파서였습니다. 따라서 CString 클래스를 기반으로 패커에 중요한 차이점이 있는 서로 다른 문자열의 계층 구조를 만드는 것이 매우 편리하다는 것이 밝혀졌습니다.
나는 특히 데이터 패커가 작성된 후 패커가 원래 설계되지 않은 많은 디지털 정보가 포함된 문자열에 대해 데이터 패커를 사용하는 작업이 발생했다는 사실을 좋아했습니다. 물론 그런 데이터도 패킹했지만, 입력한 알파벳을 기호에 불과한 것으로 생각하고 했지만, 문자열이 여러 개의 단어와 숫자로 구성되어 있다는 것을 알고 속도를 잃지 않고 패킹을 크게 향상시켰습니다. 따라서 이러한 문자열을 숫자로 나타내는 클래스(숫자에 대한 특정 압축기)가 작성되고 모든 것이 기존 클래스에 추가되었으며 패커는 새 데이터로 작업하기 시작했습니다. 이러한 기능은 원래 의도된 것이 아니었습니다.
그 때 코드를 수정하고 유지 관리하는 OOP의 기능을 확인했습니다. 물론 프로세서 오버 헤드가 있지만 이것은 프로그래머의 작업 감소로 상쇄 이상입니다.
따라서 OOP를 공부하기 시작하는 모든 사람은 OOP의 장점이 명확하고 명확하게 보일 수 있는 작업을 시작하는 것이 좋습니다. 즉, 공통 조상을 가진 클래스의 인스턴스를 나타내는 목록에서 다른 개체를 처리하는 작업에서.봐, 내 구독에이 채널이 있습니다. 일반적으로 저자에 대해 긍정적 인 의견이 있습니다. 분쟁이 시작된 비디오 주제의 반복도 있습니다.
나는 비디오의 거의 모든 것에 동의합니다. 몇 가지 작은 이의가 있습니다. 이의는 없지만 설명이 있습니다(예: NULL은 오류를 나타내는 매우 유용한 포인터라고 생각합니다. , 비디오는 올바르게 말합니다 - 개체로 조작할 수 없음).
그리고 그 밖의 모든 것, 부정확성, 개발 순서, getters-setter 및 거의 동일한 NULL에 관한 모든 것이 정확합니다.
작가님께 경의를 표합니다.
철학적인 사람이고 추상화에 능한 내가 전문가들에게 사랑받는 프로그래밍 접근 방식을 필사적으로 거부하는 것이 이상합니다. 잉태된 실용성으로 OOP는 엔터티를 획득하고 작업에 중복이 되었습니다. 도구의 "중복성"은 솔루션과 부족을 방해합니다. 그리고 이러한 중복성은 의심할 여지 없이 마케팅의 결과입니다. 그것에 대해 생각해보십시오. 최소한의 OOP는 컴퓨터 문제 분야의 모든 것을 해결하기에 충분합니다. 모든 것이 간단한 기능과 적절한 메모리 작업으로 생성될 수 있는 것처럼. 초등학교 수준에서 나는 즉시 OOP를 수락했습니다. 그러다가 어떤 존재는 존재의 필요성을 정당화할 수 없고, 과업에서 추상화된 자신의 삶을 성장하는 개념 안에서 살 수 없다는 것을 알아차렸다. 예, 솔루션에 내장되어 있지만 개발자의 지능에 기생합니다. 작업 프로세스를 느리게 하여 효율성을 떨어뜨립니다. 그들은 혼란, 구문, 규칙을 방해합니다 ... 솔루션 내부의 이러한 선택 사항이 마음에 들지 않았습니다.
따라서 가장 최소한의 OOP를 사용합니다. 마케팅이 시작되기 전에 생성된 것입니다.
철학적인 사람이고 추상화에 능한 내가 전문가들에게 사랑받는 프로그래밍 접근 방식을 필사적으로 거부하는 것이 이상합니다. 잉태된 실용성으로 OOP는 엔터티를 획득하고 작업에 중복이 되었습니다. 도구의 "중복성"은 솔루션과 부족을 방해합니다. 그리고 이러한 중복성은 의심할 여지 없이 마케팅의 결과입니다. 그것에 대해 생각해보십시오. 최소한의 OOP는 컴퓨터 문제 분야의 모든 것을 해결하기에 충분합니다. 모든 것이 간단한 기능과 적절한 메모리 작업으로 생성될 수 있는 것처럼. 초등학교 수준에서 나는 즉시 OOP를 수락했습니다. 그러다가 어떤 존재는 존재의 필요성을 정당화할 수 없고, 과업에서 추상화된 자신의 삶을 성장하는 개념 안에서 살 수 없다는 것을 알아차렸다. 예, 솔루션에 내장되어 있지만 개발자의 지능에 기생합니다. 작업 프로세스를 느리게 하여 효율성을 떨어뜨립니다. 그들은 혼란, 구문, 규칙을 방해합니다 ... 솔루션 내부의 이러한 선택 사항이 마음에 들지 않았습니다.
따라서 가장 최소한의 OOP를 사용합니다. 마케팅이 시작되기 전에 생성된 것입니다.
응. 여기에서 파일 작업과 같은 클래스를 만들었습니다. 사용하기 시작하고 버그가 떨어지기 시작했습니다. 코드의 한 부분에서는 핸들이 닫혀 있고 다른 부분에서는 핸들로 무언가를 하려고 합니다. 2번으로 접근합니다. 첫 번째는 어디에서, 무엇을 했는지 항상 기억하려고 노력하는 것입니다. 한 명의 개발자라도 이것은 그다지 성공적이지 않습니다. 두 번째는 작업 전에 검증 작업을 수행하는 것입니다. 자, 다음 버그: 코드 전체에 흩어져 있는 검증 작업에서 여기 저기에 오타가 있고, 부호가 같지 않고, 한 곳에서 수정되고, 다른 곳에서 잊어 버렸습니다. 결과적으로 좋아하는 코드 효율성에서 우리는 진부하고 단순한 것으로 오고, 각 Read/Write 메서드 및 이와 유사한 다른 메서드에는 check 메서드에 대한 호출이 포함되며 호출될 때 취소할 가능성이 있습니다. 거의 사용하지 않습니다. 그런 다음 최신 하드웨어를 사용하면 해결 중인 작업의 98%에서 소모된 주기와 메모리 소모를 계산할 수 없기 때문에 이것이 좋은 것임을 이해하게 됩니다.
응. 여기에서 예를 들어 파일 작업과 같은 클래스를 만들었습니다. 사용하기 시작하고 버그가 떨어지기 시작했습니다. 코드의 한 부분에서는 핸들이 닫혀 있고 다른 부분에서는 핸들로 무언가를 하려고 합니다. 2번으로 접근합니다. 첫 번째는 어디에서, 무엇을 했는지 항상 기억하려고 노력하는 것입니다. 한 명의 개발자라도 이것은 그다지 성공적이지 않습니다.
피터는 그것을 얻는다.
그것이 문제입니다. Peter는 전체 프로그램에서 항상 사용할 수 있고 언제든지 필요한 것을 가져오는 모든 변수의 거대한 테이블을 사용하는 것이 편리합니다. 타이탄의 경우 암기가 매우 편리합니다.
OOP에서 캡슐화는 사용자가 코드의 어디에서나 필요한 변수에만 액세스할 수 있고 다른 변수에는 액세스할 수 없도록 하는 데 사용되는 필수 기능입니다. 그리고 Peter에게 이것은 마이너스이며, 그는 이미 어디서, 무엇을, 어떻게 사용했는지 기억합니다. 그는 언제든지 프로그램의 어느 부분에 있는 모든 변수에 액세스할 수 있기를 원합니다. 그는 내 접근 방식을 좋아하지 않습니다 . 변수에 액세스 하려면 먼저 인터페이스에 대한 포인터를 가져와야 하고, 인터페이스에서 원하는 기능을 가져와야 하며, 그런 다음 필요한 값을 반환해야 합니다. 그리고 이러한 단계에서 액세스 제한이 발생할 수 있습니다. 제한이 있기 때문에 이점이 있다고 생각합니다. 이유가 있기 때문에 도입된 것이므로 몇 가지 중요한 세부 사항을 고려하지 않았다는 의미입니다. 그리고 Peter에게는 항상 모든 것을 고려하기 때문에 이것이 방해입니다.
응. 여기에서 파일 작업과 같은 클래스를 만들었습니다. 사용하기 시작하면 버그가 나타나기 시작합니다. 코드의 한 부분에서는 핸들이 닫혀 있고 다른 부분에서는 핸들로 무언가를 하려고 합니다. 2번으로 접근합니다. 첫 번째는 어디에서, 무엇을 했는지 항상 기억하려고 노력하는 것입니다. 한 명의 개발자라도 이것은 그다지 성공적이지 않습니다. 두 번째는 작업 전에 검증 작업을 수행하는 것입니다. 자, 다음 버그: 코드 전체에 흩어져 있는 검증 작업에서 여기 저기에 오타가 있고, 부호가 같지 않고, 한 곳에서 수정되고, 다른 곳에서 잊어 버렸습니다. 결과적으로 좋아하는 코드 효율성에서 우리는 진부하고 단순한 것으로 오고, 각 Read/Write 메서드 및 이와 유사한 다른 메서드에는 check 메서드에 대한 호출이 포함되며 호출될 때 취소할 가능성이 있습니다. 거의 사용하지 않습니다. 그런 다음 최신 하드웨어를 사용하면 해결 중인 작업의 98%에서 소모된 주기와 메모리 소모를 계산할 수 없기 때문에 이것이 좋은 것임을 이해하게 됩니다.
반대의 상황을 상상해보자. 글쎄, 당신은 버그가 없습니다. 아니요, 거의 발생하지 않습니다. 모든 것을 기억하고 모든 것을 고려하기 때문입니다! "전문적인 의무" 때문에 OOP를 사용 하시겠습니까? 나는 아니라고 생각한다. 그러면 무엇이 당신을 걱정하게 합니까? - 코드의 효율성만. 코드가 가능한 한 빨리 실행되도록 모든 오버헤드를 제거하려고 합니다. 또한 빠르게 개발되는 방식으로 코드를 작성하려고 합니다.
여기 저기에 나타나는 버그에 대해 이야기하면 이해는 하지만 OOP의 사용 여부와 관련이 있는 경우에는 동의하지 않습니다. 버그의 수는 코드에 대한 지식과 이해도에 따라 다릅니다. 무엇보다 코드는 작성한 사람이 알고 연결하지 않습니다. 그 쪽은 항상 버그가 적습니다. 알다시피, OOP는 코드의 이식성을 촉진하는데, 그 반대는 다른 프로그래머가 잘 이해하지 못한다는 것입니다. 다음은 버그의 출처입니다.
모든 것을 직접 작성하고 프로파일러 및 검사 기능 없이 2000줄 블록에서 버그를 찾습니다. 그냥, 나는 내 코드를 알고 있습니다. 버그에 대한 최고의 치료법입니다.))
피터는 그것을 얻는다.
그것이 문제입니다. Peter는 전체 프로그램에서 항상 사용할 수 있고 언제든지 필요한 것을 가져오는 모든 변수의 거대한 테이블을 사용하는 것이 편리합니다. 타이탄의 경우 암기가 매우 편리합니다.
OOP에서 캡슐화는 사용자가 코드의 어디에서나 필요한 변수에만 액세스할 수 있고 다른 변수에는 액세스할 수 없도록 하는 데 사용되는 필수 기능입니다. 그리고 Peter에게 이것은 마이너스이며, 그는 이미 어디서, 무엇을, 어떻게 사용했는지 기억합니다. 그는 언제든지 프로그램의 어느 부분에서나 모든 변수에 액세스할 수 있기를 원합니다. 그는 내 접근 방식을 좋아하지 않습니다. 변수에 액세스하려면 먼저 인터페이스에 대한 포인터를 가져와야 하고, 인터페이스에서 원하는 기능을 가져와야 하며, 그런 다음 필요한 값을 반환해야 합니다. 그리고 이러한 단계에서 액세스 제한이 발생할 수 있습니다. 제한이 있기 때문에 이점이 있다고 생각합니다. 이유가 있기 때문에 도입된 것이므로 몇 가지 중요한 세부 사항을 고려하지 않았다는 의미입니다. 그리고 Peter에게는 항상 모든 것을 고려하기 때문에 이것이 장애물입니다.
조지, 그것은 단지 기억에 관한 것이 아닙니다. 나는 모국어와 영어를 사용하여 나 자신에게 편안한 개발 환경을 만들었습니다. 이중 언어 코드는 단일 언어 코드보다 훨씬 더 잘 기억됩니다. 특히 표준어에 집착하지 않고 원하는 대로 변수를 호출할 때. 확인했습니다. 나는 프로그래밍의 전문성에 대해 신경 쓰지 않고 편리하게 쓰기 시작했습니다. 그 결과 코드를 빠르게 탐색하기 시작했고 코드를 읽고 기억하고 개발하기가 쉬웠습니다. 다음은 아시죠...
추신. 내가 전문성에 대해 신경 쓰지 않으려고 부른 것이라고 생각하지 않도록 하십시오. 어떠한 경우에도. 나는 지나치게 부풀려진 자존심 때문에 신경도 쓰지 않았다. 이것은 나쁠 뿐만 아니라 좋은 것으로 밝혀졌습니다. :)
Peter, 당신은 팀에서 일한 적이 없다고 생각합니다. 우리는 모든 사람이 거대한 작업에서 자신의 역할을 어떻게 수행하는지, 그리고 마지막에 어떻게 모두 함께 참여하는지 알지 못했습니다.
예를 들어 OOP가 없으면 Windows를 만들고 개발하는 것이 불가능했습니다.
필요없으면 수업도 안쓰도록 노력하겠습니다. 그러나 로봇을 다중 통화 로봇 으로 만들기로 결정했을 때 OOP가 없으면 어떤 일이 일어날지 이미 명확했기 때문에 즉시 수업을 신청했습니다.
클래스를 사용하면 사용된 쌍이 동일한 클래스의 개체이고 동시에 작업하는 것이 이미 매우 쉽다는 것이 분명합니다.
Peter, 당신은 팀에서 일한 적이 없다고 생각합니다. 우리는 모든 사람이 거대한 작업에서 자신의 역할을 어떻게 수행하는지, 그리고 마지막에 어떻게 모두 함께 참여하는지 알지 못했습니다.
예를 들어 OOP가 없으면 Windows를 만들고 개발하는 것이 불가능했습니다.
필요없으면 수업도 안쓰도록 노력하겠습니다. 그러나 로봇을 다중 통화 로봇 으로 만들기로 결정했을 때 OOP가 없으면 어떤 일이 일어날지 이미 명확했기 때문에 즉시 수업을 신청했습니다.
클래스를 사용하면 사용된 쌍이 동일한 클래스의 개체이고 동시에 작업하는 것이 이미 매우 쉽다는 것이 분명합니다.
예, 팀에서 일하지 않았습니다. 내 접근 방식은 한 개발자의 실험으로 간주되어야 합니다. 나는 그를 따르라고 촉구하지 않는다. 내 접근 방식에 너무 많은 오만함이 있습니다.))
프로그래머가 외환의 세계에 들어가면 전문가가 될 필요가 없고 OOP를 알 필요가 없습니다.
시장의 복잡성을 연구하고 수익성 있는 거래 전략을 개발하는 것이 좋습니다. OOP를 사용 하는지 여부는 중요하지 않습니다. 이는 EA의 수익성에 영향을 미치지 않습니다.
에너지를 낭비할 필요가 없습니다.