The State of Immutability

현대 자바스크립트에서 불변성은 뜨거운 주제입니다. 이 주제가 지금 인기를 끌고 있는 이유는 기능 프로그래밍 패러다임 때문입니다. 불변 데이터는 돌연변이가 원치 않는 부작용으로 간주되는 기능적 접근법과 밀접하게 연결되어 있습니다. 더 이상 고민하지 말고, 돌연변이성과 불변성에 대한 세부사항을 살펴봅시다.

자바스크립트에서 변경할 수 없는 데이터 구조

자바스크립트와 다양한 언어에서 assign문은 두 가지 방식으로 작동합니다. 기본 유형(문자열, 숫자, 부울)에 대한 할당은 값을 전달하며, 복합 유형(객체)의 경우 참조(메모리 포인터)를 전달합니다. 복합 유형의 경우, 변경 사항은 실제로 동일한 장소에 대한 포인터 일 뿐이므로 모든 변경 사항에 영향을 미칩니다. 오직 기본 유형만 불변하며 안전하게 변경할 수 있으며, 기본 유형을 제외한 모든 유형은 기본적으로 변경 가능합니다.

그렇다면 불변의 요점이 무엇인지 생각해 봅시다. 자바스크립트는 이처럼 불변성을 가진 것이 아니라, 복합재료를 위한 불변 구조도 없고, 심지어 그것을 언어에 도입할 미래의 계획도 없습니다. 언어가 신경 쓰지 않는다면 왜 신경을 써야 합니까?

신뢰가 중요하기 때문에 신경을 써야 한다.

변경 가능한 구조를 사용하는 것은 신뢰 부족의 이유입니다. 모든 코드 부분에서 참조에 대한 액세스를 통해 변형을 수행 할 수 있습니다.

자바스크립트는 매우 융통성이 있습니다. 즉, 어떤 객체도 즉석에서 완전히 다른 무언가로 변형 될 수 있습니다. 한 줄에서는 개를 나타내는 객체가 될 수 있고 다음 줄에서는 개가 닭으로 변이 될 수 있습니다. 이러한 상황은 상태 형태와 코드 예측 가능성에 대한 두려움을 증가시킵니다.

돌연변이에 대한 몇 마디

돌연변이의 기회는 무언가가 변하지 않을 것이라고 보장하지 못합니다. 최악의 시나리오는 일부 구조가 응용 프로그램의 개별 부분에서 사용될 때 발생합니다. 그러면 한 구성 요소의 모든 변형이 다른 구성 요소에 버그를 만들 수 있습니다. 이러한 버그는 문제의 원인이 오류의 범위를 벗어나기 때문에 추적하기가 어렵습니다. 이것은 나쁜 부작용의 예입니다.

돌연변이는 부작용의 원인이다.

부작용은 현재 범위 외부에 영향을주는 모든 것입니다. 코드의 많은 부분이 동일한 참조를 다루는 경우, 모든 변경이 모든 부분에 영향을줍니다. 코드가 단단히 결합되기 시작하고, 단일 책임 규칙을 따르는 대신 코드 조각이 발생하고, 범위 밖에서 제어되지 않는 일을하고 있기 때문에 부작용이 좋지 않습니다. 원치 않는 애플리케이션은 더 넓은 애플리케이션 컨텍스트에 영향을 미칩니다.
밖에서 만지는 것은 항상 위험하며 예측할 수없는 결과를 초래합니다. 버그가 발견되면 질문이 제기됩니다 - 변경된 곳은 어디입니까? 정확히 무엇이 바뀌 었습니까? 누구도 참조에 액세스 할 수 있습니까? 그러나 변화의 역사는 없으며 쉽게 답할 수 없습니다.

돌연변이는 현재 상태 만 제공한다.

하나의 참조가 여러 번 변경되면 이러한 변경 사항이 기록되지 않습니다. 이전 상태에 액세스 할 수 없습니다. 객체 속성을 변경하면 실제로 메모리를 다시 쓰고, 이전 값은 손실됩니다. 변화에 대한 지식 부족과 관련된 문제는 동일한 변경 가능한 구조에 대한 액세스 권한을 가진 여러 곳에서 증가하고 있습니다. 그 시간에 구조가 어떻게 변화하는지 알 수 없습니다.

자동차 객체에서 자전거 객체로 형태를 바꾸는 것 - 주차장 모니터링 없음!

돌연변이는 예측할 수 없는 상태의 원인이다.

돌연변이 절차에 많은 단계가 포함되어 있다면 많은 속성이 변경되고 있는 경우 절차가 중간에서 제어가 가능합니다. 이 경우 상태는 이전 유효한 버전으로 롤백해야하며, 그렇지 않은 경우 상태는 알 수 없는 모양으로 남습니다. 알 수 없고 예측할 수없는 상태는 이 구조가 소비되는 장소에서 충돌로 변할 수 있습니다.

