オブジェクト指向との間の差のためのプロセス
プロセス指向（ポップ）とは何ですか
プロセス指向（プロセス指向プログラミング）は、イベント中心のプログラミングのアイデアです。これは、これらの手順のすべてを達成するための機能を使用し、その後、問題を解決するために必要な手順を分析して、呼ばれる順序に従うことです。
オブジェクト指向（OOP）とは何ですか
オブジェクトは、オブジェクト指向プログラミングのアイデアを中心に
例の理解のために
車、車のステーションを起動します。車の開始は、車のステーションが別のイベントであることをイベントであり、プロセス指向の考え方は、私たちはイベントではなく、車自体を懸念しているということです。これら二つのイベントのための2つの機能を形成し、呼び出しが続きます。オブジェクト指向の考え方については、我々は懸念している車のようなオブジェクトであるが、そのようなオブジェクトは、2つのイベントが動作しています。そして、これらの行為は注文しませんでした。思考のプロセス指向の方法は、総合的な分析は、思考のオブジェクト指向の方法が構築されています。
プロセス指向とオブジェクト指向の長所と短所
プロセス指向
長所：オブジェクト指向よりもパフォーマンスが、理由は呼び出されたときにクラスをインスタンス化する必要性、オーバーヘッドは、資源の消費量が比較的大きく、そのようなマイクロコントローラ、組み込み開発、のLinux / Unixおよび他の一般的に使用されるプロセス指向の開発など、パフォーマンスが最も重要な要因です。
短所：なしオブジェクト指向と保守が容易、再利用しやすく、拡張しやすいです
オブジェクト指向
利点：低結合システムは、システムをより柔軟にし、維持しやすいように設計することができるオブジェクト指向のカプセル化、継承、多型特性があるので、メンテナンスが容易と再利用、簡単には、展開します
短所：プロセス指向のパフォーマンスよりも低く
オブジェクト指向の三つの基本的な機能
パッケージ
パッケージには、プログラムの属性のアクセスレベルを読み取り、変更制御するパブリックインターフェースにのみオープン、オブジェクトのプロパティと実装の詳細を隠蔽することである抽象データが得られ、行為（又は機能）、組み合わされた有機全体を形成する、すなわち有機合成のソースコードデータと操作データが「クラス」、データクラスのメンバである機能を形成します。
パッケージの目的は、セキュリティを強化し、プログラミングを簡素化することで、ユーザーがだけクラスのメンバーの使用に特定のアクセス権への外部インタフェースを介して、特定の実装の詳細を知っている必要はありません。
受け継ぎます
継承はオブジェクト指向の継承メカニズムの基本的な特徴の1階層のクラスを作成することができますです。継承サブクラスは特性と親クラスの動作を継承しているサブクラスオブジェクト親クラスまたはサブクラスを有する（インスタンス）インスタンスのフィールドとメソッドは、親クラス、同じ親クラス挙動を有するサブクラスからメソッドを継承するように、。
図と同様に、以下：
ポリモーフィズム
同じ現象の異なる多形形態または複数の形態を有する能力。同じクラスのインスタンス（オブジェクト）の方法を指すは、異なる状況において異なる形態を有します。多型の異なる内部構造を有するオブジェクトが同じ外部インターフェイスを共有できるようにします。これは、異なるオブジェクトごとに異なる特定のアクションが意味するが、一般的なクラスを介して、彼ら（これらの操作は）同じように呼び出すことができます。
オブジェクト指向の5つの基本原則
シングル責任の原則（SRP）
クラスは、クラスが1つのジョブのみを持つべきであることを意味し、それを変更するために、唯一の理由があるはずです。
たとえば、クラスのスタッフ、エンジニア、営業担当者に、これらのケースの販売マネージャーは、クラスの考慮事項のスタッフにあり、その結果は他の場合には、この仮定の下で、それぞれの方法のスタッフのクラスがどのを決定する必要があり、非常に混乱するだろう場合は、クラス構造体から、それは非常に肥大化されます。
オープンクローズドの原則（OCP）
オブジェクトまたはエンティティは、修正のため閉鎖、拡張のために開いている必要があります。
私たちは、モジュールを拡張するとき、あなたがソースコードを持っており、DLLファイルを変更したり、再コンパイルする必要はありません閉じて変更！この原則は、私たちはクラスを設計するときに便利ですまた、インターフェイスのカプセル化、抽象化、および多型の技術を考慮する必要があり、この原則に従います
リヒター置換原則（LSP）
Q（x）は、xはQ（y）が確立されなければならない場合にSがTのサブクラスであるターゲット・タイプTが、オブジェクト型、YがSである場合に確立されます。方言の翻訳（Ieはサブクラスにも同様に適用可能である親クラスの呼び出し）：あなたが親を使用している場合はソフトウェア、そして子供は自分のクラスと感知できない親と子のクラスオブジェクトの区別に適用する必要があります。それは、そのサブクラスに親クラスを置き換え、内部のソフトウェアであり、動作は変更されません、簡単に言えば、サブタイプは、その親タイプを置き換えることができなければなりません。
依存関係逆転の原則（DIP）
高レベルのモジュールは、彼らが抽象化に依存しなければならない、低レベルのモジュールに依存してはなりません。具体的な実装ではなく、依存抽象実装よりも、抽象化に依存しなければなりません。
例えば、今日は草食動物を導入し、その後、ウサギや羊に会いました。明日は牛、馬や他の草食動物を認識した場合でも、私たちは常に、明らかに不合理である草食動物の説明を、調整する必要があることがわかります。だから我々は、エンティティに依存サブクラスを聞かせてはならない親モジュールは、サブクラスのモジュールに依存して許可してはいけません。したがって、（抽象クラスとして設計された草食動物抽象クラスまたはインタフェース下層は実装の詳細に対応するように、親クラスに影響を与えることなく）。
インタフェース分掌の原則（ISP）
クライアントが使用されていない彼らの方法に頼ることを余儀なくされるべきではないとアクセス権を持っているか、いないクライアント・インターフェースを実装することを強制すべきではない、複数の専門的なインターフェースを使用すると、単一のインターフェースを使用するよりもはるかに優れています！
例えば、インタフェース定義、インタフェースで同様のメソッドの数を削減するために、最終的にでしょう、維持し、それはあまりにも多くのエネルギーを取ったときのインターフェイスを実装し、クライアントへのコミットメントを操作するのと等価で定義されたインタフェースの順序でこのコミットメントは、あまりにも多くのコミットメントは、あなたの時間と維持するために多くのエネルギーである持ってもちろん、より良い、できるだけより簡潔な、です！