定期的にオブジェクト指向disを書いてしまってるのだけど。 とりあえずオブジェクト指向の話をすると定義が人によって違いすぎるので、改めてここでの定義を書いておくと 、基本的にはOMTの「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」 に従うのですが 「1990年に流行りソフトウェア開発のすべてを飲み込み、いまとなっては人それぞれ定義が違って技術的議論に使えなくなった、主にオブジェクトを基本単位としてプログラムを整理するやりかたを指すマーケティング用語」 という感じです。 ほとんどの場合で人によってオブジェクト指向の指す範囲が違いすぎて、技術的知見の共有には使えなくなっています。でも、いずれの定義にしろオブジェクトを基本単位にするというのは重要ではないかと。 ソフトウェアの組織化の単位としてオブジェクトを使うというのが大事で、データの搬送に構造体代
公開中の内容・構成については、変更されることもあります。現在のDrop 2.0Betaの作成状況を下記のマークで示しています。 .....完成かな？ .....もう少しです .....まだまだ 現在も相変わらず修正中です。 みなさんからのご意見は、以下のDrop Q&A;にてご紹介させていただきます。 はじめに Dropの読み方・使い方 LastUpdate: 3.11 コンセプト編 第１章 Drop構成用語集（オブジェクト指向用語編） LastUpdate: 2.15 第２章 Drop構成用語集（開発プロセス編) LastUpdate: 2.15 第３章 オブジェクト指向開発の考え方（映画撮影のように) LastUpdate: 2.15 第４章 Dropの目指すもの LastUpdate: 3.11 プロジェクトチーム構成編 第５章 プロジェクト構成の問題 LastUpdat
2017年8月30日（水）にDDD AllianceのLT（時間10分）で登壇しました。 ddd-alliance.connpass.com 以下が発表資料です。 オブジェクト指向を学んで図解力、仕事力アップ from Haruo Sato LTのきっかけ LTのきっかけは現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法の書評をブログで書いたことです。 shacho.beproud.jp はてなブックマークが500を超え、そのタイミングで書籍の売上も伸びたそう（私のブログからも2日間で70冊売れました）なので、DDD Alliance運営の高崎さんからお声がかかりました。 LTの内容 「現場で役立つシステム設計の原則Night!」という全体テーマなので、オブジェクト指向に関係することで内容を検討し、UMLを中心とした図解の効果について話すことにしました*
ソリューション開発部の田中です。 普段の仕事の中で疑問を覚え、さまざまな書籍やサイトにあたったけれども見つからない・・・そんな「今まで無かった!」オブジェクト指向の原理原則を紹介いたします。オブジェクト指向言語を使う開発者の方や、ソフトウェアの保守性を高めたい管理職の方にお勧めします。
昨日のDDD(ドメイン駆動設計)勉強会in仙台は、４名の参加者でした。前半は「オブジェクト指向エクササイズ」の説明、後半はレガシーコードをオブジェクト指向エクササイズで書き換えてみる演習を行いました。用意したレガシーコードはこちら https://t.co/xdXEl43mrH — Takehiro Inoue (@i_takehiro) March 18, 2016 なんか面白そうなのが流れてきたので、やってみた。 でき上がったコードは GitHub に上げています。 まずはソースを読む ソースは こちら に上げられている。 クラス図にすると、以下のような感じ（分かりやすいように日本語にしてる）。 いい感じで気持ち悪いですね！ 「飲み物」クラスと「自動販売機」クラスがある。 どうやら、「自動販売機」にお金を投入して「飲み物」を購入するプログラムを想定しているらしい。 これらを使うクライア
あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを理解することで、よりよいプログラムを書くためのもので、正確なソフトウェア工学の歴史を学ぶためのものではありません。正確な歴史を把握したい場合は、原典をあたるようにしてください。 また、想定している読者は「よくあるオブジェクト指向プログラミングの学習」を既にし
Go言語での構造体実装は、埋込や独自コンセプトのインターフェースといったGo言語独自の機能を理解して行う必要があります。 今年からGo言語を始めましたが理解が曖昧なままだと実装に迷うことが何度かありました。今回よい機会なので、Go言語での構造体実装パターンとしてまとめてみることにしました。 構造体実装パターン実装パターンの洗い出しとして、GoFデザインパターンをGo言語で実装する手法をとりました。 その中で繰り返し現れる実装をGo言語での構造体実装パターンとしてまとめてみました。 コンストラクタ関数エクスポートによるアクセス許可インターフェースによるポリモフィズム構造体によるポリモフィズム構造体によるサブクラス・レスポンシビリティ構造体による移譲関数による移譲以下、それぞれのパターンを解説していきます。 コンストラクタ関数Go言語には構造体のコンストラクタがないため、構造体の初期化を行うに
history 13/3/31 Tag について追加 intro Go を触ってて interface を用いた設計がまだまだよくわかってなかったので、一旦まとめることにしました。 Go には明示的な継承の機能は無く、 interface も例えば Java のそれとはかなり毛色が違うので、(Class ではなく) Struct の設計に結構癖があると感じます。 Go の interface は言語設計的にもかなり尖っていて、 Go という言語を強く特徴付けていると同時に、 Go 言語自体の開発者たちもこの機能をかなり重要視しています。 例えば、 Go の開発者の一人である Russ Cox 氏によれば Go's interfaces―static, checked at compile time, dynamic when asked for―are, for me, the most
“オブジェクト指向”の意味を本当に理解するには、この概念の始まりを振り返ることが必要です。最初のオブジェクト指向言語はSimulaという言語で、1960年代に登場しました。オブジェクト、クラス、継承とサブクラス、仮想メソッド、コルーチンやその他多くの概念を導入した言語です。おそらく最も重要なのは、データとロジックが完全に独立したものであるとする、当時では全く新しい考え方をもたらしたことでしょう。 Simula自体には馴染みがない方も多いかもしれませんが、Simulaからインスピレーションを得たとされるJavaやC++、C#、Smalltalkといった言語は皆さんよくご存知でしょう。さらにそこからインスピレーションを得たものとしてObjective-CやPython、Ruby、JavaScript、Scala、PHP、Perlなど様々な言語があり、Simulaは現在使用されているポピュラーな
Monadic Programmingのススメ - Functional Reactive Programmingへのアプローチ
PROCESS「手続き」をモデル化俯瞰図所属するストーリの俯瞰図です。モデル「深」化どういうこと？モデルにおいて、ビジネス上意味のある「プロセス」というのは確かに存在します。ただし、既存のドメインオブジェクトにあてはめようとすると、「プロセス」の特性上、オブジェクトの設計がぎこちないものになってしまいます。そこで、「プロセス」という観点でモデリングを行い、通常オブジェクトとは切り離してモデル化します。どうして？オブジェクトは、手続きをカプセル化し、代わりに目的や意図にフォーカスさせるために存在します。「プロセス」は手続きそのものなので、この考え方に当てはまりにくい部分です。既存のオブジェクトに無理やり押し込めると、オブジェクトの責務があいまいになり、ぼやけた設計になってしまいます。どうすれば？選定明示すべきプロセスと隠蔽すべきプロセスを区別する鍵は単純です。ドメインエキスパートが話題に上げ
この記事では、私がオブジェクト指向のどこを愛しどこを素晴らしいと感じていて、そのうえでなぜオブジェクト指向を使うことを避けているのかを書き留めておきます。関数型言語使いの方で、「オブジェクト指向の何がいいのかわからない」「オブジェクト指向難しすぎ・複雑すぎ」とおっしゃる方にぜひ読んでいただきたいと思っています。また、「オブジェクト指向言語完璧に理解したわ」と思っている方にも読んでいただきたく思います。 なお、ここでのオブジェクト指向の定義は、「各言語でオブジェクト指向と呼ばれているものすべて」とします。JavaやScalaやJavaScriptやSmalltalkやRubyやCommon LispやOCamlがオブジェクト指向と呼んでいるものすべての総称です。もっとまともな定義が知りたい方は以下の記事がおすすめです。 オブジェクト指向の概念の発明者は誰ですか？(改訂版) - Smallta
ちょっと煽り気味のタイトルにしてみましたが、Railsで開発する時は意識的にOOPに寄せないとオブジェクトの力が活かせなくなるよってことと、Railsが提供しているクラスの責務を分割することを支援してくれる機能について話をします。 ActiveRecordの性質 Rails開発においては、モデル層にロジックを書いてコントローラーは薄くしろ、というのはしつこく言われているので、概ね浸透してきていると思います。 それに加えて、最近私が結構しつこく主張しておきたいのが、モデル = ActiveRecordでは無いよ、ということです。 ActiveRecordは成り立ちから言うと、ロジックとDBへの永続化をまとめてカプセル化するアーキテクチャパターンから来ています。(詳しくはエンタープライズアプリケーションアーキテクチャパターンという書籍を読むと良いです) この方法はロジックが複雑でない場合、つま
［奇妙なクラスと実世界］ ＩＮＤＥＸ オブジェクト指向モデルと実世界 １．１ オブジェクト指向アプローチの特徴 １．２ 実世界に即したモデルを作ることへの疑問 銀行アプリケーションの事例 ２．１ 典型的な分析モデル ２．２ 奇妙なクラスの存在 ２．３ 実世界そのままを表現したモデル ２．４ 両替商モデルから大銀行モデルへ ２．５ オブジェクト指向が描くモデル ２．６ オブジェクト指向モデルと現実世界での役割分担の違い まとめ ３．１ オブジェクト指向モデルは組織化された超分散協調社会 「奇妙なクラスと実世界」をPDF形式でご覧になれます。 ご覧になるには、Adobe Acrobat Readerが必要です。 以下のボタンをクリックしてダウンロードしてください(無料)。
［実世界をそのまま表現するモデルとは］ ＩＮＤＥＸ １．はじめに ２．従業員－会社モデル ３．従業員－会社モデルの検討 ４．従業員－会社モデルの解説 ５．顧客モデル ６．実世界をそのまま表現するモデルとは ７．まとめ ８．モデリングと言葉、そしてＵＭＬ 「実世界をそのまま表現するモデルとは」をPDF形式でご覧になれます。 ご覧になるには、Adobe Acrobat Readerが必要です。 以下のボタンをクリックしてダウンロードしてください(無料)。
[モデリングの勘所 -オブジェクトモデルと実世界-] オブジェクト指向アプローチによるモデリングを行うと、対象とする実世界をそのまま表現できる、あるいはしやすいと言われます。 しかし実際にモデリングを経験された方の中には、実世界を理解してオブジェクトモデルとして表現するのに苦労をしたり、違和感を感じる方も多いのではないでしょうか？ 以下の記事では、実世界とオブジェクトモデルが表現する世界の違いについて、いくつかの切り口からじっくりと考察してみました。 オブジェクトモデラーを目指している方は、是非ご一読ください。 ＩＮＤＥＸ 第１回 奇妙なクラスと実世界 <1998.10-11> オブジェクトが協調動作するといっても、銀行口座とカレンダー同士が勝手に話し合って利息を計算してくれる世界って、素朴に考えるとずいぶんと不思議です。 この疑問を追求することで、オブジェクトモデルで表現される振る舞いと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: オブジェクト指向設計実践ガイド ～Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方: Sandi Metz (著), 髙山泰基 (翻訳): Digital Ebook Purchas
