절차 적 프로그래밍에 비해 객체 지향 프로그래밍의 이점은 무엇입니까?


77

C와 같은 절차 언어와 C ++과 같은 객체 지향 언어의 차이점을 이해하려고합니다. 나는 C ++을 사용한 적이 없지만 두 사람을 구별하는 방법에 대해 친구들과 논의했습니다.

C ++에는 객체 지향 개념뿐만 아니라 변수 정의를위한 공용 및 개인 모드가 있다고 들었습니다 .C에는없는 것들. Visual Basic.NET에서 프로그램을 개발할 때 이것들을 사용하지 않아도됩니다. 이것들의 장점은 무엇입니까?

또한 변수가 공용이면 어디에서나 액세스 할 수 있지만 C와 같은 언어의 전역 변수와 어떻게 다른지 명확하지 않습니다. 개인 변수가 로컬 변수와 어떻게 다른지 명확하지 않습니다.

내가 들었던 또 다른 것은 보안상의 이유로 함수에 액세스 해야하는 경우 먼저 상속해야한다는 것입니다. 유스 케이스는 관리자가 필요한만큼만 모든 권한을 가질 수는 없지만 조건부로도 작동하는 것 같습니다.

if ( login == "admin") {
    // invoke the function
}

왜 이것이 이상적이지 않습니까?

객체 지향적 인 모든 것을 수행하는 절차적인 방법이 있다고 생각되면 왜 객체 지향 프로그래밍에 관심을 가져야합니까?



11
이 프로그래밍 패러다임 맵 이 도움이 될 수 있습니다.
AProgrammer

26
일부 다운 보트를 상쇄하려면 +1 만약 동료가 그런 질문을한다면, 아마 약간의 우려가 있고 심지어 그에게 하향 투표를 할 수도 있습니다. 그러나이 질문은 미래의 소프트웨어 엔지니어가 요청한 것으로 보이며, 게시하기 전에 주제를 생각하고 토론하는 데 시간을 보낸 것처럼 들립니다. 나는 그를 기각하기보다는 그를 도와 준 것에 투표합니다.
DXM

14
@DXM 훌륭한 아이디어! 동료 주변에 떠 다니는 공감 / 공감 화살표 ...
yannis

