オブジェクト指向設計

輪読会メンバー Izumi Haruya github.com Sekine Yutaro github.com Abe Kaisei github.com 第9章 現実世界とソフトウェアのギャップを埋めるモデリング ステップ❶(業務分析) : 現実世界の仕事の作り方 ステップ❷(要件定義) : コンピュータに任せる仕事の範囲を決める ステップ❸(設計) : ソフトウェアをどう作るかを決める 第10章 擬人化して役割分担されるオブジェクト指向設計 設計の目標 重複を排除する ポリモーフィズム・継承・ダックタイピング DRY 部品の独立性を高める(疎結合にする) クラスの機能やメソッド命名を適切…

輪読会メンバー Izumi Haruya github.com Sekine Yutaro github.com Abe Kaisei github.com 第5章 メモリの仕組みの理解はプログラマのたしなみ OOPを使って書いたプログラム メモリの使い方に特徴があるので、メモリの使い方の理解が最低限必要になってくる プログラムのメモリ領域 メソッドエリア(静的領域) OOPで書いたプログラムは、有限のメモリ領域であるヒープ領域を大量に使う 静的領域は、従来のメモリ領域で管理する方法 メソッドエリアとは上記で説明した、ヒープ領域で管理する方法 ヒープ領域 スタック領域 ガレージコレクションとは…

輪読会メンバー Izumi Haruya github.com Sekine Yutaro github.com Abe Kaisei github.com 第4章 OOPは無駄を省いて整理整頓するプログラミング技術 ポイント OOPの基本的な仕組み 以前と比べどこが優れているのか OOPが持つ構造化言語にはない３つの仕組み クラス、ポリモーフィズム、継承がある 重複した無駄なロジックを排除し、必要な機能を整理整頓する仕組み 3つの仕組みは、構造化言語で解決できなかった「グローバル変数」と「貧弱な再利用」という2つの問題を解決するためのものである 三代要素１ークラスに関わる３つの仕組み クラス…

輪読会メンバー Izumi Haruya github.com Sekine Yutaro github.com Abe Kaisei github.com 第3章 OOPを理解する近道はプログラミング言語の歴史あり ポイント OOP以前のプログラミング言語の歴史 OOPがなぜ必要になったか OOPは必然性を持って登場した 機械語から構造化プログラミングまでの進化の歴史を振り返る なぜOOPが必要になったか 1940年代~ 黎明期には機械語でプログラムを書いていた このときコンピュータは、2進数で書いた機械語しか解釈できなかった 以下は算術計算を実行する命令であり、これを見ても直感的にわからな…

輪読会メンバー Izumi Haruya github.com Sekine Yutaro github.com Abe Kaisei github.com まえがき 旧版と比べて第3版の変更点 「オブジェクト指向がなぜ難しいのか」をより客観的な視点で説明することに注力するようになった 引用:オブジェクト指向でなぜつくるのか P10 （本書で気になる問い） モデリングとコミュニケーションを重要視する 「一見凄そう」で終わらない（理解しようとする）姿勢が大事 第1章 オブジェクト指向はソフトウェア開発を楽にする技術 この章のポイント オブジェクト指向の基本的な考え方 オブジェクト指向の全体像 オ…

輪読会メンバー Izumi Haruya github.com Sekine Yutaro github.com 第9章費用対効果の高いテストを設計する 変更可能なコードを書く為の3つのスキル オブジェクト指向設計の理解 コードのリファクタリングスキル リファクタリングとは、ソフトウェアの外部の振る舞いを保ったままで、内部の構造を改善していく作業を指します。MartinFowler『新装版リファクタリング─既存のコードを安全に改善する』（児玉公信・友野晶夫・平澤章・梅澤真史共訳、オーム社、2014） Sandi Metz. オブジェクト指向設計実践ガイド ～Rubyでわかる 進化しつづける柔軟…

輪読会メンバー Izumi Haruya github.com Sekine Yutaro github.com 第7章モジュールでロールの振る舞いを共有する 継承で解決できない問題 例えば、2つのサブクラスに共通する性質を組み合わせする際、単純な継承では解決できない 上記の場合、継承の手法を使い「ロール（役割）」を共有する解決法がある 7.1ロールを理解する 問題によっては、以前には関連のなかったオブジェクト同士に共通の振る舞いを持たせなければならない場合があり、この共通の振る舞いをクラスと直交させる役割を「ロール」という この依存関係を最小にする方法を本節で学ぶ ロールを見つける モジュー…

6月もお休みで今後を考えます。 ぺやんぐ(@peyangu485)です。 5/31、ぺやんぐ (ver 0.32.1) がリリースされました。 更新内容は以下のとおりです。 技術・開発関連 特になし ゲーム MHRサンブレイク(MR119、HR303) BF2042 地球防衛軍5(オンライン進め中) rimworld(睡眠時間泥棒) Foundation ポケモンSV(色違い探し) THE LAST SPELL(1ステージ目配信終わり) 終了 アルセウス(クリア！ 動画編集中) ポケモンウルトラサン(クリア後のRR団と伝説捕獲) 読書 途中 教養としてのコンピューターサイエンス講義(第3部) …

