久々に
経理の仕事において、四半期決算ってのは本当に大変なお仕事で、ほぼ1ヶ月持っていかれます。
翌月はそのリカバリでボーッとしているという感じでした。
(これはどうにかして負荷を軽減したいところ・・・)
その余波で「良いコード/悪いコードで学ぶ設計入門」を読み進めるのもすっかり止まってしまい、また書き方もだいぶ忘れてしまった・・・んですが、こういう時にちゃんと学習記録を書き残してあると安心ですね。
11章はコメントってことで、コード少なめ文章多めという感じです。
コードも Perl で書き直すほどのものではないという感じなので、サクサク読んでいきます。
11章 コメント
11.1 退化コメント
- 情報が古くなり、実装を正しく説明しなくなったコメントを退化コメントという
- コメントは(コードの)劣化コピーにすぎないので、意図が通じるクラス名の命名などが必要
- ロジックの挙動をなぞるだけのコメントは退化しやすい
11.2 コメントで命名をごまかす
- すごい文字数のメソッドが出てくる
- 書き写したくない
- メソッドの可読性を上げるとで、説明のコメントが不要になる
11.3 意図や仕様変更時の注意点を読み手に伝えること
- 意図や指標変更時の注意点をコメントしよう
11.4 コメントルールのまとめ
11.5 ドキュメントコメント
- ドキュメントコメント?って思ったけど、Perl だったら POD 、JavaScript だったら JSDoc みたいなものを言うらしい。知らんかった
12章 メソッド
12.1 必ず自身のクラスのインスタンス変数を使うこと
12.2 不変をベースに予期せぬ動作を防ぐ関数にすること
- オブジェクトのプロパティ書き換えるときも新しいプロパティ作ってそれを返す、みたいな感じかな
12.3 尋ねるな、命じろ
- あるクラスがよそのクラスの状態を判断したり、状態に応じてよその値を変更したりするのは低凝集構造
- getter / setter が多用されているコードはその状況になりやすい
- メソッドの呼び出し側で複雑な処理をするのはでなく、呼び出される側で制御をするよう設計する
12.4 コマンド・クエリ分離
- 初めて聞く
- メソッドはコマンド(変更)、またはクエリ(問い合わせ)のどちらか一方だけを行うよう設計する
- コマンドとクエリを同時に行うメソッド種別をモディファイアという
- 知らんかった
- モディファイアはなるべく避ける
- そろそろコード書きたくなってきたので書いてみる
#!/usr/bin/env perl use strict; use warnings; use feature qw/say/; use Function::Parameters; fun gain_and_get_point($point){ my $point += 10; return $point; } # モディファイア my $origina_point = 0; my $modifier = gain_and_get_point($origina_point); say $modifier; # 10 # コマンド・クエリ分離 fun gain_point($point){ $point += 10 } fun gat_point($point){ return $point; } my $gain_pint = gain_point($origina_point); say gat_point($gain_pint); # 10
12.5 引数
- 引数は不変にすること
- フラグ引数は使わない
- 切り替え機構はストラテジパターンを利用する
- null を渡さない
- 例)未装備状態を null ではなく、 Eqipment.EMPTY で表現する
- 出力引数を使わない
- 引数は限りなく少なくする
12.6 戻り値
- 型を使って戻り値の意図を表明すること
- プリミティブ型を使わず、独自の型を使って戻り値の意図を明確に表明する
- 引数に null を渡さないように、null を返さない
- エラーは戻り値で返さず、例外にする
と、12章はここまで。次の13章も文章が多い感。