2
표준 반론 : C에서 할 수있는 모든 것을 할 수있는 어셈블러 방법도 있습니다. 왜 C에 관심을 가져야합니까? (힌트 : 추상화 수준을 높이는 것입니다. C ++은 C 속도의 대부분을 희생하지 않고이 작업을 수행합니다. C ++의 성공의 주요 이유는 IMO입니다.
sbi

답변:


135

지금까지의 모든 답변은 "c와 c ++의 차이점은 무엇입니까?"라는 질문의 주제에 중점을 두었습니다. 실제로 차이가 무엇인지 아는 것처럼 들리지만 왜 그 차이가 필요한지 이해하지 못합니다. 그래서 다른 답변은 OO와 캡슐화를 설명하려고 시도했습니다.

귀하의 질문에 대한 세부 사항을 바탕으로 몇 가지 단계를 다시 거쳐야한다고 생각하기 때문에 또 다른 대답을 들려주었습니다.

C ++ 또는 OO의 목적을 이해하지 못합니다. 응용 프로그램은 단순히 데이터를 저장해야하기 때문입니다. 이 데이터는 변수에 저장됩니다. "왜 변수에 액세스 할 수 없게 만들고 싶습니까? 이제 더 이상 변수에 액세스 할 수 없습니다! 모든 것을 공개하거나 더 나은 글로벌 환경으로 만들면 어디서나 데이터를 읽을 수 있으며 아무런 문제가 없습니다." -현재 당신이 쓰고있는 프로젝트의 규모에 따라 당신은 옳을 것입니다. 아마도 많은 문제는 없을 것입니다 (또는 아직 문제를 알지 못했을 것입니다).

당신이 정말로 대답해야 할 근본적인 질문은 "왜 데이터를 숨기고 싶습니까? 그렇게한다면 나는 그것을 사용할 수 없습니다!"라고 생각합니다. 그리고 이것이 이유입니다.

새 프로젝트를 시작하고 텍스트 편집기를 열고 함수 작성을 시작한다고 가정 해 봅시다. 무언가를 저장해야 할 때마다 (나중에 기억하기 위해) 변수를 만듭니다. 일을 단순화하기 위해 변수를 전역으로 만듭니다. 앱의 첫 번째 버전이 훌륭하게 실행됩니다. 이제 더 많은 기능을 추가하기 시작합니다. 더 많은 기능이 있으며 이전에 저장 한 특정 데이터를 새 코드에서 읽어야합니다. 다른 변수를 수정해야합니다. 더 많은 기능을 계속 작성하십시오. 코드가 커질수록 다음 기능을 추가하는 데 시간이 오래 걸리는 것입니다. 코드가 커질수록 작동하던 것을 깨뜨리지 않고 기능을 추가하는 것이 점점 어려워집니다. 왜? 모든 것을 기억해야하기 때문에전역 변수가 저장되므로 모든 변수가 수정되는 위치를 기억해야합니다 . 그리고 어떤 순서어떤 함수를 호출해도 괜찮은지 기억 하고 다른 순서로 호출하면 전역 변수가 아직 유효하지 않기 때문에 오류가 발생할 수 있습니다. 이것에 부딪친 적이 있습니까?

일반적인 프로젝트 (코드 라인)는 얼마나됩니까? 이제 자신보다 5000 ~ 50000 배 큰 프로젝트를 이미징하십시오. 또한 여러 사람들이 일하고 있습니다. 팀의 모든 사람들이 모든 변수가 무엇을하고 있는지 기억하거나 어떻게 알 수 있습니까?

위에서 설명한 것은 완벽하게 연결된 코드의 예입니다. 그리고 시간이 시작된 이후 (1970 년 1 월 1 일 시작된 것으로 가정), 인간은 이런 문제를 피할 수있는 방법을 찾고 있습니다. 이를 피하는 방법은 코드를 시스템, 서브 시스템 및 구성 요소로 분할하고 데이터에 액세스 할 수있는 기능 수를 제한하는 것입니다. 5 개의 정수와 어떤 종류의 상태를 나타내는 문자열이 있다면 5 개의 함수 만 설정하거나 값을 얻는다면이 상태로 작업하기가 더 쉬울까요? 또는 100 개의 기능이 동일한 값을 설정하거나 얻는 경우? OO 언어 (예 : C)가 없어도 사람들은 다른 데이터에서 데이터를 분리하고 코드의 다른 부분간에 명확한 분리 경계를 만들기 위해 열심히 노력해 왔습니다. 프로젝트가 특정 크기에 도달하면 프로그래밍의 편의성이 향상되지 않습니다. "함수 Y에서 변수 X에 액세스 할 수 없습니다."

이것이 OO 개념이 도입 된 이유이며 이것이 매우 강력한 이유입니다. 데이터 를 보는 코드가 적을수록 다음 기능을 추가 할 때 무언가를 깨뜨릴 가능성이 적기 때문에 데이터를 자신에게서 숨길 수 있으며 의도적으로 데이터를 원할 수도 있습니다. 이것이 캡슐화 및 OO 프로그래밍 개념의 주요 목적입니다. 이를 통해 시스템 / 서브 시스템을 훨씬 더 세분화 된 상자로 나눌 수 있습니다. 전체 프로젝트의 규모에 관계없이 주어진 변수 세트는 50-200 줄의 코드로만 액세스 할 수 있습니다. OO 프로그래밍에는 훨씬 더 많은 것이 있지만 본질적으로 C ++은 데이터 / 기능을 개인, 보호 또는 공용으로 선언하는 옵션을 제공하는 이유입니다.

OO에서 두 번째로 큰 아이디어는 추상화 계층의 개념입니다. 절차 적 언어에도 추상화가있을 수 있지만 C에서는 프로그래머가 이러한 레이어를 만들기 위해 의식적인 노력을 기울여야하지만 C ++에서는 클래스를 선언 할 때 추상화 레이어를 자동으로 만듭니다 (이 추상화 여부에 관계없이 여전히 사용자의 몫임) 값을 추가하거나 제거합니다). 추상화 계층에 대해 더 많이 읽고 연구해야하며 더 많은 질문이 있으면이 포럼에서 그에 대한 답변을 기뻐할 것입니다.