はじめに 共通処理クラス（Common・Util） 例: 共通処理クラス 無関係な共通処理が雑多に置かれるアンチパターン 改善例: 専用のクラスを作成する 横断的関心事 概要 例 横断的関心事は静的メソッドとして設計しても良い 参考 続く… コメント はじめに 本記事では「良いコード 悪いコードで学ぶ設計入門」で学んだ内容と別途気になって調べた内容や知識も含めアウトプットしています。 書籍に記載されている内容を順序立ててまとめるというよりは、整理しておきたい周辺の知識と深ぼった内容を雑多に書いています。 書籍ではJavaで説明されていたのですが本記事ではRubyに置き換えながら解説しています。…

はじめに デザインパターン（設計パターン） デザインパターン例 完全コンストラクタ どんな問題解決を解消するか 生焼けの解決方法 値オブジェクト どんな問題解決を解消するか 解決方法 例 参考 続く… コメント はじめに 本記事では「良いコード 悪いコードで学ぶ設計入門」で学んだ内容と別途気になって調べた内容や知識も含めアウトプットしています。 書籍に記載されている内容を順序立ててまとめるというよりは、整理しておきたい周辺の知識と深ぼった内容を雑多に書いています。 書籍ではJavaで説明されていたのですが本記事ではRubyに置き換えながら解説しています。 デザインパターン（設計パターン） ソフ…

はじめに クラスベースのオブジェクト指向設計 クラス単体で正常に動作するよう設計する 適切な初期化ロジック 正常な値のルールを定義 ガード節 参考 続く… コメント はじめに 本記事では「良いコード 悪いコードで学ぶ設計入門」で学んだ内容と別途気になって調べた内容や知識も含めアウトプットしています。 書籍に記載されている内容を順序立ててまとめるというよりは、整理しておきたい周辺の知識と深ぼった内容を雑多に書いています。 書籍ではJavaで説明されていたのですが本記事ではRubyに置き換えながら解説しています。 クラスベースのオブジェクト指向設計 クラスを定義してそのクラスからオブジェクトを作成…

サマリ 前回記事（下記）では、AdaBoostをスクラッチ実装したスクリプトを提示しました。本記事では前回記事で作成したスクリプトを、再利用性や可読性が高まるようにリファクタリングした結果を提示します。 aisinkakura-datascientist.hatenablog.com 具体的には下記の3種類の変更をスクリプトに施しました。 メソッドが単一責任になるようにした。これにより、アルゴリズムに変更が生じた際に、どのメソッドを変更すれば良いのか分かりやすくなる（再利用性が高まる）。 変数名やメソッド名を分かりやすくした。これにより、コメントをつけずともメソッドや変数が何を指し示すものかわ…

Javaのカプセル化（Encapsulation）は、オブジェクト指向プログラミングの主要な原則の一つであり、クラス内のデータを隠蔽し、不適切なアクセスから保護することを指します。カプセル化を使用することで、クラスの内部データを隠蔽し、そのデータへのアクセスを制御することが可能となります。 カプセル化は主に以下の2つのステップで実現されます： データ隠蔽: クラスのフィールド（変数）は、privateというアクセス修飾子を使用して隠蔽されます。これにより、そのフィールドはクラス外部から直接アクセスすることができなくなります。 アクセサメソッド: フィールドがprivateであるため、クラスの外…

・codewars 1問 ・写経（p.c.） ・SQL実践入門 6.3 ・オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方 4.4 やっぱりコードだよなぁ、対象が何にせよ。

⚠️注意：この記事には一般的なモノの考え方とはかけ離れたひねくれ思考が含まれています ※ この記事はプログラマー向けの内容なので、一般の方は理解不能になる怖れがあります オブジェクト指向設計をすれば プログラムが読みやすくなる、という人がいます これ、間違っていますよね？

Codewars：Array.diff ちょっとだけネットサーフィンしてた 応用数学のWikipediaとか ゲーム理論のWikipedia、めっちゃ詳しいのなんでなんだろ オブジェクト指向設計実践ガイド Rubyでわかる進化し続ける柔軟なアプリケーションの育て方 4.2 インタフェースを定義する Effective SQL 項目4 列ごとにプロパティを1つだけ格納する 関数型プログラミングの基礎 1.3 関数型モデルの残り読み SQL実践入門 第6章 結合 結合を制する者はSQLを制す 6.1 機能から見た結合の種類 AWS認定ソリューションアーキテクト - アソシエイト問題集 1問 以下は…

オブジェクト指向設計実践ガイド Rubyでわかる進化し続ける柔軟なアプリケーションの育て方 4.1 インタフェースを理解する Effective SQL 項目3 繰り返しグループを取り除く 関数型プログラミングの基礎 1.3 関数型モデル 置換ルール 体調崩したっぽい

オブジェクト指向設計実践ガイド Rubyでわかる進化し続ける柔軟なアプリケーションの育て方 5.3 ダックタイピングへの恐れを克服する / 5.4 まとめ 第4章 柔軟なインタフェースを作る 最初の文章 Effective SQL 項目2 冗長なデータを取り除く 関数型プログラミングの基礎 1.3 関数型モデル の初めの方

オブジェクト指向設計実践ガイド Rubyでわかる進化し続ける柔軟なアプリケーションの育て方 5.1 残り / 5.2 ダックを信頼するコードを書く Effective SQL 第1章 データモデルの設計 項目1 すべてのテーブルに主キーが定義されていることを確認する 関数型プログラミングの基礎 1.2 チューリング機械、命令型モデルの特徴 自分での学習の時間のような頭構成を、どう仕事で使うのがいいか、ということを、休暇明けから考えている。