スッキリわかるJava入門

Amazon製の攻性防壁にフルボッコにされた件

励んでます、『感謝の正拳突き』

気付けば時は流れ6月も中旬ですね。ご無沙汰しております、takaxiです。
いつも拙著『スッキリわかるJava入門』への暖かいコメント、ありがとうございます。

つい先日、おかげさまでAmazon様でのレビューが50件を超えました。

有名な先生や今をときめくエンジニアならともかく、私のような地味な素人の著書に、50名様もの方が、時間と手間を割いてご意見をくださったこと、文字通りの「有難いこと」だと、しみじみ感慨にふけっております。

時折、Amazonを開いてみて、新しいコメントを戴いていることを見つける度に、

合掌。

の日々でございます1。

そして、51回目の合掌

そんなことより、きいてくれよ>>1よ。

久しぶりに気持ちよく晴れた昼下がり。最近ちょっと電池の持ちが悪くなったiPadくんで、いつものようにAmazon.co.jpのレビューページを開いた瞬間、それは起きたんだ。

PK2 → PPPK → アッパー → キャンセル → 昇竜拳っっ！！

を精神に食らってのけぞる俺。

遠ざかる意識の中で、

「こっ、攻性防壁3ッ...!?
はやく...JPCERTに...連絡しな...きゃ...っ!!（ガクッ）」

と思いを巡らすのでありました。

それほど、私が猛省するレビューコメントをいただいたので、今回はそのご報告です。

私ね。いつかこんな日が来るって、心のどこかで思ってたんだ（爽やか涙笑）

51件目のAmazonレビューで「ちょっと違うんじゃないの?!」というご指摘いただいたのは、そう、

「オブジェクト指向の定義」。

・・・えぇ、本当に手をだしちゃいけない代物だってことは、わかってました。

これまで長い間、「viとEmacs論争」の次ぐらいに、サ○ゼリヤで安く出せるぐらいたくさんの血が流れてきたことを、私はよーく知っています。飲み屋でこの議論を始めると、大抵次元が崩壊してしまうことも、何度も目にしていますとも4。

拙著にも書かせて戴いたように、この「オブジェクト指向の定義」というものが、一番難しいと実感しています。オブジェクト指向をマスターし、十分に活用している人でさえ、その定義を伺うと人によって異なっていることも少なくありません。

私自身も仕事柄、よく「オブジェクト指向って何？」という疑問に解説を求められるのですが、学び手が答えに辿り着くには、大きくわけて2つのアプローチがあると考えています。

アプローチ1: 構造的なオブジェクトの定義から発展させながら説明

今回のレビューコメントでもご提案いただいた、伝統的な解説アプローチです。このアプローチでは、まず「オブジェクトの定義」を明らかにします。

オブジェクトとは、データとコードを1つにまとめたもの

この定義は、オブジェクトというものの構造という、ゆらぎのないものを条件とした定義ですので、はじめての方にも明解かつ理解しやすいのが特徴です。

そして、「このように定義されるオブジェクトを複数組み合わせプログラムを作っていくのが、オブジェクト指向プログラミングなんですよ」、という議論の発展のさせかたでオブジェクト指向プログラミングを説明していきます。

アプローチ1による説明や学習の難しさ...

私自身は、このアプローチ1には、いくつかの難しさを秘めていると感じています。

確かに「オブジェクトとは」までは非常にスムーズに学習が進むのですが、次に控える「オブジェクト指向とは」を学習する段階で、とても難しくなってしまうのです。

私がはじめてC++を学んだとき5、このアプローチ1による解説をいくら読んでも、どうしても次のような疑問が残ってスッキリしなかったんです。

「データとコードを一緒にしたからって、なにが嬉しいの？」
「たかがデータとコードを一緒にしたぐらいで、すげーいいことがあるって、ありえなくない？」
「っていうか俺、今でもC言語で関連する関数や変数をひとまとめにしてるけど6」

中でも最大の疑問が、上記の２つ目のものでした。子供心ながら、

「別々に持っているテレビとビデオデッキを、1つのテレビデオにしたって、物理的構造が変わるだけで、基本的にできることは変わらないじゃないか。」

なんていうことを、ビデオ部分だけが先に壊れてしまったテレビデオの前でしみじみと考えた、ひぐらしの鳴く夏の夕暮れ。

ばらばらだった関数と変数を、構造的にまとめただけで、世の中で言われるような（そして、自分が苦しい思いをして勉強する価値があるような）すごいメリットが生まれるもの、楽しいものであるとは、どうしても思えなかったのです。

「メリット」を理解できないことの重大さ