5
좋은 대답은 질문에 주어진 적절한 수준에 도달 한 것 같습니다
Carlos

29
+1 ... 대부분의 경우, "시간이 시작된 이후 (1970 년 1 월 1 일 시작한 것으로 가정) ..."line
CaffGeek

4
@ 차드-나는 혼자 라인 하나 이상의 점수를해야한다고 생각했다 :)
DXM

절차 적 패러다임에서 이야기하는이 규모의 문제를 처리하는 방법이 있습니다. 이것을 함수라고합니다. 그러나 문제를 설명하는 좋은 방법입니다.
annoying_squid

@DXM-대답을 올바르게 이해했는지 잘 모르겠습니다. 절차 적 프로그래밍에서도 동일한 세트 / get 기능을 얻을 수 있습니다. 전역 변수를 수정 / 가져 오기 위해 C에 set / get 함수를 작성할 수 있습니다. 이 방법을 사용하여 전역 변수를 수정하는 함수의 수를 제한하고 있습니다. 그리고 OOP에서도 set / get 메소드를 사용하면 객체 외부에서 이러한 메소드를 사용하여 값을 변경합니다.
kadina

10

흠 ... 아마도 객체 지향 프로그래밍의 기본 의도를 백업하고 시도하는 것이 가장 좋습니다. 객체 지향 프로그래밍의 많은 목적은 추상 데이터 유형을 생성하는 것입니다. 의심 할 여지없이 친숙한 간단한 예를 들어 문자열을 고려하십시오. 문자열에는 일반적으로 문자열의 내용을 담을 수있는 버퍼가 있으며 문자열에서 작동 할 수있는 일부 기능 (검색, 문자열의 일부에 액세스, 하위 문자열 생성 등) 또한 (적어도 일반적으로) 문자열의 (현재) 길이와 (아마도) 버퍼의 크기를 추적하므로 (예를 들어) 문자열의 크기를 1에서 1000000으로 늘리면 더 큰 메모리를 유지하기 위해 더 많은 메모리가 필요한시기를 알 수 있습니다 함유량.

이러한 변수 (버퍼, 현재 길이 및 버퍼 크기)는 문자열 자체에 고유하지만 특정 함수 에만 국한 되지않습니다 . 각 문자열에는 특정 길이의 내용이 있으므로 해당 문자열의 내용 / 길이를 추적해야합니다. 반대로, 동일한 함수 (예 : 하위 문자열 추출)는 서로 다른 시간에 여러 다른 문자열에서 작동 할 수 있으므로 데이터가 개별 함수에 대해 로컬 일 수 없습니다.

따라서 문자열 전용의 일부 데이터가 생겨 문자열 함수에만 (직접적으로) 액세스 할 수 있습니다. 외부 세계는 문자열 함수를 사용하여 문자열의 길이를 얻을 수 있지만 문자열의 내부에 대해 알 필요는 없습니다. 마찬가지로 문자열을 수정할 수도 있지만 문자열 함수를 통해 다시 문자열 문자열을 수정하면 문자열 개체에 해당하는 변수 만 직접 수정합니다.

