OOC 2024 の発表資料です。後のフィードバックを参考に、より妥当な文言に改訂してあります。 ※ 本コンテンツには、一部特定の宗教思想の迫害に言及する表現がございますが、そのような行いを肯定する意図の内容ではございません。
OOC 2024 の発表資料です。後のフィードバックを参考に、より妥当な文言に改訂してあります。 ※ 本コンテンツには、一部特定の宗教思想の迫害に言及する表現がございますが、そのような行いを肯定する意図の内容ではございません。
この記事は第2のドワンゴ Advent Calendar 2015の5日目です。 ちなみに前日は@deflisさんでした。 先日の記事で分かる通りドワンゴ社員()なのですが、まぁ@mesoさんが「厳格な管理とかめんどくさいので、元社員も参加すればいいんじゃないかな。」とか言ってるしお目こぼし頂きたく… 去年のアドベントカレンダー記事は「関数型プログラミングとは結局なんなのか」というタイトルで、関数型プログラミングという語が何を指していて何を指していないのか、みたいなことをなるべく平易にまとめました。 なので今年は「オブジェクト指向プログラミング(以下OOP)とは結局なんなのか」という記事にしてみた…のですが、なにぶん語の指す範囲が広く、また自分も理解しきっているわけではないので、多少不正確な点があるかもしれません。 「関数型は流行りだけど、今更OOPかよ」とか思われるかもしれませんが、お付
タイトルの「リスコフ置換原則」以外にも色々あったみたいですが、とりあえずその話が多めだったのでこういうタイトルにしておきました。 tweetは自由に、追加、削除してください
POUR L'OBTENTION DU GRADE DE DOCTEUR ÈS SCIENCES PAR Dipl.-Inform., RWTH, Aachen, Allemagne et de nationalité allemande acceptée sur proposition du jury: Prof. M. A. Shokrollahi, président du jury Prof. M. Odersky, directeur de thèse Prof. V. Kuncak, rapporteur Dr D. Syme, rapporteur Dr M. Zenger, rapporteur Object-Oriented Pattern Matching Burak EMIR THÈSE NO 3899 (2007) ÉCOLE POLYTECHNIQUE FÉDÉ
なんだか、最近ceylonっていう新しいJVM上の言語がでたらしく、自分のTL上では話題になってました・・・ が、自分は興味わかないというか、Scalaがこれだけtwitterをはじめものすごく実用でつかわれてるのに、今更新しい言語つくって普及させるとかどうなの？という立場です。まぁ言語仕様もちゃんと見てないであれなんですが(・ω・`) だれかceylonの魅力を延々と語ってください。 たしかに、Scalaは複雑すぎる的な印象は仕方ない部分もあるかもしれないですが・・・とか考えてるときに、そういえばScalaを作成する以前にodersky先生がつくっていた言語あったよなーとか思い出して、前から書こうかと思っていたのでpizzaについて紹介してみます!というよくわからない流れヽ(｀▽´)/ pizzaというのは、Scalaの作者であるodersky先生がScalaを作る前につくっていたJVM
TL;DR MVCもレイヤで捉えて関係性の設計をするといいのでは 普通のRubyオブジェクトを積極的に使いたいですね 「パーフェクト Rails」に期待しましょう 長くなって面倒くさくなり、途中から手抜き感が半端ないですが許してください この記事の位置付けなど 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog [翻訳] エリック・エヴァンスのドメイン駆動設計 エンタープライズ アプリケーションアーキテクチャパターン これらの参考文献を踏まえてRailsアプリケーションのリファクタリングをしていて、だいぶ方向性や考え方がまとまってきたので、これからチームに合流する人を想定読者に、Qiitaがどんな感じで作られているのかを文書化したものです。（参考文献の一覧は記事の最後にあります） 内容的には文献[2,3]を踏
先日の大阪DDD勉強会に刺激を受けて、「ユースケース駆動開発実践ガイド」と「オブジェクト開発の神髄」と「アジャイルソフトウェア開発の奥義」「実践UML」を読み直している。 ラフなメモ書き。 【元ネタ】 【限定募集：第1回の申込者のみ、参加登録可能】第２回ドメイン駆動設計読書会@大阪 - ドメイン駆動設計読書会@大阪 | Doorkeeper vol2_20140309 · dddosaka/reading_ddd_report Wiki 【１】個人的には、オブジェクト指向設計という考え方は好き。 データモデリングはDB設計でも業務の設計でも必須だが、データだけではシステムは動かない。プログラムも作る必要があるけれど、DOAにこだわると、なぜかソースの自動生成に走ってしまうように思える。 オブジェクト指向設計は、アジャイル開発と相性がよい。 また、開発チームの構造解析にもオブジェクト指向設計
オブジェクトの世界と関数の世界
3月19日(月)に要求開発アライアンスのセッション『Object-Functional Analysis and Design: 次世代モデリングパラダイムへの道標』を行いましたが、説明を端折ったところを中心にスライドの回顧をしています。 「オブジェクトの世界と関数の世界」として用意した以下のスライドを説明します。 このスライドは元々、以下の2つの情報を表現するために用意していたのですが、いろいろ書き込んでいくうちに、OFADでのモデル変換の流れの側面が大きくなってしまいました。 オブジェクトの世界と関数の世界は併存するのが必然 アプリケーション・モデルの実装側はできるだけ関数型にしていく このため、同じような情報を持つスライドをセッションでは2つ省略しましたが、逆に、このスライドでは、「OFADでのモデル変換の流れ」の説明になってしまい、肝心なことの説明ができなくなってしまったので、この
Apertos Project Members Yasuhiko Yokote, Sony Corporation: principal designs, R3000 implementation Takao Tenma, Sony Corporation: Ape programming environment, MC++: C++ extension for Apertos Ken-ichi Murata: network protocol handlers, Cognac programming language Technical Papers Sub Projects Technology transfer project Sub Projects in the past... Jun-ichiro "itojun" ITOH: device drivers, i486 impl
● DCIが面白い件 DCI凄い！ヤバイ！ 「DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien」(翻訳) http://d.hatena.ne.jp/digitalsoul/20100131/1264925022 前に読んだときは難しすぎて(長すぎて)途中で挫折したけど、今改めて読んだらDCIは凄いと気付いた。以下、まとめ。 今回、内容理解の決め手となったのは「前半部分を読まない」ことだった。 そんな無謀な読み方(読んでないのだけれど)をした私の理解なので、 もちろん間違いはあるはず。 という前提で、 ツッコミを入れる気満々なテンションでどうぞ。 古来からプログラムの中心は＜データ＞であった なぜなら、それが設計の中で一番変化しにくい要素(箇所)であるから そして、＜データ構造＞とそれに対する＜処理＞の2つで考えるようになった (手続き型
以下、ここまでの流れを追わずに、主に放言だけ。いろんな方があれこれ書いていて。TL で目にしたのだけでも収集つかないし、断片的すぎるし、書いてる時にほとんど読んでいなかったので。他の人のは、ここから後で交錯した部分だけ引用させていただくよ。 話題の流れの情報収集 といいつつ、流れにはのっていない。(^^; 21:59:21 nsiena: 流れが分かってないけど、MVC2 が話題なの? | 22:04:22 uokumura: @nsiena ごめんなさいそこに飛んでるのたぶん私だけです。震源は http://bit.ly/ygzrQ ここです。 || 22:07:22 nsiena: @uokumura thx! 読んでまわるるる。 22:44:22 nsiena: #article 読んでる: 「Seaside へ GO!! -- 楽々サーバサイド Web プログラミング -- 第２回
Throwable、Exception、RuntimeException(RTE)、Errorあたりを整理しながら、色々考えてみた。私見に基づくので、間違っているかもしれないけれど、自分としては頭が整理できたかな、と感じたので晒してみる。異論があったらコメントください。 まず、一番基礎的なところで、継承関係の整理から。こんなツリーになっています。 Throwable Error Exception RuntimeException そして、本稿での用語の定義。caller＝呼出す側のコード callee＝呼出される側（throwする側）のコードとします。 Throwable Throwableは「throw文に指定できる何か」という意味ですね。 Instances of two subclasses, Error and Exception, are conventionally used
昨日のエントリ id:aufheben:20090430 について。 概念って言っちゃったので話が難しい方向へ進んでしまいましたが、Value と Entity の違いが有効になるのは、やはり設計以降だと思います。Value と Entity を意識することで、不具合が発生しにくくなります。でも、不変性が Value の本質的な特性ではないと言われてしまうとわけがわからなくなってしまいます。そんなわけで、ちょっとこだわってみました。 ちなみに、Value って価値を表すものだから本当は重要なんだけれど、概念モデリングでは通常 Value は脇役です。Value を表に出すと概要がつかめなくなってしまうので。主役は Entity なんだけど、DDD はそこが弱いと思うので、僕は以下の3冊をおススメしています。 Javaエンタープライズ・コンポーネント―カラーUMLによるJavaモデリング 作
きっかけは忘れたのですが、一昨日会社で Value Object の定義の話になって、Twitter でつぶやいたところ議論が盛り上がったのでログを残しておきます。 5/1追記: 個人的に重要だと思うところを太字にしました。あと、コメントを追記しました。 glad2121 少し頭痛が... 単なる寝不足か? Value Object で議論しすぎたか? glad2121 概念的な Value を「不変、かつオープンなもの」と仮に定義してみよう。1が2に変わったら、それは別インスタンス。製品の仕様みたいに、仮に不変であっても非公開な情報があればエンティティ。 glad2121 Entity は価値を保有する。Value は価値を定義する。 glad2121 Value にアイデンティティがないってほんと? Value 自身がアイデンティティじゃないのか? tadayosi @glad2121
Simula は サブルーチンの不自由さに対し改善を施すことで、クラスとオブジェクトを発明しました。その副作用として、コールスタックによる自動メモリ管理が使えなく(←「コイツ使えね~っ」の「使えない」）なってしまいました。 * * * 「階層的プログラミング構造」Ole-Johan Dahl, C.A.R Hoare より引用しつつ。 Simula が シミュレーションのための言語を模索する過程で クラス・オブジェクトの発明に行きいきさつは、 平行しているプロセスを表現するために, 対応するプログラム要素が,計算機で多重プログラム(multiprogram)処理されなければならない,というわけではない.しかし,プログラムは,一時的に停止(中断)し,後で止まっていたところから再び実行出来ることが必要である.そこで動作している対象,すなわちシミュレーションにおける“プロセス”は,スケジュール機
「ＯＯ（ＯＯＰ）とは何か？」については、ネタが割れてしまえばそんなに複雑なものではない…と個人的には最近、考えるようになってきています。 リスコフのユーザー定義型（aka、抽象データ型。データと手続きのセット）そのもの、あるいはその「ユーザー定義型」をクラスやそれに準ずる機能で実現しようとするＯＯ（ストラウストラップ。aka、クラス指向。継承を使ったプログラミング）。もしくはそれらを一般化したＯＯ（クック。aka、手続きによる抽象化）。 メッセージングにより動的性を実現しようとするＯＯ（ケイ。aka メッセージ指向） 今回登場した、後者のメッセージングのＯＯのミニマリズムをおしすすめることによって派生的に生じたＯＯ（アンガーとスミスからの 派生 変形。aka、プロトタイプベースＯＯ。フレームとスロット、あとは委譲機構があれば十分…というミニマル化の結果、アンガーとスミスの頃には重要だった“
「オブジェクト指向でなぜ作るのか」以来、OOP が解らなくなってしまった三猫です。あーー、もう、わっかんない、と混乱のまっただ中にいる私にかけられた、sumim さんの優しい言葉。 とりあえず、ケイのメッセージングのＯＯとストラウストラップら（リスコフ、メイヤーなど）の抽象データ型のＯＯの要点について、みねこあさんなりの解釈を簡単でいいので箇条書きにでもしてもらうことはできますか？ そこからすりあわせたほうがよいと思います。 http://d.hatena.ne.jp/minekoa/20080803#c1217824520 よーし！ 箇条書きといわず、がんばっちゃうぞー。（と暴走する私。） ストラウストラップのOOP ストラウストラップの考える OOP 、本当は、What is.. 論文 に当たるのが正しい姿なのですが、今の私の脳内というと、実は申し訳ないことに「プログラミング言語 C+
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
