抽象の癖

教育と商業開発の長年にわたって、私は単語抽象化の意味を完全に理解していない多くの学生と開発者に会ってきました。 この用語の意味を明確にするための多くの試みのうち、この記事は判明しました。 カットの下にあるもの：

• 抽象化の定義と、それがOOPのどこから来たかの説明。
• 抽象化の障壁、抽象化の副作用であるものの簡単な例による説明。
• ハードコードはどのように取得されますか？

抽象化とは何ですか？

ウィキペディアでは、抽象化と抽象化のプロセスを次のように定義しています。

抽象化（lat。Abstractioから-気晴らし）-本質的で規則的な兆候を強調するために、非本質的な側面、特性、物体（物体または現象）の関係からの認識の過程における気晴らし。 抽象化; そのような気晴らしの結果としての理論的な一般化。



ヨーロッパの哲学と論理では、抽象化は、ますます一般的なモデル、つまり抽象化の階層を形成する概念を段階的に生成する方法として解釈されます。 最も発達した抽象化システムは数学です。 議論中の概念の抽象化の程度は、抽象化のレベルと呼ばれます。 目標と目的に応じて、異なる抽象化レベルで同じオブジェクトについて話すことができます。



Grady Butchは抽象化の概念をはるかに単純に定義していますが、意味は同じです：

抽象化は、オブジェクトを他のすべてのオブジェクトと区別する本質的な特性を強調しています。

なぜ抽象化が必要なのですか？

抽象化は保護機能を実行し、情報が過剰になっても心を失わないようにします。 ボールペンで書くとき、数十億のインク分子が紙の分子と相互作用して文字を作ると考えなければならないとしたら、私たちがどう生きるか想像してみてください。 言い換えれば、不必要な詳細に時間を無駄にすることなく、本質を把握することができます-「上から」問題を見てください。



鳥瞰図がなければ、バルセロナのデザインがどれほど正確か想像できたでしょうか？ ちなみに、ボールペンを使用した例については、読書も機能しません-手紙上の同じ文字のスタイルは一人でも異なっています。



抽象的思考は、多くの新しい情報を処理して同化できるメカニズムです。 抽象化がなければ、私たちにとって唯一の選択肢は、非常に原始的な生き物であり続けることです。



ブラジルでは、この部族はインディアンの小さな部族ピラに住んでいます。 この国籍の代表者は、非常に貧弱な抽象的な思考を持っています。 アルファベットは、3つの母音と8つの子音で構成されています。 数字の代わりに数字を表す言葉がありません。数字の代わりに、いくつかの概念があります。 彼らには色はありません-明暗の概念、時間と歴史だけです-彼らは今日だけ生きて、それだけを覚えています。 最も古い生きている人が覚えていること; いいえ-宗教、工芸、芸術。 私たちの通常の理解には、まだ多くのものがあります。 そして、これは抽象的な思考が発達していないためです。 確かに、公正には、彼らが自分自身を絶対に幸せな人だと感じることは注目に値します！



そのため、お互いの情報を交換するために、私たちの周りの世界を知り、説明する方法として抽象化が必要です。 抽象化により、サブジェクトドメインを一連の概念とそれらの間の関係に分解できます。



写真はロンドンのレゴランドを示しています。 すべてのアイテムが子供のデザイナーから収集されているという事実にもかかわらず、私たちはそれらの中に家、窓、ドア、都市ブロック、人々を簡単に認識することができます。

抽象化の障壁と副作用

抽象化の重要な特性を理解するために、平面への投影の構築との類似性を引き出します。



ボール、円柱、箱の3つの図形があるとします。一方、底面の円の中心を通る円柱の対称軸は、箱の対称軸に平行です。 明らかに、ボールと円柱が円形に投影され、円柱と平行六面体が長方形に投影されるように、投影を作成するために2つの平面を選択できます。



この例の投影は、オブジェクトの抽象化、つまり幾何学的図形を示しています。 ある平面では、ボールと円柱の投影を区別できず、他の平面では円柱と平行六面体の投影を区別できません。 この効果は、抽象化の障壁と呼ばれます。 抽象化はオブジェクト全体を表すのではなく、その本質的な特性セットのみを表します。非常に異なるオブジェクトの中には、区別できないものがあることに注意する必要があります。 これが不便な場合は、異なる抽象化のセットを選択する必要があります。