지금까지 보안이가는대로, 나는이 비유로 합리적인있는 동안, 그것의주의 것 없는 일들이 실제로 어떻게 작동하는지. 특히 C ++ 에서의 액세스는 운영 체제에서의 액세스와 같은 종류의 요구 사항을 충족시키기위한 것이 아닙니다 . 운영 체제는 제한 사항 을 적용 해야 하므로 (예를 들어) 일반 사용자 는 관리자를 위해 예약 된 작업을 수행 할 수 없습니다 . 대조적으로, C ++의 액세스 제어는 사고 를 막기위한 것입니다. 설계 상 원하는 사람은 누구나 쉽게 우회 할 수 있습니다. 파일을 읽기 전용으로 표시하는 순서와 동일하므로 실수로 파일을 삭제하지 않습니다. 파일을 삭제하기로 결정한 경우 파일을 읽기 전용에서 읽기 / 쓰기로 변경하는 것은 쉽지 않습니다. 그것을 읽기 전용으로 설정하는 것은 적어도 그것에 대해 잠시 생각 하고 파일을 삭제 하기결정 하여 실수로 잘못된 키를 눌렀을 때 실수로 삭제되지 않도록합니다.


6

OOP 대 C는 실제로 당신이 논의한 것들에 관한 것이 아닙니다. 의도하지 않은 (때로는 의도적으로) 서로 영향을 줄 수없는 영역에 코드를 패키징하는 것입니다.

C를 사용하면 기본적으로 어느 곳에서나 모든 기능을 실행할 수 있습니다. OOP는 메소드를 클래스로 그룹화하고 메소드를 포함하는 클래스를 참조하여 메소드를 사용할 수있게하여이를 방지합니다. 따라서 OOP의 잠재적 인 큰 장점 중 하나는 경험이 많지 않아도 코드 배열을 개선 할 가능성이 훨씬 높다는 것입니다.


4
-1. C에서 모든 기능을 전역으로 만드는 독점 기능은 없습니다. 모든 함수를 정적으로 선언하여 범위를 로컬 파일로 제한 할 수 있습니다. 이 측면에서 C는 C ++, Java 등과 다르지 않습니다. 또한 OOP는 언어 구문에 관한 것이 아니며 C에서 OO 프로그램을 작성할 수는 있지만 OO에 대한 구문 지원 언어보다 약간 더 조잡 할 수 있습니다. 그리고 반대로 : OO를 지원하는 언어를 선택했기 때문에 OOP를 얻지 못합니다. 객체 지향은 언어 기능이 아닌 프로그래밍 스타일 입니다.

@ 룬딘 : 기술적으로 정확하지만 요점을 놓쳤습니다. OOP 언어는 기본 동작으로 OOP 방식으로 동작합니다. C는 그렇지 않습니다.
John Fisher

1
OO 언어로 강요하는 것은 없습니다. 예를 들어, 언급 할 가치가없는 수많은 C ++ 프로그램을 보았습니다. 마찬가지로 OO에 대한 단서가 없지만 클래스, 유산 등을 구현하려고하면 엉망인 프로그램을 만들 확률이 약 100 %입니다.

@ 룬딘 : 저는 C ++이 좋은 예라고 생각하지 않습니다. 그것은 (많은) 수정없이 C 프로그램을 컴파일 할 수 있도록 (또는 최소한) 의미합니다. 클래스를 맨 위에 추가한다고해서 C # 또는 Java 수준에서 OOP 언어로 만들지는 않지만 그러한 종류의 개발을 가능하게합니다.
존 피셔

OO가 아닌 프로그램도 Java로 작성할 수 있으며, 하나의 거대한 주 파일을 해킹하면됩니다. OO는 여전히 언어별로 다릅니다. 프로그래머가 OO에 대해 모르는 경우 세계의 어떤 언어도 저장할 수 없습니다.

4

잘 작성된 수업은 약간의 "신뢰의 섬"이어야합니다. 당신은 그것을 사용하고 그것이 "올바른 일"을하고 일반적인 함정으로부터 당신을 보호한다고 가정 할 수 있습니다. 이것은 좋은 클래스를 빌딩 블록으로 만듭니다. 이것은 많은 기능과 변수로 재사용 할 수 있습니다. 절차 적 솔루션은 전선, 칩, 주석 및 납땜 비트와 비슷하지만 좋은 클래스는 USB 플러그와 같아야합니다.

