OO 디자인의 강점은 의미론인가요 아니면 캡슐화인가요?

Question

객체 지향 설계(OOD)는 데이터와 그 방법을 결합합니다.내가 보기에 이는 두 가지 큰 성과를 달성합니다.캡슐화(그래서 어떤 데이터가 있는지는 신경 쓰지 않고 원하는 값을 얻는 방법만 고려) 및 의미 체계(데이터를 이름과 함께 연결하고 해당 메서드는 원래 의도한 대로 데이터를 일관되게 사용함)를 제공합니다.

그렇다면 OOD의 강점은 어디에 있을까요?대조적으로, 함수형 프로그래밍은 명사보다는 동사에 풍부함을 부여하므로 캡슐화와 의미 체계 모두 데이터 구조가 아닌 메소드에 의해 제공됩니다.

나는 스펙트럼의 기능적 끝 부분에 있는 시스템으로 작업하며 지속적으로 OO의 의미와 캡슐화를 갈망합니다.그러나 OO의 캡슐화가 객체의 유연한 확장에 장벽이 될 수 있음을 알 수 있습니다.그래서 지금은 의미론이 더 큰 강점이라고 볼 수 있어요.

아니면 모든 가치 있는 코드의 핵심은 캡슐화입니까?

편집하다:특히 여기서는 OO가 제공하는 캡슐화 유형을 의미합니다. changeColor(door,blue) 된다 door.changeColor(blue).

Answer 1

당신은“캡슐화”의 다소 좁은 정의를 사용하는 것 같습니다. 캡슐화를“방법과 결합하는 것”으로 정의한다고 가정 할 때 옳을까요?

내가 틀렸다면 이 게시물의 나머지 부분을 무시하십시오.

캡슐화는 느슨한 용어가 아닙니다.실제로 이는 국제표준화기구(International Organization for Standardization)에서 정의한 것입니다.ISO의 개방형 분산 처리 참조 모델 - 다음 5가지 개념을 정의합니다.

실재:구체적이거나 추상적인 관심 사항.

물체:엔터티의 모델입니다.객체는 동작과 상태로 특징지어집니다.

(객체의) 동작:발생 시기에 대한 제약 조건이 포함된 작업 모음입니다.

상호 작용:해당 개체의 상호 작용 하위 집합과 해당 개체가 발생할 수 있는 시기에 대한 제약 조건 집합으로 구성된 개체 동작의 추상화입니다.

캡슐화:객체에 포함된 정보는 객체가 지원하는 인터페이스에서의 상호 작용을 통해서만 액세스할 수 있다는 속성입니다.

우리는 더 자명한 제안을 할 수 있습니다:일부 정보는 이러한 인터페이스를 통해 액세스할 수 있으므로 일부 정보는 객체 내에 숨겨져 액세스할 수 없어야 합니다.그러한 정보가 나타내는 속성을 정보 은닉이라고 하며, Parnas는 모듈이 어려운 결정과 변경될 가능성이 있는 결정을 모두 숨기도록 설계되어야 한다고 주장함으로써 이를 정의했습니다. 훌륭한 컴퓨팅 논문 중 하나를 참조하세요.

http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf

정보가 숨겨져 있는 것은 데이터뿐만이 아니라는 점에 유의하는 것이 중요합니다.변경하기 어렵거나 변경될 가능성이 있는 개체와 관련된 동작의 일부 하위 집합입니다.

귀하의 게시물에서는 OO의 캡슐화와 함수형 프로그래밍의 차이가 데이터 관리에서 비롯된다고 말하는 것 같지만, 적어도 ISO와 Parnas에 따르면 데이터 관리는 캡슐화의 핵심이 아닙니다.그래서 함수형 프로그래밍의 캡슐화가 왜 OO의 캡슐화와 달라야 하는지 모르겠습니다.

또한 게시물에서 기능적 프로그래밍은 "데이터 구조보다는 방법에 따라 캡슐화"를 제공한다는 것을 언급합니다. 이것은 절대보다는 규모의 차이라고 생각합니다.만약 제가 "데이터 구조"라는 단어 대신 "객체"라는 단어를 사용한다면(다시 한번 말씀드리지만 제가 잘못 해석하고 있다면 알려주세요) OO의 객체별 캡슐화와 함수형 프로그래밍의 메서드별 캡슐화에서 의미를 찾는 것 같습니다.

