変化が激しく脆いドメインで技術的負債を増やさない設計
はじめに ソフトウェア設計についてのポエム。 それも、ドメインが短期的なサイクルで大きく変化をしてしまうような領域での。 僕が携わる領域、つまりメディアサイトでのSEO施策を反映するシステムでの経験を念頭にしている。 結論から言えば、ビルド・アンド・スクラップを可能にしようという話です。 「変化の激しく脆いドメイン」とは？ 問題の解決策のコアとなる部分が頻繁に変わるドメインのこと。 特にプロダクトのライフサイクルよりも早く変わるドメインのことを指したい。 僕が携わっている「Webメディア」というのも、この変化の激しく脆いドメインに当たると思う。 Webメディアにおける開発では、SEOやUXについて考慮することは避けることはできない。 しかし、SEOやUXは頻繁に変わるGoogleのアルゴリズムやユーザの嗜好によって正解が変わっていく。 一年前に正解だったものが、次の年にはただの技術的負債に
境界づけられたコンテキスト 概念編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab
境界づけられたコンテキストとは 公式DDD Referenceの定義は以下の通りです。(和訳はだいぶ意訳しています) bounded context A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable. 境界づけられたコンテキスト 特定のモデルを定義・適用する境界を明示的に示したもの。 代表的な境界の例は、サブシステムやチームなど。 まぁなかなかよくわからないですよね。DDD用語の中でもかなり難解なワードです。 境界づけられたコンテキストは、2つの観点から解説が必要でしょう。 ・概念としての境界づけられたコンテキスト ・境界づけられたコンテキストをどう実装に
![境界づけられたコンテキスト 概念編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/6bb65ba88fd34a29140629a2f7085b6e005c2663/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20171128%2F20171128072027.png)
オブジェクト指向と20年戦ってわかったこと - Qiita
この記事の内容 オブジェクト指向と10年戦ってわかったこと Twitterやはてブコメントを見たら、「わかりやすかった」というコメントもあったのですが、どちらかというとネガティブ方面なコメントが多く目につきました。マサカリという用語で忌憚なく意見を言う風潮については別にいいんですが、「わかりにくい」「間違っている」「古い」みたいなコメントは何も生み出さないし、みんなでニコニコポエムを投稿しあうやさしいインターネッツになったらいいなって思ったので、僕もオブジェクト指向について投稿しようと思います。 何原則？ ３原則じゃなくて4では？みたいなコメントもあったのですが、別に3でも4でも5でも重要ではないかなって思います。この4原則の出どころがどこかは知らないですが、C++かSmalltalkあたり(このあたりの話を見かけたのはJava登場前だった気がする)をターゲットとしている気がします。Jav
DI・DIコンテナ、ちゃんと理解出来てる・・？ - Qiita
意外と分からずに、「とりあえず」とか「なんとなく」で使っちゃうパターンが多い系案件な気がして書いてみます。 こんな事ありませんか？ DIとDIコンテナの違いを説明出来ない DIとサービスロケータの違いを説明出来ない DIを使ってるつもりが、サービスロケータになっている DI、サービスロケータが、ただの「パターン」の１つであることを理解してない DI(Dependency Injection)を正しく理解する そもそも、Dependeny Injectionを日本語にするとどういう意味になるでしょうか。 多くの人が「依存性の注入」とか応えるのではないでしょうか？ 私もそうでした。きっと何かで読んだのでしょう。 (wikipediaに「依存性の注入」と書いてありますね) 補足 なぜ依存性を注入してあげると良いのか、そのメリット等は後述しますが、 DIというのはただのパターンの１つです。 たまに
javaプログラマー向け学習のための本（新人から５年めくらいまで）を考えてみた - Qiita
1.ガチ新人向けのコンピュータに関する教養 新入社員で専門課程で情報処理教育を受けていない場合の基礎教育 専門教育を受けていてもレベルによっては、適宜読んだほうがよい プログラムはなぜ動くのか 第２版 知っておきたいプログラムの基礎知識 プログラマにとってCPUとはなにか データを2進数でイメージしよう コンピュータが小数点数の計算を間違える理由 四角いメモリーを丸く使う メモリーとディスクの親密な関係 自分でデータを圧縮してみよう プログラムはどんな環境で動くのか ソース・ファイルから実行可能ファイルができるまで OSとアプリケーションの関係 アセンブリ言語からプログラムの本当の姿を知る ハードウェアを制御する方法 コンピュータに「考え」させるためには レッツ・トライC言語! ネットワークはなぜつながるのか 第2版 知っておきたいTCP/IP、LAN、光ファイバの基礎知識 第1章 Web
オブジェクト指向の問題点 - ビスケットのあれこれ
オブジェクト指向プログラミングを神格化するような記事が流れてきたので，僕が知っている問題点について書いてみたいと思います．僕がまだ学生だったころは，オブジェクト指向の評価もまだそれほど定まっていなくて，オブジェクト指向の次はどんなパラダイムが出てくるかとか普通に学生レベルで議論していたものですが，ここまで強大になってしまうとそれを打ち負かそうなんて気にはならないのでしょうか．僕にはオブジェクト指向が普遍的な真理という感じは全然しなくて，ここまで使われてる理由は，現実的なテクノロジーで大きなシステムを作らなければならない必要性のほうを優先した結果であると認識しています．オブジェクト指向がその後の25年ほどもずっと安定してその地位を保てるほど素晴らしいものとは思えないのです． 以下で上げる問題点は，個別に解決している研究はあったりしますし，僕も論文を書いたりしましたけど，実際の言語に導入されて
Javaの道：クラス（９．オーバーライドとオーバーロード）
オーバーライド オーバーライドとはスーパークラスにおいて定義されているメソッドを、サブクラス内で再定義することを言います。スーパークラスのメソッドを変更することはできないが、サブクラスに特化した機能を付与したい場合に使用します。 オーバーライドを定義する際には以下の規定があります。 オーバーライドする側はオーバーライドされる側と戻り型、メソッド名、引数型、引数の数が同じでなければなりません。どれか一つでも異なる場合はオーバーライドとは見なされません。 オーバーライドされる側のメソッドに指定されるアクセスレベルより厳しい制限を持つアクセスレベルをオーバーライドする側のメソッドに付与することはできません。例えばオーバーライドされる側のメソッドにprotectedが指定されている場合、オーバーライドする側のメソッドにprivateを指定することはできません。 オーバーライドされる側のメソッドに指
オブジェクト指向の概念の発明者は誰ですか？ - Smalltalkのtは小文字です
忙しい人のためのまとめ 一般に「オブジェクト指向プログラミング」と呼ばれる考え方には発案者が異なる二系統がある。（ただし簡単のため、次のうち前者から批判的に派生して生じたプロトタイプベースのオブジェクト指向はここには含めていない） アラン・ケイによる、変化に強い長期運用可能な遅延結合システムを SIMULA67 にあった「オブジェクト」をメッセージの受け手とすることで実現（オブジェクトにメッセージ送信）するアイデアに基づく「メッセージングのオブジェクト指向」と、 ビアルネ・ストラウストラップ（前後して抽象データ型を発案したリスコフ本人、オブジェクトクラスを考えたニガードらSIMULA陣営、Eiffelのメイヤーらも同様の着想を得ている）による、ユーザー定義型（抽象データ型）を SIMULA67 にあった「クラス」という言語機能を使って実現（カプセル化、継承、多態性）するアイデアに基づく「抽
オブジェクト指向について考えたいので、Lispでオブジェクトもどきみたいなものを実装してみる - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 最近になって、「関数型とは何か」みたいな文章が増えている。それらの文章は玉石混交しているし、技術的ではない部分も多いので、自嘲の意味で「ポエム」と自ら呼んでいたりする。その関係もあってか、手元にある『On Lisp』と『実用Common Lisp』にある「Lispによるオブジェクト指向」に関する章を読んだりしていた。そこで、考えたことをメモしておく。 以下、利用している処理系はRacket languageを想定している。 Lispでオブジェクト指向っぽいものを作ってみる この項目はLispによってオブジェクト指向を作るための道筋みたいなものである。もし、Lispに興味が無ければ、一挙に飛ばしてもいい。 はじまり よく言われているように、「関数型」と呼ばれる言語の特徴として「副作用」をできるだけ排除する傾向にある、ということはできる。副作用とは、ある変数などにおいて変化を発生させ
デザインパターンを読み解く
ポリモーフィズム（サブクラスによる切り替え、抽象化） ここに分類されるのは、オブジェクト指向の第３原則、ポリモーフィズムを使用したパターンです。ポリモーフィズムを使用すると、動的に使用するクラスを切り替えることができます。＜参照＞ 他に分類されているものでも、ポリモーフィズムが重要な位置を占めているものもありますが、ここではそれしか使われていないものを扱います。 ただデザインパターン全体を通して強調されているのは、インターフェースでプログラミングするということです。実装への依存をなくし、そうすることによって設計の骨組みを明らかにするのです。 Template 次のようなメソッドがあった場合に、処理Bのところを条件によって変えたい場合があるとします。 class Hogehoge { void doit() { ... 処理A ... ... 処理B ... ... 処理C ... } }
継承はメソッドを使いまわすためにあるのでない - 超ウィザード級ハッカーのたのしみ
まだまだオブジェクト指向を極めたわけではないのですが、最近気になったこと。 オブジェクト指向の継承はメソッドを使いまわすためにあるのではないということです。 Fooというクラスがあって、BarというクラスがFooを継承（inherit)しているとする。つまり、Bar is a Fooとなっている。 このとき、Barに求められるのは、Fooと同じメソッドを持つということだけではない。メソッドの動作は変えても良いが、意味は変えてはならない。プログラム内でFooクラスを使っているところをBarに置き換えても、Fooを使っているつもりで動作しなければならない。 これを守ろうと思ったら、継承はむやみにできなくなると思うです。 ただメソッドを使いまわしたいだけなら継承ではなくて、委譲(delegate)をするべきなのです。例えば、Fooを継承したBarというクラスがあったとして、他にFooを継承したク
オブジェクト指向プログラミングとは結局なんなのか | 黒曜の吹き溜まり
この記事は第2のドワンゴ Advent Calendar 2015の5日目です。 ちなみに前日は@deflisさんでした。 先日の記事で分かる通りドワンゴ社員()なのですが、まぁ@mesoさんが「厳格な管理とかめんどくさいので、元社員も参加すればいいんじゃないかな。」とか言ってるしお目こぼし頂きたく… 去年のアドベントカレンダー記事は「関数型プログラミングとは結局なんなのか」というタイトルで、関数型プログラミングという語が何を指していて何を指していないのか、みたいなことをなるべく平易にまとめました。 なので今年は「オブジェクト指向プログラミング(以下OOP)とは結局なんなのか」という記事にしてみた…のですが、なにぶん語の指す範囲が広く、また自分も理解しきっているわけではないので、多少不正確な点があるかもしれません。 「関数型は流行りだけど、今更OOPかよ」とか思われるかもしれませんが、お付
staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて - 達人プログラマーを目指して
何が良いプログラムかという点はもちろん人やコンテキストによって異なりますが、少なくともプログラマーとしての私の信念としては、 機能拡張や変更が容易なプログラム 単体試験によって正しく動作することの検証が容易なプログラム どういった内容が記述されているか理解しやすいプログラム といったものこそ、「品質の高い」プログラムが持つべき性質として、まず真っ先に挙げるべき事項であると考えています。もちろん、前提として顧客の要件に従うということは大切なことです。しかし、一般に要件は長期にわたって変更されるものですし、使い捨てのプログラムを除けば、プログラムを長期にわたって保守するコストという点も見過ごすべきではありません。したがって、ユーザーの目には触れない上記の性質をもっと重視すべきだと思うのです。 DRYの原理 上記のような性質を満たすプログラムを作る上で大切になってくる原理として、DRYの原理とい
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - ひがやすを技術ブログ
このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(
Railsでサービスとフォームを導入してみる話 - assertInstanceOf('Engineer', $a_suenami)
この記事はRuby on Rails Advent Calendar 2013の6日目の記事です。 前日は @tkawa さんの「Favoriteの設計実装はパターンとして使える」でした。 Railsで適切に責務を分割するということ RailsはいわゆるMVCと呼ばれるアーキテクチャパターンにのっとったフレームワークであり、プロジェクトを作成するとデフォルトでmodels/、views/、controllers/などのディレクトリが作成されます。 基本的にロジックを記述する場所はモデルであり、ビューには表示処理だけを、コントローラにはアプリケーション上必要な手続きだけを記述するべきであると一般的には言われています。*1 ただ、それを忠実に実践していった結果、モデルが肥大化しメンテナンシビリティやテスタビリティが低下するという問題も多く指摘されています。 これについては4日目に @joker
Martin Fowler's Bliki in Japanese - ドメインモデル貧血症
http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな
ダメエンジニアの8つの特徴 - Hack Your Design!
(画像はウンコード・マニアより引用) 1. オブジェクト指向を理解しない ダメエンジニアはオブジェクト指向を理解しません。 もちろんオブジェクト指向を理解しなくてもプログラミングはできますし、動くプログラムを書くことは可能です。しかしオブジェクト指向プログラミングを使わずに（あるいは十分に理解せずに）書いたプログラムは著しくメンテナンス性・可読性が低く、共通化すべき箇所が共通化されず無駄なロジックが散在するコードとなるでしょう。 オブジェクト指向の技術は1970年頃の登場以降、様々な進化を遂げながらも今なお開発の最前線で使われている技術です。こんなすばらしい技術を使わない手はないでしょう。 2. コードが美しくない ダメエンジニアのコードは汚いです。 では美しいコードとはなんなのか。個人的には「プログラマの思想が見えるコード」「一貫性があるコード」だと思っています。 思想が見えるコードとい
アジャイルソフトウェア開発の奥義を読んだ - 転職した
アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技 作者: ロバート・C・マーチン,瀬谷啓介出版社/メーカー: ソフトバンククリエイティブ発売日: 2008/07/01メディア: 大型本購入: 18人 クリック: 586回この商品を含むブログ (71件) を見る OOPを勉強するのに良いと勧められて買った本。かなり内容が濃い本で600ページにも及ぶため、読み進めるのに苦労した。完全に消化不良なので機会を見つけて読み返すようにしたい。 ただ消化不良なりにもいくつも発見があって、 アジャイルソフトウェア開発とはなにか テストコードをうまくかけない根本原因 デザインパターンはやはり重要ということ といった事について気づきがあった*1。 アジャイルソフトウェア開発とはなにか この本を読んだ事でアジャイルソフトウェア開発とはなんぞやということに対してようやく答えが見えた気が
デザインパターンとともに学ぶオブジェクト指向のこころ を読んだ - takatoshiono's blog
読んだ理由 最近、ソフトウェアの設計力が不足していると感じる。もっといい感じにクラスを設計して、オブジェクト指向ぽいプログラムを書けるようになりたい。しかもスピード感を持ってやりたい。ということで、いまさらだけど、オブジェクト指向についてもう一度学んでみようと思った。本を読めばいいという訳じゃないけど、とりあえずもっと知識を増やしたい。渋谷の東急百貨店 7F の丸善＆ジュンク堂書店に行って、 オブジェクトデザイン (Object Oriented SELECTION) エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES) の3冊で悩んだ結果、これを買った。決める要因となったのは、 ついでにデザインパターンについて理解を深められたらいいなと思った これまで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
クロージャデザインパターン
