読者です 読者をやめる 読者になる 読者になる

memorandums

日々のメモです。

オブジェクト指向エクササイズ

programming

ちょっと古いネタですが。。。たまたま見つけた以下のslideshareを見て感動。

よく見ると序盤の元ネタ本は見覚えが。

ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション

ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション

2章のRubyでの内部DSLの実装方法が読みたくて買った本でした。

その5章に上記のプレゼン中で紹介されていた標題の章がありました。ゼミ室にあったので読み返してみました。

ちょっと横道に逸れて。。。

モジュール分割。。。難しいですね。オブジェクト指向でいうところのどのデータをどの機能をクラスに持たせるか。典型的な例を使って授業はできても、では、実際の案件でその知見はいつどこで適用すればいいんだろう?はわからない。モジュールの良さを評価する指標はないわけではないけど、リポジトリマイニングして開発後にわかってもありがたくも何ともない。構築中に支援してくれないと意味がない。企業における実際のOJTなどはどのように進めるのでしょうか。クラスへの責務割当など経験を積んで失敗から感覚的に学ぶものだ。。。以外に明快なソリューションはあるのでしょうか。

それはさておき話を戻して。

何も考えずに実装すると巨大な何でも屋クラスができてしまうので、それを強制的に食い止めようというのがこのエクササイズの目的のようです。以下の9つのルールにしたがって1000行程度のソフトウェアを書いてみなさい、とのことです。より詳しくはQiitaで紹介されています。

  1. 1つのメソッドにつきインデントは1段階までにすること
  2. else句を使用しないこと
  3. すべてのプリミティブ型と文字列型をラップすること
  4. 1行につきドットは1つまでにすること
  5. 名前を省略しないこと
  6. すべてのエンティティを小さくすること
  7. 1つのクラスにつきインスタンス変数は2つまでにすること
  8. ファーストクラスコレクションを使用すること
  9. Getter、Setter、プロパティを使用しないこと

プログラミング演習の序盤では、2重ループを書いたり、変数名を1文字で書いたり、カプセル化=Getter/Setterを書くことだとか、やってますが。学びには段階がありますからしかたがありません。でも、どこかのタイミングでこういうような演習を取り入れてみたいです。

要求仕様を実現する方法をイメージして部品を考えて作り出し、それらを組み合わせて形にしていく。実体はないけどソフトウェアは精密機械のような製品。物理法則、材料力学、化学・電気特性は関係ない。あるのはコンピュータやネットワークの性能の制約。自由度がある分、考えるのは大変ですが、そんな自由度がある試行を楽しいと思える人に向いている仕事と思います。Software Developerは。3Dプリンターの登場により、個人でも部品を簡単に製造できる時代と言われていますが、ソフトウェアはもとから自作部品で製品を作り上げてきた。そういう世界だと思います。