그러나 위의 ISO 정의에 따르면 객체는 내가 모델링하려는 모든 것입니다.따라서 클래스 중 일부가 패키지의 인터페이스에 기여하고(즉, 패키지의 공개 클래스) 일부가 정보에 숨겨져 있는 경우(패키지의 비공개 클래스) 클래스는 패키지 내에 캡슐화될 수 있습니다.

동일한 토큰으로 메소드는 클래스 내에 캡슐화됩니다. 일부 메소드는 공개이고 일부는 비공개입니다.이를 한 단계 더 낮추어 McCabian 순차적 코드 시퀀스가 ​​메서드 내에 캡슐화되어 있다고 말할 수도 있습니다.각각은 캡슐화된 영역 내에 캡슐화된 노드 그래프를 형성합니다.이 모든 그래프는 그래프 스택을 형성합니다.따라서 함수형 프로그래밍은 함수/파일 수준에서 잘 캡슐화될 수 있지만 이는 OO의 메서드/클래스 그래프와 다르지 않으며 본질적으로 OO의 클래스/패키지 그래프와도 차이가 없습니다.

또한 위에서 Parnas라는 단어가 사용되었다는 점에 유의하세요.변화.정보 은닉은 미래의 어려운 설계 결정 변경과 같은 잠재적인 사건과 관련이 있습니다.OO의 강점이 어디에 있는지 묻습니다.글쎄, 캡슐화는 확실히 OO의 강점이지만, 질문은“캡슐화의 강도는 어디에 있습니까?”가됩니다. 그리고 그 대답은 명확한 명확성 중 하나입니다.변경 관리.특히 캡슐화는 변경으로 인한 잠재적인 최대 부담을 줄여줍니다.

여기서는 "잠재적 결합"이라는 개념이 유용합니다.

"커플링" 자체는 컴퓨팅의 또 다른 훌륭한 논문에서 "한 모듈에서 다른 모듈로의 연결에 의해 설정된 연결 강도의 척도"로 정의됩니다.

http://www.research.ibm.com/journal/sj/382/stevens.pdf

그리고 논문에 따르면 그 이후로 결코 나아지지 않았습니다. "모듈 간의 연결을 최소화하면 변경 사항과 오류가 시스템의 다른 부분으로 전파되는 경로도 최소화되어 한 부분의 변경으로 인해 발생하는 재앙적인 "파급 효과"가 제거됩니다. 다른 오류가 발생하여 다른 곳에서 추가 변경이 필요하고 새로운 오류가 발생하는 등의 문제가 발생합니다.

그러나 여기에 정의된 대로 쉽게 해제할 수 있는 두 가지 제한 사항이 있습니다.첫째, 결합은 모듈 내 연결을 측정하지 않으며 이러한 모듈 내 연결은 모듈 간 연결만큼 많은 "리플" 효과를 발생시킬 수 있습니다. 이 논문에서는 모듈 내 연결과 관련하여 "응집력"을 정의합니다. 그러나 이는 결합이 정의된 요소(즉, 라벨 또는 주소에 대한 참조) 간의 연결 측면에서 정의되지 않습니다.둘째, 모듈이 연결되어 있다는 점에서 모든 컴퓨터 프로그램의 결합이 제공됩니다.Parnas가 말하는 잠재적인 변화를 관리하기 위한 결합의 정의에는 범위가 거의 없습니다.

이 두 가지 문제는 잠재적인 결합이라는 개념을 통해 어느 정도 해결됩니다.프로그램의 모든 요소 간에 형성할 수 있는 최대 연결 수입니다.예를 들어 Java에서 패키지 내의 패키지 전용(기본 접근자) 클래스는 연결을 형성할 수 없지만(즉, 리플렉션에도 불구하고 외부 클래스는 이에 의존할 수 없음) 패키지 내의 공용 클래스는 가능합니다. 그것에 의존성을 가지고 있습니다.이 공개 클래스는 현재 다른 클래스가 이에 의존하지 않더라도 잠재적인 결합에 기여할 것입니다. 나중에 디자인이 변경되면 클래스가 이에 의존할 수 있습니다.

캡슐화의 강점을 보려면 부담의 원칙을 고려하세요.부담의 원리는 두 가지 형태를 취합니다.

