変更可能と変更不可能の違いとは。

変更可能と変更不可能は、ソフトウェア開発とインフラストラクチャー管理の両方に対する最新のアプローチを推進する原則です。

この違いは、ホワイトボードにテキストを書くことに似ています。単語を追加したり、部品を消去したり、書かれた内容を変更したりできるなら変更可能な参考情報ですしかし、作業が終わった瞬間にホワイトボードがガラス張りになり、新しいホワイトボードに別の何かを書く必要がある場合、それは変更不可能な参考情報になります。

この概念はコンピューティング全体で広く適用されますが、最も一般的にはプログラミングにおいて使用されます。プログラミングでは、どのデータ型を直接変更できるか、またどのような場合に新しいコピーを作成する必要があるかを理解することが、一般的なタスクにとって重要です。これらのタスクには、アルゴリズムの作成、アプリケーション・プログラミング・インターフェース（API）の構築、オブジェクト指向プログラミング（OOP）でのクラスの設計などが含まれます。

変更可能オブジェクトと変更不可能オブジェクトのどちらを使用するかは、メモリー内でのデータの管理方法、データの共有や変更の安全性、および意図しない副作用の発生の有無に影響します。これが、変更可能と変更不可能が初心者と経験豊富なプログラマーの両方にとって基本的な概念である理由です。

例えば、Pythonプログラミング言語では、リストと辞書は変更可能なタイプです。それらのオブジェクト内で、項目を追加、削除、または変更できます。対照的に、ブール値（Trueまたは偽値）やタプル（1、2、3）のような順序付けられたコレクションなどのオブジェクトは変更できません。全く新しいオブジェクトを作成しない限り、その内容を変更したり変異させたりすることはできない。

変更可能データと変更不可能データのどちらを選択するかは、通常、データに頻繁な更新が必要か、スレッド間で共有されるか、バージョン履歴が必要かどうかという3つの重要な要素によって決まります。

変更可能なタイプは一般に、データが頻繁な更新を必要とする場合や、プログラムの複数の部分が同じオブジェクトを変更する場合に最適です。

変更可能なオブジェクトは、データを適切に変更し、新しいオブジェクトを作成する必要を回避することで、メモリーの使用量を削減します。ガーベッジ・コレクション（メモリーを解放するために未使用データを削除するプロセス）のプロセッサー使用量を削減できるため、作成および収集する必要がある一時オブジェクトの数が減る場合があります。

例えば、アプリのショッピングカートは、変更ごとに新しいオブジェクトを作成することなく、変更可能なリストを使用してアイテムを直接追加または削除します。

変更可能なタイプは、新しいオブジェクトを作成するのではなく、既存のオブジェクトを更新するため、（増大するリストやリアルタイム・カウンターなど）頻繁に変更されるデータにより良い性能を発揮します。この効率により、迅速な変更を必要とするデータ構造でのオペレーションが高速化されます。

例えば、音楽アプリのプレイリストでは、変更可能なリストを使用して迅速に更新できます。楽曲の追加や削除が行われた際、1,000曲のプレイリストを再構築する必要がある従来の方法と比較して、マイクロ秒単位で処理が可能です。

変更可能なオブジェクトを使用すると、プログラムの複数の部分が同じオブジェクトにアクセスし、変更できます。このプロセスにより、共有状態（複数のコンポーネントが読み書きするデータを読み書きしてアクションを調整することができます）で作業できるようになります。これは、コンポーネントが共通データを通じて調整または通信する必要がある場合に役立ちます。

例えば、プロジェクト管理アプリは、変更可能なオブジェクトを使用してタスク・リスト、カレンダー、通知を共有します。1人のチームメンバーがタスクを更新すると、全員がその変更をすぐに確認します。

変更不可能タイプは通常、データが作成後に変更されない場合に最適です。プログラムの複数の部分が同じデータにアクセスする、同時実行性のあるアプリケーションでは特に重要です。

変更不可能オブジェクトの状態は固定されているため、他のコードによって変更されることはありません。主要な機能により、予期せぬミューテーションに関連するバグがなくなるため、プログラムの予測性が高まり、理解しやすくなります。

例えば、アプリは取引記録を変更不可能オブジェクトとして保管することが多いため、後で変更することはできません。これは、規制の遵守を確保し、取引が改ざんされていないことを証明する監査証跡を維持するためにクリティカルです。

変更不可能オブジェクトは、作成後に状態を変えることができないため、一般にスレッドセーフです。複数のスレッドは競合することなく同時に安全にそれらを読み取ることができますが、開発者は依然として同時システムで参照を慎重に管理する必要があります。そのため、複数のスレッドが競合を引き起こすことなく同じデータにアクセスする必要があるマルチスレッド・プログラムに最適です。

例えば、アプリは、現在の状況、予測、アラートについて同時スレッドを実行できます。気象データを変更不可能オブジェクトとして保管することで、各スレッドが予期せず変更されるリスクを負わずに同じ情報を読み取ることができます。

不変オブジェクトでは、プログラム実行中に値が予期せず変更されないため、デバッグが簡単になります。主要な機能は、副作用によるバグを減らし、チームがより迅速に問題を解決するのに役立ちます。

例えば、ビデオ・ゲームでは、プレイヤーのヘルスと統計が変更不可能オブジェクトとして保管されることがよくあります。これらの値は予期せず変更できないため、開発者は、関連しないコードが統計を変更しないことを知って、バグを簡単に追跡できます。

