はじめに
こんにちは、iTOC事業部の横地です。
弊社には「APアカデミー」という技術系やビジネス系の社内研修が用意されています。
先日、数年ぶりに AP アカデミーを受講しました。受講したのは「Java研修（オブジェクト指向編）」です。
直近で業務で必要になったわけではないのですが、ときどき設計（特にデザインパターン系）やコードのよしあしに関する本を読むときにサンプルコードが Java だったりするので、そのときに抵抗なく読めるようにしたいというのが主な目的でした。また、普段コードを書くことがないので、たまには学習したほうが良いかなという思いもありました。
本記事では、本アカデミーを受講した私がアカデミーの概要や個人的な感想をまとめます。
アカデミーの内容と流れ
形式としては、時間を合わせたオンライン受講と、各自のペースで進める Udemy の受講のセットという形でした。
主な内容は以下の通りです。
- オブジェクト指向の概念
- クラス、メソッド、フィールド、コンストラクタ
- カプセル化
- 継承
Udemy 側には演習課題があるので、課題のコードを書いて講師に提出してレビューをしてもらう、という流れでした。回答例を見ずにコードを書いたので、それに対してレビューをしてもらえるとはありがたかったです。
なお、今回の講座を受講するにあたっての Udemy の受講費用は会社負担でした。ありがたいです。
アカデミーの最後にはオリジナルの演習問題があり、同じように各自でハンズオンして、レビューしてもらうという流れでした。
IDE は IntelliJ IDEA を利用しました。不慣れだったので当初は VS Code を利用しましたが、迷って書いてつまずくという行為を含めたかったため、GitHub Copilot には黙っていてもらいました。
あと、本来はオブジェクト指向編の前提になる基礎編を受講できればよかったのですが、未受講でした。なので、条件分岐、繰り返し、変数の概念などの基礎的な部分はあらかじめ別の Udemy コンテンツで学習しておきました。
あわせて読んだ本
特に指定はありませんでしたが、前提知識含めて不安があったので以下の書籍を読みました。
登場人物が素朴な疑問をぶつけてくれて、とてもよかったです。なお、図書館で借りた関係で第3版ですが、現在は第4版が出ています。
感想
全体的な感想についてまとめます。
レビューのありがたさ
特に講師にレビューしてもらえることがよかったです。
個人的にレビュー依頼のやり取りで工夫したのは、コードに加えて以下の点を README.md に含めたことです。
- もやもやしたこと・迷ったこと
- 条件式の書き方や、処理の定義場所（どのクラスが妥当かなど）分け方について、こう迷ったけどこうした、という疑問や思考の経緯
- 試してみたこと
- 厳密には課題の範囲ではないけど試したこと(
@Overrideアノテーションなど)
- 厳密には課題の範囲ではないけど試したこと(
このようなポイントにいても、講師の方が一緒に考えてくれたり、現場経験を踏まえた話をしてくれたりしました。独学では得られない体験なので、とてもありがたかったです。
今振り返ってみると、仕事の進め方としてはレビュー依頼する前にするべき相談も含まれていたと思います。
オブジェクト指向の難しさ
オブジェクト指向は難しいなとずっと思っていたのですが、大きく分けて概念、文法、応用、という3つの壁があるなと感じました。
1. 概念の壁
まず、それは何、という話。
これは、「クラスはたい焼きでいうと鋳型で、そこからできた食べれるたい焼きがインスタンスはで～」や「犬や猫は動物クラスを継承して、同じように鳴けと命令しても～」のようなたとえ話で、いったんは理解しやすい気もします。
心の声としては「分かった気がする。分かった気がするが・・？」といった感じです。
2. 文法の壁
「クラスやメソッドの定義はこう書いて、インスタンス生成は new して～」などの話。概念を理解したうえであれば、文法（書き方）は覚える、という要素が強いかもしれません。
心の声「なるほど、こう書くのか。完全に理解した」
3. 応用の壁
心の声「なんも分からん」
これが一番手ごわく感じます。表現が難しいのですが、モノの理解を試されている感覚があります。
書籍「『記録・情報・知識』の世界―オントロジ・アルゴリズムの研究」の「はじめに」には、
「わかる」ことは「分ける」こと
とあります。
これを踏まえ「クラスをどう分けるか」は「物事をどう見てどう理解しているか」に通じると感じました。
目に見えるモノであれば比較的単純です。犬や猫は4本足だし、鳴く。各個体の年齢もある。これをクラス図に書くことはしやすいです。
一方で、目に見えないものに応用しようとすると難易度が急に高く感じます。そして、実際のサービスや業務システムは、直接目に見えなかったり物理的に触れないもの（業務ルールなど）を扱うことも多いです。
これが、私が感じる応用の壁です。別の言い方をすると「例え話の先」に行くのが難しく思います。
今回のアカデミーではゲームを題材とした演習が含まれていました。ゲームは目に見える現実（かつ、ほぼ既知の概念）を仮想空間に写し出す形なので、応用の壁の少し手前にある階段のように感じました。なので、ゲームはちょうどよいのかもしれません。
突き詰めると、ここでいう応用に必要なのはモデリングでしょうか。精進します。
型とコンパイルエラー
型が決まっている言語は安心感があるなと思いました。エラーには、データ形式に起因するエラーが含まれると思っているので、型が決まっているとその手のエラーを一定防げる感覚があります。
また、実行時ではなくコンパイル段階で発生するタイプのエラーがあるのも、ある意味で安心がありました。コンパイルが通っていればコンパイルエラーはつぶせていると考えらえるためです。
このへんは、普段コンパイルが必要なく、型もゆるい処理系を扱っていることからくる感想かもしれません。
ステップ実行は便利
Java に限りませんが、ステップ実行をして「この段階でこの変数の値はなんだろ？」などを確認できるのが便利でした。
普段からコードを書かれている方にとっては当たり前だと思うのですが、私は普段はステップ実行ができないタイプのものを書いているため思った次第です。
やや逸それますが、IDE 方面でいうと、自分で書いたクラスやメソッドが補完で表示されると認められた感じがしてよいです。
おわりに
業務で Java を扱う予定はないのですが、当初の目的どおり Java のサンプルコードを読むことへの抵抗が減った感覚があります。
独学で学習するコンテンツはたくさんありますが、このように人が集まってコミュニケーションできる機会をいただけたのは、よい体験でした。