강력한 형식에서는 엔터티 컬렉션을 변환하는 부담이 변환된 엔터티 수의 함수라고 명시합니다.약한 형식은 엔터티 모음을 변환하는 데 따른 최대 잠재적 부담이 변환된 엔터티의 최대 잠재적 수에 따른 함수임을 나타냅니다.

소프트웨어 시스템을 생성하거나 수정하는 부담은 생성되거나 수정된 ​​클래스 수의 함수입니다. 여기서는 OO 시스템을 가정하고 "클래스"를 사용하며 클래스/패키지 수준의 캡슐화와 관련됩니다.우리는 함수형 프로그래밍의 함수/파일 수준에도 똑같이 관심을 가질 수 있었습니다.(“부담”은 현대 소프트웨어 개발은 ​​일반적으로 비용 또는 시간 또는 둘 다입니다.) 특정 수정 클래스에 의존하는 클래스 수정 된 클래스에 의존하지 않는 클래스보다 영향을받을 확률이 높습니다. .

수정된 클래스가 부과할 수 있는 최대 잠재적 부담은 해당 클래스에 의존하는 모든 클래스에 영향을 미치는 것입니다.

따라서 수정된 클래스에 대한 종속성을 줄이면 해당 업데이트가 다른 클래스에 영향을 미칠 가능성이 줄어들고 해당 클래스가 부과할 수 있는 최대 잠재적 부담도 줄어듭니다.(이것은 "구조화된 디자인" 논문을 다시 설명한 것에 불과합니다.)

따라서 시스템의 모든 클래스 간의 최대 잠재적 종속성 수를 줄이면 특정 클래스에 대한 영향으로 인해 다른 클래스가 업데이트될 가능성이 줄어들고 따라서 모든 업데이트의 최대 잠재적 부담이 줄어듭니다.

캡슐화는 모든 클래스 간의 최대 잠재적 종속성을 줄임으로써 약한 형태의 부담 원칙을 완화합니다.이는 프로그램을 구성하는 논리적 수단으로 잠재적 결합을 사용하여 그러한 주장을 수학적으로 증명하려고 시도하는 "캡슐화 이론"에 의해 모두 다루어집니다.

그러나“캡슐화가 가치있는 코드의 열쇠입니까?”라고 물을 때는 주목하십시오. 대답은 반드시 다음과 같아야합니다.아니요.모든 가치 있는 코드에 대한 단일 키는 없습니다.캡슐화는 특정 상황에서 코드의 품질을 향상시켜 "가치 있는" 코드가 되도록 돕는 도구일 뿐입니다.

또한“… 캡슐화는 객체의 유연한 확장에 대한 장벽이 될 수 있습니다.”라고 썼습니다. 예, 가장 확실하게 할 수 있습니다.이는 실제로 어렵거나 변경될 가능성이 있는 객체의 설계 결정을 확장하는 데 대한 장벽이 되도록 설계되었습니다.그러나 이것은 나쁜 것으로 생각되지 않습니다.대안적인 접근 방식은 모든 클래스를 공개하고 프로그램이 최대 잠재적 결합을 표현하도록 하는 것입니다.그러나 약한 형태의 부담 원칙은 업데이트 비용이 점점 더 높아질 것이라고 말합니다.이는 확장 장벽을 측정해야 하는 비용입니다.

마지막으로, 당신은 캡슐화와 의미론을 흥미롭게 비교했는데, 당신의 의견으로는 OO의 의미론이 더 큰 장점이라고 생각합니다.나도 의미론자는 아니지만(램지 씨가 그의 논평에서 언급하기 전에는 그런 단어가 존재하는지조차 몰랐습니다) 하지만 당신은 "의미 또는 단어의 의미에 대한 해석”, 그리고 매우 기본적으로 woof() 메소드가 있는 클래스는 Dog라고 불려야 한다는 것입니다.

이 의미론에는 실제로 큰 힘이 있습니다.

나에게 흥미로운 점은 의미론적으로 캡슐화를 반대하고 승자를 찾는다는 것입니다.나는 당신이 그것을 찾을 수 있을지 의심됩니다.

내 생각에는 캡슐화를 촉진하는 두 가지 힘이 있습니다.의미론과 논리.

