『ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用』は、現代ソフトウェア開発の”知の高速道路” - Magnolia Tech
ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用 作者:田中 ひさてる技術評論社Amazon 予約してまで買ったものの、なかなか時間が取れず、読めていなかった『ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用』をようやく読み終わりました。 筆者である田中ひさてるさん自身で描かれた表紙の可愛らしさからは想像もできないハードな内容なので、一気に読もうとすると「分かった気」になるだけで全然理解していなかった、ということになりがちなので、3回くらいぐるぐる読むといいと思います（そうです、この本は本文もイラストも丸っと同じ人が書いているのです！！）。 目次 第1章 クリーンアーキテクチャ 第2章 パッケージ原則 第3章 オブジェクト指向 第4章 UML（統一モデリング言語） 第5章 オブジェクト指向原則 SOLID 第6章 テスト駆動開発 第7章 依存
変化が激しく脆いドメインで技術的負債を増やさない設計
はじめに ソフトウェア設計についてのポエム。 それも、ドメインが短期的なサイクルで大きく変化をしてしまうような領域での。 僕が携わる領域、つまりメディアサイトでのSEO施策を反映するシステムでの経験を念頭にしている。 結論から言えば、ビルド・アンド・スクラップを可能にしようという話です。 「変化の激しく脆いドメイン」とは？ 問題の解決策のコアとなる部分が頻繁に変わるドメインのこと。 特にプロダクトのライフサイクルよりも早く変わるドメインのことを指したい。 僕が携わっている「Webメディア」というのも、この変化の激しく脆いドメインに当たると思う。 Webメディアにおける開発では、SEOやUXについて考慮することは避けることはできない。 しかし、SEOやUXは頻繁に変わるGoogleのアルゴリズムやユーザの嗜好によって正解が変わっていく。 一年前に正解だったものが、次の年にはただの技術的負債に
「オブジェクト指向設計実践ガイド」がすごくよかった - takanamitoのブログ
普段RailsでWebアプリを作っていて、いつクラスを作るべきか、どんなインターフェイスを作るべきか、そもそもよい設計やコードとは何なのかよくわからなくなっていた。 同僚に相談したらこの本を勧められて2017年に1回途中まで、年明けにもう1回全部通して読み直したのでいったんまとめる。 オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方 作者: Sandi Metz,?山泰基出版社/メーカー: 技術評論社発売日: 2016/09/02メディア: 大型本この商品を含むブログ (1件) を見る この本を読んでなおいろんな機能が詰まりまくったServiceクラスを作るPullRequestを出した自分に 丁寧にapp/models以下に単一責任の原則に基づいたプレーンなクラスを作って、ドメインモデルを表現するコードレビューをしてくれた同僚がいた。 ちょ
ゲーム(FEH)におけるダメージ管理で学ぶメソッド設計 - Qiita
RPGやSLGの多くでは敵味方キャラクター間の戦闘が発生し、お互いにダメージを与えHPを削りあいます。 この時に能力値をパラメータとしてダメージを計算することになるのですが、これがゲームバランスやギミックの要求により結構面倒な計算式になったりしますので管理しやすい設計を考えます。 １．FEHのダメージ計算 例としてFEH（ファイアーエムブレムヒーローズ）を挙げます。言語はKotlinですがKotlin特有の記述はそんなに使わないはずなので誰でも読めるかと思います。 data class Hero(var hp: Int, var atk: Int, var spd: Int, var def: Int, var res: Int, var weapon: Weapon) FEHの能力値はHP,攻撃、速さ、守備、魔防の4種類です。武器には物理攻撃と非物理攻撃がありisMaterial()など
インターフェースとは？～継承とは役割が違う～｜オブジェクト指向プログラミング(OOP)をおさらいしよう（３） - GiXo Ltd.
「インターフェース」を理解する上で「継承」の事は忘れてください こんにちは。技術チームの岩谷です。前々回、前回とオブジェクト指向プログラミング(OOP)をおさらいする連載を書かせていただいています。今回は第三回として、前回の継承機能と並んでOOP言語が持つ特徴的な機能の一つである「インターフェース」について説明します。私は最初にJavaに触れた時に「継承とインターフェースの違い」に戸惑いましたが、それはインターフェースの役割を理解していなかった事が原因でした。今回の記事で私は皆さんにそれをお伝えしたくて、あえて極端な表現を用いながら説明させていただきます。 まず申し上げます、 インターフェースを理解する上で、とりあえず「継承」の事は忘れてください。 「インターフェースと継承との違い」を考えないでください。これが頭にあると理解の邪魔になってしまうのです。 インターフェースは「このクラスは、○
新入社員 コード設計の改善体験談 | QUARTETCOM TECH BLOG
10月に入社した開発部の澤井です。現在、新人研修を受けています。カルテット開発部では、新人一人に対して教育担当者が二人もつきます。（とても贅沢です） ところで、皆さんはコード設計についてどのような考えをお持ちでしょうか。私は現在、新人研修を通してより良いコード設計について学ぶ日々ですが、残念ながら「これが良いコード設計です」と言えるだけの知識はまだありません。 そこで本エントリーでは、新人研修で取り組んだ問題を例にして、実際に自分のコードがどのように変化していったのかを書くことで、私が新人研修を通して学んだこと、考えたことをお伝えできればと思います。 取り組んだ問題：「群島の宝探し」 これは、教育担当の後藤が作成したオリジナル問題です。大まかなルールは以下のとおりです。 群島はスタートとゴール、およびA島〜E島の5つの島からなる プレイヤーは1回〜複数回サイコロを振り、スタートからゴールを
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向では、モデリング（分析）、設計、実装は、切れ目のない一体の活動。初期の分析は初期の設計であり、初期の実装。毎日分析し、毎日設計し、毎日実装しながら、一歩一歩、モデルも実装も進化させていく。Read less
契約による設計の紹介 - Hatena Developer Blog
こんにちは、チーフエンジニアの id:hakobe932 です。 はてなでは毎週、社内技術勉強会を開催しています。先週の勉強会では現在開催中のはてなインターン2016の参加者のみなさんもインターン生も参加して、いっしょに技術交流を行いました。 このエントリでは、そこで発表した、契約による設計の紹介をしたスライドを公開します。 契約による設計はBertrand Meyer氏によるオブジェクト指向入門*1という書籍で紹介されている考え方です。 オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング) 作者: バートランド・メイヤー,酒匂寛出版社/メーカー: 翔泳社発売日: 2007/01/10メディア: 単行本（ソフトカバー）購入: 11人 クリック: 307回この商品を含むブログ (130件) を見る 契約による設計で
リファクタリング: デメテルの法則(Law of Demeter, LoD) - Rails Webook
Photo by Wonderlane | Flickr - Photo Sharing! デメテルの法則について勉強したのでまとめてみました。間違っているかもしれませんのでコメントいただけると助かります。 目次 デメテルの法則とは デメテルの法則に反している例 デメテルの法則の適用 まとめ 1. デメテルの法則とは wikipediaより引用 デメテルの法則 - Wikipedia デメテルの法則 、または最小知識の原則とは、ソフトウェアの設計、特にオブジェクト指向プログラムの設計におけるガイドラインである。 簡潔に言うと「直接の友達とだけ話すこと」と要約できる。 あるオブジェクトAは別のオブジェクトBのサービスを要求してもよい（メソッドを呼び出してもよい）が、オブジェクトAがオブジェクトBを「経由して」さらに別のオブジェクトCのサービスを要求してはならない。 これが望ましくないのは、オ
オブジェクト指向とは何なのか考えてみた - Flat Leon Works
オブジェクト指向の概要 オブジェクト指向の位置づけ 命令型から手続き型へ、そしてオブジェクト指向へ オブジェクト指向+αでメリットが出てくる (おまけ)良質なプログラミングとは何か まとめ オブジェクト指向とは何なのか考え抜いてみました。 オブジェクト指向の概要 用語の位置づけプログラミング(プログラム設計)の手法 用語の意味オブジェクトへのメッセージ送信でプログラミング(プログラム設計)を行うこと なぜ使われるのか1.手続き型プログラミングより自然な考え方になるから 2.プログラミング言語の機能によるサポート次第でより便利になるから 3.設計の工夫で良質なプログラミングが可能になるから オブジェクト指向の解説がわかりにくくなっているのは、「オブジェクト指向自体の解説」と「オブジェクト指向をより便利にする言語機能の解説」と「オブジェクト指向でよりよいプログラミングを行うための手法の解説」が
オブジェクト指向プログラミングにおいてユーティリティクラスに代わるもの | To Be Decided
このエントリでは、Yegor Bugayenkoによる記事、OOP Alternative to Utility Classesを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 ユーティリティクラス(またはヘルパークラス)は、スタティックメソッドだけを持っていて、状態を内包しない「構造体」だ。 Apache CommonsのStringUtils、IOUtils、FileUtilsや、GuavaのIterables、Iterators、またJDK7のFilesはユーティリティクラスのいい例だ。 ユーティリティクラスはよく使われる共通機能を提供するので、この設計手法はJava(やC#、Rubyなど)の世界でとても人気だ。 要するに我々は、DRY原則に従い、重
【本には書いてないオブジェクト指向⑦】関数とユーティリティクラスは禁止 | そるでぶろぐ
関数を作ってはいけない関数というのは、Cなどの手続き型言語で言う関数のことです。 関数を正確に表現すると、 クラス変数にもインスタンス変数にも一切アクセスしないメソッドです。次の例が関数です。 /* 姓と名を基に氏名を返す */ public String getFUllName(String surName, String givenName) { return surName + " " + givenName; } /* 消費税額を返す */ public BigDecimal getSalesTaxf(BigDecimal amount) { BigDecimal tax = new BigDecimal(5); return tax.multiply(amount).divide(100, RoundingMode.HALF_UP); } クラス変数にもインスタンス変数にも一切ア
【本には書いてないオブジェクト指向①】オブジェクト指向を上手に活かすために | そるでぶろぐ
ソリューション開発部の田中です。 ここに書いたのは、私が設計・実装したJavaのフレームワーク開発を主に通じて理解したオブジェクト指向の原理原則です。 私は単なるエンジニアであって学者や研究者ではない上に、オブジェクト指向について誰かから教わった経験も無いため、ここに書いてある内容は科学的に吟味されたものではありません。 しかし、普段の仕事の中で気付いた合理性のある内容だと考えています。オブジェクト指向言語を日常使ってはいても、オブジェクト指向そのものをみっちりと学習したことがない人にとって特に役立つ内容だと思います。 オブジェクト指向って?オブジェクト指向の最初の説明として良く出てくるのが、 隠蔽継承多態性というものです。 これらはオブジェクト指向の特徴を確かに言い表していますが、オブジェクト指向的な設計や実装を初学者が理解するための役に立たないと私は考えています。少なくとも初心者にとっ
コンポジションとデリゲーション - ソフトウェアエンジニアの日常の雑記
一般のJava入門の書籍の中で、継承の仕組みはとても取り上げられるのだが、 コンポジション(集約)とデリゲーション(委譲)については、ほとんど触れられていないと思う。 個人的には継承と同じくらい重要であるコンポジションとデリゲーションの仕組みのおさらいをしておく。(初心者向け書籍にまともな記述がないので間違っていたらコメントください) コンポジションというのは、外部クラスのインスタンスを自クラス内で宣言し機能を使おうというものである。 デリゲーションは、上記のコンポジションで宣言されたインスタンスで使えるメソッドを使うことである。 下記の例だと、実際の処理を行うComputerクラスとHumanクラスがあって、それを操作するmainメソッドを持ったOperatorクラスがいる。 Operatorクラスは、Humanクラスのメソッドを使い仕事をさせようとするが、Humanクラスはその中で、C
レイヤー設計とか、オブジェクト指向とか、DDDとか、その辺 - まっつんの日記
自分の指向としては、技術の勉強というとDDDとかOODとか、そういう抽象的方面が好きなのだが、オブジェクト指向否定論もあることは承知している。 ---------------追記 2020/09/27 この記事は「ユーザーのメンタルモデルを反映させる」というMVCの本来の設計思想を捉えていません。ただ、巷に流布しているものを元に考えた記事としては資料的には無価値ではないと思いますので、ログとして残しときます。 MVCの本来の考えはOOUIの本や、コプリエンのLean Architecture本が良さそう ------------------------------- 過剰設計の落とし穴 実際、レイヤー構造や業務モデルを頑張って作っているが、実装時に足かせになったり、プログラマがよく規約や方針を理解できずに、ごちゃごちゃに作り、余計に複雑になってしまったりするのは、色々聞く。（自分はこれをや
Javaの検査例外は、呼び出し側で「どんなに注意しても防げない」異常系 - Qiita
注：本記事の内容はJavaで公式にドキュメントされているものではなく筆者の見解です。とはいえクラスを設計する上で有用な指針たり得ると思われるので公開したものです。 おさらい - 検査例外と非検査例外 Javaの例外クラスには「catchしないとコンパイルエラーになる」検査例外（チェック例外、checked exception）とそうでない非検査例外（非チェック例外、unchecked exception）があります。 検査例外は最近は嫌われる傾向がありC#では採用されていませんしAltJava言語も軒並み不採用、さらにはJavaの新しめのライブラリにも非検査例外しか投げないものが出てきていますが、適切に使えば安全なプログラミングのための強力な武器であり、検査例外の有意義さについては @irxground さんの Javaの検査例外の存在意義 をご覧ください。 例外クラスを自作する場合、検査
オ・ト・ナのカプセル化再入門 - Qiita
よく、初心者向けの教科書に「とりあえずprivateを指定し、必要な物はpublicにしましょう。」と書いてありますが、これは大きな間違いです。 最初にアクセス修飾子を熟知しておかなければ、Java という言語を扱う上で最良の設計を行なうことは難しいでしょう。 そんな教科書は今すぐ窓から投げ捨てるか、ちり紙代わりに使いましょう。 Package パッケージは Java のクラス郡をまとめるための仕組みです。主に利用する目的として、以下の 2 点ががあります。 名前の衝突を避ける事が出来る。 パッケージによるアクセス制御を行なえる。 これらを利用する事で Facade デザインパターンを忠実に実現することができます。 Java のカプセル化においてこの仕組みは必要不可欠でしょう。 Design patterns 次に、ソフトウェア設計において基本的な 2 パターンを紹介します。 Facade
【本には書いてないオブジェクト指向⑧】Privateメソッド禁止 | そるでぶろぐ
ソリューション開発部の田中です。 ここに書いたのは、私が設計・実装したJavaのフレームワーク開発を主に通じて理解したオブジェクト指向の原理原則です。 私は単なるエンジニアであって学者や研究者ではない上に、オブジェクト指向について誰かから教わった経験も無いため、ここに書いてある内容は科学的に吟味されたものではありません。 しかし、普段の仕事の中で気付いた合理性のある内容だと考えています。オブジェクト指向言語を日常使ってはいても、オブジェクト指向そのものをみっちりと学習したことがない人にとって特に役立つ内容だと思います。 前回の記事はこちら。 Privateメソッドを作りたくなった時は存在するべきクラスを見逃しているこのページの見出しを見て「えっ?!」と思う人は多いでしょう。でも、私がマネージメントする開発では「Privateメソッド禁止」は当たり前なんです。 例を使った下の説明で詳しい内容
インターフェイス指向設計 - yuku-t
2015-03-12 インターフェイス指向設計 book review 『インターフェイス指向設計』を読んだ。念の為に書き添えておくと、この本が指すインターフェイスというのは、いわゆるUIのことではなく、プログラミング部品としてのinterfaceのこと。 インターフェイス指向設計 ―アジャイル手法によるオブジェクト指向設計の実践作者: Ken Pugh,角谷信太郎(監訳),児島修出版社/メーカー: オライリージャパン発売日: 2008/05/24メディア: 大型本購入: 16人 クリック: 357回この商品を含むブログ (67件) を見る この本のいいところは オブジェクト指向プログラミングの肝は 高凝集 で互いに 疎結合 なオブジェクトを用いてプログラムを構築することにある という態度を一貫して保ち、その目的を達成するにはどうすべきかという観点からインターフェイスの利用について語ってい
インターフェイスを設計するために読んだ技術書まとめ - 自由課題
アーキテクトの(機能面での)主要な仕事の１つに、システムを構成するサブシステム/コンポーネントの境界、つまりインターフェイスを決める、というものがあります。またはそこまで大げさに捉えなくても、例えばライブラリのAPIを設計する、というのは単にプログラミングをする、ということとは少し違う視点が求められるように思います。 案外インターフェイスを考えるという観点での技術書まとめがないような気がしたので、需要があるかわかりませんが関連して読んだ本を紹介しておきます。なお、個人的なキャリア上、C++/Javaが対象です。(色々経験したら随時追加するかも知れません) 何か他にいい本があったらぜひ教えてください。 言語仕様をきちんと知る まずはAPIを設計する対象言語をよく知る、ということは必要であると思います。これだけだと、結果的にプログラミングに精通するということとあまり変わりはないかも知れません。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