심층적으로 논의되지 않은 한 가지 점은 인터페이스 / 구현 측면입니다. 인터페이스는 동작을 설명하지만 실현은 아닙니다. 리스트 인터페이스는 개념을 설명합니다목록 및 동작 : add, remove 및 size 메서드와 같은 항목이 필요합니다. 이제이 목록을 구현하는 방법에는 여러 가지가 있습니다 (예 : 연결 목록 또는 배열 버퍼 사용). OO 프로그래밍의 장점은 인터페이스를 사용하여 구현에 대해 알지 않고도 동작에 대해 추론 할 수 있다는 것입니다. 내부 변수 또는 메소드에 액세스하면이 추상화가 손상되고 목록 구현을 다른 것으로 대체 할 수 없으며 클래스를 사용하여 코드를 건드리지 않고 기존 구현을 개선 할 수 없습니다. 이것이 사설 변수와 메소드가 필요한 주된 이유 중 하나입니다. 구현의 내부 세부 사항을 보호하기 위해 추상화가 그대로 유지됩니다.

OO는 한 걸음 더 나아갑니다. 예를 들어 라이브러리의 경우 아직 존재하지 않는 것에 대한 인터페이스를 정의하고 해당 인터페이스와 작동하는 코드를 작성할 수 있습니다. 사용자는 인터페이스를 구현하는 클래스를 작성하고 라이브러리에서 제공하는 서비스를 사용할 수 있습니다. 이것은 절차 적 프로그래밍으로는 불가능한 유연성을 허용합니다.


인터페이스 개념은 객체 지향 언어에 고유하지 않습니다. 더 큰 요소는 비 OOP 언어에서 모듈 내에서 사용되는 거의 모든 함수가 동일한 전역 네임 스페이스에 속해야한다는 것입니다. 이것은 하나의 접두사 중 함수 이름들이 따라 행동, 또는 다른 완전히 다른 일을 많은 유사한 소리가 나는 방법이 무엇인지 나타 내기 위해해야합니다 (예 : SetLocation를 이동하는 데 사용할 수있는 Monster반면, SetPosition를 이동할 수 PopupWindowMove위치를 조정하는 데 사용할 수 있습니다 의 DisplayCursor). 올바른 "이동"방법을 찾는 중 ...
supercat

... MyMonstor->편집자가 글을 쓸 때 유형에 적용 가능한 메소드 목록 만 표시하는 경우 훨씬 쉽게 만들 수 있습니다 Monster. 수십 개의 서로 다른 종류의 물건이 있고 각각이 약 12 ​​개의 작업을 지원하는 경우 분석법 목록의 클러 터 양을 90 % 줄이면 생산성이 크게 완화 될 수 있습니다.
supercat

@supercat 이름 충돌은 비 OOP 문제가 아닌 언어 문제입니다. 반면, 네임 스페이스는 컴파일러가 본질적으로 함수의 이름을 자동으로 바꾸거나 맹 글링해야하기 때문에 문제가됩니다. 그렇다면 왜 수동으로하지 않습니까?
annoying_squid

@annoying_squid : OOP가 제공하는 기능 은 funciton의 기본 인수 유형 을 효과적으로 사용 하여 네임 스페이스를 선택할 수 있다는 것입니다. ittype 의 변수가있는 경우 SuperFancyWhizBang, SuperFancyWhizBang메소드 중 하나를 호출 it할 때 형식을 작성할 필요가 없습니다 SuperFancyWhizBang. 말하는 it.woozle()것은 컴파일러가 자동으로 woozlewithin을 찾도록 지시합니다 SuperFancyWhizBang.
supercat

3

Turing 머신으로 또는 C 또는 C ++ 프로그램이 결국 컴파일 할 머신 코드를위한 어셈블리 언어로 모든 것을 수행하는 방법이 있습니다.

차이점은 코드가 할 수있는 것이 아니라 사람들이 할 수있는 것에 관한 것입니다.

사람들은 실수를합니다. 많이.

