メソッドの引数はオペランドのみにする原則(メソッドの引数がクラス設計に影響する) - A Day In The Life
前回に続きメイヤー著「オブジェクト指向入門 第2版 方法論・実践」で面白い原則があったのでまとめてみました(コード例はJavaで書きました)。 前提 メソッドの引数は２種類ある オペランド メソッドの操作対象であるオブジェクト オプション 操作のモード オペランドとオプションの見分け方 引数にデフォルト値を設定しておけば呼び出し側で特に指定しなくてよい引数はオプションである クラスが進化する過程においてオペランド引数は変わらないがオプションは増えたり減ったりする ※メソッド呼び出し時に引数にデフォルト値があると便利だと感じた場合やある呼び出しでは引数の指定が必要ないと感じた場合その引数はオプションである可能性が高いです。 メソッドの引数はオペランドのみにする コピー機を表す以下のクラスがあった場合。printメソッドの引数printingSize,color,numberOfCopiesは
設計要件をギッチギチに詰めたValueObjectで低凝集クラスを爆殺する - Qiita
/// <summary>契約コントローラー</summary> public class ContractController { private ContractAmount _contractAmount; /// <summary>税込金額を計算する。</summary> /// <param name="amountExcludingTax">税別金額。</param> /// <param name="salesTaxRate">消費税率。</param> /// <returns>税込金額。</returns> public int CalculateAmountIncludingTax(int amountExcludingTax, decimal salesTaxRate) { return (int)(amountExcludingTax * (1.0m + sales
関心の分離を意識した名前設計で巨大クラスを爆殺する - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名「神クラス」とも「大きな泥団子」とも呼ばれる、長大で複雑で、様々なクラスと密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、命名に関する考え方を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 巨大クラスを爆砕し、小さなクラス群に分割する。 クラス結合度を下げ、影響範囲を小さくすることで保守コストや変更コストを下げる。 ダメな例 例えばECサイトの「商品」を考えてみます。 よくありがちなのは、商品をその
Unity開発で使える設計の話＋Zenjectの紹介
ゲームの仕様書を初めて作成する人のための足掛かりのスライド ▼以下のスライドを一つにまとめました ・ゲームの仕様書を書こう１ 仕様書作成の分業とリストの作成 https://www.slideshare.net/ChizuruSugimoto/ss-173331109 ・ゲームの仕様書を書こう２ 仕様書に記載する機能内容 https://www.slideshare.net/ChizuruSugimoto/ss-173332578 ・ゲームの仕様書を書こう３ 仕様書に記載するデータと画面 https://www.slideshare.net/ChizuruSugimoto/ss-173333150 ・ゲームの仕様書を書こう４ 仕様書作成で楽をするconfluenceの活用 https://www.slideshare.net/ChizuruSugimoto/confluence-17333
Laravelで実践クリーンアーキテクチャ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事を書くにあたって Laravel について色々サポートしてくれた皆さまに向けてお礼申し上げます。ありがとうございました。 本記事はクリーンアーキテクチャに対する理解を深めていただくために、「実践クリーンアーキテクチャ」の内容を Laravel で実装して解説するという内容になっています。 記事のゴールは「クリーンアーキテクチャに対する理解を深めてもらう」というものです。つまり、この実装の形は一例に過ぎません。 はじめに 皆さんクリーンアーキテクチャはご存知でしょうか。 そう、こんな図のアレです。 The Clean Archit
オブジェクト指向できていますか？
Visual Studio Users Community Japan #1 で発表した資料になります。 https://vsuc.connpass.com/event/143114/
PHP: 静的メソッドは何のためにあるか？ - Qiita
本稿ではPHPの静的メソッドが何のためにあるかを考えるものである。 クラスとインスタンスの概念的な関係性 静的メソッドを理解するには、クラスとインスタンスの関係性を理解していなければならない。 クラスとインスタンスの関係は何だろうか？ 一言で言えば、クラスは、複数のインスタンスの集合である。概念的な集合であって、インスタンスの配列という意味ではない。例えば、$user1のオブジェクトと$user2のオブジェクトを総じて、Userと呼べるのは、Userが$user1と$user2の集合だからだ。 以上の集合論的な観点を踏まえると、静的メソッドは何のためにあるかといえば、集合に含まれるすべてのオブジェクトに共通した処理(公理ともいう)を記述するためにあると言える。 逆を言えば、集合の一要素にすぎない$user1にのみ関係する処理は静的メソッドにはならない。Userクラス(ここまで読んだみなさん
オブジェクト指向は禁止するべき - きしだのHatena
プログラムがまだ不慣れな人が「プログラムちょっとわかるようになったけど、まだぜんぜんオブジェクト指向とかできてません」のように言ったり、ちょっと慣れた人が「このソース、ぜんぜんだめ。オブジェクト指向ができてない」にようなことを言ったり、まるで、オブジェクト指向ができてるかどうかがよいプログラムかどうかを表すことになってるようだ。 Javaのアルゴリズムの本に、「Javaなのにオブジェクト指向ができていない」のような書評がついているのを見たときには、お前は何を求めてるんだと思ったりもした。 そのようなオブジェクト指向は、窓から投げ捨てるべきだ。オブジェクト指向はプログラムのよしあしの基準にならない。 むだにHogeインタフェースとHogeImplクラスがあったり、むだにnewするだけのcreateメソッドがあったり、どこで値が設定されてるかわからないオブジェクトがひきまわされてたり、ソースコ
いまさら聞けない「オブジェクト指向設計の3つのコツ」～オブジェクト指向設計問題解説 #objectoriented - CodeIQ Blog
CodeIQ中の人、millionsmileです。 いろいろ経歴を積むと、「いまさら聞けない」ことが増えてきます。「オブジェクト指向」というのもそんないまさら聞けないものの一つでしょうか。 そんなわけで、いまさら聞けないことをイマサラ問題として出題してみました。 問題は、日本のITエンジニアの父と言いたくなるくらい温かみのあるフィードバックをしてくれることで好評な有限会社システム設計の増田亨さんからの出題です。オブジェクト指向設計について2問出題していただきました。総計65名もの方に挑戦いただきました！ 問題の解説記事は、オブジェクト指向設計の3つのコツを中心に説明してくれていますので、読みやすいですし、頭にすっと入ってきます。 ではでは、増田亨さんによる解説記事をお楽しみください。 https://codeiq.jp/ace/toru_masuda/ ◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇
必須のプロパティをコンストラクタで受け取る設計にすべきか？
しゃるしぃ @chocolamint 「オブジェクトが使用可能になるまでに追加でプロパティに値をセットする必要がないように設計する。」は結構微妙。コンストラクタの引数でセットにするとオブジェクト初期化子に比べて見づらいし、デフォルトコンストラクタが消えると何かと不便。絶対必要なプロパティなら1回動かせばわかるわけだし 2013-02-15 13:31:29 しゃるしぃ @chocolamint 引数が増えるならクラス化すればいいってことになるとなおさら微妙。だってHogeArgumentsクラスのプロパティをセットしなかったら一緒やん。 2013-02-15 13:32:15
状態管理用の変数をインスタンスに持たせるなこのタコって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
たとえば、今、「ユーザーが方向を入力したらプレイヤーが動くゲーム作りたい」みたいなはなしがあるとする。その場合、モデルクラスはまあシンプルな実装として下のようなものが考えられると思う。 「できたよー」って見せにいったら、今度は「あのさー、『高速移動モード』っていうモード欲しいんだよね。そのモードだと二倍速で動くの」って言われたとする。シンプルにやるとこうなりますね。 「できたよー」って見せにいったら、今度は「なあ、すげえ面白いこと考えたんだけど、『蟹モード』って面白くない？横は4倍速で動くんだけど縦は半分の速度で動くの」とか言われたわけです。あなたは「お、おう」と言って、以下のようにコードを修正しました。 これ、ヤバい感じしますね。破滅の匂いがする。「今度は『よっぱらいモード』欲しいな〜。入力に関係なくランダムに動くの」みたいなこと言われたら確実に複雑さが爆発してメンテ不能になり鬱になり死
デザインパターン厨よ、これが黄金の回転だ - @ledsun blog
状態管理用の変数をインスタンスに持たせるなこのタコって話 に面白い機能追加とリファクタリングの例がありました。TDDに慣れ親しんだ身からすると、 「黄金の回転のリズム」 テストを書く テストが通る最低限のコードを書く リファクタリング に比べると、リファクタリングのサイクルが大きいなと感じたので自分もやってみました。 元のクラス シンプルなmoveメソッドで移動方向に動くPlayerクラス*1 機能追加1 二倍速 2倍速で動くようにしたい 二倍速く動くなら二回 move すればよい サブクラスFastPlayerを追加して実現。 機能追加2 カニ 横は4倍速で動くんだけど縦は半分の速度で動く KaniPlayerクラスを追加してとりあえず機能を実現 class KaniPlayer < Player def move(direction) case direction when :up @
Getter/Setterを避けて役に立つドメインオブジェクトを作る - かとじゅんの技術日誌
Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んでます。モデリングに関しては成分薄めですが、よい本だと思います。はい。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 作者: Robert C.Martin,角征典,高木正弘出版社/メーカー: KADOKAWA発売日: 2018/07/27メディア: 単行本この商品を含むブログを見る 本書の大筋から少し逸れるが、「5章 オブジェクト指向プログラミング」の「カプセル化」が面白かったので、これを切り口にモデリングについて考えてみる。 OO言語のカプセル化はすでに弱体化している オブジェクト指向の三大要素の一つである、カプセル化について、以下のようなことが書いてあります。 「カプセル化」がOOの定義の一部となっているのは、OO言語がデータと関数のカプセル化を簡単かつ効果的なものにしているから
リスコフの置換原則
それらは、先人達がオブジェクト指向を研究したり実践したりしていく中で、発見されてきたものです。 どれも、オブジェクト指向を正しく利用するためには非常に重要なことですので、今後順次解説していきます。 今回は、リスコフの置換原則のお話です。 英語で言うと "the Liskov Substitution Principle" ということで、LSP と略されたりします。 コンテンツ 例えれば職能 あなたの羅針盤 実際のはなし 契約 犯罪者 ポリモーフィズムの羅針盤 オススメ リスコフの置換原則…と聞くとまず思うのが、「リスコフ」ってなに？ということだと思います。 はい、「リスコフ」というのはこの原則を提唱した人の名前です。 「そういう名前の人が言い出したんだな」とだけ思っとけば OK です。 そうすると、肝心なのは「置換原則」ってとこだけですね。 じゃあ、何と何を置換するでしょう？ はい、スーパ
オブジェクト指向設計原則とは - Qiita
はじめに オブジェクト指向の設計原則を説明します 勉強内容のアウトプットです 単一責任の原則 単一責任の原則は非常にシンプルな内容で、「1つのクラスに1つの役割(機能)」と言うものです。 これはカプセル化で強く言われる「小さなカプセル」ということに通じます。 ただ、この「1つのクラスに1つの役割」という考え方は正しいのですが、コレを正確に運用するのは非常に難しいです。運用が難しいというのは「1つのクラスに1つの役割」という言葉を指針としてしまうと思わぬ間違いを生むということです（言葉自体は正しいが、人間はアホなので間違っちゃうのです） そこで、クラスの妥当性をチェックするために別の角度から眺める必要が出てきます。この時の言葉が 「クラスを変更する理由が2つ以上存在してはならない」 という言葉です。この言葉は単一責任の原則の話で重要となる言葉ですので、覚えておいてください。 さて、あなたはあ
グローバルゲームジャムでクラス設計をやった話2017 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? お知らせ 2017/11/26開催の「プログラマのためのUnity勉強会」において、 Unity開発で使える設計の話＋Zenjectの紹介 というタイトルで講演しました。こちらのスライドを先に見てから本記事を参照されることをおすすめします。 はじめに 去年に引き続き、今年もGGJに参加してきました。今回もそのことを書きたいと思います。 今回の内容は以前に投稿したUnity開発で便利だったアセット・サービス紹介 & Unityでのプログラミングテクニックとつながりがあるので、こちらを先に読んでからのほうがわかりやすいかもしれません。 Gl
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHP: Builderパターンの実装手順 #1【基礎実装】 - Qiita
ポリモーフィズムを活用するとなぜ if や switch が消えるのか？ - Qiita
trait と abstract class の使い分け
【Effective Java】項目15 可変性を最小限にする - tatsuyamukuの日記