デザインパターンとオブジェクト指向設計(カプセル化)
頼むからCovid-19インスタンスを中野クラスをスーパークラスに持つスバルインスタンスに移譲させないでくれと願う今日この頃です。
暇と退屈の倫理学のあらすじに興味深い描写があります。
時間とお金に余裕ができたら、好きなことをする。
19世紀だったら、需要(自分が好きなこと)が供給(好きなことを満たしてくれるサービス)の先に来ていたけど、
今は供給(広告が提供するサービス)が需要(自分の好きなこと)の先に来てしまっている。
「時間とお金に余裕ができたら、好きなことをする」
自分の本当に好きなことって時間とお金に余裕ができてからじゃないとできないのだろうか?
今のままだとお金に余裕ができる頃には、時間に余裕ができなくなって、結果として好きなことができないじゃないか、と2年前の新卒銀行員時代に考えていたこととリンクして、「暇と退屈の倫理学」の沼にハマっていきました。。
オブジェクト指向に対する理解を深めようとした一週間でした。
ウイルスクラスからCovid-19インスタンスが作られる。
ウイルスクラスには免疫力を下げるというメソッドがある。そして繁殖力が強い、飛沫感染するといった属性を持つ。
振る舞いとデータ、カプセル化
データは変数に入る
振る舞いは、データを扱う
この二つを一緒に格納することをカプセル化という。
カプセル化したものを設計図としてクラスに保管しておく。
ビジネスロジック
アプリケーションをプレゼンテーション・ビジネスロジック・データアクセスの 3 つに分けたとき、「プレゼンテーションでもデータアクセスでもない部分がビジネスロジック」
アプリケーションの中核をなすロジックを書く場所で、3層アーキテクチャ(プレゼンテーション層、ビジネスロジック層、データアクセス層)の一部を指している。MVCでいう、モデルとコントローラーが担う場所。
なんだか似ている用語が多くて戸惑ってしまう。
それぞれに対応するそうは下記のような画像で強引に理解することにする。
「ビジネスロジック」とは何か、どう実装するのか - Qiita
Gofデザインパターン
Rails wayに沿ってアプリの設計をしていくときに、開発者同士で共通の認識があったら効率がいい。
過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し、名前をつけ、再利用しやすいように特定の規約に従ってカタログ化したものを指しているそう。(cited: wikipedia)
このGof(gang of four)を参考にすると、オブジェクト指向型のアプリ設計がしやすくなる。
大きく下記三つのパターン分けがされていてる。
生成に関するパターン、構造に関するパターン、振る舞いに関するパターン
振る舞いに関するパターンは、クラスを設計するときに特に参考になった。