의미론적 캡슐화는 단순히 캡슐화된 노드(일반 용어를 사용하기 위해)의 의미를 기반으로 하는 캡슐화를 의미합니다.따라서 '동물'과 '미네랄'이라는 두 개의 패키지가 있다고 말하고 Dog, Cat, Goat라는 세 가지 클래스를 제공하고 이 클래스를 어떤 패키지에 캡슐화해야 하는지 묻는다면 다음과 같습니다. 다른 정보가 없으면 시스템의 의미론에 따라 세 가지 클래스가 '미네랄'이 아닌 '동물' 패키지 내에 캡슐화되어야 한다고 주장하는 것이 완전히 옳을 것입니다.

그러나 캡슐화의 또 다른 동기는 논리, 특히 위에서 언급한 잠재적 결합에 대한 연구입니다.캡슐화 이론은 잠재적인 결합을 최소화하기 위해 여러 클래스를 캡슐화하는 데 사용해야 하는 패키지 수에 대한 방정식을 실제로 제공합니다.

나에게 있어 캡슐화는 전체적으로 의미론적 접근 방식과 논리적 접근 방식 간의 절충안입니다.이것이 프로그램을 의미상 이해하기 쉽게 만든다면 내 프로그램의 잠재적 결합이 최소값 이상으로 높아지도록 허용하겠습니다.그러나 거대하고 낭비적인 수준의 잠재적 결합은 의미상 아무리 분명하더라도 내 프로그램을 재구성해야 한다는 경고가 될 것입니다.

(그리고 만약 훌륭한 Mister Ramsey가 아직도 읽고 있다면, 당신이나 당신의 의미론자 친구들이 내가 여기서 사용하고 있는 "의미론" 단계에 대해 더 나은 단어를 줄 수 있습니까?좀 더 적절한 용어를 사용하는 것이 좋을 것 같습니다.)

안부, ed.

Answer 2

캡슐화 및 결과 추상화는 분명히 OO의 주요 강점입니다. "사물"은 "행동"을 불러 일으킬 수있는 것을 술어에 넣을 수 있으므로 명사는 동사보다 의미 론적 중요성을 초래합니다.

궁극적으로, 어느 정도의 캡슐화없이 일관되고 유지 가능한 형태로 복잡한 시스템을 설계하는 것은 어렵습니다.

Answer 3

객체 시스템이 이들 중 어느 것도 제공하지 않는 LISP 프로그래머로서, 나는 위의 어느 것도 없다.

JWZ : "의사 스마트 토크 객체 모델은 잃어 버리고 일반 기능 (비외-오버 라이드 규칙에 따라 적절하게 제한)이 승리합니다."

나는 당신과 다른 사람들이 여기에 나열하는 바람직한 속성 (캡슐화, 모듈성 등)이 당신이 생각하는 것만 큼 내재되어 있지 않다고 생각합니다. 그들은 종종 자바 스타일의 OO와 함께 제공되지만 순전히 그 결과는 아닙니다.

Answer 4

복잡성을 분리합니다 IMO는 모든 디자인의 주요 목표입니다. 인터페이스 뒤에 기능을 캡슐화합니다. 사용하기가 더 간단합니다 기능 자체보다.

OO는 이에 대한 다양한 메커니즘을 제공합니다.

캡슐화 실제 구현과 무관 한 사용자 정의 표면을 설계 할 수 있습니다. (역설적으로, "단순한 의미는 다릅니다").

의미론 문제 영역의 요소를 나타내는 엔티티를 모델링 할 수 있으므로 이해하기 쉽습니다.

---

특정 규모에 도달하는 모든 프로젝트는 복잡성을 관리하는 데 운동이됩니다. 나는 수년 동안 우리가 관리하는 법을 배운 복잡성의 한계를 따라 프로그래밍이 삐걱 거렸다는 주장을 베팅했습니다.

나는 수년간 기능 프로그래밍에 덤벼를 흘리지 않았지만, 이해할 때 그것은 강력하고 엘간, AMD 아름다운 단어에 대한 수학자의 의미로 가장 잘 설명 될 수 있습니다. "아름답다"와 "우아함"은 이러한 맥락에서 복잡한 시스템의 진실 또는 관련 구조에 대한 훌륭한 통찰력을 설명하여 놀랍게도 단순한 관점에서 볼 수 있습니다. 그것은 주어진 복잡성을 받아들이고 그것을 탐색하려고합니다.

당신이 언급 한 유연성은 당신의 요구에 따라 POV를 바꿀 수있는 능력을 이해하는 데 있습니다. 그러나 캡슐화와 상반되는 것입니다. 한 위치에서 무의미한 세부 사항은 다른 위치에서 유일한 관련이있을 수 있습니다.