一方、この例からわかるように、円柱は円と長方形の両方に投影できます-円柱とは異なる幾何学的特性を持つオブジェクト。 抽象化されたオブジェクトのプロパティとは異なる独自のプロパティの抽象化の存在は、抽象化の副作用と呼ばれます。



最初の写真は、スライバーから収集された2つの図を示しているため、特定の照明条件下で「人間の影」を投影します。 たとえば、1つのシルエットは男性で、もう1つのシルエットは女性のようです。 これは、抽象化の副作用でもあります。 これで、すべての形状を影で分類できます。

抽象化の例

適用範囲	抽象化	解説
整数	リングZpからの数。ここで、p = 2 ^ビット容量（8、16、32、64ビット）	この抽象化により、間隔–p / 2 + 1からp / 2までの整数のみを表現できます。 副作用はオーバーフローの問題です。
実数	浮動小数点数	実数は数えられず、浮動小数点数は有限です。 つまり、数え切れない実数は、単一の浮動小数点数で表されます。 副作用は丸め誤差です。これは、比較演算を使用して2つの数値を比較することはできず、小さなイプシロン| ab | <epsilon => a == b、またはa / b * 1000は、a * 1000 / bとは大きく異なる場合があります。 数学にはすべての分野が登場しています。数値法は、結果が実数の計算と大きく変わらないように浮動小数点計算を整理する方法を研究しています。
お金	浮動小数点数	浮動小数点数の丸め誤差は、それらを金融取引に使用することを不可能ではないにしても、少なくとも人生を大きく複雑にします。 いずれにせよ、私は最初に通貨単位の別のクラスを書くことを考えます。
画像	マシングラフィックス	コンピューターグラフィックスは、コンピューター画面上の画像をよりリアルにするために飛躍的に発展しています。
ソフトウェア	手続き	プロシージャは、手続き型プログラミングの分解の基本要素です。 副作用とは、厳密に定義された一連のコマンドを持つプロシージャであり、プロシージャ自体を書き換えない限り変更できません。
ソフトウェア	クラス	以下でクラスについて説明します。
サブジェクトエリア	本質の抽象化とエンティティ間の関係	副作用-認識、誤解、偏見などを反映 特定の主題の主題領域について。
ビジネスロジック	手続き	上記のように、プロシージャの副作用はコマンドの厳格なシーケンスです。 通常、ビジネスロジックには多くの例外が含まれており、ユーザーが通常は語るのを忘れているため、ビジネスロジックは変更される可能性があります。 多くの場合、ビジネストランザクションをプロシージャとして提示しようとすると失敗します。
ソフトウェア	並列化操作のスレッド	マルチスレッドプログラミングは理解するのが非常に困難であることが判明し、ほとんどの人は理解していません。
正方形は、すべての辺が等しい長方形です。	正方形クラスは、長方形から継承できません。	クラスは抽象化です。 それらには、数学的なオブジェクトとは異なり、継承を不可能にする独自のプロパティがあります。

クラス

Grady Butchは、OOPを次のように定義しています。

オブジェクト指向プログラミングは、プログラムをオブジェクトのコレクションとして表現するプログラミング方法論であり、各オブジェクトは特定のクラスのインスタンスであり、クラスは継承階層を形成します。



この定義で最も重要な点は、継承階層です。 OOPを他のすべての方法論と区別するのは継承であるためです。



人間の思考の2つの基本原則は、グループ化と一般化です。 実際、クラスは、人間の脳のグループ化と一般化のメカニズムの抽象化です。 当然、副作用と障壁があります。 同時に、1つのクラスを同様のオブジェクトと一致させることでグループ化が達成され、クラスの階層によりOOPの一般化が達成されます。 クラス階層はポリモーフィズムによって実装されます。



ちなみに、OOPは、おそらく現時点で最後のプログラミングパラダイムであり、ハードウェアレベルでサポートされているため、さらに興味深いものです。



