オブジェクト指向言語は、プログラムをクラスと呼ばれるモジュールに分割します。各クラスには、データ（フィールド）とメソッドで構成される機能が含まれています。（すべての言語がこれらの用語を使用するわけではありませんが、ここではこれで十分です。）言語には、クラスの機能を他のクラスがアクセスできるかどうかについてさまざまな規則があり、これらは多くの場合、クラスに適用されるアクセス修飾子に基づいています。

オブジェクト指向の世界で最も長く続いている議論の1つは、オープン継承と設計された継承の間の議論です。設計された継承の原則は、おそらくジョシュ・ブロッホによって最もよく要約されています。「継承のために設計および文書化するか、そうでなければそれを禁止する」。このアプローチでは、どのメソッドが継承可能かを慎重に決定し、他のメソッドをシールして、オーバーライドされないようにします。

最近、サーバーを介してJSONデータ構造を流すのをよく見かけるようになりました。JSONドキュメントは、集約指向データベースを使用するか、リレーショナルデータベースでシリアル化されたLOBを使用することにより、直接永続化できます。JSONドキュメントは、Webブラウザーに直接提供したり、サーバー側のページレンダラーにデータを転送したりするためにも使用できます。JSONがこのように使用されている場合、オブジェクト指向言語を使用すると、JSONをオブジェクトに変換してから再度レンダリングするだけで、プログラミングの労力が無駄になるため、邪魔になるという人がいます。私は無駄であるという点には同意しますが、これはオブジェクトの問題ではなく、カプセル化を理解していないことによるものだと主張します。

オブジェクト指向設計について学ぶと、データをカプセル化することが重要であることをすぐに学びます。カプセル化の最も単純な形式は、アクセサー（取得および設定メソッド）またはプロパティを使用することです。言語がそれをサポートしている場合は。（クラス内でこれを行うものもあります- 自己カプセル化

プログラミングにおいて、オブジェクトの基本的な概念は、データと動作のバンドルです。これにより、関連する一連の関数を記述するときに共通のデータコンテキストが提供されます。また、データの操作に対するインターフェイスも提供され、オブジェクトがそのデータへのアクセスを制御できるようになり、派生データをサポートし、データの無効な変更を防ぐことが容易になります。多くの言語は、オブジェクトの定義として機能するクラスを定義するための明示的な構文を提供しています。ただし、ファーストクラスの関数とクロージャーを備えた言語がある場合は、これらの構成を使用して、関数としてのオブジェクトパターン（もともとユージン・ウォーリングフォードによって記述された）を使用してオブジェクトを作成できます。

彼らは、ゲッターメソッドを見たときに口の左側がピクピクすることでわかります。彼らのバトルアックスを素早く引き抜き、ゲッターが根絶者の足元で感謝の恍惚状態で気絶すると、満足した叫び声が上がります。

メソッドがオブジェクトの観察可能な状態を変更しないと言うとき、人々は何を意味するのでしょうか？

これは、設計された継承とは反対の態度です。オープン継承の支持者は、クラスをシールしたり、クラスの継承を阻止するためのその他の行為をしたりして、継承を禁止することを期待しません。

Webページに対してテストを作成する場合、リンクをクリックしたり、表示されている内容を判断したりするために、そのWebページ内の要素を参照する必要があります。ただし、HTML要素を直接操作するテストを作成すると、UIの変更に対してテストが脆くなります。ページオブジェクトは、HTMLページまたはフラグメントをアプリケーション固有のAPIでラップし、HTMLを掘り下げることなくページ要素を操作できるようにします。

情報量の多いプログラムをモジュール化する最も一般的な方法の1つは、プレゼンテーション（UI）、ドメインロジック（別名ビジネスロジック）、およびデータアクセスの3つの広範なレイヤーに分離することです。したがって、HTTPリクエストの処理とHTMLのレンダリングについて知っているWebレイヤー、検証と計算を含むビジネスロジックレイヤー、およびデータベースまたはリモートサービスで永続データを管理する方法を解決するデータアクセスレイヤーに分割されたWebアプリケーションをよく見かけます。

protectedアクセス修飾子を使用して、クラスにデータを含めるのは優れたOO設計ですか？

最初にC#に出会ったとき、私は最初からプロパティの概念が好きでした。C++/JavaのgetXおよびsetXの規則は、私には常に少しばかげていました。obj.X = other.Xと書く方がはるかに自然です。getメソッドとsetメソッドを持つプロパティを提供すると、一般的な規則が言語の自然にサポートされる機能になります。

公開されたインターフェースは、（最初にリファクタリングで使用した）定義されているコードベースの外部で使用されるクラスインターフェースを指すために使用した用語です。そのため、Javaのpublicよりも意味が大きく、実際にはC#の非internal publicよりも意味が大きくなります。IEEE Softwareのコラムで、公開とpublicの違いは、実際にはpublicとprivateの違いよりも重要であると主張しました。

メソッドまたはクラスをシールすると、サブクラスがそれをオーバーライドできなくなります。

データのカプセル化は、オブジェクト指向スタイルの中心的な原則です。これは、オブジェクトのフィールドは公開されるべきではなく、代わりにオブジェクト外からのすべてのアクセスはアクセサーメソッド（ゲッターとセッター）を介して行うべきであると述べています。公開アクセス可能なフィールドを許可する言語もありますが、通常はプログラマーにこれを行わないように注意を促します。自己カプセル化はさらに一歩進んで、データフィールドへのすべての内部アクセスもアクセサーメソッドを介して行う必要があることを示しています。アクセサーメソッドのみがデータ値自体に触れる必要があります。データフィールドが外部に公開されていない場合、これは追加のプライベートアクセサーを追加することを意味します。

ソフトウェア開発を、コードを苦労して作成することから、コンポーネントを簡単に組み立てることによって強力なシステムを構築することに変更するという概念は、私たちがこの職業に参入して以来の目標でした。それは時々垣間見られるものの、決して本当に達成されない目標です。ただし、多くのテクノロジーが産業再利用のニンジンをぶら下げています。

命令、尋ねるなは、オブジェクト指向がデータとそのデータを操作する関数をバンドルすることについてであることを人々が思い出すのを助ける原則です。オブジェクトにデータを要求してそのデータに基づいて行動するのではなく、代わりにオブジェクトに何をすべきかを伝えるべきであることを思い出させます。これにより、データを伴うように動作をオブジェクトに移動させることが奨励されます。

モジュールによって提供されるすべてのサービスは、ストレージまたは計算のどちらによって実装されるかを示さない均一な表記法を通じて利用できる必要があります。

-- バートランド・メイヤー

バートランド・メイヤーは、彼の非常に影響力のある本オブジェクト指向ソフトウェア構築でこの原則を提唱しました。

この原則の重要な点は、personオブジェクトがあり、その年齢を尋ねる場合、年齢がオブジェクトの保存されたフィールドであるか、計算された値であるかに関係なく、同じ表記法を使用する必要があるということです。それは事実上、personのクライアントは、年齢が保存されているか計算されているかを知ったり、気にする必要がないことを意味します。