関心の分離を意識した名前設計で巨大クラスを爆殺する - Qiita
大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名「神クラス」とも「大きな泥団子」とも呼ばれる、長大で複雑で、様々なクラスと密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、命名に関する考え方を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 巨大クラスを爆砕し、小さなクラス群に分割する。 クラス結合度を下げ、影響範囲を小さくすることで保守コストや変更コストを下げる。 ダメな例 例えばECサイトの「商品」を考えてみます。 よくありがちなのは、商品をそのまま「商品クラス」と設計してしまうこと。 単純な商品クラスは、往々にして出品、予約、注文、発送など、様々なユースケースのクラスと結合してしまいがちです。 商品クラス自体も、結合したクラスに関連する知識(ロジック)を持ち始め、どんどん巨大化複雑化していきます。
同僚のコードレビューでこんなにクラスの設計が良くなったという話 - Qiita
弊社では、案件とは関係のないプロジェクトでも業務時間中にみんなにコードレビューを依頼できる時間が確保されています(参加は任意)。案件のコードレビューを依頼したり、ちょっとした個人の制作物を見てらったりと使い方は色々です。 先日、TypeScriptの練習にQiitaのAPIを叩いていて記事を表示するブログウィジェットを作成しました。このウィジェットのレビューを依頼したところ、クラスの設計について具体的な指摘と、それに対する改善を経験できたのでこの記事に記載します。 今回作ったQiitaWidgetの要件 Qiitaの公式APIV2から記事とユーザー情報を取得し、HTMLテンプレートに表示する 投稿の合計いいね数を算出するために、あるユーザーの投稿を全件取得する (このために複数回リクエストの送信とレスポンスデータの結合を行う) パラメータによってユーザー、いいね数によるソート、表示件数、ラ
現場で役立つシステム設計の原則で個人的に面白かったところメモ - Qiita
『現場で役立つシステム設計の原則』という本を付箋を付けながら一通り読んだ?ので 個人的に面白かったところを自分用にメモしておきます。 本当にメモです。 本質とはだいぶ違うところだと思うので買って読んで下さい。。 (付箋はつけていたけどうまく説明できなさそうなところは消しました。) 目的ごとに変数を用意する 段落わけと、目的ごとの変数で分かりやすい。 一度作った変数を変更するのを破壊的代入といい、それをなくすことでコードが安定するそうです。 int basePrice = quantity * unitPrice int shippingCost = 0 if (basePrice < 3000) { shippingCost = 500 } int itemPrice = ... コレクション型を扱うロジックを専用クラスに閉じ込める これをコレクションオブジェクトやファーストクラスコレクシ
Rubyで親クラスから子クラスの定数を参照
— 環境 — Ruby 2.2.2 Rails 4.2 ※ 2015/11/12 記事の末尾に追記しました。 リファクタリング前のコード 単純化してますけど、具体的には以下のようなサンプルで、最初に書いたのが次のようなコード。 class Person def initialize(name, age) @name = name @age = age end def get_old @age += 1 end end class Female < Person MARRIAGE_AGE = 16 def marriageable? @age >= MARRIAGE_AGE end end class Male < Person MARRIAGE_AGE = 18 def marriageable? @age >= MARRIAGE_AGE end end taro = Male.new('
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://harold-spm.com/programmer-kyoutuuten/
