Анти-паттерны (anti-patterns), также известные как ловушки (pitfalls) — это классы наиболее часто внедряемых плохих решений проблем. Они изучаются, как категория, в случае когда их хотят избежать в будущем, и некоторые отдельные случаи их могут быть распознаны при изучении неработающих систем. Концепция также прекрасно подходит к...
내 게시물은 OOP를 싫어해서 대가를 치르게 된 차단된 topicstarter의 질문에 대한 응답으로 작성되었습니다.
topicstarter용 체크리스트:
객체 지향 프로그래밍은 (역순으로 구문을 읽으십시오) 객체 지향 프로그래밍 입니다. 또는 객체 기반 프로그래밍.
개체는 실제 개체(예: "기계") 또는 가상 개체(예: " pupkin 's grail") 의 매개변수 및 동작 을 설명하는 프로그램 코드(일반적으로 다른 코드와 분리됨)로 이해됩니다. 각 개체는 말하자면 자신의 삶을 살고 자체 주스로 끓일 수 있습니다. 외부 세계와의 통신을 위해 외부에서 액세스할 수 있는 특수 기능과 같은 제한된 "신경 채널" 세트가 사용됩니다.
내 생각에 OOP의 주요 장점은 개체의 코드를 다른 코드와 독립적으로 디버깅할 수 있다는 것입니다. 그런 다음 모자이크처럼 더 복잡한 개체를 조립합니다. 예를 들어, "여자" 개체에는 "동체", "하체 차량", "탱크", "조종석" 등의 다른 개체가 포함될 수 있습니다.
MQL에서 OOP의 좋은 예는 MQL5 Wizard 입니다. 이를 통해 미리 만들어진 디버그 개체에서 어드바이저를 어셈블할 수 있습니다. 또한 이러한 개체를 결합할 수 있습니다.
OOP에 찬성하는 가장 치명적인 주장: OOP의 본질을 탐구하는 사람들은 그것에 앉습니다. 프로그래밍이 더 쉽고 코드가 더 명확하고 구조화되어 있습니다.
Вы хотите быстро проверить торговую идею, не тратя времени на программирование? Выберите в "Мастере MQL5" нужный тип торговых сигналов, подключите модули сопровождения позиций и управления капиталом - на этом вся работа закончена. Создайте свои реализации модулей или закажите их через сервис "Работа" - и комбинируйте новые модули с уже существующими.
OOP에 찬성하는 가장 치명적인 주장: OOP의 본질을 탐구하는 사람들은 그것에 앉습니다. 프로그래밍이 더 쉽고 코드가 더 명확하고 구조화되어 있습니다.
뭔가 예, 예, OOP를 마스터하기 전까지는 그곳에 등반할 가치조차 없을 정도로 눈보라가 몰아치는 것 같았습니다.
내가 이해하자마자 모든 것이 손으로 처리되었으므로 더 이상 변수에 대해 고유한 이름을 만들 필요가 없습니다.
첫 번째 중첩의 카운터 i, 두 번째 중첩의 카운터 j, 배열 크기의 크기 는 전체 수천 번째 코드를 뒤지지 않습니다. 하지만 내 변수가 0으로 재설정되지 않은 곳은 어디입니까? :o) 그리고 가장 중요한 것은 모든 것이 전체 보기에 표시된다는 것입니다. 프로그램을 열면 모든 것이 즉시 명확해집니다. 여기에 개체의 호출이 있습니다. 개체의 상호 작용이 있습니다. 개체가 수행하는 작업을 이해해야 하는 경우 개체 코드로 이동합니다.
뭔가 예, 예, OOP를 마스터하기 전까지는 그곳에 등반할 가치조차 없을 정도로 눈보라가 몰아치는 것 같았습니다.
내가 이해하자마자 모든 것이 손으로 처리되었으므로 더 이상 변수에 대해 고유한 이름을 만들 필요가 없습니다.
첫 번째 중첩의 카운터 i, 두 번째 중첩의 카운터 j, 배열 크기의 크기는 전체 수천 번째 코드를 뒤지지 않습니다. 하지만 내 변수가 0으로 재설정되지 않은 곳은 어디입니까? :o) 그리고 가장 중요한 것은 모든 것이 전체 보기에 표시된다는 것입니다. 프로그램을 열면 모든 것이 즉시 명확해집니다. 여기에 개체의 호출이 있습니다. 개체의 상호 작용이 있습니다. 개체가 수행하는 작업을 이해해야 하는 경우 개체 코드로 이동합니다.
+10
소규모 프로젝트의 경우 OOP를 사용할 필요가 없다는 주장에 대해서도 반박할 수 있습니다.
가능한 한 OOP를 밀어 넣어야 하는 것 같습니다. 코드는 약간 길어지지만 투명도는 여러 번 증가합니다.
나는 OOP의 지지자입니다. 왜냐하면 나 자신을 위해 밑바닥부터 프로그래밍의 편리함을 이해했기 때문입니다. 개체 상호 작용 인터페이스에서 클래스 구현에 이르기까지. 클래스 구현으로 시작하는 모든 사람은 올바른 OOP로 작성하지 않고 기능적 래퍼를 작성합니다. 변수와 함수를 위한 편리한 이름 공간을 제외하고 이러한 래퍼는 아무 것도 하지 않습니다. 이것은 일반적인 라이브러리 접근 방식입니다. 하지만 이 최소한의 것조차 누군가에게는 어울리고, 당당하게 "나는 OOP로 쓴다"고 말하지만, 그것이 그들의 권리다.
OOP 패러다임을 비판하기에 충분한 경험을 가진 노련한 프로그래머와 현대 소프트웨어의 전체 흐름의 창시자가 있습니다. 이것은 오래된 주제이며 원칙적으로 모든 것이 언제 어디서 무엇을 잃는 지 가장 작은 세부 사항까지 오랫동안 빨아 들여 왔습니다.
Прошло ровно 10 лет с публикации известной и классической в мире программирования статьи, написанной Ричардом Гэбриелом, название которой стало уже нарицательным и вынесено в заголовок моей заметки. Его статья стала настолько острой и злободневной для своего времени, что вызвала бурный всплеск обсуждений в сообществе программистов, целый ряд...
내 생각에 당신은 매우 잘못되었습니다!
대규모 프로젝트(최소한 수천 줄의 코드)가 있으면 클래스 프로그래밍(OOP)이 작업을 매우 쉽게 만들고 개발 프로세스, 그리고 가장 중요한 디버깅을 쉽게 제어할 수 있게 해줍니다.
또한 OOP는 일상 생활에서 객체(집, 나무, 사람, 자동차, 주문 등)의 인스턴스를 다루기 때문에 프로젝트를 실제 생활에 더 가깝게 만듭니다. 속성 및 메서드 집합으로 :)
예, OOP에서 뭔가를 하려고 하면 그것이 더 우아하고 이해하기 쉽다는 것을 스스로 알게 될 것입니다. 절차적 프로그래밍보다 쉽습니다!
MoneyJinn :
MetaTrader 5에서 일반 절차 프로그래밍을 사용하십시오.
OOP는 절차적 프로그래밍의 진화입니다.
결국, 아무도 당신이 기능 없이 할 수 있다고 주장하지 않습니다. 결국 특정 지점까지는 훨씬 더 빠릅니다. 다른 데이터로 동일한 작업을 수행하는 코드 섹션이 있다는 것은 중요하지 않습니다. 복사-붙여넣기는 매우 쉽습니다.
함수를 재사용하면 OOP가 손실됩니다. 기능 확장은 항상 새로운 기능을 생성하고 다양한 조건에 따라 이 기능을 호출할 수 있도록 코드를 다시 작성하는 것입니다. 잘 작성된 OOP 프로그램에서 확장은 모든 코드를 다시 작성할 필요가 없는 단순한 것입니다.
OOP 없이 프로그램을 작성할 때 스케일링 문제, 불필요한 데이터와 수백 개의 함수, 무작위로 겹친 변수, 기능의 "핫" 교체 필요성으로 인한 불편함을 경험하지 않는다면 OOP가 필요하지 않습니다.
예, OOP를 위해 OOP로 작성하는 것은 가치가 없으며 아무 것도 얻을 수 없습니다. 함수를 클래스로 바꿀 필요가 없습니다. 안티 패턴 피하기
OOP는 "Niva" 또는 "Lada"와 같은 실수입니다.
MetaTrader 5에서 일반 절차 프로그래밍을 사용하십시오.
MetaTrader 4에서와 같이 여기에서도 사용할 수 있습니다.
MetaQuotes가 이에 중점을 두지 않는 것은 유감입니다.
OOP는 절차적 프로그래밍의 진화입니다. ...
OOP 없이 프로그램을 작성할 때 확장 문제, 풍부한 추가 데이터 및 수백 가지 기능, 무작위로 겹친 변수, 기능의 "핫" 교체 필요성에 대한 불편함이 없다면 OOP가 필요하지 않습니다.
예, OOP를 위해 OOP로 작성하는 것은 가치가 없으며 아무 것도 얻을 수 없습니다. 함수를 클래스로 바꿀 필요가 없습니다. ...
100% 동의합니다.
또한 OOP는 일상 생활에서 객체(집, 나무, 사람, 자동차, 주문 등)의 인스턴스를 다루기 때문에 프로젝트를 실제 생활에 더 가깝게 만듭니다. 속성 및 메서드 집합으로 :)
가상의 집, 나무, 사람 중 어느 것이 현실에 더 가깝습니까? 아니면 프로세서에서 실제로 실행되는 순서대로 프로그램을 보는 것입니까?
이것은 종교적인 문제입니다. 그리고 모든 사람은 자신의 선택이 있습니다.
내 게시물은 OOP를 싫어해서 대가를 치르게 된 차단된 topicstarter의 질문에 대한 응답으로 작성되었습니다.
MT5와 같은 제품을 마스터하거나 MT4에서 MT5로 전환하려는 일반 트레이더를 위한 답변입니다.
내 게시물은 OOP를 싫어해서 대가를 치르게 된 차단된 topicstarter의 질문에 대한 응답으로 작성되었습니다.
topicstarter용 체크리스트:
객체 지향 프로그래밍은 (역순으로 구문을 읽으십시오) 객체 지향 프로그래밍 입니다. 또는 객체 기반 프로그래밍.
개체는 실제 개체(예: "기계") 또는 가상 개체(예: " pupkin 's grail") 의 매개변수 및 동작 을 설명하는 프로그램 코드(일반적으로 다른 코드와 분리됨)로 이해됩니다. 각 개체는 말하자면 자신의 삶을 살고 자체 주스로 끓일 수 있습니다. 외부 세계와의 통신을 위해 외부에서 액세스할 수 있는 특수 기능과 같은 제한된 "신경 채널" 세트가 사용됩니다.
내 생각에 OOP의 주요 장점은 개체의 코드를 다른 코드와 독립적으로 디버깅할 수 있다는 것입니다. 그런 다음 모자이크처럼 더 복잡한 개체를 조립합니다. 예를 들어, "여자" 개체에는 "동체", "하체 차량", "탱크", "조종석" 등의 다른 개체가 포함될 수 있습니다.
MQL에서 OOP의 좋은 예는 MQL5 Wizard 입니다. 이를 통해 미리 만들어진 디버그 개체에서 어드바이저를 어셈블할 수 있습니다. 또한 이러한 개체를 결합할 수 있습니다.
OOP에 찬성하는 가장 치명적인 주장: OOP의 본질을 탐구하는 사람들은 그것에 앉습니다. 프로그래밍이 더 쉽고 코드가 더 명확하고 구조화되어 있습니다.
...
OOP에 찬성하는 가장 치명적인 주장: OOP의 본질을 탐구하는 사람들은 그것에 앉습니다. 프로그래밍이 더 쉽고 코드가 더 명확하고 구조화되어 있습니다.
뭔가 예, 예, OOP를 마스터하기 전까지는 그곳에 등반할 가치조차 없을 정도로 눈보라가 몰아치는 것 같았습니다.
내가 이해하자마자 모든 것이 손으로 처리되었으므로 더 이상 변수에 대해 고유한 이름을 만들 필요가 없습니다.
첫 번째 중첩의 카운터 i, 두 번째 중첩의 카운터 j, 배열 크기의 크기 는 전체 수천 번째 코드를 뒤지지 않습니다. 하지만 내 변수가 0으로 재설정되지 않은 곳은 어디입니까? :o) 그리고 가장 중요한 것은 모든 것이 전체 보기에 표시된다는 것입니다. 프로그램을 열면 모든 것이 즉시 명확해집니다. 여기에 개체의 호출이 있습니다. 개체의 상호 작용이 있습니다. 개체가 수행하는 작업을 이해해야 하는 경우 개체 코드로 이동합니다.
뭔가 예, 예, OOP를 마스터하기 전까지는 그곳에 등반할 가치조차 없을 정도로 눈보라가 몰아치는 것 같았습니다.
내가 이해하자마자 모든 것이 손으로 처리되었으므로 더 이상 변수에 대해 고유한 이름을 만들 필요가 없습니다.
첫 번째 중첩의 카운터 i, 두 번째 중첩의 카운터 j, 배열 크기의 크기는 전체 수천 번째 코드를 뒤지지 않습니다. 하지만 내 변수가 0으로 재설정되지 않은 곳은 어디입니까? :o) 그리고 가장 중요한 것은 모든 것이 전체 보기에 표시된다는 것입니다. 프로그램을 열면 모든 것이 즉시 명확해집니다. 여기에 개체의 호출이 있습니다. 개체의 상호 작용이 있습니다. 개체가 수행하는 작업을 이해해야 하는 경우 개체 코드로 이동합니다.
+10
소규모 프로젝트의 경우 OOP를 사용할 필요가 없다는 주장에 대해서도 반박할 수 있습니다.
가능한 한 OOP를 밀어 넣어야 하는 것 같습니다. 코드는 약간 길어지지만 투명도는 여러 번 증가합니다.
+10
소규모 프로젝트의 경우 OOP를 사용할 필요가 없다는 주장에 대해서도 반박할 수 있습니다.
가능한 한 OOP를 밀어 넣어야 하는 것 같습니다. 코드는 약간 길어지지만 투명도는 크게 높아집니다.
나는 OOP의 지지자입니다. 왜냐하면 나 자신을 위해 밑바닥부터 프로그래밍의 편리함을 이해했기 때문입니다. 개체 상호 작용 인터페이스에서 클래스 구현에 이르기까지. 클래스 구현으로 시작하는 모든 사람은 올바른 OOP로 작성하지 않고 기능적 래퍼를 작성합니다. 변수와 함수를 위한 편리한 이름 공간을 제외하고 이러한 래퍼는 아무 것도 하지 않습니다. 이것은 일반적인 라이브러리 접근 방식입니다. 하지만 이 최소한의 것조차 누군가에게는 어울리고, 당당하게 "나는 OOP로 쓴다"고 말하지만, 그것이 그들의 권리다.
OOP 패러다임을 비판하기에 충분한 경험을 가진 노련한 프로그래머와 현대 소프트웨어의 전체 흐름의 창시자가 있습니다. 이것은 오래된 주제이며 원칙적으로 모든 것이 언제 어디서 무엇을 잃는 지 가장 작은 세부 사항까지 오랫동안 빨아 들여 왔습니다.
http://blogerator.ru/page/oop_why-objects-have-failed
OOP 서포터님들의 답변입니다.
http://bugtraq.ru/library/programming/objectshavenotfailed.html
C++ 속도 비교(소규모 테스트) 객체 지향 및 절차 프로그래밍(+ 다른 컴파일러)
https://www.mql5.com/ru/forum/132434/page3