Download to read offline
Fizzbuzz solid
- 1.
- 3.
- 4.
- 5.
- 6.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15. その前にFizzBuzzの仕様について考えてみた FizzBuzzにおいて変更されうる仕様は下記の通りと定義した 1. それぞれのルール 例）３で割り切れる場合はFizz →３で割り切れる場合はBizz 2. ルールの組み合わせと順序 例）３で割り切れる場合はFizz、５で割り切れる場合はBuzz → ３で割り切れる場合はFizz、５で割り切れる場合はBuzz、７で割り切れる場合はBizz 例）３で割り切れる場合はFizz、５で割り切れる場合はBuzz、３と５で割り切れる場合はFizzBuzz → ３で割り切れる場合はFizz、５で割り切れる場合はBuzz、３と５で割り切れる場合はBuzzFizz 3. 入力 例）１〜１００の数値に対して処理を行う → １〜２００の数値に対して処理を行う 例）１〜１００の数値に対して処理を行う → 配列の各要素に対して処理を行う 4. 出力 例）画面出力 → ファイル出力
- 17.
- 18. （再掲）FizzBuzzの仕様について考えてみた FizzBuzzにおいて変更されうる仕様は下記の通りと定義した 1. それぞれのルール 例）３で割り切れる場合はFizz →３で割り切れる場合はBizz 2. ルールの組み合わせと順序 例）３で割り切れる場合はFizz、５で割り切れる場合はBuzz → ３で割り切れる場合はFizz、５で割り切れる場合はBuzz、７で割り切れる場合はBizz 例）３で割り切れる場合はFizz、５で割り切れる場合はBuzz、３と５で割り切れる場合はFizzBuzz → ３で割り切れる場合はFizz、５で割り切れる場合はBuzz、３と５で割り切れる場合はBuzzFizz 3. 入力 例）１〜１００の数値に対して処理を行う → １〜２００の数値に対して処理を行う 例）１〜１００の数値に対して処理を行う → 配列の各要素に対して処理を行う 4. 出力 例）画面出力 → ファイル出力
- 19.
- 20. 2. ルールの組み合わせと順序 ルールが追加、削除された時に既存のルールは影響を受けない またChain ofResponsibility パターンを採用しているためルールの適応順序は自由に定義できる
- 21. （補足）Chain of Responsibilityパターン Chain of Respoisibility パターンとは、「責任」を負ったものが、「鎖」状につな がれた状態をイメージさせるパターンです。 それぞれのクラスには次に適応すべきクラスのインスタンスをフィールド変数と して持ちます http://www.techscore.com/tech/DesignPattern/ChainOfResponsibility.html/
- 22. （補足）Chain of Responsibilityパターン それぞれのルールはAbstractRuleクラスを継承しており、AbstractRuleクラスはフィールド変数に AbstractRuleクラスのインスタンスもしくはnullを$nextRuleとして保持します それぞれのルールは自身の責務を行なった後に$nextRuleがAbstractRuleクラスのインスタンスであれば、 そのルールに責務を移譲します
- 23. （補足）Chain of Responsibilityパターン 例えば3の倍数はFizz→5の倍数はBuzz→7の倍数はBizzの順番でルールを適応する（105の時に FizzBuzzBizzと表示させたい）のであれば 1. BizzRule->$nextRule=null 2. BuzzRule->$nextRule=1で定義したインスタンス 3. FizzRule->$nextRule=2で定義したインスタンス とすればFizz→Buzz→Bizzの順番でルールが適応される
- 24.
- 25.
- 26.
- 27.
- 28.
- 29. 全てのクラスはインターフェースに依存しているので、例えばFizzRuleクラスを改修した時にFizzBuzzクラ スも改修を行う必要がある、といったことは無い また何らかの理由があってChain of Responsibilityパターンの採用を見送る必要があったとしてもIRuleは変 更されないのでFizzBuzzクラスが影響を受けるといったこともない
- 30.
- 31.
- 32.
- 33.
- 34. インターフェース分離の法則 インターフェース分離の法則は「クライアントに、クライアントが利用しないメ ソッドへの依存を強制してはならない。」という法則です 例えば、以下のようなコードがあったとします。 interface ultraSuperDeluxeGreateBigSugoiEngine { void Departure(); voidPlayMusic(); void CallYourGirlFriend(); //その他いろんな機能 } この時、「このインターフェースを継承したクラスのPlayMusicメソッドを変更 した場合に他のメソッドも修正する必要がある」という問題点があります https://qiita.com/UWControl/items/98671f53120ae47ff93a
- 35.
- 36. Iteratorを実現したクラスではrewind(), current(), key(),next(), valid()の定 義を行う必要がある CountUpIteratorは$positionが$max以下の間、インクリメントを続けるイ テレーターである。そのためcurrent()の定義は不必要である（正確にい うとcurrent()とkey()は同じ内容となる） そもそもIteratorインターフェースとは何か？ PHP 5 は、たとえば foreach 命令などによる反復処理を可能とするよう オブジェク トを定義する手段を提供します。 デフォルトで、 全ての アクセス権限がある プロ パティは、反復処理に使用することができます。 1~100の間、$positionが$max以下の間、インクリメントを続けるってイ テレーターなのか？ http://php.net/manual/ja/language.oop5.iterations.php
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46.