OOP, DCI and Ruby - what your system is vs. what your system does — Saturn Flyer
If you've read my previous article on the tip of the iceberg with DCI then you might be curious to find out more about it. You read a very simple example that was only used to make a point. But for sure, you're left wondering a bit: Why not make some other class to manage this if we want to separate functionality? Is this at odds with the program's "connascence" And another good question came up i
DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticism
この記事はartima developerに掲載されている、Trygve Reenskaug氏とJames O. Coplien氏による記事「The DCI Architecture: A New Vision of Object-Oriented Programming」を、著作権者であるBill Bennrs氏の許可を得て翻訳したものです。本文内の図の著作権はArtima, Inc.に帰属します。（原文公開日：2009年3月20日） 要約 オブジェクト指向プログラミングはプログラマとエンドユーザの視点をコンピュータコードにおいて統一するものと考えられていた。この恩恵はユーザビリティとプログラムの分かりやすさの両面にわたる。しかし、オブジェクトは構造をとらえるのに長けている一方で、システムの動作をとらえることができていない。DCIはエンドユーザのロールに関する認識モデルとロール間の関係を
beとdoを分離する - ✘╹◡╹✘
http://clean-ruby.com/ The classes that we begin to define should represent data or model the behavior of the data object, but *not both* 札幌でおっさんっぽい人達がDCI、DCIって言って盛り上がってたから、最近DCIについて触れるためにClean Rubyって本をゆっくり読んでみてたんだけど、筆者がこういう主張をしてて、ナルホディウス、ナルホディウスですぞーって思ってた。どう在るかというのと、どう振舞うかというのは、それぞれ別の箇所でまとめて定義されているべきとのこと。実装としては、Userみたいなclassがデータ(=どう在るか:be)を定義していて、XXXableとかXXXerみたいなmoduleが処理(=どう振る舞うか:do)を定義していて、Us
else句を使わないのが良いコードなの？いや、そんなはずは・・・ · DQNEO日記
if (条件) { return 20; } else { return 30; } ↓ if (条件) return 20; return 30; こうすれば確かにネストは浅くなりますが、いつも毎回こう書く方がよいのでしょうか？ elseを書いた方がよいケースもあるのではないか 条件の部分が特殊・例外的な場合は、確かにこの方がわかりやすいと思います。 例えば、スーパーマリオで、マリオの状態が「無敵・チビ・大きい」の３種類しかないとします。 敵に触れたときの挙動を関数として書きます。 (オブジェクト指向っぽくないかもしれませんが、本記事の主眼はif-elseの書き方です。) function () { if (マリオ.is無敵モード) { 敵.死ぬ(); return ; } //以下、通常モードの場合のコードを書く } 無敵モードは特殊な状態だから、これはよいと思います。 しかし、マリオ
JavaScript脳で理解するRubyのオブジェクト指向
「世の中がRubyで埋まればいいのに」と思うあなたの気持ちとは裏腹に、世界は一層多様で複雑なものに向かっています。エントロピーは日々増大しています。 人々は、その非効率性を指して「多様性は悪である」といいます。しかし画一的世界は創作の原動力となる人々のモチベーションを低下させ、そのやる気を奪います。つまり複雑で理解できない混沌として多様な世界こそが、人々に前に進むエネルギーを注入するのです。 僕たちはハリウッド映画を見るとき、韓国ドラマを見るとき、それから日本人が演じるドラマを見るときに、その文化や歴史的背景に基づく演出の僅かな違いに目ざとく気付きます。そしてその違いによって脳は刺激を受け活動を開始するのです。何一つ同じものなどありません。 僕の脳は完全にJavaScript脳です1。他言語の知識は無いと言っていいです2。その結果、プログラム言語の世界が極めて画一的に見えています。これは極
オブジェクト指向エクササイズ - Strategic Choice
書籍「ThoughtWorksアンソロジー」の「第5章 オブジェクト指向エクササイズ」より。概要優れたオブジェクト指向設計の原理を自分のもにし、実際に使えるようになるためのエクササイズ。ほぼ必然的にオブジェクト指向になるコードを書くように強制する9つのルールを、1000行程度のプロジェクトで適用してエクササイズ。要するに、オブジェクト指向の「理解」を「実践力」にするための『練習』メニューの紹介。注意あくまで「練習」で、普遍的なルールとは限らない。ただし、筆者（Jeff Bay）は実際のプロジェクトで適用して上手く運用出来ているらしい。エクササイズ・ルール一覧ルール1：インデント１段階 1つのメソッドにつきインデントは1段階までにすることルール2：else句禁止 else句を使用しないことルール3：プリミティブ禁止 すべてのプリミティブ型と文字列型をラップすることルール4：ドット１つ 1行に
OOコード養成ギブス - rants
Binstock on Software: Perfecting OO's Small Classes and Short Methods The Pragmatic Programmersシリーズの新しい本、The ThoughtWorks Anthologyの中に 興味をそそるエッセイがある。Jeff Bayの"Object Calisthenics"だ。 これは良いオブジェクト指向の性質を実証する小さなルーチンを書く方法をマスターするための 詳細にわたるエクササイズだ。オブジェクト指向なルーチンを書く能力を向上させたい開発者がいるなら このエッセイに目を通すことを勧める。ここにBayのアプローチを要約してみよう。 彼は次にあげられる制約のもとに1000行のプログラムを書くことを勧めている。 これらの制約は意図的に過剰な制限となっているが、これは開発者を手続き的なやり方から脱却させるた
オブジェクトの広場
今月もオブジェクトの広場をどうぞお楽しみください。記事に対する感想は、ぜひ公式Facebookページのコメント欄までお願いいたします。（2023.12.20） 寝かせて使うソフトウェアコンテスト 本選レポート オージス総研主催のソフトウェアアイデアコンテストOGIS-RI Software Challenge Award 「寝かせて使うソフトウェアコンテスト」の本選と最終審査を2023年11月15日（水）に当社東京オフィスで開催しました。本レポートでは受賞作品と本選の様子をご紹介します。 はじめての自然言語処理 第30回 Elyza 日本語 Llama2 指示応答モデルのファインチューニングと vLLM での推論 今回は Elyza の日本語 Llama 2 指示応答モデルをファインチューニングし、vLLM にデプロイして高速に推論してみます。70 億パラメータモデルならギリギリ Tesl
ドラゴンボールで学ぶオブジェクト指向 改 - 達人プログラマーを目指して
ドラゴンボールといえば、大変に人気の高い国民的、いや世界的な漫画、アニメですが、昨日匿名ダイアリーでドラゴンボールをネタにしたオブジェクト指向の解説がホッテントリに入っていました。 ドラゴンボールで学ぶオブジェクト指向 多くの人に親しみやすい題材でオブジェクト指向の考え方を解説するというのは非常に興味深い試みなのですが、オブジェクト指向の説明としては不適切なところがあり、ちょっと残念な内容になっています。私自身ドラゴンボールの専門家（ドメインエキスパート）ではないため、不正確なところがあるかもしれませんが、ストーリーを思い出しながら、私なりにドラゴンボールをネタとしたオブジェクト指向の解説にリトライしてみたいと思います。 なお、オブジェクト指向でもプログラミング言語によって表現できる内容が異なるため、当然設計技法は違ってきます。ここではJava、C++、C#、Visual Basicといっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - PoohSunny/Hatena-Textbook: はてな研修用教科書