Oo, Otoh는 환원 주의자 접근 방식입니다. 우리는 더 높은 수준으로 이동하여 POV를 변경합니다. "Old Oo"에는 POV의 단일 계층 구조가 있으며 인터페이스는이 모델에서 다른 POV를 모델링하는 방법입니다.

내가 그렇게 말할 수 있다면, OO의 힘은 "정상적인 사람들"에 더 적합합니다.

Answer 5

어떤 형태의 모듈성 확장 가능한 디자인의 열쇠입니다. 인간의 한계는 사람들이 한 번에 너무 많은 정보를 "그로킹"하는 것을 방해하지 않으므로 문제를 관리 가능하고 응집력있는 덩어리로 세분화해야합니다. 이해 큰 프로젝트뿐만 아니라 작업 할당을 세분화합니다 많은 사람들 사이에서 큰 프로젝트.

위의 목표를 달성하기 위해 큰 프로젝트의 가장 효과적인 "부서"/"파티셔닝"을 선택하는 방법은 무엇입니까? 경험은 OO가 여기에서 큰 승자라는 것을 보여 주었고, 많은 사람들이 OO의 두 가지 주요 속성이 다음과 같이 동의 할 것이라고 생각합니다.

• 캡슐화: 각 클래스는 구현에 관해 시대의 구현에 관한 일련의 구현 별 가정 세트를 캡슐화하고 이러한 가정에 불가지론적인 인터페이스를 노출시킨다. 이러한 캡슐화 된 추상화를 레이어링하면 예상되는 변화에 직면하여 구성 요소/구현을 쉽게 교체 할 수있는 강력한 설계를 설계 할 수 있습니다.
• 명사 중심: 대부분의 도메인에서, 인간은 도메인의 명사/데이터에 대해 생각하여 처음에 도메인 모델을 분해 한 다음 각 명사와 관련된지지 동사를 식별합니다.

기능 프로그래밍 (FP)과 OO에 대해 블로그 이것에 대해 간단히 말해서 FP는 구현 기술에 관한 것이라고 생각하지만 OO는 프로그램 구조와 설계에 관한 것이므로 두 사람은 보완 적이며 OO는 척도의 '큰'끝에서 더 지배적이며 FP는 더욱 지배적입니다. '작은'끝에. 즉, 대규모 프로젝트에서 고급 구조는 OO 클래스 디자인에 의해 가장 잘 설명되어 있지만 많은 모듈 수준 세부 사항 (구현 및 모듈의 인터페이스 모양의 세부 사항)은 FP가 가장 잘 모양입니다. 영향.

Answer 6

객체 지향 디자인의 강도는 얼마에 비례합니다 늦은 바인딩 디자인에서 발생합니다. 이것은 Nygaard 개념이 아니라 OO의 Kay 개념입니다. 앨런 케이는 썼다:

나에게 OOP는 메시징, 현지 유지 및 보호 및 국가 프로세스의 숨기기, 모든 것의 극도의 늦은 바인딩만을 의미합니다. SmallTalk와 Lisp에서 수행 할 수 있습니다. 이것이 가능한 다른 시스템이있을 수 있지만, 나는 그것들을 알지 못합니다.

문헌의 대부분은 객체 방향의 C ++ 아이디어에 유리한 후기 바인딩을 무시합니다.

Answer 7

물러서서 더 높은 수준에서 이것을 살펴 보겠습니다. 모든 언어 기능의 장점은 문제/솔루션을 문제 영역과 관련하여보다 자연스럽게 표현할 수있는 능력에 있습니다.

OOP의 역학은 스트러크 및 기능 포인터와 함께 일반 C로 쉽게 구현됩니다. 당신은 그렇게하는 방식으로 약간의 OOP 느낌을 얻을 수 있습니다. 그러나 OOP 관용구는 그러한 환경에서 거의 다가오지 않습니다. OOP에 대한 실제 언어 지원이있을 때 패러다임의 표현력이 나오고 언어가 아이디어를 구현하는 방식은 "상기"와 방법에 매우 실질적인 영향을 미칩니다. 예를 들어 LISP, Python, Ruby 등의 클로저/람다를 사용한 코드 차이를 참조하십시오.

따라서 결국 그것은 구성 요소와 기본 개념에 관한 것이 아니라 C ++에서 OO를 구성하고 사용하는 방법이 무엇인지에 관한 것입니다.

