抽象化 (abstraction) は、設計の基本スキルですね。
とはいっても「抽象化とは何か?」とか「どうやって抽象化するか?」を、簡単に説明するのは難しい。
私の場合「抽象化」という言葉を理解してから、設計を覚えたわけではない。
ソフトウェア開発の現場で、失敗しながら覚えてきた「コツ」みたいなものが「抽象化」と呼べるかな?という程度の感じ。
超自己流「抽象化論」...
抽象化は「手段」なので、何か結果が残ります。
「あるもの」を抽象化すると「別のもの」が出てくる。
そして、抽象化した「結果」は、元の「あるもの」に比べ、
・小さい
・少ない
・短い
...
という特徴がある。
簡単でしょう?
「小さくする」「少なくする」「短くする」ことが「抽象化」なんです。
大きくなる、多くなる、長くなるのは、抽象化とは、正反対の方向。
これは、具象化。「具だくさん」にすること。
「お吸い物」が抽象化で、「ごった煮」が具象化か?
私が、最初に "Abstract" と出会ったのは、大学で、英語の文献を読まされたとき。
文献の最初に必ず「Abstract」がある。
文の数にして、10以下で、段落ひとつ、程度が多かったかな。
数10ページある文献の内容が、とっても短く、まとめてある。
日本語でいうと
・抜粋
・要旨
とか、そんな感じでしょうか。
「論文の全体」を「ひとつの段落」に「小さく」まとめなおしたもの。
それが "Abstract" なんですね。
文献の最後にも、数段落の「Summary(要約)」がある。
これも「論文全体」を「短く」まとめたもの。
「抽象化(Abstraction)」というのは、ようする、こういうことなんです。
「大量の情報」から、大事なとこだけ抜き出して「小さく」したもの。
今日は、「紀元後2010年1月30日土曜日」です。
日常生活では、こんな長ったらしい表現は、使いませんね。
「今日の次の次の日は、紀元後2010年2月1日である」なんて言わないですよね?
・あさって
・月曜
・週明け
・月初
・1日(ついたち)
...
状況によるだろうけど、こうやって、簡単な言い方で、済ませている。
これも「抽象化」の一種なんです。
「長い表現」を「短い」表現に短縮する。
文字の数も「少ない」ですね。
ソフトウェア技術者だという、こういうのが得意というか、好きな人が多い。
・Domain-Driven Design を DDD
・String を s
・index を i
...
これも、抽象化の一種。
元の表現に比べ、小さく、文字数が少なく、短くなっているから。
「現実世界」は、理解不能なくらい、めちゃくちゃ具だくさんで、入り組んでいる。
モデルは、現実世界を「小さく」「少なく」「短く」まとめたもの。
UML の図なんて、現実世界の、ほとんど、すべてを取り除いた、ごくごく少数の要素を絵にしたもの。
UML で描いたモデルはスーパー「抽象絵画」なんですね。
モデルをコードにすると、モデルよりコードのほうが「大きく」「多く」「長く」なる。
とは言っても、コードも、現実世界から比べれば、「超々」抽象的。
だから、モデルを描いたり、コードを書いたりしている、ということは、かなりレベルの高い「抽象化」を、毎日やっている、ということなんです。
※ Abstarct 宣言するのが、抽象化ではない。
時々
・抽象化は難しい
・抽象化できない
という言い方を目にします。
わたし流の解釈だと、コード書く人が「抽象化が難しい」とか「抽象化できない」なんてわけがない。
コードを書くこと自体、すごい「抽象化」作業なんですから。
どうも「抽象化」という手段(作業)に「正解」や「真の答え」があると思っている人が多そう。
この「正解」幻想が、「抽象化」のハードルをめちゃくちゃ高くしちゃっているんだと思う。
「抽象化」は、単なる手段なんで、「元になったもの」より「結果」が
・小さく
・少なく
・短く
なっていれば、それは、「抽象化」できた、ということ。
抽象化したら、長くなった、というのは、さすがに間違い。
※ Abstract Class が 100行超えていて、具象クラスが、10行という、冗談を時々、見かけますけどねえ。
抽象化の「結果」が、役に立てば、それでOK。
役に立たなければ、やりなおし。
ただ、それだけのことです。
・簡単な絵を描いてみたら、みんなの理解が一気にすすんだ
・いろいろな言葉がとびかって混乱したけど、用語を整理したら、すっきりした
・ぐちゃぐちゃしたコードからメソッドを抽出して、良い名前をつけたら、コードが、読みやすくなった
...
こういうのが「役に立つ」抽象化。
自分は「小さく」「少なく」「短く」して「わかりやすく」したつもりでも、
・伝わらない
・誤解された
・ぽかんとされた
...
というのは、「役に立たなかった」から、失敗。
でも、「まちがい」ではない。
その状況では「役に立たなかった」だけのこと。
抽象化に「まちがい」なんてないんです。
別の方向に「小さく」「少なく」「短く」して、やりなおしてみるだけのこと。
「抽象化」は設計の基本。だから、ある方向の「抽象化」が「役に立たなかった」からといって、「抽象化」を放棄してはいけない。
別の方向に「抽象化」してみる。
そうやって、何回も試行錯誤をしていると、自然に、役に立つ抽象化のコツが掴めてくる。
「抽象化」の方向の引き出しが多い人、「抽象化」を状況に応じて手を変え品を変え、やり直せる人。
そういう人が「設計能力」が高い、という。
設計スキルをアップするには、
・「抽象化」の引き出しを増やす
ことです。
ものごとを、
・小さくする
・少なくする
・短くする
には、いろいろなやり方がある。
いろいろな「方向」への抽象化がある。
そういうやり方、「方向」については、次の記事で書きます。
次回予告「抽象化の引き出しを増やす」...
とはいっても「抽象化とは何か?」とか「どうやって抽象化するか?」を、簡単に説明するのは難しい。
私の場合「抽象化」という言葉を理解してから、設計を覚えたわけではない。
ソフトウェア開発の現場で、失敗しながら覚えてきた「コツ」みたいなものが「抽象化」と呼べるかな?という程度の感じ。
超自己流「抽象化論」...
抽象化の結果
抽象化は「手段」なので、何か結果が残ります。
「あるもの」を抽象化すると「別のもの」が出てくる。
そして、抽象化した「結果」は、元の「あるもの」に比べ、
・小さい
・少ない
・短い
...
という特徴がある。
簡単でしょう?
「小さくする」「少なくする」「短くする」ことが「抽象化」なんです。
大きくなる、多くなる、長くなるのは、抽象化とは、正反対の方向。
これは、具象化。「具だくさん」にすること。
「お吸い物」が抽象化で、「ごった煮」が具象化か?
抽象化:抜粋/要約
私が、最初に "Abstract" と出会ったのは、大学で、英語の文献を読まされたとき。
文献の最初に必ず「Abstract」がある。
文の数にして、10以下で、段落ひとつ、程度が多かったかな。
数10ページある文献の内容が、とっても短く、まとめてある。
日本語でいうと
・抜粋
・要旨
とか、そんな感じでしょうか。
「論文の全体」を「ひとつの段落」に「小さく」まとめなおしたもの。
それが "Abstract" なんですね。
文献の最後にも、数段落の「Summary(要約)」がある。
これも「論文全体」を「短く」まとめたもの。
「抽象化(Abstraction)」というのは、ようする、こういうことなんです。
「大量の情報」から、大事なとこだけ抜き出して「小さく」したもの。
抽象化:短縮
今日は、「紀元後2010年1月30日土曜日」です。
日常生活では、こんな長ったらしい表現は、使いませんね。
「今日の次の次の日は、紀元後2010年2月1日である」なんて言わないですよね?
・あさって
・月曜
・週明け
・月初
・1日(ついたち)
...
状況によるだろうけど、こうやって、簡単な言い方で、済ませている。
これも「抽象化」の一種なんです。
「長い表現」を「短い」表現に短縮する。
文字の数も「少ない」ですね。
ソフトウェア技術者だという、こういうのが得意というか、好きな人が多い。
・Domain-Driven Design を DDD
・String を s
・index を i
...
これも、抽象化の一種。
元の表現に比べ、小さく、文字数が少なく、短くなっているから。
現実世界、モデル、コード
「現実世界」は、理解不能なくらい、めちゃくちゃ具だくさんで、入り組んでいる。
モデルは、現実世界を「小さく」「少なく」「短く」まとめたもの。
UML の図なんて、現実世界の、ほとんど、すべてを取り除いた、ごくごく少数の要素を絵にしたもの。
UML で描いたモデルはスーパー「抽象絵画」なんですね。
モデルをコードにすると、モデルよりコードのほうが「大きく」「多く」「長く」なる。
とは言っても、コードも、現実世界から比べれば、「超々」抽象的。
だから、モデルを描いたり、コードを書いたりしている、ということは、かなりレベルの高い「抽象化」を、毎日やっている、ということなんです。
※ Abstarct 宣言するのが、抽象化ではない。
正しい抽象化?
時々
・抽象化は難しい
・抽象化できない
という言い方を目にします。
わたし流の解釈だと、コード書く人が「抽象化が難しい」とか「抽象化できない」なんてわけがない。
コードを書くこと自体、すごい「抽象化」作業なんですから。
「正解」とか「真理」ではない
どうも「抽象化」という手段(作業)に「正解」や「真の答え」があると思っている人が多そう。
この「正解」幻想が、「抽象化」のハードルをめちゃくちゃ高くしちゃっているんだと思う。
「抽象化」は、単なる手段なんで、「元になったもの」より「結果」が
・小さく
・少なく
・短く
なっていれば、それは、「抽象化」できた、ということ。
抽象化したら、長くなった、というのは、さすがに間違い。
※ Abstract Class が 100行超えていて、具象クラスが、10行という、冗談を時々、見かけますけどねえ。
役に立つこと
抽象化の「結果」が、役に立てば、それでOK。
役に立たなければ、やりなおし。
ただ、それだけのことです。
・簡単な絵を描いてみたら、みんなの理解が一気にすすんだ
・いろいろな言葉がとびかって混乱したけど、用語を整理したら、すっきりした
・ぐちゃぐちゃしたコードからメソッドを抽出して、良い名前をつけたら、コードが、読みやすくなった
...
こういうのが「役に立つ」抽象化。
自分は「小さく」「少なく」「短く」して「わかりやすく」したつもりでも、
・伝わらない
・誤解された
・ぽかんとされた
...
というのは、「役に立たなかった」から、失敗。
でも、「まちがい」ではない。
その状況では「役に立たなかった」だけのこと。
「まちがい」なんてない
抽象化に「まちがい」なんてないんです。
別の方向に「小さく」「少なく」「短く」して、やりなおしてみるだけのこと。
「抽象化」は設計の基本。だから、ある方向の「抽象化」が「役に立たなかった」からといって、「抽象化」を放棄してはいけない。
別の方向に「抽象化」してみる。
そうやって、何回も試行錯誤をしていると、自然に、役に立つ抽象化のコツが掴めてくる。
「抽象化」の方向の引き出しが多い人、「抽象化」を状況に応じて手を変え品を変え、やり直せる人。
そういう人が「設計能力」が高い、という。
設計スキルをアップするには、
・「抽象化」の引き出しを増やす
ことです。
ものごとを、
・小さくする
・少なくする
・短くする
には、いろいろなやり方がある。
いろいろな「方向」への抽象化がある。
そういうやり方、「方向」については、次の記事で書きます。
次回予告「抽象化の引き出しを増やす」...