クラスの主な副作用は、クラスを作成したプログラマーの経験、ステレオタイプ、偏見を反映することです。 その結果、同じタスクに対して異なる人が異なるクラスのセットを取得することになります。 さらに、同じ人が同じ問題を解決しますが、異なる時点で、彼の人生経験が変化しているという理由だけで、異なるクラスのセットを受け取ります。



注目に値する2番目の副作用は、他人のコードが常に自分のコードよりも明確でないことです。





これが起こる理由を理解します。 人がコードを書くとき、下から上へ、つまり低レベルのコンポーネントから高レベルのコンポーネントへと移動する方が自然です。 最初に1つのクラスを作成し、次に2番目のクラスを作成し、1番目のクラスに依存します。



人が他の人のコードを理解しようとするとき、彼は単に逆方向に上から下に移動します。 つまり、最初に一般的な本質を理解し、次にそれをコンポーネントに分解してから、各コンポーネントの本質などを理解しようとします。 多くの場合、下から上、上から下へのこれらの思考の動きは、異なる人々の間で一致しません。 当然のことながら、コンポーネントへのコードの内訳が、それを行う方法についての彼自身の信念と一致した場合、学生は他の誰かのコードを学ぶのが簡単になるでしょう。 そうでない場合は、開発者の思考の流れを理解するのにある程度の努力が必要です。 したがって、誰かがここに「完全なハードコード」であると言ったが、書き直せばより簡単で理解しやすくなります。 これは常に100％真実です...しかし、彼にとってのみ、残りの部分にとって、書き換えの価値はそれほど明白ではありません。



ちなみに、意図的に何もしなければ、ボトムアップで開発する場合、コードは強く相互接続されます。つまり、再利用できません。 この影響を克服するには、依存関係反転の原則に従う必要があります。



説明した副作用がどのように現れるかを簡単な例で示します。 大都市の多くの居住者は、大きなスーパーマーケットで購入されます。 妻が夫を買い物に出して、いつものように「タンクにいる人のために」リストを作成することを忘れないようにするとします。

私たちは彼女の思考の流れをたどろうとします。

「では、今日は夕食に何を料理しますか？」

-あなたは子供を甘やかすためにおいしいものを調理する必要があります。

-だから、小麦粉、牛乳が必要になります。

-ミキサーのバッテリーが少なくなっているようです。

-やめて！ 子供にはビタミンが必要です。 ニンジン。 にんじんジュースを作ります。 みかん。 新年はもうすぐです！

-家にパンはありますか？ いいえ、そうではないようです。

-まだオイルを購入する必要があります。

-赤ちゃんのことを忘れた-ビタミン。 りんごを買う。

-ペンがうまく書けないもの。 おそらくインクはすぐになくなるでしょう。 購入する必要があります！

-だから、子供はジュースを買う必要があります。

-また、おもちゃ-彼を喜ばせてください。

-ボルシチにジャガイモはありますか？ ボルシチには十分ですが、1週間ではありません。 だから、あなたも購入する必要があります。

-先生が私に2つのノートブックを持って来るように頼んだのを忘れていました。

-ボルシチにはサワークリームが必要です。

-砂糖が終わったように。

-子供はブドウが大好きです。

-それでも、ボトル入りの水を購入する必要があります。



その結果、次のリストが得られます。

• 小麦粉
• 牛乳
• 電池
• にんじん
• みかん
• パン
• 油
• りんご
• ペン
• ジュース
• おもちゃ
• じゃがいも
• ノート
• サワークリーム
• 砂糖
• ぶどう
• 水

夫が店に来るとき、彼は何を発見しますか？ リストされている製品は、店舗のさまざまな場所にあります。 通常、リストは長いため、すでに購入したものを思い出すことは十分に困難です。 これには、一部の部門が一時的に閉鎖されていることが課されています。商品は荷降ろしされており、一部の商品は販売されていません。 より経験豊富な同志は、非常に夢中になった表情の鉛筆またはペンを使い、常に自分のリストを見ていきます。 しかし、とにかく、購入するものを忘れてください。 私自身の経験から言えば、この「何か」が最も重要であると言えるので、店に行く価値がありました。



