이는 절차적 형식과 CArrayObj 및 CObject 기반 모두에서 수행할 수 있습니다. 문제는 개체를 추가 또는 제거하거나 정렬할 때 동작을 변경해야 할 때 시작됩니다. OOP에서 포인터의 실제 배열에 대한 지원과 이에 대한 작업은 기본 개체에 포함됩니다. 배열에 실제로 포함된 하위 개체를 변경해도 아무 영향을 주지 않습니다. 절차 스타일(배열에 포함된 실제 개체 변경)을 사용하면 일반적으로 개체 크기의 변경을 고려해야 하기 때문에 더 많은 위치에 영향을 줍니다. 실수하기가 훨씬 쉽습니다.
2. 크로스 플랫폼 - OOP 스타일로 구성하는 것이 훨씬 편리합니다. 예를 들어, 거래 포지션의 요청에 따라 - 우리는 인터페이스를 얻었고 우리가 어떤 플랫폼에서 작업했는지는 중요하지 않습니다 - 인터페이스는 모든 주문에 대한 모든 데이터를 얻을 수 있는 가상 기능 을 제공합니다( 또한 MT4) 또는 직위(MT5)의 경우, 전문가의 관점에서 볼 때 차이가 전혀 없습니다. 전문가는 자신이 어떤 플랫폼에서 작업하는지 알 필요가 없습니다.
3. 음, 결국, "절차적 프로그래밍에서 염두에 두십시오" - 이것은 "객체-프로시저 작성", 즉 OOP에서 객체를 나타내는 데이터와 절차 사이의 일부 링크를 만드는 것입니다.
4. 그리고 우리는 많은 공통점이 있는 많은 종류의 주문을 가지고 있습니다. 기본 개체가 될 COrderInfo 개체와 그 하위 개체가 다른 유형의 주문을 나타내도록 하는 것이 합리적입니다. 동시에, 거래 프로세서(CTradeProcessor 클래스가 있음)는 전달된 주문과 이 주문을 처리하는 데 필요한 절차를 정확히 자동으로 지원합니다.
5. 교차 링크가 가장 적은 곳에서 버그를 잡기가 더 쉽습니다. 그것은 캡슐화와 다형성으로도 제공됩니다. 우리는 거래 포지션 인터페이스(CTradePositionI)를 요청하며 이 포지션을 나타내는 실제 클래스(CMT4PositionInfo, CMT5PositionInfo)에 대한 모든 링크는 이 인터페이스를 통해서만 만들어지므로 실제 기능으로 직접 작업할 때보다 오류를 수정하기가 더 쉽습니다. , 거래 포지션 데이터를 반환합니다.
1. 예를 들어 무엇을 위해?
2. 인터페이스를 생성하지 않도록 동일한 기능을 다른 플랫폼에서 컴파일할 수 없는 이유는 무엇입니까?
3. 함수를 클래스의 멤버로 호출하는 것과 유사하게 처리하기 쉽도록 함수의 텍스트를 구조체의 종류에 따라 포장하는 것을 의미합니다. 이를 위해서는 원칙적으로 객체를 생성할 필요가 없습니다.
4. 설정으로 하나의 기능을 만들고 인터페이스를 통해 여러 객체와 불필요한 연결을 생성하지 않는 것이 더 합리적입니다.
5. 또한 이러한 모든 연결을 프로그래밍한 다음 인터페이스 등을 통해 추적해야 합니다. 이 경우 버그도 미묘할 수 있습니다. 직업은 처음에는 불필요하고 의미가 없습니다.
2. 인터페이스를 생성하지 않도록 동일한 기능을 다른 플랫폼에서 컴파일할 수 없는 이유는 무엇입니까?
3. 함수를 클래스의 멤버로 호출하는 것과 유사하게 처리하기 쉽도록 함수의 텍스트를 구조체의 종류에 따라 포장하는 것을 의미합니다. 이를 위해서는 원칙적으로 객체를 생성할 필요가 없습니다.
4. 설정으로 하나의 기능을 만들고 인터페이스를 통해 여러 객체와 불필요한 연결을 생성하지 않는 것이 더 합리적입니다.
5. 또한 이러한 모든 연결을 프로그래밍한 다음 인터페이스 등을 통해 추적해야 합니다. 이 경우 버그도 미묘할 수 있습니다. 직업은 처음에는 불필요하고 의미가 없습니다.
1. 음, CTradePosition 클래스 는 사실 미결 주문 목록입니다. 순서가 다르며 인터페이스, 기본 클래스 및 실제 클래스를 갖는 것이 매우 편리합니다.
2. 단 하나의 인터페이스. 모든 플랫폼용. 그리고 OOP의 경우 - 우리는 우리가 일하는 곳을 생각하지 않습니다. 플랫폼 종속 및 주문 종속 모멘트를 고려할 필요는 없습니다.
3. 그런 패키지에서 객체와 함수의 차이점은 무엇입니까? 나는 이것에 대해 이야기하고 있습니다 - 사실, 그것은 같은 것입니다. 객체의 경우 자동 생성자 함수도 추가되지만 기본적으로 비어 있습니다.
4. 바로 이 "설정이 있는 단일 기능"이 문제의 원인입니다. 일반적으로 많은 설정이 있기 때문입니다. 그리고 그것들은 클래스 계층의 다른 수준으로 분리되지 않고 바로 이 기능에 집중되어 있습니다. 반면에 인터페이스를 사용하면 이 컨텍스트에서 사용되지 않는 모든 설정("고려 범위 밖")을 그대로 둘 수 있습니다. 이는 코드 이해와 오류 가능성에 매우 좋은 영향을 미칩니다. , 그리고 그들의 탐지에. 이것이 바로 OOP의 주요 이점입니다. 우리는 객체의 계층 구조의 다른 수준에 "흩어져 있는" 모든 기능을 가지고 있으며, 그 중 하나 또는 다른 부분으로 작업할 때 나머지 부분은 방해하지 않습니다. 설정이 있는 단일 기능에서 모든 기능은 불필요하더라도 항상 사용할 수 있습니다. 이것은 일반적으로 단순히 변수를 실수로 혼동할 수 있기 때문에 문제의 원인입니다. 주요 단점은 그러한 단일 기능에서 오식비를 감지하기가 훨씬 더 어렵다는 것입니다.
5. 어떤 경우에도 이러한 연결이 필요하고 프로그래밍해야 합니다. 이는 실제로 단일 기능에서 동일한 설정입니다. 여기 내 예를 들어 - 단일 기능에서 플랫폼의 차이, 다양한 유형의 주문, 위치 표현의 차이 - 이 모든 것이 고려되어야 합니다. 인터페이스가 있을 때 - 모든 것이 우리를 위해 "단절"됩니다 - 인터페이스에 의해 정의된 것만 고려할 수 있습니다.
한 코드 블록에서 다른 블록으로의 액세스를 제한하는 것이 캡슐화의 요점입니다. 이 기능에 액세스할 수 있는 모든 사람이 최대의 기회를 가질 수 있도록 "최대 설정의 하나의 큰 보편적 기능"을 갖는 반대를 제안합니다. 제 경험상 이것은 잘못된 방법입니다. 반대로 올바른 방법은 프로그램의 한 블록이 다른 블록의 기능을 필요로 하는 경우 사용자를 최대한 제한하는 것입니다. 이 기능만 있어야 하며 그레인 이상은 없어야 합니다. 이것은 보다 안정적이고 오류 없는 코드의 핵심입니다.
주문의 경우 고유한 데이터 유형 을 만들 수 있습니다. 인터페이스, 개체 및 불필요한 버그와 불안정을 유발하는 기타 불필요한 복잡성이 필요하지 않습니다.
내 연습은 결국 그것이 필요하다는 것을 보여줍니다.
나는 5년 전, 그 당시 MT4에서 이 길을 따랐습니다. (OOP에 대해 몰랐기 때문이 아니라 인터페이스와 상속을 귀찮게 하기에는 너무 게으르다. 특히 그 당시 MT4와 MT5는 MQL 구현 측면에서 크게 다르기 때문에). 이것은 그가 틀렸다는 것을 깨닫게 했습니다. 이것은 "복잡함"이 아니라 상당히 합리적인 제한, 일종의 "바보에 대한 보호"입니다. 수백 개의 변수 각각이 무엇을 담당하는지 항상 기억한다면 캡슐화가 필요하지 않습니다. 나는 이것을 기억하지 못한다. 그리고 나는 프로그램의 각 블록에서 가능한 한 적은 수의 엔티티에 접근하는 것을 선호한다.
OOP가 MT4에 등장하자마자 나는 인터페이스를 기반으로 모든 개발을 단일 형식으로 즉시 번역하기 시작했습니다.
1. 내 연습은 결국 그것이 필요하다는 것을 보여줍니다. 이것은 그가 틀렸다는 것을 깨닫게 했습니다.
2. 나는 이것을 기억하지 못한다. 그리고 나는 프로그램의 각 블록이 가능한 적은 수의 엔티티에 접근하는 것을 선호한다.
1. 무엇이 필요하고 무엇이 잘못된 것인지 설명되지 않았습니다. 이것은 특별한 데이터 유형 이므로 원하는 대로 액세스를 구성할 수 있습니다. 이 예는 분명히 실패했습니다.
2. 프로그래머가 자신의 프로그램에서 자신의 데이터에 액세스하는 것을 금지하려면 그가 거기에서 엉망이 될 것이라고 구실을 합니다. 이것은 분명히 잘못된 생각입니다. 그러면 모든 종류의 까다로운 해결 방법을 만들어야 하기 때문입니다. 프로그래머에게 이 액세스 권한을 부여하는 방법 나중에 그리고 그 과정에서 가능한 버그로 불안정한 코드가 생성됩니다. 이것은 운전자가 핸들을 만지지 못하게 하고 차선책을 제시하는 것과 유사합니다. 그러면 어떻게 운전자가 핸들 대신 차를 운전할 수 있습니까?
2. 프로그래머가 자신의 프로그램에서 자신의 데이터에 액세스하는 것을 금지하려면 그가 거기에서 엉망이 될 것이라고 구실을 합니다. 이것은 분명히 잘못된 생각입니다. 그러면 모든 종류의 까다로운 해결 방법을 만들어야 하기 때문입니다. 프로그래머에게 이 액세스 권한을 부여하는 방법 나중에 그리고 그 과정에서 가능한 버그로 불안정한 코드가 생성됩니다. 이것은 운전자가 핸들을 만지지 못하게 하고 차선책을 제시하는 것과 유사합니다. 그러면 어떻게 운전자가 핸들 대신 차를 운전할 수 있습니까?
음 ... 아니. 코드의 아무 곳에서나 이 위치에 필요한 것만 사용할 수 있어야 합니다. 다른 모든 것은 가능하면 잘려야 합니다.
운전자와 귀하의 상황에서 이는 차가 주차된 상태에서 운전자가 핸들을 만지는 것을 금지하는 것이 합리적이라는 것을 의미합니다. 그가 주차장에서 핸들을 돌리기 위해 머리에 들지 않도록 - 결국, 이때 예를 들어, 휠 얼라인먼트 센서를 휠에 연결할 수 있으며 운전자가 핸들을 잡는 것으로 이어질 것입니다. 이러한 각도를 설정하는 데 오류가 있습니다.
아이디어는 매 순간 그 순간에 필요한 기능만 프로그램에서 사용할 수 있고 다른 모든 것은 닫힐 것이라는 것입니다. 나는 이것이 가장 적은 수의 오류가 발생하는 방법이라고 오랫동안 확신해 왔습니다.
음 ... 아니. 코드의 아무 곳에서나 이 위치에 필요한 것만 사용할 수 있어야 합니다. 다른 모든 것은 가능하면 잘려야 합니다.
아이디어는 매 순간 그 순간에 필요한 기능만 프로그램에서 사용할 수 있고 다른 모든 것은 닫힐 것이라는 것입니다. 나는 이것이 가장 적은 수의 오류가 발생하는 방법이라고 오랫동안 확신해 왔습니다.
자신을 금지해야 하는 것과 허용해야 하는 것에 대해 끊임없이 고민하는 것은 분명히 매우 비논리적인 요구 사항입니다. 물론 프로그래머가 술에 취해 코드를 작성하고 자신을 제어하지 않는 한, 이해할 수 없는 많은 코드를 작성할 수 있습니다. 그 자신. 나는 이것이 술취한 알코올 프로그래머가 코드의 오류를 피하는 데 도움이 되지 않을 것이라고 생각하며, 냉철한 사람들은 처음에 이것을 필요로 하지 않습니다.
자신을 금지해야 하는 것과 허용해야 하는 것에 대해 끊임없이 고민하는 것은 분명히 매우 비논리적인 요구 사항입니다. 물론 프로그래머가 술에 취해 코드를 작성하고 자신을 제어하지 않는 한, 이해할 수 없는 많은 코드를 작성할 수 있습니다. 그 자신. 나는 이것이 술취한 알코올 프로그래머가 코드의 오류를 피하는 데 도움이 되지 않을 것이라고 생각하며, 냉철한 사람들은 처음에 이것을 필요로 하지 않습니다.
1. 예를 들어 개체 배열이 필요합니다.
이는 절차적 형식과 CArrayObj 및 CObject 기반 모두에서 수행할 수 있습니다. 문제는 개체를 추가 또는 제거하거나 정렬할 때 동작을 변경해야 할 때 시작됩니다. OOP에서 포인터의 실제 배열에 대한 지원과 이에 대한 작업은 기본 개체에 포함됩니다. 배열에 실제로 포함된 하위 개체를 변경해도 아무 영향을 주지 않습니다. 절차 스타일(배열에 포함된 실제 개체 변경)을 사용하면 일반적으로 개체 크기의 변경을 고려해야 하기 때문에 더 많은 위치에 영향을 줍니다. 실수하기가 훨씬 쉽습니다.
2. 크로스 플랫폼 - OOP 스타일로 구성하는 것이 훨씬 편리합니다. 예를 들어, 거래 포지션의 요청에 따라 - 우리는 인터페이스를 얻었고 우리가 어떤 플랫폼에서 작업했는지는 중요하지 않습니다 - 인터페이스는 모든 주문에 대한 모든 데이터를 얻을 수 있는 가상 기능 을 제공합니다( 또한 MT4) 또는 직위(MT5)의 경우, 전문가의 관점에서 볼 때 차이가 전혀 없습니다. 전문가는 자신이 어떤 플랫폼에서 작업하는지 알 필요가 없습니다.
3. 음, 결국, "절차적 프로그래밍에서 염두에 두십시오" - 이것은 "객체-프로시저 작성", 즉 OOP에서 객체를 나타내는 데이터와 절차 사이의 일부 링크를 만드는 것입니다.
4. 그리고 우리는 많은 공통점이 있는 많은 종류의 주문을 가지고 있습니다. 기본 개체가 될 COrderInfo 개체와 그 하위 개체가 다른 유형의 주문을 나타내도록 하는 것이 합리적입니다. 동시에, 거래 프로세서(CTradeProcessor 클래스가 있음)는 전달된 주문과 이 주문을 처리하는 데 필요한 절차를 정확히 자동으로 지원합니다.
5. 교차 링크가 가장 적은 곳에서 버그를 잡기가 더 쉽습니다. 그것은 캡슐화와 다형성으로도 제공됩니다. 우리는 거래 포지션 인터페이스(CTradePositionI)를 요청하며 이 포지션을 나타내는 실제 클래스(CMT4PositionInfo, CMT5PositionInfo)에 대한 모든 링크는 이 인터페이스를 통해서만 만들어지므로 실제 기능으로 직접 작업할 때보다 오류를 수정하기가 더 쉽습니다. , 거래 포지션 데이터를 반환합니다.
1. 예를 들어 무엇을 위해?
2. 인터페이스를 생성하지 않도록 동일한 기능을 다른 플랫폼에서 컴파일할 수 없는 이유는 무엇입니까?
3. 함수를 클래스의 멤버로 호출하는 것과 유사하게 처리하기 쉽도록 함수의 텍스트를 구조체의 종류에 따라 포장하는 것을 의미합니다. 이를 위해서는 원칙적으로 객체를 생성할 필요가 없습니다.
4. 설정으로 하나의 기능을 만들고 인터페이스를 통해 여러 객체와 불필요한 연결을 생성하지 않는 것이 더 합리적입니다.
5. 또한 이러한 모든 연결을 프로그래밍한 다음 인터페이스 등을 통해 추적해야 합니다. 이 경우 버그도 미묘할 수 있습니다. 직업은 처음에는 불필요하고 의미가 없습니다.
1. 예를 들어 무엇을 위해?
2. 인터페이스를 생성하지 않도록 동일한 기능을 다른 플랫폼에서 컴파일할 수 없는 이유는 무엇입니까?
3. 함수를 클래스의 멤버로 호출하는 것과 유사하게 처리하기 쉽도록 함수의 텍스트를 구조체의 종류에 따라 포장하는 것을 의미합니다. 이를 위해서는 원칙적으로 객체를 생성할 필요가 없습니다.
4. 설정으로 하나의 기능을 만들고 인터페이스를 통해 여러 객체와 불필요한 연결을 생성하지 않는 것이 더 합리적입니다.
5. 또한 이러한 모든 연결을 프로그래밍한 다음 인터페이스 등을 통해 추적해야 합니다. 이 경우 버그도 미묘할 수 있습니다. 직업은 처음에는 불필요하고 의미가 없습니다.
1. 음, CTradePosition 클래스 는 사실 미결 주문 목록입니다. 순서가 다르며 인터페이스, 기본 클래스 및 실제 클래스를 갖는 것이 매우 편리합니다.
2. 단 하나의 인터페이스. 모든 플랫폼용. 그리고 OOP의 경우 - 우리는 우리가 일하는 곳을 생각하지 않습니다. 플랫폼 종속 및 주문 종속 모멘트를 고려할 필요는 없습니다.
3. 그런 패키지에서 객체와 함수의 차이점은 무엇입니까? 나는 이것에 대해 이야기하고 있습니다 - 사실, 그것은 같은 것입니다. 객체의 경우 자동 생성자 함수도 추가되지만 기본적으로 비어 있습니다.
4. 바로 이 "설정이 있는 단일 기능"이 문제의 원인입니다. 일반적으로 많은 설정이 있기 때문입니다. 그리고 그것들은 클래스 계층의 다른 수준으로 분리되지 않고 바로 이 기능에 집중되어 있습니다. 반면에 인터페이스를 사용하면 이 컨텍스트에서 사용되지 않는 모든 설정("고려 범위 밖")을 그대로 둘 수 있습니다. 이는 코드 이해와 오류 가능성에 매우 좋은 영향을 미칩니다. , 그리고 그들의 탐지에. 이것이 바로 OOP의 주요 이점입니다. 우리는 객체의 계층 구조의 다른 수준에 "흩어져 있는" 모든 기능을 가지고 있으며, 그 중 하나 또는 다른 부분으로 작업할 때 나머지 부분은 방해하지 않습니다. 설정이 있는 단일 기능에서 모든 기능은 불필요하더라도 항상 사용할 수 있습니다. 이것은 일반적으로 단순히 변수를 실수로 혼동할 수 있기 때문에 문제의 원인입니다. 주요 단점은 그러한 단일 기능에서 오식비를 감지하기가 훨씬 더 어렵다는 것입니다.
5. 어떤 경우에도 이러한 연결이 필요하고 프로그래밍해야 합니다. 이는 실제로 단일 기능에서 동일한 설정입니다. 여기 내 예를 들어 - 단일 기능에서 플랫폼의 차이, 다양한 유형의 주문, 위치 표현의 차이 - 이 모든 것이 고려되어야 합니다. 인터페이스가 있을 때 - 모든 것이 우리를 위해 "단절"됩니다 - 인터페이스에 의해 정의된 것만 고려할 수 있습니다.
한 코드 블록에서 다른 블록으로의 액세스를 제한하는 것이 캡슐화의 요점입니다. 이 기능에 액세스할 수 있는 모든 사람이 최대의 기회를 가질 수 있도록 "최대 설정의 하나의 큰 보편적 기능"을 갖는 반대를 제안합니다. 제 경험상 이것은 잘못된 방법입니다. 반대로 올바른 방법은 프로그램의 한 블록이 다른 블록의 기능을 필요로 하는 경우 사용자를 최대한 제한하는 것입니다. 이 기능만 있어야 하며 그레인 이상은 없어야 합니다. 이것은 보다 안정적이고 오류 없는 코드의 핵심입니다.
1. 음, CTradePosition 클래스 는 사실 미결 주문 목록입니다. 순서가 다르며 인터페이스, 기본 클래스 및 실제 클래스를 갖는 것이 매우 편리합니다.
구조 배열이나 MT4에서 구현되는 방식으로 주문을 유지하는 것이 왜 나쁜가요?
구조 배열이나 MT4에서 구현되는 방식으로 주문을 유지하는 것이 왜 나쁜가요?
각 사용자가 이 어레이에 액세스할 때 너무 많은 권한과 추가 정보를 갖고 있다는 사실입니다.
제 생각에는 주문에 액세스하기 위해 사전에 동의한 인터페이스를 사용하여 사용자에게 필요한 기능의 일부만 제공하는 것이 더 정확합니다.
각 사용자가 이 어레이에 액세스할 때 너무 많은 권한과 불필요한 정보를 갖고 있다는 사실입니다.
제 생각에는 주문에 액세스하기 위해 사전에 동의한 인터페이스를 사용하여 사용자에게 필요한 기능의 일부만 제공하는 것이 더 정확합니다.
주문의 경우 고유한 데이터 유형 을 만들 수 있습니다. 인터페이스, 개체 및 불필요한 버그와 불안정을 유발하는 기타 불필요한 복잡성이 필요하지 않습니다.
주문의 경우 고유한 데이터 유형 을 만들 수 있습니다. 인터페이스, 개체 및 불필요한 버그와 불안정을 유발하는 기타 불필요한 복잡성이 필요하지 않습니다.
내 연습은 결국 그것이 필요하다는 것을 보여줍니다.
나는 5년 전, 그 당시 MT4에서 이 길을 따랐습니다. (OOP에 대해 몰랐기 때문이 아니라 인터페이스와 상속을 귀찮게 하기에는 너무 게으르다. 특히 그 당시 MT4와 MT5는 MQL 구현 측면에서 크게 다르기 때문에). 이것은 그가 틀렸다는 것을 깨닫게 했습니다. 이것은 "복잡함"이 아니라 상당히 합리적인 제한, 일종의 "바보에 대한 보호"입니다. 수백 개의 변수 각각이 무엇을 담당하는지 항상 기억한다면 캡슐화가 필요하지 않습니다. 나는 이것을 기억하지 못한다. 그리고 나는 프로그램의 각 블록에서 가능한 한 적은 수의 엔티티에 접근하는 것을 선호한다.
OOP가 MT4에 등장하자마자 나는 인터페이스를 기반으로 모든 개발을 단일 형식으로 즉시 번역하기 시작했습니다.
1. 내 연습은 결국 그것이 필요하다는 것을 보여줍니다. 이것은 그가 틀렸다는 것을 깨닫게 했습니다.
2. 나는 이것을 기억하지 못한다. 그리고 나는 프로그램의 각 블록이 가능한 적은 수의 엔티티에 접근하는 것을 선호한다.
1. 무엇이 필요하고 무엇이 잘못된 것인지 설명되지 않았습니다. 이것은 특별한 데이터 유형 이므로 원하는 대로 액세스를 구성할 수 있습니다. 이 예는 분명히 실패했습니다.
2. 프로그래머가 자신의 프로그램에서 자신의 데이터에 액세스하는 것을 금지하려면 그가 거기에서 엉망이 될 것이라고 구실을 합니다. 이것은 분명히 잘못된 생각입니다. 그러면 모든 종류의 까다로운 해결 방법을 만들어야 하기 때문입니다. 프로그래머에게 이 액세스 권한을 부여하는 방법 나중에 그리고 그 과정에서 가능한 버그로 불안정한 코드가 생성됩니다. 이것은 운전자가 핸들을 만지지 못하게 하고 차선책을 제시하는 것과 유사합니다. 그러면 어떻게 운전자가 핸들 대신 차를 운전할 수 있습니까?
2. 프로그래머가 자신의 프로그램에서 자신의 데이터에 액세스하는 것을 금지하려면 그가 거기에서 엉망이 될 것이라고 구실을 합니다. 이것은 분명히 잘못된 생각입니다. 그러면 모든 종류의 까다로운 해결 방법을 만들어야 하기 때문입니다. 프로그래머에게 이 액세스 권한을 부여하는 방법 나중에 그리고 그 과정에서 가능한 버그로 불안정한 코드가 생성됩니다. 이것은 운전자가 핸들을 만지지 못하게 하고 차선책을 제시하는 것과 유사합니다. 그러면 어떻게 운전자가 핸들 대신 차를 운전할 수 있습니까?
음 ... 아니. 코드의 아무 곳에서나 이 위치에 필요한 것만 사용할 수 있어야 합니다. 다른 모든 것은 가능하면 잘려야 합니다.
운전자와 귀하의 상황에서 이는 차가 주차된 상태에서 운전자가 핸들을 만지는 것을 금지하는 것이 합리적이라는 것을 의미합니다. 그가 주차장에서 핸들을 돌리기 위해 머리에 들지 않도록 - 결국, 이때 예를 들어, 휠 얼라인먼트 센서를 휠에 연결할 수 있으며 운전자가 핸들을 잡는 것으로 이어질 것입니다. 이러한 각도를 설정하는 데 오류가 있습니다.
아이디어는 매 순간 그 순간에 필요한 기능만 프로그램에서 사용할 수 있고 다른 모든 것은 닫힐 것이라는 것입니다. 나는 이것이 가장 적은 수의 오류가 발생하는 방법이라고 오랫동안 확신해 왔습니다.
음 ... 아니. 코드의 아무 곳에서나 이 위치에 필요한 것만 사용할 수 있어야 합니다. 다른 모든 것은 가능하면 잘려야 합니다.
아이디어는 매 순간 그 순간에 필요한 기능만 프로그램에서 사용할 수 있고 다른 모든 것은 닫힐 것이라는 것입니다. 나는 이것이 가장 적은 수의 오류가 발생하는 방법이라고 오랫동안 확신해 왔습니다.자신을 금지해야 하는 것과 허용해야 하는 것에 대해 끊임없이 고민하는 것은 분명히 매우 비논리적인 요구 사항입니다. 물론 프로그래머가 술에 취해 코드를 작성하고 자신을 제어하지 않는 한, 이해할 수 없는 많은 코드를 작성할 수 있습니다. 그 자신. 나는 이것이 술취한 알코올 프로그래머가 코드의 오류를 피하는 데 도움이 되지 않을 것이라고 생각하며, 냉철한 사람들은 처음에 이것을 필요로 하지 않습니다.
자신을 금지해야 하는 것과 허용해야 하는 것에 대해 끊임없이 고민하는 것은 분명히 매우 비논리적인 요구 사항입니다. 물론 프로그래머가 술에 취해 코드를 작성하고 자신을 제어하지 않는 한, 이해할 수 없는 많은 코드를 작성할 수 있습니다. 그 자신. 나는 이것이 술취한 알코올 프로그래머가 코드의 오류를 피하는 데 도움이 되지 않을 것이라고 생각하며, 냉철한 사람들은 처음에 이것을 필요로 하지 않습니다.
이것은 많은 사람들이 찾는 매우 논리적인 요구 사항입니다.
당신은 그것을 필요로하지 않습니다 - 글쎄 ... OOP를 사용하지 마십시오.