オブジェクト指向の最初に、三つの特徴
1.包装：外部変数と隠し属性クラスの、外部修飾内部データを回避するために、フォーム（方法）を介して外部とのインタフェースを提供します。カプセル化は、パッケージの内部での動作に基づいて、データ・インタフェースとデータの使用であり、具体的な詳細が隠されているデータを保護するために、外の世界との限られたインターフェースを残します。
パブリック クラス学生{ プライベート文字列名; //はの名前を示しプライベート文字列変数宣言 プライベート int型年齢; // 歳示すプライベート整数宣言公共学生を（文字列名、int型年齢、性別文字列、文字列メジャー）{ // コンストラクタがargを この .nameの= 名; この .age = 年齢; } パブリック文字列のgetNameは（）{ // の名前を取得するメソッド の戻り名; } 公共 ボイドのsetName（文字列名）{ // 設けられたメソッド名 、これは = .nameの名前。 } 公共 int型 getAge（）{ // メソッドは、年齢を取得するには 、戻り年齢; } パブリック 無効 setAge（int型 {年齢） // の年齢設定方法 この .age = 年齢; } }
2.継承：独自のユニークな特性と行動が増加しながら、オブジェクトのサブクラスは、（保護し、公共の）親クラスのすべての属性や行動を持っています。これの基本的な考え方は継承されているホイールを、作成重複を避けるため、コードの再利用を助長しています。
3.多型：単純に異なるプログラムが複数、同じ名前と共存過負荷と多型クラスを達成するために一般的に使用される方法（別名カバレッジ）を上書きする場合。
過負荷：同じメソッド名、パラメータリストは同じではありません。異なるパラメータが、異なるパラメータ・タイプ、異なるパラメータの数、パラメータの異なる順序（パラメータの型が同じでないなければならない）のリストであってもよいです。
書き換え：サブクラスは、親クラスの再仮想メソッドを実装します。
パッケージは、実装の詳細、そのようなモジュラーコードを隠すことができ、継承は、コードモジュール（クラス）がすでに存在して拡張することができ、その目的は、である - コードの再利用
クラス間の第二に、関係
1.クラスに対して、この関係は、この関係を実現呼ばれる、インタフェースの継承と呼ばれ、継承されました。
2.依存性、クラスAの方法は、別のクラスBを使用することです 一般的に、依存性はローカルのような変数、パラメータ、方法、または静的メソッドを呼び出すことで、Javaに反映されます。
パブリック クラスペン{ 公共 空の書き込み（）{ システム。OUT .println（「書くために使用ペン」）; } } パブリック クラスミー{ 公共 空の書き込み（ペン）{ // ここで、パラメータ私とペンベース方式 のペン.WRITE（）; } }
3.重合、Bクラスの強力な参照関係のクラスの一部であり、クラスとBクラスのライフサイクルは重要ではありませんので、ときに削除クラス、Bクラスは削除されません。一般に、集約関係は、Javaのメンバー変数として具体。例えば、インターフェイスとインターフェイスのデータ・タイプとの関係が破壊されるが、データ型が破壊されないであろう。
前記組み合わせは、Bクラスは、重合よりも強い参照関係からなるクラスの一部であり、人生の終わりの種類も、ライフサイクルBクラスの終わりを意味するので、削除されたクラスは、Bクラスが続くときに削除します。一般に、集約関係は、Javaのメンバー変数として具体。例えば、息子インターフェイスとインターフェイス、関係項目は、インターフェースが破壊されたときに、サブインターフェースは、アイテムが破壊されます。
組み合わせ少ない相続、。
継承短所：
1.カプセル化損傷、時にはサブクラスは、例えば、方法を実装する必要がある必要はありません
アヒルが飛んでいないので、あなたは、この問題を解決したい場合、あなたは1をパッケージ化する必要があります
那如果再来一个会游泳的鸟，会下蛋的鸟呢，那你的继承层级可能会多达十种，继承层级一旦多于三层，就较难理解、维护了。但是如果把会游泳、会飞、会下蛋等特性做成功能组件自由组合就不会有这个问题了。
2.紧耦合，修改父类可能会影响所有的子类以及子类的调用类，例如修改方法签名（返回值、名字、参数列表），会影响到所有子类。
三、设计模式六大原则
1.职责单一：一个类只负责一项职责，如果这项职责很复杂，可以拆分成多个子功能进行组合，避免一个类过于庞大，难以修改。
问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。
2.依赖倒置：实现依赖抽象，高层模块不应该依赖低层模块，二者都应该依赖其抽象。使用接口、抽象类的方法，参数使用接口（抽象）类进行传递，便于不同子类的传参。
问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。
3.里氏替换：所有父类出现的地方都能用子类代替，子类不应该修改父类已经实现的方法。类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。
问题由来：有一功能P1，由类A完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。
4.接口隔离：设计接口尽量精简，客户端不应该依赖它不需要的接口。
问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。
5.迪米特原则（最少知道）：一个类对自己依赖的类知道的越少越好。尽量降低类与类之间的耦合，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。
问题由来：类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
6.开闭原则：对修改关闭，对扩展开放。