OOP는 인간 코딩 실수 가능성의 공간의 크기와 확률 밀도를 줄이는 데 도움이되는 패러다임과 구문을 소개합니다. 때로는 특정 클래스의 데이터 객체에 대해 실수를 불법으로 만들어서 (예 : 해당 객체에 대해 선언 된 메서드가 아님). 때로는 실수를 좀 더 장황하게 표현하거나 언어를 정식으로 사용하는 것에 비해 문체 적으로 이상하게 보입니다. 때로는 훨씬 덜 일관성이 있거나 얽힌 사용법 (공개 대 개인)의 인터페이스가 필요합니다. 기타

프로젝트가 클수록 실수 가능성이 높아집니다. 작은 프로그램 만 경험 한 경우 새 코더가 노출되지 않을 수 있습니다. 따라서 OOP가 가치있는 이유에 대한 의문이 있습니다.


2

귀하의 질문은 차이보다는 OOP의 목적에 관한 것 같습니다. 게시물의 개념은 캡슐화입니다. CHANGE를 지원하기위한 캡슐화가 있습니다. 다른 클래스가 내부에 액세스하면 클래스를 손상시키지 않고 수정하기가 어렵습니다. OOP에서는 다른 클래스가 자신과 상호 작용할 수있는 인터페이스 (공개 멤버)를 제공하며 내부를 숨겨 안전하게 변경할 수 있습니다.


함수 프로토 타입 만 사용하십시오. 캡슐화입니다.
annoying_squid

2

개인 변수를 어디에서 읽을 수 있더라도 공개 변수를 사용할 수있는 이유는 무엇입니까? 공공 및 민간의 실제 사용은 무엇입니까? 모두가 사용할 수 있다고 말하지 마십시오. 왜 우리가 일부 조건을 사용하고 전화를 걸지 않겠습니까?

응용 프로그램에서 둘 이상의 문자열을 원하지 않기를 바랍니다. 또한 지역 변수가 함수 호출간에 지속되기를 바랍니다. 이러한 것들이 접근성 측면에서 동일하지만 수명 및 기타 사용 측면에서 동일 할 수 있습니까? 그들은 절대적으로 동일하지 않습니다.


1

많은 사람들이 한 번 컴파일 된 프로그램은 이진 코드로 바뀌고 이진 문자열을 사용하여 정수를 나타낼 수 있으므로 모든 프로그램은 결국 숫자 일뿐입니다. 그러나 필요한 숫자를 정의하는 것은 매우 어려울 수 있으므로 높은 수준의 프로그래밍 언어가 등장합니다. 프로그래밍 언어는 결국 생성되는 어셈블리 코드의 모델 일뿐입니다. 문맥 지향 프로그래밍에 대한이 아주 좋은 논문을 통해 절차 적 프로그래밍과 OO 프로그래밍의 차이점을 설명하고 싶습니다 http://www.jot.fm/issues/issue_2008_03/article4/

이 그림에서 볼 수 있듯이, 절차 적 프로그래밍은 계산 단위를 이름과 연관시키기 위해 하나의 차원 만 제공합니다. 여기서 프로 시저 호출 또는 이름은 프로 시저 구현에 직접 맵핑됩니다. 그림에서, 호출 m1은 선택의 여지가 없지만 프로 시저 m1의 유일한 구현을 호출합니다.

객체 지향 프로그래밍은 절차 적 프로그래밍의 차원에 이름 확인의 또 다른 차원을 추가합니다. 메소드 또는 프로 시저 이름 외에, 메시지 디스패치는 메소드를 찾을 때 메시지 수신자를 고려합니다. 그림 -b에서 우리는 m1 메소드의 두 가지 구현을 볼 수 있습니다. 적절한 방법의 선택은 메시지 이름 m1뿐만 아니라 실제 메시지의 수신자, 여기서 Ry에 따라 달라집니다.

실제로 캡슐화 및 모듈화가 가능합니다.

여기에 이미지 설명을 입력하십시오

그림 -c는 주제 지향 프로그래밍이 객체 지향 메소드 디스패치를 ​​또 다른 차원으로 확장하는 것에 관한 것이다.