Answer 8

다형성과 함께 캡슐화. 하나 이상의 인터페이스를 구현할 수있는 대부분의 OOP 언어로 클래스의 능력은 내 소프트웨어 개발에 가장 큰 영향을 미쳤습니다. 이 기능을 사용하면 두 객체 간의 상호 작용을 정확하게 정의 할 수 있습니다.

상호 작용을 정의 할뿐만 아니라 몇 년 후에 코드 섹션으로 돌아와서 무엇이 일어나고 있는지 명확하게 볼 수 있도록 문서화하십시오.

이 기능은 기능 언어보다 OOP 언어를 사용하는 것을 선호하는 주된 이유입니다. 매우 강력하지만, 기능적 언어로 작성된 소프트웨어는 유지 보수주기가 수십 년 안에 측정 될 때 유지해야 할 고통이라는 것을 발견했습니다. (AutoLISP 소프트웨어에서 AutoCAD에서 발견)

Answer 9

IMHO, OO는 단순히 다른 객체와 상호 작용하는 객체를 의미합니다. 캡슐화는 단순히 개념을 추상화하는 것을 의미합니다. 따라서 소켓과 .connect ()를 만듭니다. 그것이 어떻게 연결되는지, 당신은 실제로 신경 쓰지 않습니다 (이것은 기본적으로 캡슐화에 대한 나의 정의입니다).

그리고 순수한 기능적 프로그래밍은 물체를 사용하여 의사 소통 할 수 있습니다. 그러나 이러한 객체는 불변이어야합니다. 따라서 다시 IMHO, FP는 OO 개념을 쉽게 사용할 수 있습니다. C와 같은 명령 언어는 여전히 OO의 개념을 사용할 수 있습니다. 예를 들어, 사용해서는 안되는 개인 섹션이있는 각 "클래스"파일.

Answer 10

당신의 질문은 벽돌을 분석하여 집의 이점을 도출하고 싶어하는 것처럼 읽습니다.

시맨틱 컨텍스트와 캡슐화를 제공하는 능력은 OO의 클래스의 기본 기능 일뿐입니다. (벽돌처럼 특정 힘을 견딜 수 있고 특정 공간을 주장 할 수 있습니다.)

비유를 계속하려면 : 최대 벽돌을 얻으려면 그냥 합치십시오. 동일한 것은 클래스와 객체에 적용됩니다.

거기 많은 디자인 패턴입니다 OO 프로그래밍에 사용할 수 있습니다. 그들 대부분은 당신이 언급 한 능력 "캡슐화"와 "의미 론적"에 의존합니다.

이러한 패턴 중 일부는 질문의 세 번째 단락에 대한 답변이기도합니다.

• 기존 클래스의 동작을 확장하려면 파생 클래스를 만들 수 있습니다.
• 기존 객체의 동작을 확장하거나 변경하려면 다음을 고려할 수 있습니다. 데코레이터 패턴.

Answer 11

OO의 진정한 힘은 캡슐화보다는 다형성에 있습니다.캡슐화는 어느 정도 달성 ​​가능하고 함수형 언어에서 사용되지만, 다형성은 함수형 언어로 구현되면 매우 어색할 것입니다.

("디자인 패턴"을 읽으십시오. 4인조 OO의 힘을 이해하기 위해.)

@Phil, 당신이 올바르게 이해했다면 당신이 언급한 차이점은 프로그램이 데이터/메서드를 호출하는 방식 사이에 있습니다.oo에는 먼저 개체/인스턴스가 있고 그 다음 개체의 데이터/메서드가 개체를 통해 호출됩니다.함수형에서는 메서드가 직접 호출됩니다.

그러나 기능적 프로그램의 구현을 살펴보면 데이터와 메서드가 래핑되어 있음을 알 수 있습니다(클래스가 아닌 파일에 있음).예를 들어, C 프로그램에는 다른 파일에서 액세스할 수 있는 함수를 선언하는 헤더 파일이 있으며, 선언된 함수를 통해서만 액세스할 수 있는 데이터는 개인 데이터입니다.프로그래머가 충분히 주의를 기울이는 한 OO의 대부분의 캡슐화는 기능적 프로그램에서 구현될 수 있습니다.(특정 포인터 트릭을 사용하면 상속도 가능합니다.)