このようにアプローチ1には、初学者がいきなり「オブジェクト指向のメリットとその発生機序について、納得できる説明を得られにくい」という特徴があります。

このことは、単に「メリットが実感できないから、頑張って学び続けることが難しい」という問題のみならず、次のような問題に繋がります。

「オブジェクト指向のメリットはどのようなものか。」
「どのような仕組みでそのメリットが生まれるのか。」
を心底納得して理解していないがために、
「そのメリットを引き出すようなコードの書き方」ができない。

実際私は、アプローチ1による「オブジェクトの定義」に沿った次のようなJavaのクラス数百個以上から構成される、実稼働しているシステムのソースコードを、そう遠くない過去に目にしています。

// モジュールIDの上2桁は開発チームID
public class MODULE0008 {
  public boolean reqflag1;

  public int req1001(REQ1001 r) { ...100行ぐらい?... }
  public void req2001(REQ2001 r) { ...200行ぐらい?... }
}

あぁ...7。たしかに、データとコードを1つにまとめてるよね。

確かに、オブジェクトの必要条件は備えてる。そして、オブジェクトを複数組み合わせてシステムを作ってる。

でも、これは私たちが学ぶべき、また、学ぶ価値のある、従来ない大きなメリットを生み出す、「オブジェクト指向」というものなんだろうか。

アプローチ2: 概念の写像というメリットからの解説

私は「アプローチ1」に出会ったあと、スッキリしないながらも、何年かC++でプログラミングを続けてみました。

他人のコードもたくさんを読んで、前に挙げたような「別にオブジェクト指向のメリットを感じないコード」にもたくさん出会いつつ、でも中には「断片的にだけれどもメリットを感じるコード」も見つけたりして、自分でも書いてみて、そうしてやっと少しずつ「なにが嬉しいのか」がわかっていったように思います。

そして、独学だったからでしょう、「アプローチ1」に出会って4〜5年ほど経った頃、やっと自分なりに整理がついた瞬間がありました。

そうか。
データとコードを一緒に持つオブジェクトは、俺の頭の中にある「ひとかたまりの概念」たちを、そのまま素直に表現できるから、か。

その後、オブジェクト指向分析設計論やドメイン駆動設計などに出会う度に、自分の理解を確認していきました。また、私にスクラムを指導してくださったJames O. Coplien氏8のコースの受講中にあった、次のようなやりとり（雰囲気＆意訳）でも、自分の理解があながち間違ってはいないと勇気を戴きました。

Corp「What's the core concept of Object Oriented Programing?
How do you think?9」

受講者A「Inheritance!10」

受講者B「Polymorphism!11」

Corp「No. I do think, it's a good tool for you
to clone ideal objects in your brain
into the world of code.12」

そして、多くの学び手のプログラミング学習をお手伝いするようになってからは、

「現実世界の概念を写しとる」という感覚から説明したほうが、圧倒的に、興味をもたれやすく、心が折れにくく、理解も早い

ということに気づきました。

そうして、「オブジェクトの構造や構文」からではなく、「オブジェクト指向における概念とメリット」から説明するアプローチに辿り着き、これが拙著の解説にもなったのです。

選ぶということは、捨てるということ

誤解していただきたくないのですが、決して「アプローチ1」が間違っているわけではありません。

むしろアプローチ1で多くの試行錯誤を経たほうが、最終的には言語に対するより深い理解を得られることは、私を含むアプローチ1で学んだ人13だけが心の底から実感できることです14。

ただ、これまでの記事で書いてきたように私自身、「デスマに投入される部隊」にいた関係で、無力感を感じることも少なからずありました。

私の目の前には「オブジェクト指向の学習を途中で挫折し、プログラミングに興味を失い、死んだ目をして仕様書をコードに機械変換する作業に明け暮れる若手」とか「オブジェクト指向言語を使った手続き型プログラミングをして、メリットを享受できていないデスマ現場」とかが真夏のアブラゼミのように転がっていて、そのどれもが真剣に苦しみの渦中にありました。

もちろん世の中には「アプローチ1」による書籍も、研修もあったけれども、（メリットを引き出す使い方が行えるようになるまでに時間がかかりすぎて）彼らを救う武器にはなりませんでした。

私は、それをどうにかしたかった。

だから、拙著ではその目的にかなう「アプローチ2」を選んだこと15を、後悔していません。

猛省した理由

じゃぁ、どうしてこの記事の冒頭で「猛省」したと書いたか...ですが、レビューに次の記述があったからです。

