回答:
ここでのほとんどの回答はOOPに焦点を当てていますが、カプセル化ははるかに早く始まります。
すべての関数はカプセル化です。擬似コードで:
point x = { 1, 4 }
point y = { 23, 42 }
numeric d = distance(x, y)
ここでdistance
は、平面内の2点間の(ユークリッド)距離の計算をカプセル化します。実装の詳細を非表示にします。これはカプセル化であり、純粋で単純です。
抽象化とは、一般化のプロセスです。具体的に実装して、多少関係はあるものの、さまざまなタイプのデータに適用できるようにします。抽象化の古典的な例は、qsort
データをソートするCの関数です。
重要なのqsort
は、並べ替えるデータを気にしないことです。実際、並べ替えるデータがわかりません。むしろ、その入力タイプはタイプレスポインター(void*
)であり、これはCの「データのタイプは気にしません」(これはタイプ消去とも呼ばれます)と言う方法です。重要な点はqsort
、データ型に関係なく、の実装は常に同じであるということです。唯一の事があるの変更には、データ型にデータ型とは異なり、比較機能、です。qsort
したがって、ユーザーは関数の引数として上記の比較関数を提供する必要があります。
カプセル化と抽象化は非常に密接に関連しているので、それらは本当に分離できないということを指摘することができます。実際には、これはおそらく本当です。そうは言っても、ここではあまり抽象化されていないカプセル化を示します。
class point {
numeric x
numeric y
}
ポイントの座標をカプセル化しますが、それらを論理的にグループ化する以外に、それらを物質的に抽象化しません。
そして、これはカプセル化されていない抽象化の例です:
T pi<T> = 3.1415926535
これは指定された値(π)を持つジェネリック変数 pi
であり、宣言は変数の正確なタイプを気にしません。確かに、私は実際のコードでこのようなものを見つけるのは困難です:抽象化は事実上常にカプセル化を使用します。ただし、上記は実際には変数テンプレート(=変数の汎用テンプレート)を介してC ++(14)に存在します。少し複雑な構文を使用します。例:
template <typename T> constexpr T pi = T{3.1415926535};
カプセル化は実装の詳細を隠しています。これは、一般的な動作または特殊な動作の場合とそうでない場合があります。
抽象化は一般化(たとえば、一連の動作に対して)を提供します。
ここで良いの読み取りです:抽象化、カプセル化、および情報隠蔽オブジェクト庁のエドワードV.ベラールこともできます。
多くの回答とその例は誤解を招くものです。
カプセル化とは、データとそのデータを操作する関数を1つのコンポーネントにまとめ、オブジェクトの一部のコンポーネントへのアクセスを制限することです。
カプセル化とは、通常、オブジェクトの内部表現が、オブジェクトの定義外のビューから隠されることを意味します。
抽象化は、実装の詳細を含めずに重要な機能を表すメカニズムです。
カプセル化: - 情報の隠蔽。
抽象化: - 実装の隠蔽。
例:
class foo{
private:
int a, b;
public:
foo(int x=0, int y=0): a(x), b(y) {}
int add(){
return a+b;
}
}
foo
クラスのオブジェクトの内部表現は、クラスの外に隠されています。->カプセル化。
のオブジェクトのアクセス可能なメンバー(データ/関数)foo
は制限されており、そのオブジェクトだけがアクセスできます。
foo foo_obj(3, 4);
int sum = foo_obj.add();
メソッドの実装add
は隠されています。->抽象化。
qsort
Cでの関数の使用は、抽象化の例です。あなたはそれの実装の詳細を知りません。ここにはカプセル化は含まれていません。C ++でオブジェクトのデータフィールドを初期化するためにコンストラクターを使用することは、カプセル化(コンストラクターによるオブジェクトのコンポーネントへのアクセスの制御)の例です。
カプセル化は、いくつかのものをボックスに入れて、のぞき穴を提供します。これにより、ギアをいじるのを防ぐことができます。
抽象化フラットアウトでは、ギア、ラチェット、フライホイール、核コアなど、重要ではない詳細は無視されます。彼らはただ「行く」
カプセル化の例:
抽象化の例:
抽象化は一般化された用語です。つまり、カプセル化は抽象化のサブセットです。
例2:ソリューション・アーキテクトは、高レベルの作成者である抽象ソリューション全体の技術的なデザイン、そしてこの設計は、その後に引き渡される開発チームのための実装
。
ここでは、ソリューションアーキテクトが抽象として機能し、開発チームがカプセル化として機能します。
例3:ユーザーデータのカプセル化(ネットワーク)
抽象化(またはモジュール性)–タイプにより、プログラマーはビットまたはバイトよりも高いレベルで考えることができ、低レベルの実装に煩わされることはありません。たとえば、プログラマーは、文字列を単なるバイトの配列としてではなく、文字値のセットとして考えることができます。さらに、型を使用すると、プログラマーは任意のサイズの2つのサブシステム間のインターフェースについて考え、表現することができます。これにより、ローカリゼーションのレベルが向上し、サブシステムの相互運用性に必要な定義が、これら2つのサブシステムが通信するときに一貫性を保つことができます。 ソース
上記では多くの良い答えが提供されていますが、ここでは私の(Java)視点を紹介します。
データのカプセル化とは、クラス内の論理的にグループ化されたデータへのアクセスをラップして制御することを意味します。通常、別のキーワード- データ非表示に関連付けられています。これは、アクセス修飾子を使用してJavaで実現されます。
簡単な例は、プライベート変数を定義し、ゲッターメソッドとセッターメソッドを使用してその変数にアクセスできるようにするか、メソッドをプライベートにすることです。ユーザーがこれらのメソッドと変数について知る必要はありません。
注:カプセル化はデータの非表示のみに関するものであることを誤解しないでください。カプセル化と言うときは、関連するデータと動作をグループ化、パッケージ化、またはバンドルすることに重点を置く必要があります。
一方、データ抽象化は一般化の概念であり、複雑なロジックの下がユーザーに公開されません。Javaでは、これはインターフェースと抽象クラスを使用して実現されます。
例-
私たちが考えてみましょうインタフェースの動物を、それが機能を有するmakeSound()を。このインターフェースを実装する2つの具象クラスDogおよびCatがあります。これらの具象クラスには、makeSound()関数の個別の実装があります。動物がいるとしましょう(外部モジュールから取得します)。すべてのユーザーが知っているのは、受信しているオブジェクトが一部の動物であり、動物の音を印刷するのはユーザーの責任であることです。総当たりの方法の1つは、受け取ったオブジェクトをチェックしてそのタイプを識別し、それをその動物のタイプに型キャストしてから、そのオブジェクトに対してmakeSound()を呼び出すことです。しかし、より簡潔な方法は、物事を抽象化することです。動物を多態参照ですその上でmakeSound()を呼び出します。でランタイム実際のオブジェクトの型が適切な機能が呼び出されますが何であるかに依存します。
詳細はこちら。
複雑なロジックは、タッチパッドにカプセル化された回路基板にあり、ユーザーにそれを抽象化するための素敵なインターフェイス(ボタン)が提供されています。
PS:上記のリンクは私の個人ブログへのリンクです。
車を運転するときと同じように、アクセルペダルの働きはわかっていますが、カプセル化されているため、その背後にあるプロセスがわかりません。
C#で例を挙げましょう。整数があるとします:
int Number = 5;
string aStrNumber = Number.ToString();
Number.ToString()のようなメソッドを使用して、数値5の文字表現を返し、それを文字列オブジェクトに格納できます。このメソッドは、それがどのように行われるかではなく、何を行うかを教えてくれます。
これらは、コンピュータサイエンスやプログラミングに固有ではない、ややあいまいな概念です。他の人がこれらの重要な概念を理解するのに役立つかもしれないいくつかの追加の考えを提供したいと思います。
カプセル化 -必要なインターフェースを公開しながら、システムの特定の部分へのアクセスを隠したり制限したりします。
抽象化 -具体的な現実、特定のオブジェクト、または実際のインスタンスとは別に、特定の特性が削除されたものを検討することで、複雑さを軽減します。
主な類似点は、これらの手法は理解度と実用性の向上を目的としていることです。
主な違いは、抽象化は物事をより単純に表現する手段(多くの場合、表現をより広く適用できるようにするため)であるのに対し、カプセル化は、他のものと物事の相互作用方法を変更する方法です。
これは、うまくいけば物事をより明確にするカプセル化の例です:
ここでは、Arduino UnoとArduino Unoがエンクロージャー内にあります。エンクロージャーは、カプセル化とは何かについての優れた表現です。
カプセル化は、特定のコンポーネントを外部の影響や知識から保護し、他のコンポーネントとのインターフェースとなるコンポーネントを公開することを目的としています。プログラミング用語では、これには、アクセス修飾子を介して情報を隠すことが含まれます。これにより、特定の変数やプロパティを読み書きできる範囲が変わります。
しかしそれ以上に、カプセル化はそれらの外部インターフェースをはるかに効果的に提供することも目指しています。私たちのArduinoの例では、これには、ユーザーのデバイスとの対話をはるかに簡単にする素晴らしいボタンと画面を含めることができます。これらは、デバイスの動作に影響を与える簡単な方法をユーザーに提供し、それ以外の場合ははるかに困難であるその操作に関する有用な情報を取得します。
プログラミングでは、これは、次のような、分離可能な構築物に様々な構成要素のグループ化を伴うfunction
、class
またはobject
。また、これらの構成要素と対話する手段を提供すること、およびそれらの構成要素に関する有用な情報を取得する方法も含まれます。
カプセル化は、多くの追加の方法でプログラマーを支援します。特に、コードの保守性とテスト容易性の改善です。
ここで他の多くの答えは抽象化を一般化として定義しましたが、私は個人的に定義が誤っていると思います。一般化は実際には特定のタイプの抽象化であり、逆ではありません。つまり、すべての一般化は抽象化ですが、すべての抽象化が必ずしも一般化であるとは限りません。
これが抽象化について私がどのように考えたいかです:
木があるというイメージですか?たぶんあなたはそうするでしょう。しかし、それは本当に木なのでしょうか?もちろん、そうではありません!これは、ツリーと呼ばれるようなピクセルの集まりです。それは実際のツリーの抽象化を表すと言えます。ツリーのいくつかの視覚的な詳細が省略されていることに注意してください。また、成長したり、水を消費したり、酸素を生成したりしません。どうして?これは画面上の色の束であり、コンピュータのメモリ内のバイト数で表されます。
そして、ここに抽象化の本質があります。それは物事を単純化して理解しやすくする方法です。あなたの頭を通るすべてのアイデアは、現実の抽象化です。あなたの木の精神的なイメージは、このjpegよりも実際の木ではありません。
プログラミングではTree
、シミュレートされた成長、水消費、および酸素生産のためのメソッドを含むクラスを作成することにより、これを有利に使用できます。私たちの作成は、実際の樹木の経験を表すものであり、特定のシミュレーションで本当に気にかけている要素のみを含みます。バイトと数学で何かの経験を表現する方法として、抽象化を使用します。
プログラミングの抽象化により、いくつかの「具体的な」オブジェクトタイプ(実際に存在するタイプ)間の共通点を検討し、一意のエンティティ内でそれらの共通点を定義することができます。たとえば、Tree
クラスはから継承する場合がabstract class Plant
あります。これには、すべての植物のようなクラスに適用できるいくつかのプロパティとメソッドがありますが、植物の各タイプに固有のものは削除されます。これにより、コードの重複が大幅に削減され、保守性が向上します。
abstract class
とプレーンの実際的な違いclass
は、概念的にはの「実際の」インスタンスがないということabstract class
です。Plant
オブジェクトを作成することは十分に具体的ではないため、意味がありません。すべての「本物」Plant
は、より具体的なタイプでもありPlant
ます。
また、プログラムをより現実的なものにしたい場合は、Tree
クラス自体が抽象的すぎる可能性があることを考慮する必要があります。実際には、すべてのはTree
、より具体的なタイプであるTree
私たちのようなものをタイプするためのクラスを作成することができますので、Birch
、Maple
など、私たちは、おそらく今からの継承abstract
、Tree
クラス。
抽象化のもう1つの良い例は、Javaコードを実行する仮想または抽象コンピューターを提供するJava仮想マシン(JVM)です。基本的に、システムのプラットフォーム固有のコンポーネントをすべて取り除き、特にシステムに関係なく、「コンピューター」の抽象的なインターフェースを提供します。
カプセル化は抽象化とは異なり、「実際の」または「正確な」ものとは何の関係もありません。何かのコンポーネントを削除して、それを単純化したり、より広く適用したりすることはありません。むしろ、同様の目的を達成するために特定のコンポーネントを非表示にする場合があります。
カプセル化:不要な/予期しない/適切な実装の詳細を、オブジェクトの実際のユーザーから隠しています。例えば
List<string> list = new List<string>();
list.Sort(); /* Here, which sorting algorithm is used and hows its
implemented is not useful to the user who wants to perform sort, that's
why its hidden from the user of list. */
抽象化:これは、一般化を提供する方法であり、したがって、非常に多様なオブジェクトを操作するための一般的な方法です。例えば
class Aeroplane : IFlyable, IFuelable, IMachine
{ // Aeroplane's Design says:
// Aeroplane is a flying object
// Aeroplane can be fueled
// Aeroplane is a Machine
}
// But the code related to Pilot, or Driver of Aeroplane is not bothered
// about Machine or Fuel. Hence,
// pilot code:
IFlyable flyingObj = new Aeroplane();
flyingObj.Fly();
// fighter Pilot related code
IFlyable flyingObj2 = new FighterAeroplane();
flyingObj2.Fly();
// UFO related code
IFlyable ufoObj = new UFO();
ufoObj.Fly();
// **All the 3 Above codes are genaralized using IFlyable,
// Interface Abstraction**
// Fly related code knows how to fly, irrespective of the type of
// flying object they are.
// Similarly, Fuel related code:
// Fueling an Aeroplane
IFuelable fuelableObj = new Aeroplane();
fuelableObj.FillFuel();
// Fueling a Car
IFuelable fuelableObj2 = new Car(); // class Car : IFuelable { }
fuelableObj2.FillFuel();
// ** Fueling code does not need know what kind of vehicle it is, so far
// as it can Fill Fuel**
抽象化:何かを単純化した/異なる方法で提示するアイデア。これは、理解と使用がより簡単であるか、状況により適切です。
電子メールを送信するクラスを考えてみましょう...抽象化を使用して、ある種のメッセンジャーボーイとして自分自身を表示するため、emailSender.send(mail、recipient)を呼び出すことができます。それが実際に行うこと-POP3 / SMTPの選択、サーバーの呼び出し、MIME変換などが抽象化されます。メッセンジャーボーイしか見えません。
カプセル化:オブジェクトに対してプライベートなデータとメソッドを保護および非表示にするアイデア。それは、何かを独立して誰にでもできるようにすることをもっと扱います。
私を例にとろう。他の世界の心拍数をカプセル化します。他の誰かがその変数を変更することを望んでおらず、私が機能するために他の誰もそれを設定する必要がないからです。それは私にとって非常に重要ですが、それが何であるかを知る必要はなく、おそらくとにかく気にしません。
周りを見回すと、触れるほとんどすべてのものが抽象化とカプセル化の両方の例であることがわかります。たとえば、あなたの携帯電話は、あなたが言ったことを他の誰かに伝えることができるという抽象概念をあなたに提示します-GSM、プロセッサーのアーキテクチャ、無線周波数、そしてあなたが理解していないまたは気にしていない何百万もの他のものをカバーします。また、シリアル番号、ID番号、頻度など、ユーザーからの特定のデータもカプセル化します。
それはすべて、世界を住みやすい場所にする:D
抽象化:必要な情報のみが表示されます。コンピューターの電源を入れる例に焦点を当てましょう。ユーザーは、システムの読み込み中に何が行われているのかを知る必要はありません(その情報はユーザーには表示されません)。
ATMの例をもう1つ取り上げます。顧客は、マシンがPINを読み取り、トランザクションを処理する方法を知る必要はありません。PINを入力し、現金を受け取り、そのままにしておくだけです。
カプセル化:クラスの機密データを非表示にすることで、その一部をプライベート化します。これは、外部からのアクセスを許可しないことにより、一部の情報をクライアントに公開しない方法です。
もう一つの例:
次のような不変のRectangleクラスを作成したとします。
class Rectangle {
public:
Rectangle(int width, int height) : width_(width), height_(height) {}
int width() const { return width_; }
int height() const { return height_; }
private:
int width_;
int height_;
}
今では私がしたことは明らかだカプセル化された(アクセスが何らかの形で制限されている)の幅と高さを、私はいませんでした抽象化されたもの(大丈夫、多分矩形は座標空間に配置された場合、私は無視されてきたが、これはの欠陥であります例)。
優れた抽象化は通常、優れたカプセル化を意味します。
優れた抽象化の例は、一般的なデータベース接続クラスです。そのパブリックインターフェイスはデータベースに依存せず、非常にシンプルですが、接続を使用して必要な操作を実行できます。でしょ?クラスにはすべての低レベルのハンドルと呼び出しが含まれている必要があるため、カプセル化もあります。
Abstraction
そしてEncapsulation
単一の一般化された例を使用することによって-------------------------------------------------- -------------------------------------------------- --------------------------------
私たちは皆、複雑な問題の計算に電卓を使用しています!
Your both example tell about just encapsulation, not abstraction
; 原因の抽象化は、hiding
むしろ何の関係もありませんGeneralizing
抽象化:抽象化とはWhat
、機能の一部を示すことです。
カプセル化:カプセル化とは、How
、機能の一部ます。
非常に簡単な例を見てみましょう
/// <summary>
/// We have an Employee class having two properties EmployeeName and EmployeeCode
/// </summary>
public class Employee
{
public string EmplpyeeName { get; set; }
public string EmployeeCode { get; set; }
// Add new employee to DB is the main functionality, so are making it public so that we can expose it to external environment
// This is ABSTRACTION
public void AddEmployee(Employee obj)
{
// "Creation of DB connection" and "To check if employee exists" are internal details which we have hide from external environment
// You can see that these methods are private, external environment just need "What" part only
CreateDBConnection();
CheckIfEmployeeExists();
}
// ENCAPLUSATION using private keyword
private bool CheckIfEmployeeExists()
{
// Here we can validate if the employee already exists
return true;
}
// ENCAPLUSATION using private keyword
private void CreateDBConnection()
{
// Create DB connection code
}
}
コンソールアプリケーションのプログラムクラス
class Program
{
static void Main(string[] args)
{
Employee obj = new Employee();
obj.EmplpyeeName = "001";
obj.EmployeeCode = "Raj";
// We have exposed only what part of the functionality
obj.AddEmployee(obj);
}
}
スタックの例を見てみましょう。配列またはリンクリストを使用して実装できます。しかし、サポートする操作はプッシュとポップです。
現在、抽象化は、プッシュとポップのインターフェースのみを公開しています。基になる表現は非表示になり(配列かリンクリストか)、明確に定義されたインターフェイスが提供されます。では、抽象化されたデータに誤ってアクセスしないようにするにはどうすればよいでしょうか。そこでカプセル化が行われます。たとえば、C ++のクラスでは、アクセス指定子を使用して、偶発的なアクセスや変更を防止しています。また、上記のインターフェイスをパブリックにすることにより、スタックを操作する唯一の方法は、明確に定義されたインターフェイスを経由することだけです。その過程で、データとそれを操作できるコードが結合されています(ここではフレンド関数を使用しないでください)。つまり、コードとデータは結合されるか、結合またはカプセル化されます。
カプセル化とは、クラスである1つのカプセルに複雑さを包み込んでいるため、カプセル化です…抽象化は、他のオブジェクトとは異なるオブジェクトの特性です...
抽象化は、1つ以上のメソッドを持つクラスを抽象化することで実現できます。それは、それを拡張するクラスによって実装されるべき特性に他なりません。たとえば、自動車を発明または設計するとき、自動車には4つのドア、ブレーキ、ステアリングなどが必要になるなどの特性を定義します。そのため、この設計を使用する人は誰でもこの特性を含める必要があります。実装は抽象化の頭ではありません。含まれるべき特性を定義するだけです。
カプセル化は、データと動作をクラスである1つのカプセルに維持し、パブリック、プライベート、保護、継承、集約、構成などのアクセス修飾子を利用することで実現されます。したがって、必要なものだけを表示し、それも、表示したい範囲に限って表示します。すなわち、公共、保護された、フレンドリーでプライベートなカファンダ……例えば、GMは上記の自動車の抽象化されたデザインを使用することにしました。しかし、彼らは同じ特性を持ち、ほぼ同じ機能を実行するさまざまな製品を持っています。したがって、上記の抽象クラスを拡張するクラスを作成します。ギアボックスの動作、ブレークの動作、ステアリングホイールの動作について説明しています。次に、すべての製品がこの共通機能を使用します。彼らは、ギアボックスが機能するか、壊れるか、ステアリングホイールが機能するかを知る必要はありません。
どちらも強力です。しかし、抽象化を使用するには、カプセル化よりも多くのスキルが必要であり、大きなアプリケーション/製品は抽象化なしでは生き残ることができません。
OOPSでのカプセル化と抽象化の違い
抽象化とカプセル化は、2つの重要なオブジェクト指向プログラミング(OOPS)の概念です。カプセル化と抽象化はどちらも相互に関連する用語です。
カプセル化と抽象化の実際の違い
カプセル化は、非表示にすることを意味します。カプセル化は、データ非表示とも呼ばれます。カプセル化は、内部に薬を隠すカプセル(薬の錠剤)のようなものと考えることができます。カプセル化はラップであり、プロパティとメソッドを隠すだけです。カプセル化は、コードとデータを1つのユニットに隠して、データを外部から保護するために使用されます。クラスはカプセル化の最良の例です。
抽象化とは、目的のユーザーに必要な詳細のみを示すことです。名前が示すように、抽象化は「何かの抽象的な形」です。プログラミングクラスで抽象化を使用して、抽象クラスを作成します。抽象クラスは、クラスのメソッドとプロパティの抽象ビューを表します。
カプセル化と抽象化の実装の違い
抽象化はインターフェイスと抽象クラスを使用して実装され、カプセル化はプライベートおよび保護されたアクセス修飾子を使用して実装されます。
OOPSは、カプセル化を利用して、プログラマーが意図しない方法でデータにアクセスできないようにすることで、型の整合性を強制します(つまり、データが適切に使用されるようにします)。カプセル化により、所定の機能グループのみがデータにアクセスできます。アクセス制限(public / privateなど)と一緒にバンドルされたデータ型と操作(メソッド)の総称はクラスです。
カプセル化を簡単な方法でデモンストレーションしてみましょう。
カプセル化は-
カプセル化は抽象化を実装します。
そして抽象化は-
例を見てみましょう
下の画像は、「データベースに追加される顧客の詳細」のGUIを示しています。
画像を見ると、Customer Classが必要であると言えます。
ステップ-1:カスタマークラスには何が必要ですか?
すなわち
1顧客コードと顧客名をデータベースに追加する関数。
名前空間CustomerContent {public class Customer {public string CustomerCode = ""; パブリック文字列CustomerName = ""; public void ADD(){//ここにDBコードが入ります}
ここでは、ADDメソッドのみがここでは機能しません。
ステップ-2:検証はどのように機能し、ADD関数は機能しますか?
データベース接続コードと検証コード(追加メソッド)が必要です。
public bool Validate()
{
//Granular Customer Code and Name
return true;
}
public bool CreateDBObject()
{
//DB Connection Code
return true;
}
class Program
{
static void main(String[] args)
{
CustomerComponent.Customer obj = new CustomerComponent.Customer;
obj.CustomerCode = "s001";
obj.CustomerName = "Mac";
obj.Validate();
obj.CreateDBObject();
obj.ADD();
}
}
これで、Extra Methods(Validate(); CreateDBObject()[Complicated and Extra method])をエンドユーザーに表示する必要がなくなりました。エンドユーザーは、顧客コード、顧客名、およびADDボタンを追加および表示するだけです。レコード。エンドユーザーは、データベースにデータを追加する方法を気にしません。
ステップ-3:エンドユーザーの操作を必要としない余分で複雑なメソッドをプライベートにします。
そのため、これらの複雑なメソッドとエクストラメソッドをパブリックではなくプライベートにして(つまり、これらのメソッドを非表示にして)、obj.Validate()を削除します。obj.CreateDBObject(); クラスのメインプログラムからカプセル化を実現します。
言い換えれば、エンドユーザーへのインターフェースの簡素化はカプセル化です。
したがって、コードは次のようになります-
namespace CustomerContent
{
public class Customer
{
public string CustomerCode = "";
public string CustomerName = "";
public void ADD()
{
//my DB code will go here
}
private bool Validate()
{
//Granular Customer Code and Name
return true;
}
private bool CreateDBObject()
{
//DB Connection Code
return true;
}
class Program
{
static void main(String[] args)
{
CustomerComponent.Customer obj = new CustomerComponent.Customer;
obj.CustomerCode = "s001";
obj.CustomerName = "Mac";
obj.ADD();
}
}
まとめ:
ステップ-1:顧客クラスには何が必要ですか?抽象化です。
ステップ-3:ステップ-3:エンドユーザーの操作を必要としない余分で複雑なメソッドをプライベートにするのはカプセル化です。
PS-上記のコードは難しく、高速です。
情報の隠蔽は、抽象化やカプセル化には厳密には必要ありません。情報は無視される場合がありますが、非表示にする必要はありません。
カプセル化 は、複雑な部分やアイデアで構成されている場合でも、何かを1つのものとして扱う機能です。たとえば、私は「椅子」に座っていると言えます。特定のデザインと機能を備えた椅子のさまざまな部分を指すのではなく、すべてを正確に組み合わせて、お尻を数フィート快適に保持します床から離れて。
抽象化はカプセル化によって可能になります。オブジェクトをカプセル化するため、内部オブジェクト構造の微妙な詳細に行き詰まるのではなく、何らかの方法で相互に関連しているものと考えることができます。抽象化とは、細部への懸念から取り除かれた、全体像を考慮する能力です。単語の語源は、学術論文の上部に表示される要約のように抽象的であり、派生サブクラスとしてのみインスタンス化できるクラスのように抽象的ではありません。
正直言って、私がお尻を椅子に垂らしたとき、その椅子の構造が私の体重をどのようにキャッチして保持するかについては決して考えません。それは私がそれらの細部について心配する必要がないほどまともな椅子です。だから私は自分のコンピュータに注意を向けることができます。繰り返しになりますが、コンピューターのコンポーネント部分については考えていません。入力できるテキスト領域を表すWebページの一部を見ているだけであり、言葉でコミュニケーションを取っています。キーボードで指が常に適切な文字をすばやく見つける方法や、最終的には、これらのキーをタップしてからこのフォーラムに投稿することを関連付けます。これが抽象化の大きな力です。システムの下位レベルは一貫性と精度で動作することが信頼できるため、私たちはより大きな作業のためのスペアに注意を払っています。
class Aeroplane : IFlyable, IFuelable, IMachine
{ // Aeroplane's Design says:
// Aeroplane is a flying object
// Aeroplane can be fueled
// Aeroplane is a Machine
}
// But the code related to Pilot, or Driver of Aeroplane is not bothered
// about Machine or Fuel. Hence,
// pilot code:
IFlyable flyingObj = new Aeroplane();
flyingObj.Fly();
// fighter Pilot related code
IFlyable flyingObj2 = new FighterAeroplane();
flyingObj2.Fly();
// UFO related code
IFlyable ufoObj = new UFO();
ufoObj.Fly();
// **All the 3 Above codes are genaralized using IFlyable,
// Interface Abstraction**
// Fly related code knows how to fly, irrespective of the type of
// flying object they are.
// Similarly, Fuel related code:
// Fueling an Aeroplane
IFuelable fuelableObj = new Aeroplane();
fuelableObj.FillFuel();
// Fueling a Car
IFuelable fuelableObj2 = new Car(); // class Car : IFuelable { }
fuelableObj2.FillFuel();
// ** Fueling code does not need know what kind of vehicle it is, so far
// as it can Fill Fuel**
抽象化はユーザーから非有用なデータを隠し、カプセル化はデータをカプセル(クラス)にバインドします。カプセル化は抽象化を実現する方法だと思います。
Abstraction
これから行う実装の契約です。実装は時間の経過とともに変更される場合があります。さまざまな実装自体は、隠されている場合とされていない場合がありますが、抽象化の背後でマスクされています。
我々は、すべての定義と仮定APIs
して、クラスのをinterface
、定義された時にdepenedに我々のコードをユーザーに尋ねるAPIs
のinterface
。セット契約に従う必要がある場合のみ、実装を自由に改善または変更できます。ユーザーは私たちの実装と結合されていません。
すべての必要なルール(メソッド)を抽象化して公開します。ルールの実装は実装者エンティティに委ねられ、実装は抽象化の一部ではありません。抽象化を行うのは、その署名と宣言だけです。
Encapsulation
状態と動作のアクセスを減らすことにより、内部の詳細を単に隠しています。カプセル化されたクラスは、明確に定義されている場合とされていない場合がありますAbstraction
。
java.util.List
はの抽象概念ですjava.util.ArrayList
。アクセス修飾子java.util.ArrayList
でマークされている内部状態non public
はカプセル化です。
編集
クラスを仮定しContainer.nava implements IContainer
、IContainer
のようなメソッドを宣言することがaddElement
、removeElements
、contains
ここなどは、IContainer
その実装クラスの抽象化を表します。抽象化とは、クラス、モジュール、またはシステムのAPIを外部に宣言することです。これらのAPIがになりますcontract
。そのシステムはまだ開発されている場合と開発されていない場合があります。システムのユーザーは宣言されたAPIに依存できるようになり、そのような契約を実装するシステムは常に宣言されたAPIに準拠し、それらのAPIの実装を常に提供します。具体的なエンティティを作成したら、内部状態を非表示にすることをカプセル化します
要するに
抽象化の使用->カプセル化 と カプセル化の使用->データの非表示
または
データ非表示はカプセル化のサブセットであり、 カプセル化は抽象化のサブセットです
リファレンス:http : //www.tonymarston.co.uk/php-mysql/abstraction.txt