이것이 다른 관점에서 OOP를 생각하는 데 도움이 되었기를 바랍니다.


0

(+1) 어리석게 들리더라도 이해하지 못하는 것에 대한 질문을한다.

차이점은 객체 및 클래스 지향 프로그래밍입니다. "일반 C"는 데이터 및 기능과 함께 작동합니다. "C ++"는 "개체 및 클래스"개념과 몇 가지 관련 보조 개념을 추가합니다.

그러나 개발자에게 "C ++"이전에 "Plain C"를 배우도록 권합니다. 또는 "Object Pascal"앞에 "Procedural Pascal"이 있습니다.

많은 개발자들은 학생들이 한 가지만을 가르쳐야한다고 생각합니다.

예를 들어, OO를받지 못하고 "Plain Structured C"만 가르치는 오래된 교사들.

또는 "필요하지 않음"때문에 OO 만 가르치고 "Plain C"는 가르치지 않는 "hipster"교사들. 또는 교육 순서에 신경 쓰지 않고 둘 다.

차라리 학생들은 "Structured Plain C"와 "Object Oriented C (C ++)"를 모두 배워야한다고 생각합니다. "Plain C"를 먼저 사용하고 나중에 "C ++"를 사용하십시오.

현실에서는 두 패러다임 (및 "기능적"과 같은 다른 패러다임)을 모두 배워야합니다.

구조화 된 프로그램을 큰 단일 객체로 생각하면 도움이 될 수 있습니다.

또한 네임 스페이스 ( "모듈")에 중점을 두어야합니다. 두 언어 모두에서 많은 교사가이를 무시하지만 중요한 것입니다.


네임 스페이스와 과부하는 프로그램을 이해하기 어렵게 만듭니다. 식별 프로세스를 상황에 맞게 만듭니다. foo()C ++에서 볼 때 전역 함수, 현재 네임 스페이스의 함수 using, 와 함께 사용하는 네임 스페이스의 함수 , 메서드, 상속 된 메서드 및 함수 호출에있는 경우 다음과 같은 네임 스페이스에있을 수 있습니다. 인수 기반 이름 조회로 해결할 수 있으며 Java 및 C #에서도 마찬가지입니다. C에서는 현재 소스 파일의 정적 함수이거나 헤더의 함수일 수 있습니다.
Calmarius

어디에서나 MODULE_Foo ()를 작성하는 것은 시각적으로 어수선 할 수 있지만 적어도 어떤 기능인지 정확히 알고 있습니다.
Calmarius

@Calmarius 해결책은 분명히 foo 라는 이름을 지정하지 않는 것 입니다.

0

한마디로, 프로젝트 관리. 내 말은 C ++을 사용하면 다른 사람이 내 코드를 사용하는 방식에 대한 규칙을 적용 할 수 있다는 것입니다. 550 만 라인 프로젝트를 진행하면서 객체 지향 프로그래밍이 매우 유용하다는 것을 알았습니다. 또 다른 장점은 나 (그리고 다른 사람들)가 특정 규칙을 따르고 컴파일 시간에 사소한 오류를 포착하게하는 컴파일러입니다. 모든 이론적 인 장점도 있지만 일상적인 실용적인 것에 집중하고 싶었습니다. 결국 모두 머신 코드로 컴파일됩니다.


-1

객체 지향 프로그래밍은 상자가있는 절차 적 프로그래밍입니다.

PP에는 하나의 상태, 하나의 상태가 있으며, 프로젝트가 커짐에 따라 엄청나게 커져 큰 상태의 작은 부분을 잊을 때마다 부작용이 나타납니다.

OO에는 상자가 많고 주가 많으며 프로젝트가 커짐에 따라 상자가 조금 커지고 상자 수가 많이 커집니다.

더 작은 상자를 보는 것이 더 쉬워지고 전체 그림의 착각을 쉽게 느낄 수 있지만 클래스와 인터페이스를 보면 중요한 결과를 가져올 수있는 구현 세부 사항이 숨겨져 있기 때문에 실제로는 거의 불가능합니다.