夫にとって便利なリストはどれですか？ すべての製品が部門ごとにグループ化されている場合、個々のグループはストアバイパス順序に対応する順序になります。 たとえば、私が行く店では、商品を次のようにグループ化すると便利です。

• 電池
• 子供用ノート
• ペン
• 水
• ジュース
• 砂糖
• にんじん
• オレンジ
• りんご
• ぶどう
• ポテト
• オイル
• パン
• 牛乳
• サワークリーム
• 小麦粉
• 子供のおもちゃ

別の重要な観察結果は、抽象化自体からどれだけ成功したかを判断することは不可能です。 これは、実際に使用する場合にのみ実行できます。 そして、いくつかの抽象化はタスクに適している一方で、他の抽象化は悪いことがわかります。 また、初期条件を少し変更すると、以前の「適切な」抽象化セットが機能しなくなる可能性があります。 たとえば、この例の2番目の買い物リストは、商品の表示順序が異なる別のストアに移動すると機能しなくなります。 彼は最初よりも良くなることはありません。

したがって、結論-すべての機会に適したクラスのセットを考え出すことは不可能です。 Open-Closed Principleの記事では、この戦略的閉鎖を呼んでいます。



自然な問題は、すぐに優れた抽象化を作成する方法です。 残念ながら、これに対する正確な答えはありません。 しかし、時間の経過とともに、何をすべきかを伝える一連のプラクティスが開発され、このケースでは良い結果が得られると約束されています。 このような慣行には、リファクタリング、コーディング標準、コードレビュー、 オブジェクト体操などが含まれます 。 これらのプラクティスの目的は、開発者グループの思考の流れを一方向に向けることです。そうすれば、他の誰かのコードがより理解しやすくなる可能性が高くなります。 個々の個人の各プラクティスに対する態度は、そのプラクティスを使用して得られた経験のみに依存します。 多くの場合、「これは機能しません」という言葉は「試した-成功しなかった」と解釈する必要があります。 反対も反対も客観的な議論はありません。

では、なぜOOPが必要なのですか？

自然言語とOOPの類似点を描いてみましょう

自然言語	OOP
言葉	クラス
ルール	構文
ジャンル	建築
文芸	パターン

人は自然言語の言葉で考えを表現します。 タスクには2つのタイプがあります。

1. それを解決するには、言語自体を知る必要があります。 たとえば、戦争と平和を書く。
2. 複雑さは言語に依存しません。 どれだけ多くの言語を知っていても。 これは何の助けにもなりません。 たとえば、フェルマーの定理。

OOPは、大規模プログラムを対象に作成されたツールです。 しかし、これは大規模なプロジェクトを作成するために必要なツールの1つにすぎません。



なぜ私はXが好きなのか、なぜXが好きではないのかというスタイルの記事に驚かされます。誰もがXがツールであることを理解しています。 結局のところ、シャベルに関するそのような記事はありません。 結局のところ、OOPは数十年存在し、シャベルは数千であり、おそらく石器時代のどこかで、マンモスシャベルまたは石が優れているというトピックに残酷なホリバーがいたことを知っていますか？

関連文献

1. Grady Butch C ++のアプリケーションの例を使用したオブジェクト指向の分析と設計

この本の紹介は不要です。 プログラミングに関する最も引用された本の1つ。

2. バーバラミントミントピラミッドの原理。

マッキンゼーのコンサルタントとして働いていたバーバラ・ミントは、人が情報をどのように認識するかに基づいて、分析文書を作成する独自の方法を作成しました。 本では、グループ化と一般化の原則に多くのスペースが与えられています。

3.ロバート・マーティン（ボブおじさん）

Robert Martinは、OOPの原則に関する一連の記事と本を執筆しています。 これらの中で最も有名なのはSOLI.Dです。 ロバートマーティンラピッドソフトウェア開発によりロシア語で出版された本。 原則、例、これらの原則が記述されている実践 。 しかし、私の意見では、 「単一責任原則」 、 「オープンクローズド原則」 、 「リスコフ置換原則」 、 「インターフェース分離原則」 、 「依存性逆転原則」の記事でそれらについて読む方が良いでしょう。