소규모 프로젝트를 통해 모든 문제를 절차 코드로 나눌 수 있음을 보여줄 수 있습니다. 그러나 100명 이상의 개발자, 여러 비즈니스 분석가 및 설계자가 모두 "모델"을 동시에 수정하려는 팀과 함께 수백만 줄의 코드 기반이 있는 경우 상황이 훨씬 더 어려워집니다. 이러한 상황에서 "비즈니스" 모델은 일반적으로 UML과 같은 디자인 도구에서 정의되며 전체 팀이 액세스할 수 있습니다.
비즈니스 모델에만 5000개 이상의 클래스가 포함되어 있습니다. 이 비즈니스 모델에는 개체 모델, SQL 인터페이스 및 기본 클래스 수를 15,000개 클래스로 만드는 네트워크 계층에 대한 클래스를 "생성"하는 도구가 있습니다.
이 토론을 위해 Id는 1960/1970년대 이후 절차에 추가된 세 가지 "확장"으로 절차 대 OOP 인수를 분해하고 싶습니다.
1) "객체 기반" 이것은 객체와 코드가 캡슐화되어 동작도 가질 수 있는 고급 "구조"를 만드는 곳입니다.
2) "클래스 기반" 이것은 객체가 서로 상속되고 계층 구조로 정렬될 수 있는 곳입니다.
3) "객체 지향" 이것은 사용자가 클래스 계층 내에서 "다형성" 동작(가상 메서드 또는 인터페이스)을 정의할 수 있는 곳입니다.
예를 들어 80/90년대의 대부분의 GUI 툴킷은 c로 만들어졌고 이러한 기능이 있었지만 위의 모든 것이 절차적 언어로 충분히 노력하면 구현할 수 있다는 주장이 있습니다. 이 토론에 실제로 적용되지 않습니다.
따라서 질문에 답하기 위해 3가지 OOP 기능을 사용하지 않고 100명 이상의 개발자와 수백만 라인 프로젝트를 구현할 수 있습니까?
내 개인적인 의견은 1)과 2) 없이 대규모 프로젝트를 제공하는 것이 사실상 불가능하다는 것입니다. 왜냐하면 "클래스 기반" 시스템 없이는 실제 데이터 구조 와 동작을 깨끗하고 간결한 방식으로 코드에 매핑하기가 너무 어렵기 때문입니다. 그리고 프로젝트 크기가 커질수록 "c로 구현할 수 있습니다"로 시작하는 것이 유지 관리가 더 어려워지는 구조가 덜한 방법의 끝없는 목록이 됩니다.
이제 1)과 2)를 제공하는 언어는 완전한 OOP 언어가 아닙니다. 그래서 우리는 "다형성(가상) 방법"이 정말로 필요한지 고려해야 합니다. 다형성이 항상 문제를 해결하는 올바른 도구는 아니며 설계를 지나치게 복잡하게 만들 수 있기 때문에 이것은 "어쩌면" 또는 "가끔"에 가깝습니다. 예를 들어 개체 저장소 또는 SQL 데이터베이스에 매핑되는 일부 데이터 구조를 모델링할 때 가상 동작을 추가하면 데이터 매핑이 더 어려워질 수 있지만 "인터페이스" 또는 "가상 메서드"가 있는 기본 클래스를 사용하여 확장 가능한 툴킷 또는 API를 정의할 때 매우 중요합니다. 전반적으로 나는 적절한 맥락에서 드물게 사용되는 다형성의 열렬한 팬입니다.
저는 수백만 줄의 "C" 코드베이스와 수백만 줄의 C++/Java/C# 코드베이스에서 작업했으며 대부분의 "C" 코드베이스는 5년 후에 "유지 관리 모드"로 전환됩니다. 코드가 너무 취약하고 수정으로 인해 종종 몇 달 간의 고통스러운 재개발 및 테스트가 발생하기 때문에 아키텍처를 변경하는 것이 두렵습니다. 일반적으로 객체 지향 프로젝트는 수정 및 리팩토링에 훨씬 더 탄력적입니다.
Alain Verleyen : "if...then...else..." 문은 작업을 수행해야 합니다.
if...then...else는 "가상" 메서드를 코딩할 수 없습니다.
"C"에는 "다형성"의 여러 구현이 있으며 대부분은 필요한 매핑을 유지하기 위해 함수 포인터의 벡터를 사용합니다. 더 나아가 이러한 "함수 포인터의 벡터"는 "계층"에서 모델링하려는 각 "유형"에 대해 정의해야 합니다. 물론 "C"는 계층 구조를 직접 지원하지 않으므로 해당 문제도 해결해야 합니다.
"C"로 구현된 "가상" 방법인 웜 백에 정말로 들어가고 싶다면 모든 Linux 배포판에서 무료로 사용할 수 있는 X Windows 툴킷을 찾아볼 수 있습니다.
물론 Windows는 약간 달라야 하며 정수 메시지 ID로 확장 가능한 구조를 사용합니다. 이는 "다형성" 동작이 id의 switch 문을 통해 구현됨을 의미합니다. (아마도 그것을 하는 가장 더러운 방법이지만 당신을 거기에 데려다 줄 것입니다)
Windows 운영 체제가 좋은 GUI를 제공한다는 데 동의하십니까? 내가 아는 한 OOP가 아닌 C. 절차 언어로 작성되었습니다.
복잡한 프로그램이 OOP로만 구축될 수 있다고 생각한다면 당신은 잘못된 Dirk입니다. OOP로 코딩하는 것이 더 나은 이유를 설명해야 합니다.
Windows 커널 은 "C"에 있지만 커널은 Windows 코드베이스의 작은 구성 요소일 뿐이며 많은 상위 수준 코드베이스는 여러 언어를 지원하는 "C" 스타일 외부 인터페이스를 사용하여 C++로 구현됩니다.
레거시 창 GUI 구성 요소조차도 "C"에서 효과적으로 "OOP" 구현되는 자체 손으로 롤링된 "다형성 동작"을 구현합니다. 예를 들어 GUI 컨트롤에서 "Handle"을 다시 가져오면 다형성 동작을 사용할 수 있는 확장 가능한 "C" 구조를 얻게 됩니다. 이것은 "C" 구문의 못생긴 집합으로 포장된 OOP입니다.
Windows가 "C"로 작성되었기 때문에 OOP가 아니라고 말하는 것은 완전히 정확하지 않습니다.
위 링크에서 인용: "그러나 어떤 종류의 호출이든 호출 비용은 인수 평가에 의해 좌우됩니다. 우리는 C 스타일이든 C++ 가상 메서드이든 간접 호출이 본질적으로 저렴하다는 것을 확인했습니다. 가상 메서드는 구조체 멤버(something->function(arg1,arg2))를 사용하는 간접 호출보다 더 비싸지 않으므로 가상 함수를 엄청나게 느린 것으로 간주하는 것은 잘못된 정보일 뿐입니다."
Java는 캡슐화된 모든 데이터 자체가 힙 기반 클래스여야 하므로 C++보다 훨씬 더 느릴 수 있으므로 더 많은 객체 역참조를 얻을 수 있습니다. 그러나 Java조차도 루프 및 기본 수학 연산에서 C와 정확히 동일한 속도일 수 있습니다.
C와 C#을 비교하면 OOP 기능 중 일부를 포함하더라도 C와 C#에서 훨씬 더 빠른 일부 코드를 작성하기가 정말 어렵습니다.
Metaquotes 표준 라이브러리가 느리다면 라이브러리 기능의 설계로 인해 90%가 될 것이며 사용된 OOP 기능과 거의 관련이 없습니다.
(비교하자면 C++ 표준 템플릿 라이브러리는 지금까지 작성된 모든 C 프로젝트의 95%를 수행합니다)
누군가 전문가가 "증거"로 compex 라이브러리를 게시할 것으로 기대합니까? ;) 여기 시장에서 팔 수 없는 준비된 것에 대한 링크를 게시할 수 있지만, 만약 내가 그렇게 한다면 Alain은 나를 차버릴 것입니다 ;) 내 프로필 을 방문하거나 벽 사진을 보고 아이디어를 얻을 수 있습니다. 나 오후.
또 다른 플랫폼? 이렇게 강력한 컴파일러가 있는 다른 플랫폼은 찾을 수 없습니다. 별말씀을요.
누군가 전문가가 "증거"로 compex 라이브러리를 게시할 것으로 기대합니까? ;) 여기 시장에서 팔 수 없는 준비된 것에 대한 링크를 게시할 수 있지만, 만약 내가 그렇게 한다면 Alain은 나를 차버릴 것입니다 ;) 내 프로필을 방문하거나 벽 사진을 보고 아이디어를 얻을 수 있습니다. 나 오후.
또 다른 플랫폼? 이렇게 강력한 컴파일러가 있는 다른 플랫폼은 찾을 수 없습니다. 별말씀을요.
@James Cater - 귀하의 의견에 감사드립니다.
포인트를 놓쳤습니다. Dirk. 전문가가 아닌 사람들은 간단하고 명확한 코드 예제를 원하는데, 사실 이것이 이 주제의 목표였습니다. 그러나 그것은 전문가들의 이해를 완전히 넘어선 것 같습니다.
소규모 프로젝트를 통해 모든 문제를 절차 코드로 나눌 수 있음을 보여줄 수 있습니다. 그러나 100명 이상의 개발자, 여러 비즈니스 분석가 및 설계자가 모두 "모델"을 동시에 수정하려는 팀과 함께 수백만 줄의 코드 기반이 있는 경우 상황이 훨씬 더 어려워집니다. 이러한 상황에서 "비즈니스" 모델은 일반적으로 UML과 같은 디자인 도구에서 정의되며 전체 팀이 액세스할 수 있습니다.
비즈니스 모델에만 5000개 이상의 클래스가 포함되어 있습니다. 이 비즈니스 모델에는 개체 모델, SQL 인터페이스 및 기본 클래스 수를 15,000개 클래스로 만드는 네트워크 계층에 대한 클래스를 "생성"하는 도구가 있습니다.
이 토론을 위해 Id는 1960/1970년대 이후 절차에 추가된 세 가지 "확장"으로 절차 대 OOP 인수를 분해하고 싶습니다.
1) "객체 기반" 이것은 객체와 코드가 캡슐화되어 동작도 가질 수 있는 고급 "구조"를 만드는 곳입니다.
2) "클래스 기반" 이것은 객체가 서로 상속되고 계층 구조로 정렬될 수 있는 곳입니다.
3) "객체 지향" 이것은 사용자가 클래스 계층 내에서 "다형성" 동작(가상 메서드 또는 인터페이스)을 정의할 수 있는 곳입니다.
예를 들어 80/90년대의 대부분의 GUI 툴킷은 c로 만들어졌고 이러한 기능이 있었지만 위의 모든 것이 절차적 언어로 충분히 노력하면 구현할 수 있다는 주장이 있습니다. 이 토론에 실제로 적용되지 않습니다.
따라서 질문에 답하기 위해 3가지 OOP 기능을 사용하지 않고 100명 이상의 개발자와 수백만 라인 프로젝트를 구현할 수 있습니까?
내 개인적인 의견은 1)과 2) 없이 대규모 프로젝트를 제공하는 것이 사실상 불가능하다는 것입니다. 왜냐하면 "클래스 기반" 시스템 없이는 실제 데이터 구조 와 동작을 깨끗하고 간결한 방식으로 코드에 매핑하기가 너무 어렵기 때문입니다. 그리고 프로젝트 크기가 커질수록 "c로 구현할 수 있습니다"로 시작하는 것이 유지 관리가 더 어려워지는 구조가 덜한 방법의 끝없는 목록이 됩니다.
이제 1)과 2)를 제공하는 언어는 완전한 OOP 언어가 아닙니다. 그래서 우리는 "다형성(가상) 방법"이 정말로 필요한지 고려해야 합니다. 다형성이 항상 문제를 해결하는 올바른 도구는 아니며 설계를 지나치게 복잡하게 만들 수 있기 때문에 이것은 "어쩌면" 또는 "가끔"에 가깝습니다. 예를 들어 개체 저장소 또는 SQL 데이터베이스에 매핑되는 일부 데이터 구조를 모델링할 때 가상 동작을 추가하면 데이터 매핑이 더 어려워질 수 있지만 "인터페이스" 또는 "가상 메서드"가 있는 기본 클래스를 사용하여 확장 가능한 툴킷 또는 API를 정의할 때 매우 중요합니다. 전반적으로 나는 적절한 맥락에서 드물게 사용되는 다형성의 열렬한 팬입니다.
저는 수백만 줄의 "C" 코드베이스와 수백만 줄의 C++/Java/C# 코드베이스에서 작업했으며 대부분의 "C" 코드베이스는 5년 후에 "유지 관리 모드"로 전환됩니다. 코드가 너무 취약하고 수정으로 인해 종종 몇 달 간의 고통스러운 재개발 및 테스트가 발생하기 때문에 아키텍처를 변경하는 것이 두렵습니다. 일반적으로 객체 지향 프로젝트는 수정 및 리팩토링에 훨씬 더 탄력적입니다.
"if...then...else..." 문은 작업을 수행해야 합니다.
if...then...else는 "가상" 메서드를 코딩할 수 없습니다.
"C"에는 "다형성"의 여러 구현이 있으며 대부분은 필요한 매핑을 유지하기 위해 함수 포인터의 벡터를 사용합니다. 더 나아가 이러한 "함수 포인터의 벡터"는 "계층"에서 모델링하려는 각 "유형"에 대해 정의해야 합니다. 물론 "C"는 계층 구조를 직접 지원하지 않으므로 해당 문제도 해결해야 합니다.
"C"로 구현된 "가상" 방법인 웜 백에 정말로 들어가고 싶다면 모든 Linux 배포판에서 무료로 사용할 수 있는 X Windows 툴킷을 찾아볼 수 있습니다.
물론 Windows는 약간 달라야 하며 정수 메시지 ID로 확장 가능한 구조를 사용합니다. 이는 "다형성" 동작이 id의 switch 문을 통해 구현됨을 의미합니다. (아마도 그것을 하는 가장 더러운 방법이지만 당신을 거기에 데려다 줄 것입니다)
Windows 운영 체제가 좋은 GUI를 제공한다는 데 동의하십니까? 내가 아는 한 OOP가 아닌 C. 절차 언어로 작성되었습니다.
복잡한 프로그램이 OOP로만 구축될 수 있다고 생각한다면 당신은 잘못된 Dirk입니다. OOP로 코딩하는 것이 더 나은 이유를 설명해야 합니다.
Windows 커널 은 "C"에 있지만 커널은 Windows 코드베이스의 작은 구성 요소일 뿐이며 많은 상위 수준 코드베이스는 여러 언어를 지원하는 "C" 스타일 외부 인터페이스를 사용하여 C++로 구현됩니다.
레거시 창 GUI 구성 요소조차도 "C"에서 효과적으로 "OOP" 구현되는 자체 손으로 롤링된 "다형성 동작"을 구현합니다. 예를 들어 GUI 컨트롤에서 "Handle"을 다시 가져오면 다형성 동작을 사용할 수 있는 확장 가능한 "C" 구조를 얻게 됩니다. 이것은 "C" 구문의 못생긴 집합으로 포장된 OOP입니다.
Windows가 "C"로 작성되었기 때문에 OOP가 아니라고 말하는 것은 완전히 정확하지 않습니다.
나는 당신이 틀렸다는 것을 증명하기 위해 절차적 언어로 GUI를 구축하지 않을 것입니다. 하지만 나는 의심의 여지 없이 할 수 있었다.
그건 그렇고 OOP에서 읽을 수 없고 훨씬 느린 코드를 쉽게 코딩할 수 있습니다. 아시다시피 Metaquotes 표준 라이브러리 는 이에 대한 좋은 증거입니다.
절차 코드보다 훨씬 느린 OOP는 완전한 신화입니다. 많은 OOP 프로젝트가 느린 이유는 제대로 설계되지 않았기 때문입니다. 가상 함수 호출에 대한 오버헤드는 예상보다 훨씬 작습니다. 특히 오늘날의 온칩 메모리 인출 아키텍처에서는 조회하고 병렬로 실행할 수 있습니다.
https://hbfs.wordpress.com/2008/12/30/the-true-cost-of-calls/
위 링크에서 인용: "그러나 어떤 종류의 호출이든 호출 비용은 인수 평가에 의해 좌우됩니다. 우리는 C 스타일이든 C++ 가상 메서드이든 간접 호출이 본질적으로 저렴하다는 것을 확인했습니다. 가상 메서드는 구조체 멤버(something->function(arg1,arg2))를 사용하는 간접 호출보다 더 비싸지 않으므로 가상 함수를 엄청나게 느린 것으로 간주하는 것은 잘못된 정보일 뿐입니다."
Java는 캡슐화된 모든 데이터 자체가 힙 기반 클래스여야 하므로 C++보다 훨씬 더 느릴 수 있으므로 더 많은 객체 역참조를 얻을 수 있습니다. 그러나 Java조차도 루프 및 기본 수학 연산에서 C와 정확히 동일한 속도일 수 있습니다.
C와 C#을 비교하면 OOP 기능 중 일부를 포함하더라도 C와 C#에서 훨씬 더 빠른 일부 코드를 작성하기가 정말 어렵습니다.
Metaquotes 표준 라이브러리가 느리다면 라이브러리 기능의 설계로 인해 90%가 될 것이며 사용된 OOP 기능과 거의 관련이 없습니다.
(비교하자면 C++ 표준 템플릿 라이브러리는 지금까지 작성된 모든 C 프로젝트의 95%를 수행합니다)
...
큰 기여에 감사드립니다.
큰 기여에 감사드립니다.
감사합니다. 저는 당신에게 말을 걸지 않았습니다. 당신이 절차상의 논쟁을 지지하는 유일한 사람일 뿐입니다. :)
'모더레이터' 역할을 해야 하니 걱정하지 마세요.
물론, 사람들이 말하는 것이 무엇이든 몇 가지 예를 보는 것이 좋습니다. 이 모든 것에 경험이 있는 사람들에게 말하기/타자 입력은 모두 훌륭하지만 저는 시각적인 손을 쓰는 유형의 학생입니다. 예를 게시해 주세요.
mql4를 계속 배울지, mql5로 전환할지, 아니면 다른 플랫폼으로 갈지 고민 중입니다.
이 스레드를 시작해주셔서 감사합니다. 이 포럼은 이것이 정말 필요합니다.
누군가 전문가가 "증거"로 compex 라이브러리를 게시할 것으로 기대합니까? ;) 여기 시장에서 팔 수 없는 준비된 것에 대한 링크를 게시할 수 있지만, 만약 내가 그렇게 한다면 Alain은 나를 차버릴 것입니다 ;) 내 프로필 을 방문하거나 벽 사진을 보고 아이디어를 얻을 수 있습니다. 나 오후.
또 다른 플랫폼? 이렇게 강력한 컴파일러가 있는 다른 플랫폼은 찾을 수 없습니다. 별말씀을요.
@James Cater - 귀하의 의견에 감사드립니다.
누군가 전문가가 "증거"로 compex 라이브러리를 게시할 것으로 기대합니까? ;) 여기 시장에서 팔 수 없는 준비된 것에 대한 링크를 게시할 수 있지만, 만약 내가 그렇게 한다면 Alain은 나를 차버릴 것입니다 ;) 내 프로필을 방문하거나 벽 사진을 보고 아이디어를 얻을 수 있습니다. 나 오후.
또 다른 플랫폼? 이렇게 강력한 컴파일러가 있는 다른 플랫폼은 찾을 수 없습니다. 별말씀을요.
@James Cater - 귀하의 의견에 감사드립니다.