반면 돌연변이는 기억을 재사용하고 빠릅니다.

그렇습니다. 돌연변이가 기억을 재사용하고 있습니다. 돌연변이는 성능과 메모리 사용에 유리합니다. 그러나 우리는 21세기에 살고 있으며 메모리가 저렴하고 프론트엔드 개발의 소규모 규모에서는 어떤 객체가 복사 될지 여부는 중요하지 않습니다. 불변 복사본이 성능에 영향을 미칠 위험은 없습니다. 가비지(Garbage) 컬렉터는 참조를 사용하지 않기 때문에 메모리 누수 나 불필요한 메모리 점유에 대해 걱정할 필요가 없습니다.

... 명확하게 말하면 프론트 엔드 측면의 문제를 언급하고 있지만, 메모리가 가장 중요한 다른 많은 종류의 소프트웨어가 있다는 것은 이해할 수 있습니다.

우리는 많은 기억을 가지고있다.

Place Oriented Programming — PLOP

Rich Hickey가 제시 한 용어는 정확하게 가변성을 사용하는 감각을 포착합니다. 값에 대한 보증이 존재하지 않는다면, 우리의 객체는 단지 메모리에있는 장소에 대한 포인터 일뿐입니다. 객체는 모양 A에서 작성되었지만 코드 실행 중에 모양 B, C, D 등으로 변환되었습니다. 변수는 값이 아닌 메모리를 나타냅니다.

불변이란 값에 관한 것입니다.

영상... https://youtu.be/-6BsiVyC1kM

불변이란 말 그대로 돌연변이가 될 수없는 것이고, 나는 더 멀리 나아갈 수 있습니다. 돌연변이는 단지 존재하지 않습니다. 변수는 단일 변경 불가능한 값을 나타냅니다. valueA! == valueB이므로 값의 변환이 없습니다. 값은 사실이며 사실은 변하지 않습니다. 특정 값으로 선언 된 것이 있으면 나머지 코드는이 정확한 값이 있다는 것을 완전히 신뢰할 수 있습니다. 이 보증은 부작용이없고 예측할 수없는 상태가 관찰되지 않고, 가장 중요한 것은 신뢰를 재구성하는 것이며, 코드의 일부분이 약간 다른 구조를 필요로한다고 하더라도 원래의 구조에 손대지 않고 자체 버전으로 작동한다는 것입니다. 값을 사용하면 보증 및 확고한 계약이 제공됩니다. 메모리 포인터를 사용하면 보증 및 계약이 제공되지 않습니다.

변경할 수없는 구조와 변경 가능한 구조

Value Oriented Programming — VOP

PLOP와는 달리 VOP는 값에 관한 것입니다. 코드는 메모리의 포인터가 아닌 값에서 작동합니다. 다른 값을 나타내는 것은 분리된 구조 여야합니다. 값은 생성에서 파기까지 변경되지 않습니다. 모든 순수한 기능 언어는 값이 지향적입니다.

어떤 차이도 새 값에 반영되어야 합니다.

변화는 돌연변이를 의미하지는 않으며, 변화의 의미는 변화를 반영한 새로운 버전의 상태를 생성합니다. 그러나 모든 경우에 적용 가능합니까? 이것은 일부 개발자, 나도, 불변의 문제가 있습니다. 문제는 대규모 데이터 수집과 같이 큰 것이 존재할 때 시작되며 작은 변화 만이 수행되어야합니다. 그런 경우에 새로운 구조를 만드는 것이 잘못되었다고 느껴질 때, 그 기억이 매우 비효과적인 방식으로 사용되는 것으로 느껴집니다. 왜 정말로 데이터의 새로운 구조를 만들 필요가 있습니다.
실제로 하나의 요소만 추가해야하거나 하나의 필드를 변경해야한다면?

그리고이 질문에 대한 답은 변화된 구조가 다른 값을 나타내기 때문입니다. 이전과 변경된 두 컬렉션은 동일하지 않습니다. 값의 크기에도 불구하고 사실은 변경 될 수 없으며 값은 변할 수 없는 사실입니다.

따라서 당신이 값의 관점에서 생각하기 시작한다면, 그런 의심은 당신을 괴롭히지 말아야 합니다. 의심이 사라지지 않으면 Immutable.js가 다음 장에서 그에 대한 몇 마디를 구하게 됩니다.

Value Oriented Programming in JavaScript

VOP는 자바스크립트로 구현 될 수 있습니다. 전에 말했듯이 자바 스크립트에는 불변 구조가 없지만 원칙과 규칙에 따라 불변성을 달성 할 수 있습니다.

객체 고정(Freeze your objects)

Object.freeze 메서드는 추가 변형으로부터 객체를 차단할 수있는 기회를 제공합니다.

