Clojure와 같은 기능적 프로그래밍 언어에 대한 (제한적으로 제한적인) 노출에서 데이터 캡슐화는 덜 중요한 역할을하는 것으로 보입니다. 일반적으로 맵이나 세트와 같은 다양한 기본 유형이 객체보다 데이터를 나타내는 기본 통화입니다. 게다가, 그 데이터는 일반적으로 불변입니다.
예를 들어, Clojure 명성의 Rich Hickey가 그 문제 에 대한 인터뷰 에서 가장 유명한 인용문 중 하나입니다 .
포 거스 : 그 아이디어에 따라 일부 사람들은 Clojure가 유형에 대한 데이터 숨김 캡슐화에 관여하지 않는다는 사실에 놀랐습니다. 데이터 숨기기를 포기하기로 결정한 이유는 무엇입니까?
Hickey : Clojure는 추상화에 대한 프로그래밍을 강력하게 강조합니다. 그러나 어느 시점에서 누군가는 데이터에 액세스 할 수 있어야합니다. 그리고 "개인"이라는 개념이 있다면, 특권과 신뢰에 상응하는 개념이 필요합니다. 그리고 그것은 복잡성과 가치가 거의 없어 시스템에 강성을 만들고 종종 원하지 않는 곳에 살도록 강요합니다. 이것은 간단한 정보를 클래스에 넣을 때 발생하는 다른 손실에 추가됩니다. 데이터가 변경 불가능한 범위 내에서, 누군가가 변경 될 수있는 것에 의존 할 수있는 것 외에는 액세스를 제공 할 때 발생할 수있는 피해는 거의 없습니다. 글쎄, 사람들은 항상 현실에서 그렇게하고, 상황이 바뀌면 적응합니다. 그리고 그들이 합리적이라면 그들은 미래에 적응해야 할 변화가있을 수있는 것을 바탕으로 결정을 내릴 때를 알고 있습니다. 그래서 그것은 위험 관리 결정입니다. 프로그래머가 자유롭게 만들어야한다고 생각합니다. 사람들이 추상화로 프로그래밍하기를 원하고 구현 세부 사항과의 결혼을 원치 않는 감각이 없다면 결코 훌륭한 프로그래머가 될 수 없습니다.
OO 세계에서 왔을 때, 이것은 지난 몇 년 동안 배운 비밀스러운 원칙 중 일부를 복잡하게하는 것 같습니다. 여기에는 정보 숨기기, 데메테르의 법칙 및 통일 접근 원칙이 포함됩니다. 캡슐화의 일반적인 스레드는 다른 사람들이 자신이 만져야 할 것과 만져서는 안되는 것을 알 수 있도록 API를 정의 할 수있게합니다. 본질적으로 일부 코드의 관리자가 소비자 코드에 버그를 도입하는 방법에 대한 걱정없이 자유롭게 코드를 변경하고 리팩토링 할 수있는 계약을 작성합니다 (개방 / 폐쇄 원칙). 또한 다른 프로그래머가 해당 데이터를 얻거나 사용할 수있는 도구를 알 수 있도록 깔끔하고 선별 된 인터페이스를 제공합니다.
데이터에 직접 액세스 할 수있게되면 해당 API 계약이 중단되고 모든 캡슐화 이점이 사라지는 것 같습니다. 또한 엄격히 불변의 데이터는 상태 및 해당 상태에서 수행 할 수있는 일련의 작업을 나타내는 의미에서 도메인 별 구조 (객체, 구조체, 레코드)를 전달하는 것이 훨씬 덜 유용한 것으로 보입니다.
기능적 코드베이스는 코드베이스의 크기가 엄청나게 증가하여 API를 정의해야하고 많은 개발자가 시스템의 특정 부분을 다루는 데 관여 할 때 나타나는 이러한 문제를 어떻게 해결합니까? 이러한 유형의 코드베이스에서 이러한 상황을 처리하는 방법을 보여주는이 상황에 대한 예가 있습니까?
Also, strictly immutable data seems to make passing around domain-specific structures (objects, structs, records) much less useful in the sense of representing a state and the set of actions that can be performed on that state.실제로는 아닙니다. 변경되는 유일한 것은 변경 사항이 새 오브젝트에서 종료된다는 것입니다. 이것은 코드에 대한 추론에서 큰 승리입니다. 변경 가능한 객체를 전달하는 것은 누가 그것을 변형시킬 수 있는지 추적해야한다는 것을 의미하며, 코드 크기에 따라 확장되는 문제입니다.