2. 내 의견으로는, 10배 정도(10배). 그러나 OOP의 주요 이점은 코드 유지 관리입니다. 이제 1년 이상 전에 작성한 코드를 매우 빠르게 이해하고 있습니다. 순전히 절차적인 방식으로 초기 ANSI C 프로그램을 어떻게 이해했는지 잘 기억하고 있습니다. 훨씬 더 어려웠습니다.
1. 이것은 OOP의 필요성에 대한 주요 답변입니다.
2. 팀 경험의 문제입니다. 나는 2008-2009년에 필요한 모든 것을 썼습니다. 몇 년 전에 나는 더 많은 것을 쓰기로 결정했습니다. 모든 것이 읽을 수 있고 문제가 없습니다.
귀하의 답변에서 나는 한 가지를 이해했습니다. OOP는 프로그래밍 원칙을 도입하고 균일성을 도입하는 일종의 표준이며 이를 기반으로 초기 오류가 적고 가장 중요하고 가장 중요한 것은 수정 중 문제가 근본적으로 감소한다는 것입니다. 그러나 GOST, 개발 단계, 문서를 주의 깊게 준수하여 동일한 결과를 얻었습니다.
왜 내 작품에서 이런 걸 본 적이 없는지 이해할 수 없습니다. 하나의 큰 프로그램이 아닌 하나의 개발자에서 변수에 대한 액세스 차별화의 문제는 어디에서 발생합니까? 100명의 개발자가 있고 각 개발자는 100개의 함수를 작성합니다. 이론적으로는 그럴 수 있습니다. 그러나 실제로 프로그래밍은 거의 40년 동안 OOP로 발전했으며 수많은 코드가 작성되었으며 나는 그런 것을 들어본 적이 없습니다.
그래서 처음에는 프로그램이 코드로 작성되었습니다.
OOP는 단순히 더 복잡한 프로그램을 더 빠르게 작성하고 더 효율적으로 유지 관리할 수 있게 해주는 기술입니다.
그러나 이것이 OOP가 모든 질병의 만병통치약이라는 의미는 아닙니다. 내 말은 - Peter's와 같은 메모리가 있는 경우 아무 것도 OOP가 필요하지 않습니다. 모든 것을 전역적으로 선언하면 됩니다. 이 모든 것을 기억하고 변수의 충돌이나 혼동을 쉽게 허용하지 않기 때문입니다. . 그러나 내 기억은 훨씬 더 나쁘다. 그리고 구별 - 나는 그것을 매우 널리 사용합니다. 최근 몇 년 동안 - 나는 const 수정자를 정말 높이 평가했습니다 - 전에는 거의 사용하지 않았습니다. 지금 - 자주. 내가 필요한 것에만 액세스할 수 있을 뿐만 아니라 더 이상 액세스할 수 없습니다. 따라서 이 액세스는 변경하지 않으려는 경우 읽기 전용입니다.
예, 실제로 필요한 데이터를 얻는 것이 거의 불가능하다는 것이 갑자기 밝혀지는 상황이 있습니다. 여러 가상 인터페이스 뒤에 숨겨져 있습니다. 그러나 이 상황은 시스템이 원래 잘못 설계되었으며 이 데이터의 전송을 제공하지 않았음을 분명히 보여줍니다. 이 상황은 정말, 정말 나쁩니다. 추가 인터페이스의 형태로 "목발"을 급하게 조각하거나 단순히 전체 시스템을 재구성해야 합니다. 음... 프로그래머가 시스템 아키텍처에 대해 더 신중하게 생각하도록 동기를 부여합니다.
프로그래머가 주요 아이디어를 구현하기 위해 가능한 모든 옵션에 대해 필요한 데이터 구조 를 모든 세부 사항에 대해 미리 보는 예언자이자 투시력이라면 아마도 그가 당신의 길을 따르는 것이 합리적일 것입니다. 또는 모든 것이 이미 작동하고 이러한 추가 기능을 사용하지 않고 코드가 디버그되는 마지막 단계에서 수행합니다. 그러나 나중에 다시 변경하거나 다시 그릴 필요가 없다는 조건으로 ...
2. 팀 경험의 문제입니다. 나는 2008-2009년에 필요한 모든 것을 썼습니다. 몇 년 전에 나는 더 많은 것을 쓰기로 결정했습니다. 모든 것이 읽을 수 있고 문제가 없습니다.
귀하의 답변에서 나는 한 가지를 이해했습니다. OOP는 프로그래밍 원칙을 도입하고 균일성을 도입하는 일종의 표준이며 이를 기반으로 초기 오류가 적고 가장 중요하고 가장 중요한 것은 수정 중 문제가 근본적으로 감소한다는 것입니다. 그러나 GOST, 개발 단계, 문서를 주의 깊게 준수하여 동일한 결과를 얻었습니다.
1. 글쎄요. OOP는 수익 창출 도구가 아닙니다. 그리고 수익성 측면에서 OOP의 필요성에 대해 이야기하는 것은 불가능합니다. OOP는 코드 개발 및 유지 관리를 단순화하는 도구입니다.
2. 10년 전의 TS가 여전히 작동하는 것이 좋습니다. 나는 그렇게 살 수 없으며, 그들은 정기적으로 나를 위해 일하지 않으며, 나는 끊임없이 수정해야합니다. 그리고 OOP - 이것은 저에게 많은 도움이 됩니다.
그리고 특정 기준인 OOP에 관해서는 그렇습니다. 그리고 스테이징과 문서화만 지켜도 같은 결과를 얻을 수 있는 것이 사실입니다. 그러나 내가 보기에는 OOP의 경우보다 이 경우에 더 많은 노력이 필요합니다.
OOP는 단순히 더 복잡한 프로그램을 더 빠르게 작성하고 더 효율적으로 유지 관리할 수 있게 해주는 기술입니다.
그러나 이것이 OOP가 모든 질병의 만병통치약이라는 의미는 아닙니다. 내 말은 - Peter's와 같은 메모리가 있는 경우 아무 것도 OOP가 필요하지 않습니다. 모든 것을 전역적으로 선언하면 됩니다. 이 모든 것을 기억하고 변수의 충돌이나 혼동을 쉽게 허용하지 않기 때문입니다. . 그러나 내 기억은 훨씬 더 나쁘다. 그리고 구별 - 나는 그것을 매우 널리 사용합니다. 최근 몇 년 동안 const 수정자를 매우 높이 평가했으며 거의 사용하지 않았습니다. 지금 - 자주. 내가 필요한 것에만 액세스할 수 있을 뿐만 아니라 더 이상 액세스할 수 없습니다. 따라서 이 액세스는 변경하지 않으려는 경우 읽기 전용입니다.
그래서 처음에는 프로그램이 코드로 작성되었습니다.
무리하지 말자, 알았지?
OOP는 단순히 더 복잡한 프로그램을 더 빠르게 작성하고 더 효율적으로 유지 관리할 수 있게 해주는 기술입니다.
이것은 매우 의심스럽습니다.
좋은 프로젝트 문서가 있는 프로그램은 더 빠르고 효율적으로 작성되고 유지 관리됩니다. 이 문제의 반향은 TERMS OF REFERENCE 에 많은 관심을 기울이는 시장에서 찾을 수 있습니다. TK가 형편없으면 OOP가 도움이 되지 않습니다.
프로그래머가 주요 아이디어를 구현하기 위해 가능한 모든 옵션에 대해 필요한 데이터 구조 를 모든 세부 사항에 대해 미리 보는 예언자이자 투시력이라면 아마도 그가 당신의 길을 따르는 것이 합리적일 것입니다. 또는 모든 것이 이미 작동하고 이러한 추가 기능을 사용하지 않고 코드가 디버그되는 마지막 단계에서 수행합니다. 그러나 나중에 다시 변경하거나 다시 그릴 필요가 없다는 조건으로 ...
글쎄, 내가 인터페이스를 통해 중요한 정보를 전송할 가능성을 제공하지 않은 상황은 나에게 드뭅니다. 그러나 다른 것이 나에게 더 중요합니다. Igor는 위에서 올바르게 말했습니다. 각 클래스는 자체 변수에 대해서만 책임이 있으며 다른 클래스에 "적합"하는 것은 불가능합니다. 결과적으로 대부분의 문제는 컴파일 단계에서 잘립니다.
OOP는 단순히 더 복잡한 프로그램을 더 빠르게 작성하고 더 효율적으로 유지 관리할 수 있게 해주는 기술입니다.
위에서 설명한 것처럼 OOP는 처음에 많은 추가 래퍼, 중간 추가 기능 및 어댑터로 인해 코드의 빠른 작성 및 디버깅을 위한 것이 아닙니다... 모든 것이 이미 작동하고 디버그되고 데이터가 데이터 가 있는 마지막 단계에서만 의미가 있습니다. 구조 가 완성 된 모양을 얻었습니다. 즉, 이것은 후속 저장을 위해 완성 된 코드를 포장하기위한 순전히 외관상의 절차입니다 ...
Ihor Herasko : .... 현대 프로그램은 실제로 문서가 필요하지 않습니다. 모든 것이 클래스 인터페이스에 명확하게 표시됩니다.
메타 따옴표에 이것을 설명하십시오. 왜 터미널, 언어 및 일반적으로 Cpp와 같은 소프트웨어 제품에 대한 문서의 산은 어디에서 거대한 매뉴얼을 작성 했습니까? 그리고 일반적으로 소프트웨어 제품이 있습니까? 문서 없이? 당신이 이것을 알아차리지 못한다는 것은 매우 이상한 일입니다.
1. 얼마가 아닙니다. 수익성은 OOP에 의존하지 않습니다.
2. 내 의견으로는, 10배 정도(10배). 그러나 OOP의 주요 이점은 코드 유지 관리입니다. 이제 1년 이상 전에 작성한 코드를 매우 빠르게 이해하고 있습니다. 순전히 절차적인 방식으로 초기 ANSI C 프로그램을 어떻게 이해했는지 잘 기억하고 있습니다. 훨씬 더 어려웠습니다.
1. 이것은 OOP의 필요성에 대한 주요 답변입니다.
2. 팀 경험의 문제입니다. 나는 2008-2009년에 필요한 모든 것을 썼습니다. 몇 년 전에 나는 더 많은 것을 쓰기로 결정했습니다. 모든 것이 읽을 수 있고 문제가 없습니다.
귀하의 답변에서 나는 한 가지를 이해했습니다. OOP는 프로그래밍 원칙을 도입하고 균일성을 도입하는 일종의 표준이며 이를 기반으로 초기 오류가 적고 가장 중요하고 가장 중요한 것은 수정 중 문제가 근본적으로 감소한다는 것입니다. 그러나 GOST, 개발 단계, 문서를 주의 깊게 준수하여 동일한 결과를 얻었습니다.
왜 내 작품에서 이런 걸 본 적이 없는지 이해할 수 없습니다. 하나의 큰 프로그램이 아닌 하나의 개발자에서 변수에 대한 액세스 차별화의 문제는 어디에서 발생합니까? 100명의 개발자가 있고 각 개발자는 100개의 함수를 작성합니다. 이론적으로는 그럴 수 있습니다. 그러나 실제로 프로그래밍은 거의 40년 동안 OOP로 발전했으며 수많은 코드가 작성되었으며 나는 그런 것을 들어본 적이 없습니다.
그래서 처음에는 프로그램이 코드로 작성되었습니다.
OOP는 단순히 더 복잡한 프로그램을 더 빠르게 작성하고 더 효율적으로 유지 관리할 수 있게 해주는 기술입니다.
그러나 이것이 OOP가 모든 질병의 만병통치약이라는 의미는 아닙니다. 내 말은 - Peter's와 같은 메모리가 있는 경우 아무 것도 OOP가 필요하지 않습니다. 모든 것을 전역적으로 선언하면 됩니다. 이 모든 것을 기억하고 변수의 충돌이나 혼동을 쉽게 허용하지 않기 때문입니다. . 그러나 내 기억은 훨씬 더 나쁘다. 그리고 구별 - 나는 그것을 매우 널리 사용합니다. 최근 몇 년 동안 - 나는 const 수정자를 정말 높이 평가했습니다 - 전에는 거의 사용하지 않았습니다. 지금 - 자주. 내가 필요한 것에만 액세스할 수 있을 뿐만 아니라 더 이상 액세스할 수 없습니다. 따라서 이 액세스는 변경하지 않으려는 경우 읽기 전용입니다.
George Merts :
예, 실제로 필요한 데이터를 얻는 것이 거의 불가능하다는 것이 갑자기 밝혀지는 상황이 있습니다. 여러 가상 인터페이스 뒤에 숨겨져 있습니다. 그러나 이 상황은 시스템이 원래 잘못 설계되었으며 이 데이터의 전송을 제공하지 않았음을 분명히 보여줍니다. 이 상황은 정말, 정말 나쁩니다. 추가 인터페이스의 형태로 "목발"을 급하게 조각하거나 단순히 전체 시스템을 재구성해야 합니다. 음... 프로그래머가 시스템 아키텍처에 대해 더 신중하게 생각하도록 동기를 부여합니다.
프로그래머가 주요 아이디어를 구현하기 위해 가능한 모든 옵션에 대해 필요한 데이터 구조 를 모든 세부 사항에 대해 미리 보는 예언자이자 투시력이라면 아마도 그가 당신의 길을 따르는 것이 합리적일 것입니다. 또는 모든 것이 이미 작동하고 이러한 추가 기능을 사용하지 않고 코드가 디버그되는 마지막 단계에서 수행합니다. 그러나 나중에 다시 변경하거나 다시 그릴 필요가 없다는 조건으로 ...
1. 이것은 OOP의 필요성에 대한 주요 답변입니다.
2. 팀 경험의 문제입니다. 나는 2008-2009년에 필요한 모든 것을 썼습니다. 몇 년 전에 나는 더 많은 것을 쓰기로 결정했습니다. 모든 것이 읽을 수 있고 문제가 없습니다.
귀하의 답변에서 나는 한 가지를 이해했습니다. OOP는 프로그래밍 원칙을 도입하고 균일성을 도입하는 일종의 표준이며 이를 기반으로 초기 오류가 적고 가장 중요하고 가장 중요한 것은 수정 중 문제가 근본적으로 감소한다는 것입니다. 그러나 GOST, 개발 단계, 문서를 주의 깊게 준수하여 동일한 결과를 얻었습니다.
1. 글쎄요. OOP는 수익 창출 도구가 아닙니다. 그리고 수익성 측면에서 OOP의 필요성에 대해 이야기하는 것은 불가능합니다. OOP는 코드 개발 및 유지 관리를 단순화하는 도구입니다.
2. 10년 전의 TS가 여전히 작동하는 것이 좋습니다. 나는 그렇게 살 수 없으며, 그들은 정기적으로 나를 위해 일하지 않으며, 나는 끊임없이 수정해야합니다. 그리고 OOP - 이것은 저에게 많은 도움이 됩니다.
그리고 특정 기준인 OOP에 관해서는 그렇습니다. 그리고 스테이징과 문서화만 지켜도 같은 결과를 얻을 수 있는 것이 사실입니다. 그러나 내가 보기에는 OOP의 경우보다 이 경우에 더 많은 노력이 필요합니다.
그래서 처음에는 프로그램이 코드로 작성되었습니다.
OOP는 단순히 더 복잡한 프로그램을 더 빠르게 작성하고 더 효율적으로 유지 관리할 수 있게 해주는 기술입니다.
그러나 이것이 OOP가 모든 질병의 만병통치약이라는 의미는 아닙니다. 내 말은 - Peter's와 같은 메모리가 있는 경우 아무 것도 OOP가 필요하지 않습니다. 모든 것을 전역적으로 선언하면 됩니다. 이 모든 것을 기억하고 변수의 충돌이나 혼동을 쉽게 허용하지 않기 때문입니다. . 그러나 내 기억은 훨씬 더 나쁘다. 그리고 구별 - 나는 그것을 매우 널리 사용합니다. 최근 몇 년 동안 const 수정자를 매우 높이 평가했으며 거의 사용하지 않았습니다. 지금 - 자주. 내가 필요한 것에만 액세스할 수 있을 뿐만 아니라 더 이상 액세스할 수 없습니다. 따라서 이 액세스는 변경하지 않으려는 경우 읽기 전용입니다.
그래서 처음에는 프로그램이 코드로 작성되었습니다.
무리하지 말자, 알았지?
OOP는 단순히 더 복잡한 프로그램을 더 빠르게 작성하고 더 효율적으로 유지 관리할 수 있게 해주는 기술입니다.
이것은 매우 의심스럽습니다.
좋은 프로젝트 문서가 있는 프로그램은 더 빠르고 효율적으로 작성되고 유지 관리됩니다. 이 문제의 반향은 TERMS OF REFERENCE 에 많은 관심을 기울이는 시장에서 찾을 수 있습니다. TK가 형편없으면 OOP가 도움이 되지 않습니다.
좋은 프로젝트 문서가 있는 프로그램은 더 빠르고 효율적으로 작성되고 유지 관리됩니다. 이 문제의 메아리는 TECHNICAL TASK에 많은 관심을 기울이는 시장에서 찾을 수 있습니다. TK가 형편없으면 OOP가 도움이 되지 않습니다.
프로그래머가 주요 아이디어를 구현하기 위해 가능한 모든 옵션에 대해 필요한 데이터 구조 를 모든 세부 사항에 대해 미리 보는 예언자이자 투시력이라면 아마도 그가 당신의 길을 따르는 것이 합리적일 것입니다. 또는 모든 것이 이미 작동하고 이러한 추가 기능을 사용하지 않고 코드가 디버그되는 마지막 단계에서 수행합니다. 그러나 나중에 다시 변경하거나 다시 그릴 필요가 없다는 조건으로 ...
OOP는 단순히 더 복잡한 프로그램을 더 빠르게 작성하고 더 효율적으로 유지 관리할 수 있게 해주는 기술입니다.
위에서 설명한 것처럼 OOP는 처음에 많은 추가 래퍼, 중간 추가 기능 및 어댑터로 인해 코드의 빠른 작성 및 디버깅을 위한 것이 아닙니다... 모든 것이 이미 작동하고 디버그되고 데이터가 데이터 가 있는 마지막 단계에서만 의미가 있습니다. 구조 가 완성 된 모양을 얻었습니다. 즉, 이것은 후속 저장을 위해 완성 된 코드를 포장하기위한 순전히 외관상의 절차입니다 ...
그러나 다른 것이 나에게 더 중요합니다. Igor는 위에서 올바르게 말했습니다. 각 클래스는 자체 변수에 대해서만 책임이 있으며 다른 클래스에 "적합"하는 것은 불가능합니다. 결과적으로 대부분의 문제는 컴파일 단계에서 잘립니다.
클래스에는 내부 변수만 있고 입력 또는 출력이 없습니다... 외부 세계와 접촉하지 않고 자체 주스에서 끓는 그러한 객체의 프로그래밍에서 사용을 본 적이 있습니까?
.... 현대 프로그램은 실제로 문서가 필요하지 않습니다. 모든 것이 클래스 인터페이스에 명확하게 표시됩니다.
메타 따옴표에 이것을 설명하십시오. 왜 터미널, 언어 및 일반적으로 Cpp와 같은 소프트웨어 제품에 대한 문서의 산은 어디에서 거대한 매뉴얼을 작성 했습니까? 그리고 일반적으로 소프트웨어 제품이 있습니까? 문서 없이? 당신이 이것을 알아차리지 못한다는 것은 매우 이상한 일입니다.