const frog = { color: 'green', sound: 'ribbit ribbit' };
Object.freeze(frog);
frog.color = 'red';
frog.sound = 'hau hau';
console.log(frog); // {color: "green", sound: "ribbit ribbit"}

위의 예제에서는 frog 속성을 변경하려했지만 결과는 객체가 변경되지 않았습니다. Object.freeze가 객체 필드에서만 돌연변이를 차단한다는 사실은 매우 중요합니다. 즉 얕은 freeze입니다. 얕은 것은 객체 내부의 복잡한 구조가 여전히 변이 될 수 있음을 의미합니다.

변경 작업 대신 새 인스턴스 만들기

// object
const claraFrog = { color: 'green', name: 'Clara' };
const juliaFrog = { ...claraFrog, name: 'Julia' };
// array
const week = ['monday','tuesday','wednesday','thursday','friday','saturday', 'sunday'];
const betterWeek = [...week];
betterWeek.shift(); // week without monday :)

스프레드 연산자는 배열 및 객체에서 새 값을 만드는 데 사용할 수 있습니다. 그것은 매우 편리한 도구이며, 코드도 매우 명확하게 보입니다. 변경된 내용과 재사용 된 내용을 볼 수 있습니다.

스프레드 연산자가 얕은 복사를 수행하면 루트 객체 참조가 변경되지만 모든 필드(객체) 또는 행(배열)이 다시 사용된다는 의미입니다. 또한이 방법이 효율적인 방식으로 메모리를 사용한다는 것을 의미합니다.

변경 불가능한 데이터 구조 사용

바 스크립트는 상자에서 벗어난 불변 구조를 가지고 있지 않지만 제 3자 구현이 있습니다. 가장 인기있는 것은 Immutable.js와 mori입니다. 둘 다 검색 트리 구조의 일종 인 trie데이터 구조를 기반으로합니다. 이러한 구조는 복사없이 새로운 인스턴스를 생성하는 매우 효율적인 방법을 허용합니다.

trie를 사용하는 개인적인 관점에서 볼 때, 실제로 복잡한 구조에서는 데이터 구조가 유용 할 수 있습니다. 다른 무엇보다도 나는 스프레드 연산자를 선호합니다. 그리고 성능 문제가 나타날 때까지 제3자 솔루션을 고려하지 않을 것입니다.

불변 기능이 함수 프로그래밍에 묶여 있습니까?

전혀 아니다. VOP는 다른 프로그래밍 패러다임에서 사용될 수 있습니다. 요즘에는 객체 지향 프로그래밍의 전문가와 전도자가 불변의 상태 저장 객체에 대해 이야기하고 있습니다. 여기 VOP는 함수형 프로그래밍에서와 같은 이점을 제공합니다. 상태가없는 객체 또는 불변 상태를 가진 객체는 그것을 소비하는 모든 당사자에 대해 보증과 신뢰를 제공합니다. 불변 객체는 모든 종속성을 생성자에 전달해야하기 때문에 단일 책임 규칙을 증폭합니다. Immunability는 객체 라이브 사이클 중 상태 변경을 차단합니다. 즉, 객체가 처음부터 끝까지 변경 불가능한 상태로 유지된다는 것을 확신 할 수 있습니다.

setter를 잊어 버리고 OOP에 불변 객체를 만듭니다. 이 주제에 대한 훌륭한 이야기 아래서, Yegor Bugayenko가 자바 언어와 관련이 있습니다.

영상 https://youtu.be/p7m7_iiqaHI

당신은 불변의 준비가 되셨습니까?

고려해야 할 모든 것들 - 불변성은 규칙과 원칙에 의해 달성 될 수 있습니다. 자바 스크립트는 변경되지 않은 불변성을 가지고 있지 않으므로, 퍼블릭 연산자와 외부 라이브러리가 쉽게 구현할 수 있습니다. 불변성이 규칙에 관한 것이라면 모든 것이 개발자의 손에 달려 있습니다. 값의 값을 본다면이 이 순간부터는 그 돌연변이가 당신의 응용에 없어져야 합니다.

그러나 문제는 나쁜 습관애 있으며, 나쁜 습관은 대부분 객체 지향 프로그래밍에서 비롯됩니다. 나쁜 습관은 우리의 마음 속에 있으며, 우리의 피부 아래 있습니다. 객체의 setter와 같은 나쁜 관행, 객체 상태를 변경하는 메소드, 상태 인 객체, 거대한 다형성 객체 등은 잘못된 것으로 간주되어 다시는 사용되지 않아야합니다.

생각의 방식을 바꾸고 값의 값을 보십시오. 불변성을 선택하는 것은 예측 가능하고 효율적이며 버그가 적은 프로그램을 향한 큰 발걸음입니다.