함수형 프로그래밍에는 많은 함수 상자가 있으며 모든 함수에는 외부 컨텍스트에 대한 다른 액세스 권한이없는 하나의 항목 (매개 변수)과 하나의 종료 (리턴)가 있는지 결정합니다.

상태가없고 부작용 (설계 상)이 없기 때문에 기능을 전체와 별도로 안전하게 분석 할 수 있으며 어떤 상황에서도 어떻게 작동하는지 100 % 알 수 있습니다.

액션을 나타내는 논리 단위로 복싱 코드를 작성하기 때문에 일반적인 액션 당 하나의 박스 만 가질 수 있습니다.

이것은 OOP에 비해 대규모 프로젝트의 코드를 크게 축소시켜 여러 클래스의 코드 기반에서 여러 아날로그 함수를 숨길 수 있습니다.

더 이상 추적 할 XXXXXXXL 상태가 없기 때문에 프로젝트를 훨씬 더 오랫동안 성장시킬 수 있기 때문에 PP를 훨씬 능가합니다.

요약하면 PP는 간단한 프로그램에 접근하는 가장 간단한 방법이고 FP는 아마도 복잡한 프로그램에 접근하는 가장 간단한 방법 일 것입니다.

모든 코드 기반을 통합하고 코드 재사용을 개선하려는 목표를 고려한다면, FP는 100 % 재사용 성을 가진 유일한 패러다임 일뿐 아니라 매우 큰 규모로 이해되는 유일한 패러다임이므로 항상 사용해야합니다. 단순히 함수를 복사하여 붙여 넣은 다음 오버 헤드없이 다른 곳에서 사용하십시오).

또한 100 % 신뢰할 수있는 단위 테스트를 무료로받을 수 있습니다.

그리고 "private static final of_doom genius awesome string_1"을 작성할 필요가 없습니다.

그리고 당신은 무료로 병렬 처리를 얻습니다.


-3

간단한 한 문장의 차이점은 C ++이 클래스가있는 C 라는 것입니다. 이 기사는 많은 도움이 될 것입니다 : -C ++ (Wikipedia)

또한이 문제에 대한 인터넷 검색이 도움이 될 것입니다. 임의의 사람들에게 이것을 설명하도록 요구하는 것은 까다로울 수 있습니다. IMHO, 누군가에게 묻는 것보다 독서를 통해 더 잘 이해


나는 그것들을 읽었지만 그들은 단지 그들이 어디에 사용되었지만 여전히 내 질문을 해결하지 못했다고 말했다.
niko

나는 구글에 노력을 기울이지 않고 질문을하지 않았지만 여전히 차이점을 이해할 수 없었기 때문에 이러한 문제를 해결하기 위해 stackoverflow를 만났습니다.
niko

1
@niko, 당신은 나를 잘못 여기고있다. 내가 의미하는 것은 독서를 통해 두 사람의 차이점을 이해하려고 노력해야한다는 것입니다. 친구에게 물어 보는 것은 좋지 않습니다. 그들이 당신을 만족시키지 못할 수도있는 자신의 이해를 제공 할 것이기 때문입니다. 그러나 걱정하지 마십시오. 여기에 훌륭한 동료가 있습니다. 그들은 확실히 당신을 도울 것입니다 :-)
Pankaj Upadhyay

2
나는 공감하지는 않았지만 "C ++는 C with Classes"라는 유혹을 받았다. 실제로 C 노력 우리의 엉덩이를 작동 ++ 할 수있는 우리의 사람들은 그것을 얻기 위해 밖으로 사람의 머리.
DeadMG

1
@Pankaj : 맞습니다. 그것은 이었다 클래스와 C. 더 이상 클래스와 함께 C가 아니므로 거의 30 년이 지났습니다. C ++은 그 이후로 먼 길을 갔다. 이제 C ++을 코딩하는 사람들은 절대 그런 식으로 참조하지 않습니다. 그것은 최악의 습관과 잘못된 인상을 장려합니다.
DeadMG
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.