O/Rマッピングツールに対する誤解をときたい - give IT a try
2010.12.23 追記 本エントリの続編となる「実装編」のブログを書きました。 こちらも合わせて読んでみてください。 O/Rマッピングツールに対する誤解をときたい -実装編 Part1- - give IT a try 本文にコメントすると泥沼に巻き込まれそうなので、ここに書いておきます。。。 http://el.jibun.atmarkit.co.jp/g1sys/2010/05/post-2d1b.html なんかこのコラムのコメントを読んでいると、「O/Rマッピングツール(ORM)はSQLを書きたくない開発者のためのツールだ」と思われているような感じを受けます。 おいらはこれまでORMを使った開発プロジェクトに3回参加しました。 確かに最初のプロジェクトでは「SQLを書かなくてもいいんだよ」とリーダーから説明されたような記憶があります。 しかしその発想は大きな誤解です。 ORMを
OOP用語ひとめぐり - みねこあ
「素人でもわかりやすい」かどうか、素人には分からない。- うっくつさん本を読む。さんに なるほど、と思いました。 「わかりやすい」とは「素人でもわかりやすい」の意。 「わかりやすい説明」を求める人はその分野に関して素人である。これは「素人」という言葉の定義に由来するものだ。「素人」である以上、その対象を厳密に理解することはできない。だから「わかりやすい説明」は掻い摘んだ概要説明となる。 （中略） 「素人でもわかりやすい」かどうか、素人には分からない。 これが最大の問題だ。しばしば言われるのとは逆だが、素人には自分が正しく読み取れたかどうか判断できないのだから、同語反復と言っても良いほどに正しい。 そのため、素人が言うところの「素人でもわかりやすい」は「読みやすい」に過ぎない。 「素人でもわかりやすい」かどうか、素人には分からない。- うっくつさん本を読む。 ならば、ただ読みやすさだけを求め
OOPと自動メモリ管理 - みねこあ
Simula は サブルーチンの不自由さに対し改善を施すことで、クラスとオブジェクトを発明しました。その副作用として、コールスタックによる自動メモリ管理が使えなく(←「コイツ使えね~っ」の「使えない」）なってしまいました。 * * * 「階層的プログラミング構造」Ole-Johan Dahl, C.A.R Hoare より引用しつつ。 Simula が シミュレーションのための言語を模索する過程で クラス・オブジェクトの発明に行きいきさつは、 平行しているプロセスを表現するために, 対応するプログラム要素が,計算機で多重プログラム(multiprogram)処理されなければならない,というわけではない.しかし,プログラムは,一時的に停止(中断)し,後で止まっていたところから再び実行出来ることが必要である.そこで動作している対象,すなわちシミュレーションにおける“プロセス”は,スケジュール機
staticとinstanceと。 - たかふーのブログ
弊社の新人のブログより。 わたしの中で、概念的なものはわかっているのですが、実際に自分で使い分けろと言われてもどういう時に使い分けたらいいのかがわからないのでパッとしません。。。。 会社の先輩が書いたソースをみると、共通処理をクラスメソッドにしています。 でも、共通処理でもクラスメソッドにできないものもあるみたいで・・・・・。 インスタンスとクラス - yumicroの日記 これについて考えてみました。 この新人が配属されている部署から考えて、ズバリ「先輩に聞いて先輩が言った通り作る」がベストな訳で、でもそうすると話が終わってしまうのとSIerと呼ばれる企業の黒い部分をいろいろ掘り起こさなくてはならなくなるのでやめましょう。 クラスフィールド、クラスメソッドとインスタンスフィールド、インスタンスメソッドの使い分けは、クラス設計とかコード設計と呼ばれる作業になります。SIerの仕事の仕方だと
10/3LTメモ：オブジェクト指向について - @katzchang.contexts
発散しそうなので、演目を変えそうな予感がします。 自動車とトラックと乗用車をオブジェクト指向でモデリングするより、オブジェクト指向モデル/プログラムを実物でモデリングしてみる演目にしよう…かな。それにしても5分じゃキツい。 オブジェクト指向とは オブジェクト指向（オブジェクトしこう）とは、オブジェクト同士の相互作用としてシステムの振る舞いをとらえる考え方である。英語の object-oriented (直訳は、「対象物志向の」・「目的重視の」という意味の形容詞) の日本語訳である。 オブジェクト指向 - Wikipedia だいたい合ってる。 オブジェクトの相互作用で云々を逆に言うと、オブジェクトと呼ぶ単位で処理を分割していくこと。つまり、他のオブジェクトへ委譲して、目的を達成すること。 クラスとは クラス（class）は、クラスベースのオブジェクト指向においてオブジェクトの設計図にあたる
フィールドごとに getter/setter を用意するな - ぐるぐる～
未だにフィールドごとに getter/setter を用意しろって言う人がいてびっくりするわけですが。 フィールドごとに getter/setter を用意する人の言い分 そうやれって本/Webページに書いてある フィールドに触れないと不便だろう それが OOP だ 言い分に対する反論 そうやるなって本に書いてある 5章 オブジェクト指向エクササイズ 5.2.10 ルール9：Getter、Setter、プロパティを使用しないこと ThoughtWorksアンソロジー List<Book> getBooks() { return books; } これはクライアントに最大限の柔軟性を提供するが、さまざまな問題を生み出す. コレクションをそのまま返すと, その内容に依存している内部状態が知らない間に無効にされてしまうかもしれない. 略 代わりに, コレクション内の情報への, 限定された, 意味
オブジェクト指向の概念の発明者は誰ですか？ - Smalltalkのtは小文字です
忙しい人のためのまとめ 一般に「オブジェクト指向プログラミング」と呼ばれる考え方には発案者が異なる二系統がある。（ただし簡単のため、次のうち前者から批判的に派生して生じたプロトタイプベースのオブジェクト指向はここには含めていない） アラン・ケイによる、変化に強い長期運用可能な遅延結合システムを SIMULA67 にあった「オブジェクト」をメッセージの受け手とすることで実現（オブジェクトにメッセージ送信）するアイデアに基づく「メッセージングのオブジェクト指向」と、 ビアルネ・ストラウストラップ（前後して抽象データ型を発案したリスコフ本人、オブジェクトクラスを考えたニガードらSIMULA陣営、Eiffelのメイヤーらも同様の着想を得ている）による、ユーザー定義型（抽象データ型）を SIMULA67 にあった「クラス」という言語機能を使って実現（カプセル化、継承、多態性）するアイデアに基づく「抽
“オブジェクト指向”の本質 - Smalltalkのtは小文字です
「ＯＯ（ＯＯＰ）とは何か？」については、ネタが割れてしまえばそんなに複雑なものではない…と個人的には最近、考えるようになってきています。 リスコフのユーザー定義型（aka、抽象データ型。データと手続きのセット）そのもの、あるいはその「ユーザー定義型」をクラスやそれに準ずる機能で実現しようとするＯＯ（ストラウストラップ。aka、クラス指向。継承を使ったプログラミング）。もしくはそれらを一般化したＯＯ（クック。aka、手続きによる抽象化）。 メッセージングにより動的性を実現しようとするＯＯ（ケイ。aka メッセージ指向） 今回登場した、後者のメッセージングのＯＯのミニマリズムをおしすすめることによって派生的に生じたＯＯ（アンガーとスミスからの 派生 変形。aka、プロトタイプベースＯＯ。フレームとスロット、あとは委譲機構があれば十分…というミニマル化の結果、アンガーとスミスの頃には重要だった“
Rees Re: OO
著者: Jonathan Rees 原文: http://www.paulgraham.com/reesoo.html 日本語訳：Shiro Kawai (shiro ＠ acm.org) これを翻訳したのは2004年7月頃だったのだが、 このメッセージについてRees氏に訳文公開の許可を求めたところ、 「あれは急いで書いたemailなので、きちんとした論になっていない。 できれば書き直したいと思っている。ただいつ出来るかわからないので、 私からのメイルがしばらく無かったら公開してもらって構わない」 との返事をもらった。それからもう半年経つので、公開することにした。 ただ、読む場合は著者本人が上記のように思っていることを留意して頂きたい。 また、原文が書かれたのは2002年であることにも注意。 いくつかの事実は古くなっているかもしれない。 2005/01/23 翻訳公開 「なぜArcはとり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
