英語で読む「達人プログラマ#5」
5章のタイトルは「Bend, or Break」つまりプログラムを捻じ曲げるか壊すかというテーマ。なんだか物騒な感じだ。
The Law of Demeter for functions attempts to minimize coupling between modules in any given program. It tries to prevent you from reaching into an object to gain access to a third object's methods.
デメテルの法則が出てくる。デメテルさんという人がいるのかと思ったら、豊穣の女神の名前だった。モジュール間のcouplingを最小にし、third objectへのアクセスを防ぐ。あるオブジェクトから直接呼び出しするobjectまではOKだが、隣の隣（３番目）はNGということだろうか。
Using The Law of Demeter will make your code more adaptable and robust, but at a cost: as a "general contractor," your module must delegate and manage any and all subcontractors directly, without involving clients of your module. In practice, this means that you will be writing a large number of wrapper methods that simply forward the request on to a delegate.
柔軟で堅牢だが、建築におけるゼネコンがサブコンに委託する際にコストは高くつく。ラッパーを大量に書かないといけないからだ。
We want to configure and drive the application via metadata as much as possible. Our goal is to think declaratively (specifying what is to be done, not how) and create highly dynamic and adaptable programs. We do this by adopting a general rule: program for the general case, and put the specifics somewhere else—outside the compiled code base.
別の章ではメタデータを使うことを推奨している。howを書くのではなく、what（何が実行されるか）を書くのがゴール。前の章の契約プログラミングの話にも通じる。
Obviously, we don't want to have three separate copies of the data. So we create a model—the data itself, with common operations to manipulate it. Then we can create separate views that display the data in different ways: as a spreadsheet, as a graph, or in a totals box. Each of these views may have its own controller. The graph view may have a controller that allows you to zoom in or out, or pan around the data, for example. None of this affects the data itself, just that view.
有名なMVCの話も出てくる。例としてExcelのようなスプレッドシートを作る場合、スプレッドシート自身のほかに、グラフやダイアログボックスがあるので、データ自身とビューを分離しようという話。
前の章は言語仕様に深入りするようだったのに対し、今回は各言語で導入しやすいレイヤーという印象だ。２章を読んだときも、まるでRuby on Railsのコンセプトを読んでるんじゃないかと錯覚したが、今回の５章からも同じような印象を感じた。もしかしてRubyプログラマは必読？
この記事が気に入ったらサポートをしてみませんか？