코드 캡슐화

최근에 저는 더 나은 소프트웨어 엔지니어와 프로그래머가 되기 위해 노력해 왔으며 제 머리를 돌리려고 하는 것은 코드를 잘 '캡슐화'하는 방법입니다. 캡슐화는 결합이 느슨하지만 응집력이 높은 코드를 생성합니다. 코드 캡슐은 원활하게 함께 작동하지만 서로 독립적이기도 합니다.

Eric Elliotthere가 말했듯이 코드의 캡슐화는 데이터의 번들링과 해당 데이터에 대한 작업을 수행하여 해당 데이터에 대한 액세스가 번들 외부에서 제한되는 것입니다. 국가 프로세스의 로컬 유지, 숨기기 및 보호입니다.

잘 캡슐화된 코드는 소프트웨어 엔지니어링의 세 가지 영원한 원칙을 염두에 둡니다.

변경 가능한 공유 상태를 피하십시오. "비결정론 = 병렬 처리 + 변경 가능한 상태" - Martin Odersky, Scala 프로그래밍 언어 디자이너

"구현이 아닌 인터페이스에 대한 프로그래밍"— Gang of Four, "디자인 패턴: 재사용 가능한 객체 지향 소프트웨어의 요소"

"요구사항의 작은 변화는 그에 상응하는 소프트웨어의 작은 변화를 필요로 합니다."— N. D. Birrell, M. A. Ould, "소프트웨어 개발을 위한 실용적인 핸드북"

나는 여전히 이 인용문이 진정으로 의미하는 바를 파악하고 내 작업에서 그것을 연습하고 있지만, 약간의 빛을 비추기 위해 차례로 간략하게 각각의 개요를 설명하겠습니다.

먼저, 변경 가능한 공유 상태입니다. 이것은 코드의 다른 부분이 동일한 데이터에 의존하고 해당 데이터가 이러한 부분에 의해 영구적으로 수정되는 곳입니다. 한 항목의 입력은 다른 항목에 의해 수정되는 일부 상태에 따라 달라질 수 있습니다. 프로그램이 다른 순서로 실행되거나 부분이 동시에 실행되기로 결정하면 혼란이 뒤따릅니다! 결과는 예측할 수 없습니다. 작동할 때도 있고 작동하지 않을 때도 있습니다.

둘째, 인터페이스 프로그래밍. 이것은 내가 이해하는 바에 따르면 메시지 전달에 의한 프로그래밍입니다. 메시지 전달은 개체의 속성을 직접 업데이트하는 대신 개체의 메서드 중 하나를 호출하면 원하는 작업을 수행할 수 있음을 의미합니다. 공개 인터페이스 뒤에서 코드를 캡슐화하는 이 아이디어는 위의 세 번째 요점도 다루기 때문에 흥미롭습니다. "요구사항의 작은 변경은 그에 상응하는 소프트웨어의 작은 변경을 필요로 해야 합니다."이와 같이 프로그래밍하면 다른 코드가 구현 세부 정보에 연결되지 않는다는 의미입니다. 어떤 메시지를 전달할지 알 뿐입니다.

좋아, 우리는 캡슐화가 무엇을 의미하는지 알지만 JS에서 어떻게 생겼는지 알 수 있습니다. 간단한 예를 살펴보겠습니다.

공장 기능 + 폐쇄

이 예에서 accountBalance는 createPerson 팩토리 함수 내에 캡슐화되어 있으며 pay() 및 getBalance() 를 호출해야만 조작할 수 있습니다.

이는 함수가 반환된 후에도 포함하는 함수의 범위 내의 개인 데이터에 액세스할 수 있음을 의미하는 권한 있는 메서드입니다. 참조도 라이브입니다. 즉, accountBalance가 변경되면 액세스 권한이 있는 모든 기능에 대해 변경됩니다.

const createPerson = ({name = "thing", age = 20} = {}) => {
  let accountBalance = 10

  return {
    pay: () => accountBalance++,
    getBalance: () => accountBalance.toLocaleString()
  }

}

const person = createPerson()
person.pay()
console.log(person.getBalance()) // '11'

이것은 이러한 중요한 개념의 매우 간단한 예이지만 특정 데이터와 코드가 공개 인터페이스 뒤에 숨겨지고 생성된 개체 인스턴스에 메시지를 전달함으로써만 조작될 수 있는 방법을 강조합니다.

참조:

https://medium.com/javascript-scene/encapsulation-in-javascript-26be60e325b4