URLオブジェクト
データベース接続オブジェクト
正規表現パターンオブジェクト
など、現実世界には存在しない概念を、オブジェクトとして扱わなければならない

これを見て、本当に、本当に、申し訳なく、自分の力不足を実感しました。

（たぶん）お金を出して買って戴き、時間をかけて640ページも読んで戴いたのに、
アプローチ2でJavaを伝える力が、自分にはまだまだ足りなかった。

確かに、拙著でオブジェクト指向を主に解説した7章では、もっとも理解しやすい「勇者」や「モンスター」のような、有形の概念を題材にしました。

しかし、「無形の概念もクラスにでき、そのようなものがたくさんある」ことを、伝えきれなかったのだと思います。

例えば、オブジェクト指向の解説が終わった直後に紹介しているDateクラス。これは、私たちが現実世界で扱う「日付情報」という概念をコードに写し取ったものです。続いて解説があるExceptionクラスについても、本文中で「現実世界における例外的な状況をクラスとして表現したもの」と記述して、解説できているもりでした。

ですので、本書をひととおり読んでくださったにも関わらず、

URLクラス
現実世界で私たちが考えたり、やりとりしたりする「URL情報」という概念をクラスにしたもの

データベース接続クラス
現実世界で、アプリとDBサーバー間に確立される「接続」という概念をクラスにしたもの

正規表現パターンクラス
現実世界で、私たちが考える「文字照合ルール」という概念16をクラスにしたもの

という風に理解いただけなかったとしたら、それは著者の力不足以外のなにものでもありません17。

今回、このようなレビューをくださった方がいたということは、その方同様に「私の力不足で、違和感を感じてしまった方」がきっと他にもいるはず...。そのことを、猛省したのです。

51回目の『合掌』

「レビューを書く」「フィードバックをする」ということは、時間も手間もかかる、とても大変なことです。

チキンな私は、レビュー自体が人様からどう見られるかなど考えちゃって、書きかけでブラウザを閉じてしまうこともよくあります。

しかし、私が学び手を応援する者として成長できるのは、皆様からフィードバックをいただけるからに他なりません。確かに悲しい気分になってしまうこともありますが、成長できないことより悲しいことなんて、たぶん、ないのです。

あらためて、51名の皆様に、感謝の『合掌』。

 

参考


このブログ記事は、著者の個人ブログ(flairDays)から移転掲載されたものです。
  1. おっかしいなぁ...そろそろ『壱乃掌』あたりは使えるようになるはずなんだけどなぁ....
  2. いちいち言わなくてもわかると思いますが、ここで浮きます。
  3. まぁ最近のAmazonなら作れちゃえそうだし。えぇ、もちろん時間単位で、かつ、1-Clickで利用できるんでしょ。
  4. おばあさんがいってた。「いい技術トークネタに力を与えるためには、悪い技術トークネタも知らなければならないって。でも、決して使うなって。」
  5. おや...もう20年ぐらい前かな...
  6. プリフィックス揃えてグループ化したり、別のコンパイル単位にしてexternつけずに外部から隠蔽したり
  7. 正確には、「嗚呼...!!」と天を仰ぎながら声をだした。このコードのややこしい不具合を直してくれって言われて。
  8. 最近はアジャイル界で有名ですが、古くからのオブジェクト指向屋さんにも有名な方のようです
  9. 何がオブジェクト指向の本質だと思う？
  10. 継承!
  11. 多態性!
  12. いや。ボクは、この道具が私たちの頭の中にある仮想的な概念をコードの世界にうまく落とし込める道具であるところにこそ本質はあると思っているんだ。
  13. 文面から、今回コメントをくださったお方もアプローチ1で学んだ方だと想像します
  14. 「あー、はいはい。vtableみたいなもので実現する感じね。」とかいう発言が自然に出てくる人と出会うと、たぶん、いろんな茨の道を歩んできたんだろうと、抱きしめたくなる。
  15. そして、「アプローチ1」を捨てたこと
  16. スッキリわかるJava入門 実践編 図1-6のようなもの
  17. ちなみに、仮にゲーム制作を想定すると、本件のレビューを書いてくださった方が挙げられた3つのクラスは、それらクラスを作る立場から見ると「ドメイン領域内」の概念であっても、使う立場からは「ドメイン領域外」の現実概念です。勇者のように、使う側から「ドメイン領域内」の概念でないということが、「違和感」の原因となったのかもしれません。また、世の中にはオブジェクト指向のメリットを享受しにくい「概念と無関係に作られたクラス」も実在し、実務上それを使う機会があることは、ご指摘の通りです

-スッキリわかるJava入門
-