7つの設計原則とオブジェクト指向プログラミング - ソフトウェア設計を考える

設計原則はよい設計をするための指針です。 では、よい設計とはなんでしょうか？ もっとも重要なソフトウェア品質は発展性 ソフトウェアの発展性がビジネス価値を生む 発展性をうみだす７つの設計原則 モジュール化 モジュール化の２つのアプローチ 型によるモジュール化 手続き的なモジュール化 関心の分離 関心の4象限 入出力と計算・判断の分離 業務の関心と実装の詳細の分離 もっとも複雑な関心事（ビジネスロジック）の分離を徹底する カプセル化と抽象化 カプセル化 ビジネスロジックのカプセル化 抽象化 データ抽象 ビジネスロジックとデータ抽象 高凝集と疎結合 凝集度 結合度 隠された結合性の問題 定義の一点性 見た目が同じコード 7つの設計原則の学び方 コードの実装例 ドメインオブジェクト設計のガイドライン 実践ガイドとして使える本 設計の考え方を理解するための本 もっとも重要なソフトウェア品質は発展性

[j5ik2o]

“ボトムアップに組み立てていくのが、オブジェクト指向プログラミングの基本アプローチ”経験則的に、OOPでうまく設計できないと言っている人たちはトップダウンでやろうとしている人たち多い

[baca-aho-doji]

こういう勉強全くやらなくっなってしまった…プログラミングする時間がほしい。

[overflow33]

モジュール化、カプセル化、抽象化、とイマイチ意味のわからなかった単語が何となくわかった気がする。ありがたい。

[ichiken7]

モジュール、クラス、サービス、単位は違えど担う機能をシンプルに保つことが高い品質と保守性を確保する。利用者や自分自身の「もっと」「あれも」「この時も」の要求に応えたくなるのをグッと我慢するかが重要。

[wa_kanou]

モジュール化の勉強をしなくては…

[tfurukaw]

まさに今、こんな記事を探していたところでした！

[t-murachi]

良いテキストだと思う。ただ、ここに目安として書かれている判断基準も、鵜呑みにしてはいけない。設計の意図が説明できることが第一であり、リファクタリングはその先に見えてくるものだから。

[rryu]

確かになんでこんなめんどくさいことをやるのかというと全ては発展性の為だなあ。あと何回かブロックを積み増しできるようにする術が設計手法という感じ。

[fuyu77]

勉強になった。業務のRailsがもの凄くスケールして複雑怪奇になりました（+カオス過ぎるフロントエンド）みたいなOOPはここに書かれてるような原則とはかけ離れているけれど、設計の要所で意識してみたいなと。

[diveintounlimit]

うーん、普通のことが書いてあるなと思った。

[dskst9]

外部品質と内部品質

[nc44v-134-nvtyqfgq]

良い。

[Magicant]

最近は増田さん位しかこの様な話題を書く人が居なくなってしまった……

[hara_boon]

基本情報とかでも疎結合がどうとかはやったけど、ちんぷんかんぷんで、ここまでちゃんと説明されてもぼやっとしかわかんないから、結局自分で手を動かして見ないと理解できないんだろうな

[kei_0000]

基準: 合目的性・安定性・発展性 設計原則: (中心)モジュール化 / 関心の分離 / カプセル化・抽象化 / 高凝集・疎結合 / 定義の一点性 「凝集度」関係性の高い要素の集まり

[Babax]

確かにモジュール化の勉強を...。

[qtamaki]

こうしてみるとオブジェクト指向の方法論には本質から外れたノイズを感じる

[noukomakuta]

読めたら読む

[kastro-iyan]

安心と信頼の無言ブクマ

[PrivateIntMain]

7つの設計原則の図の、モジュール化より上の部分はトップダウンで、下の部分はボトムアップで。どちらか片方だけやればよいのではなく、上下両方から考えるべき。一人でやることではない。話し合うこと。

[Keisuke69]

あとで読む

[yawn_yawn_yawn]

実装例でjavaのgithubが載ってる

[bluescreen]

難しそう。。。

[tinsep19]

手続き的なものはドメインオブジェクトの操作なのでフレームワークには従ってもモジュールにはならんと思うんだよね。