最も広く使用されている2つのスタイルであるオブジェクト指向プログラミング（OOP）と機能プログラミングのアプローチは、変更可能性へのアプローチが異なります。

OOPは変更可能性を採用することが多く、データと動作の両方を保持するオブジェクトを中心にプログラムを構築します。これらのオブジェクトは、プロパティの値（個人の年齢や製品価格の変更など）を更新できるセクターと呼ばれる特別関数を使用することで、時間の経過とともに変更できます。

対照的に、関数型プログラミングは不変性に傾いています。何かを変更する必要があるたびに新しい値を作成して返すため、プログラムがより予測しやすくテストしやすくなります。

プログラミング言語は、変更可能型と変更不可能型に対するアプローチも異なります。

Pythonでは、変更可能型と変更不可能型の両方が一般的です。

その一例が文字列（名前や文などの文字のシーケンス）です。Pythonの文字列は変更できません。新しいテキストを追加すると、新しい文字列オブジェクトが作成されます。対照的に、リストは変更可能です。これらの順序付けられたコレクションは反復可能であり、リスト・オブジェクト内の項目を追加、削除、または変更できます。

実行前にコードをチェックするためにコンパイラ（実行前にコードを機械語に変換するプログラム）を使用する代わりに、Pythonは実行時に型をチェックします。これは、プログラムの実行中にのみエラーが検出されることを意味します。変更不可能な文字列を変更しようとするなど、変更可能性に関するミスは、タイプエラーを引き起こします。

エラーが処理されない場合、プログラムは直ちに停止され、それ以上のコードの実行が防止されます。この手順により、開発は迅速化されますが、タイプの取り扱いには細心の注意が必要です。

Pythonの変更可能性を理解すると、関数間でデータを共有したり、共有モジュール内で作業したりする際にエラーを防ぐことができます。GitHubのチュートリアルとコード例は、Pythonの組み込み型を使用するためのベスト・プラクティスを提供しています。

JavaScriptでは、変更可能型と不変型の両方が使用されます。Pythonと同様、文字列も変更不可能です。ただし、Pythonとは異なり、すべてのオブジェクトがデフォルトで変更可能です。

JavaScriptの柔軟な構文はオブジェクト指向と機能の両方のスタイルをサポートしているため、開発者は必要に応じて変更性を管理できます。

Pythonと同様に、Java文字列は不変です。文字列の値は一度作成されると変更できません。この特性は、テキストを頻繁に構築または変更するプログラムでは非効率的になる可能性があります。

この問題に対処するために、Javaでは、新しいオブジェクトを作成せずにテキストを直接変更できる変更可能な文字列クラスであるStringBuilderを提供しています。性能を向上させ、メモリー使用量を削減し、不変性の安全性と変更性の性能上のメリットのバランスをとることができます。

C++では、constキーワードを使用して、変数、関数、さらにはオブジェクト全体を読み取り専用としてマークします。開発者は変更可能性をきめ細かく制御できるようになり、変更を防止することで変更可能なオブジェクトを変更不可能オブジェクトに効果的に変えることができます。

Javaと同様、C++文字列は実装に応じて変更可能または変更不可能になります。

C++は、オブジェクト指向と機能プログラミングの両方のスタイルをサポートしています。OOPスタイルでは、開発者は既存のオブジェクトを徐々に変更し、機能プログラミングでは既存のデータを変更する代わりに新しい値を作成します。

変更可能性と不変性の原則は、プログラミングを超えてインフラストラクチャーとシステムにまで及びます。最新のソフトウェア・エンジニアは、クラウド・アーキテクチャーとデプロイメント・パイプラインを設計する際に、これらと同じ概念を適用します。

変更可能なインフラストラクチャーとは、デプロイメント後に変更可能なサーバーその他のIT参考情報を指します。例えば、サーバーにログインして、ソフトウェアを手動で更新したり、構成を変更したり、パッチをインストールしたりする場合があります。このアプローチは柔軟性を提供しますが、サーバーが特異な「雪片」になり、変更を追跡または再現できなくなる構成ドリフトにつながる可能性があります。

変更不可能インフラストラクチャーとは、サーバーやIT参考情報がデプロイメント後に変更できないことを意味します。チームは実行中のシステムを更新する代わりに、変更が組み込まれた新しいインスタンスをデプロイし、古いインスタンスを廃止します。このアプローチにより、構成ドリフトが減り、ロールバックが簡素化され、一貫したデプロイメントが確保されます。

変更可能性と不変性の原則は、ソフトウェアやシステム設計の他の領域にも適用できます。

一部のデータベースでは追加のみのログを使用しているため、各変更は永続的に記録され、変更することはできません。また、変更可能で、ドキュメントの編集などのように、データを直接更新したり削除したりできます。

特定のクラウド・ストレージ・システムは、以前のバージョンを保持し、変更からロックするために、変更不可能ストレージとして構成できます。これにより、データが誤って変更または削除されないように保護できます。変更可能なストレージを使用すると、いつでもファイルを編集したり、置き換えたりすることができます。

Gitなどの多くのバージョン管理ツールは変更不可能モデルに従っており、各コミットは別の変更不可能なスナップショットとして保存されます。新しい変更が追加された場合でも、信頼できるバージョン履歴を確保するのに役立ちます。