新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita
あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを理解することで、よりよいプログラムを書くためのもので、正確なソフトウェア工学の歴史を学ぶためのものではありません。正確な歴史を把握したい場合は、原典をあたるようにしてください。 また、想定している読者は「よくあるオブジェクト指向プログラミングの学習」を既にし
私が愛するオブジェクト指向とそれを使わない理由 - takuto_hの日記
この記事では、私がオブジェクト指向のどこを愛しどこを素晴らしいと感じていて、そのうえでなぜオブジェクト指向を使うことを避けているのかを書き留めておきます。関数型言語使いの方で、「オブジェクト指向の何がいいのかわからない」「オブジェクト指向難しすぎ・複雑すぎ」とおっしゃる方にぜひ読んでいただきたいと思っています。また、「オブジェクト指向言語完璧に理解したわ」と思っている方にも読んでいただきたく思います。 なお、ここでのオブジェクト指向の定義は、「各言語でオブジェクト指向と呼ばれているものすべて」とします。JavaやScalaやJavaScriptやSmalltalkやRubyやCommon LispやOCamlがオブジェクト指向と呼んでいるものすべての総称です。もっとまともな定義が知りたい方は以下の記事がおすすめです。 オブジェクト指向の概念の発明者は誰ですか？(改訂版) - Smallta
Rogue Engineer's Hideout by Hideo Fukumori
(=やさぐれエンジニアのかくれが） by Hideo Fukumori / 福盛秀雄 細々とやっております。 作者について（準備中…） やさぐれ日記 さまざまな文章(の予定) オブジェクト指向プログラムでgetter/setterメソッドを使わなければならない10の理由 「ファッションとしてのUML」 「発明なき特許」？ 「共有」モデルと「パーソナル」モデルの「す れ違い」 「将棋の定跡」と「デザインパターン」 「CPUの創りかた」製作編 PDP-11シミュレータで古代のUNIXを動かしてみる 日記/blogの「カテゴリ分け機能」について考えてみた 哲学者たちとハッカーたち セマンティクス、シンタックス、Web、そして機械翻訳 僕らには用件が必要だ 逃げれば追ってくる audible.comの小技 「デザインパターン」という薬 "オープンソースカンファレンス2005"行ってきたよ （僕らの
デザインパターンを読み解く
ポリモーフィズム（サブクラスによる切り替え、抽象化） ここに分類されるのは、オブジェクト指向の第３原則、ポリモーフィズムを使用したパターンです。ポリモーフィズムを使用すると、動的に使用するクラスを切り替えることができます。＜参照＞ 他に分類されているものでも、ポリモーフィズムが重要な位置を占めているものもありますが、ここではそれしか使われていないものを扱います。 ただデザインパターン全体を通して強調されているのは、インターフェースでプログラミングするということです。実装への依存をなくし、そうすることによって設計の骨組みを明らかにするのです。 Template 次のようなメソッドがあった場合に、処理Bのところを条件によって変えたい場合があるとします。 class Hogehoge { void doit() { ... 処理A ... ... 処理B ... ... 処理C ... } }
第4回 オブジェクト指向の本質 | gihyo.jp
エンジニアとして良い仕事をするために必要なこと ソフトウェア業界で日米を往復しながら仕事をしていると、世界中のさまざまなエンジニアに会う。私のように「プログラミングを心底楽しんでいる」人から、「新3K」（きつい・厳しい・帰れない）を身をもって体験している人までさまざまだが、共通して言えることは、エンジニアとしての基礎がしっかりできている人とできていない人では、その生産効率に大きな開きがあり、それが結果的には、会社での労働環境や待遇に、そして結果として自分自身にとっての「仕事の充実度」に、大きな影響を与えているということである。 いつも締め切りに追われている、毎回バグで苦しんでいる、徹夜の連続で体力に限界がきているなど、「仕事がきつい」理由はいろいろとあると思うが、会社や上司の悪口を言う前に、自分自身がプロフェッショナルなエンジニアとしてこの業界で勝負をするうえで必要な最低限の基礎がで
Webプログラミングは何故オブジェクト指向でない？～WicketはWebプログラミングにオブジェクト指向を取り戻す - プログラマの思索
Webプログラミングは何故オブジェクト指向でない？～WicketはWebプログラミングにオブジェクト指向を取り戻す JavaでWebアプリを10年書いて思ったこと。 Webプログラミングは全然オブジェクト指向でない。 Sevlet＋JSP主体のプログラミングスタイルは、リクエストとレスポンスへPrimitiveな値をどうやって渡すか、という手続き型の発想でしか書いていない。 従来のWebプログラミングスタイルの問題点について書いてみる。 以下ラフなメモ書き。 【参考リンク】 Wicketって？ ウェブ開発をもう一歩前に Wicketで始めるオブジェクト指向ウェブ開発：第1回 Hello, Wicket｜gihyo.jp … 技術評論社 【コラム】イマドキのIDE事情 (39) Wicket、Grails、Click - IDEでみる軽量Javaフレームワーク | エンタープライズ | マイ
DCIが面白い件 - ヽ( ・∀・)ノくまくまー(2010-05-12)
● DCIが面白い件 DCI凄い！ヤバイ！ 「DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien」(翻訳) http://d.hatena.ne.jp/digitalsoul/20100131/1264925022 前に読んだときは難しすぎて(長すぎて)途中で挫折したけど、今改めて読んだらDCIは凄いと気付いた。以下、まとめ。 今回、内容理解の決め手となったのは「前半部分を読まない」ことだった。 そんな無謀な読み方(読んでないのだけれど)をした私の理解なので、 もちろん間違いはあるはず。 という前提で、 ツッコミを入れる気満々なテンションでどうぞ。 古来からプログラムの中心は＜データ＞であった なぜなら、それが設計の中で一番変化しにくい要素(箇所)であるから そして、＜データ構造＞とそれに対する＜処理＞の2つで考えるようになった (手続き型
データ構造はクラスに任せた！だから、アルゴリズムはstatic関数で書くぜ！！（キリッ - みねこあ
きむら(K)さんち経由、実はオブジェクト指向ってしっくりこないんです！。いろいろ強烈なインパクトが満載で、スルーできませんでした。 特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。 staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。 ぎゃーっ....。本人はまわりを笑っているつもりでも、逆にまわりに嗤われていますよ、絶対。 ここ以外にも突っ込みどころ満載のエントリーですので、読みながら突っ込むお手々が止まらなくって、腕がつりそう。そんな突っ込み連打なエントリーもおもしろそうですが、わたしはそういうのは上手く書けないので（性格がネチっこいから、なんだ
“オブジェクト指向”の本質 - Smalltalkのtは小文字です
「ＯＯ（ＯＯＰ）とは何か？」については、ネタが割れてしまえばそんなに複雑なものではない…と個人的には最近、考えるようになってきています。 リスコフのユーザー定義型（aka、抽象データ型。データと手続きのセット）そのもの、あるいはその「ユーザー定義型」をクラスやそれに準ずる機能で実現しようとするＯＯ（ストラウストラップ。aka、クラス指向。継承を使ったプログラミング）。もしくはそれらを一般化したＯＯ（クック。aka、手続きによる抽象化）。 メッセージングにより動的性を実現しようとするＯＯ（ケイ。aka メッセージ指向） 今回登場した、後者のメッセージングのＯＯのミニマリズムをおしすすめることによって派生的に生じたＯＯ（アンガーとスミスからの 派生 変形。aka、プロトタイプベースＯＯ。フレームとスロット、あとは委譲機構があれば十分…というミニマル化の結果、アンガーとスミスの頃には重要だった“
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行のプログラムを書くことを勧めている。 これらの制約は意図的に過剰な制限となっているが、これは開発者を手続き的なやり方から脱却させるた
プロトタイプベースの誤解 - Smalltalkのtは小文字です
クラスベースのOOとプロトタイプベースのOOで決定的に違うのは、プログラムを動かしている最中にオブジェクトが出来ること、すなわちメソッド(method)を追加したり再定義したりできるかだ。 404 Blog Not Found:タイプ・クラス・プロトタイプ - OOの語彙 これはひどい。ｗ オブジェクトに対して動的（実行時）にメソッドやインスタンス変数を追加できることと、“プロトタイプベース”においてオブジェクトがそれが属するクラスによらず独自のメソッドやインスタンス変数を持てることとは別の話です。 あらためて、「プロトタイプベース」という用語自体に問題が多いことを実感させられる記事でもありますね。個人的には、クラスを用いないオブジェクト生成手法の話でないのならば（つまり、「プロトタイプの複製でオブジェクトを生成する」ことが話の本筋でないならば）「プロトタイプベース」ではなく、「インスタン
オブジェクト指向の概念の発明者は誰ですか？ - Smalltalkのtは小文字です
忙しい人のためのまとめ 一般に「オブジェクト指向プログラミング」と呼ばれる考え方には発案者が異なる二系統がある。（ただし簡単のため、次のうち前者から批判的に派生して生じたプロトタイプベースのオブジェクト指向はここには含めていない） アラン・ケイによる、変化に強い長期運用可能な遅延結合システムを SIMULA67 にあった「オブジェクト」をメッセージの受け手とすることで実現（オブジェクトにメッセージ送信）するアイデアに基づく「メッセージングのオブジェクト指向」と、 ビアルネ・ストラウストラップ（前後して抽象データ型を発案したリスコフ本人、オブジェクトクラスを考えたニガードらSIMULA陣営、Eiffelのメイヤーらも同様の着想を得ている）による、ユーザー定義型（抽象データ型）を SIMULA67 にあった「クラス」という言語機能を使って実現（カプセル化、継承、多態性）するアイデアに基づく「抽
メッセージ指向なオブジェクト指向でのUMLって？
オブジェクト指向は単なるオブジェクト間のメッセージのやり取りに過ぎない、という言葉は、僕の身近な人たちにとっては僕から一度は聞いたことがあるだろう。そんな考えに関して注目エントリが下記。書いてある内容はほぼ同意なんだけど、部分的に引っかかりを感じざるを得ないので、僕の意見をエントリしてみる。 「 イマドキのオブジェクト指向」- アークランプ より： では、「イマドキのオブジェクト指向」とは何か。それはメッセージ指向という解釈です。オブジェクト指向は「メッセージによる処理の分割」であり、「分離された処理をオブジェクトと呼ぶ」と定義します。これまではオブジェクト指向とは「オブジェクトによる処理の分離」であったわけです。 太古の昔から、オブジェクトは「メッセージのやり取りによる処理の委譲の繰り返し」だったはず。「継承ではなく委譲を使いましょう」なんて思想は、オブジェクト指向の基本であり、それはメ
「ゲームとオブジェクト指向と一流の条件」 - カレーなる辛口Javaな加齢日記
http://d.hatena.ne.jp/shi3z/20071016/1192519532 どうも最近、若い「プログラマ」の方々と話をすると話が噛み合ない。 話をよーく聞いてみると、クラスとオブジェクトの区別がついていなかったり、継承と集約(とコンポジション)の区別がついていなかったりして、「もっと多態性を活かしたクラス設計にしなさい」と言うと、「多態性ってなんですか?」と逆に聞かれる始末で、これってゆとり世代よりずっと深刻なんじゃないかと思ったりした。仮にもプロとして。 これには全く同意． クラスとオブジェクト(インスタンス)の区別やポリモフィズム／多態性はOOPの基本中の基本だ．多態性／ポリモフィズムという「単語」は必ずしも知らなくてもいいけれど，そういう機能を使ったコードが書けないし，そういう発想がない人が多すぎる．それでJavaやC++やRubyを使ってると言うのはおこがましい
リスコフの「抽象データ型」について - Smalltalkのtは小文字です
「A History of CLU」(PDF) の 2. Data Abstraction からの抜粋。 概要 「抽象データ型」という考え方は、リスコフらにより 1972 年の終わりから 1973 年の夏頃までにまとめられた。 「抽象データ型」は、データとオペレーションのセット。 データの内部情報へのアクセスはこのオペレーションを介してのみ行える。 データの内部情報に関する詳細は隠蔽されている。 成立までの流れ 当時は、プログラミングの効率やコードの質を向上させるための手法に大きな関心が払われていた。 二つの流れが存在。ひとつはダイクストラの構造化プログラミング。もうひとつがモジュール化。 モジュール化については、リスコフも自ら「パーティション」という機構を提唱。 これはダイクストラの「抽象化レベル」という概念に基づいている。 システムは抽象化レベルごとパーティションで表わされ、パーティシ
Java講座
Java講座 1. ケアレスミスを減らす章 1.1. while ループより for ループ 1.2. 配列を返すメソッド 1.3. チェーンコンストラクタ 1.4. キャッチした例外は必ず使う 1.5. リテラルの比較 1.6. 列挙型の定義 2. 堅牢性を獲得する章 2.1. ユーティリティクラス 2.2. フィールドの可視性 2.3. メソッドの可視性 2.4. クラスの可視性 2.5. 配列フィールド定数 3. 拡張性／柔軟性を獲得する章 3.1. ファクトリーメソッド 3.2. 怠惰な初期化 3.3. 継承はカプセル化を壊す 3.4. 継承の悪い例 3.5. 継承の良い例 3.6. インターフェースの不要な修飾子 3.7. インターフェースで定数定義 3.8. 改行コード 3.9. データの入れ物として使わない 4. 知っていると便
.NET/Java向けオブジェクトDB·db4o MOONGIFT
最近は優秀なO/Rマッピングツールが出てきたお陰でそれ程苦労もなくなったが、プログラムとRDBMSはやはり相性が良いとは思いがたい。SQLを書いて、その結果を取り出して…というのはいまいち面倒だ。 現状でも効率的な更新や複雑なデータ抽出についてはやはりSQLを書く必要がある。複雑な場合にSQLを書くというのは面倒この上ない。そこで試してみたいのがオブジェクトデータベースだ。 今回紹介するオープンソース・ソフトウェアはdb4o、.NET/Javaにネイティブなオブジェクトデータベースだ。 db4oは.NET/Javaに対してネイティブに動作させることができる。monoにも対応しているので、WindowsのみならずLinuxやBSDにも対応しているのが利点だ。組み込みをはじめとして、利用実績も徐々に出てきているようだ。 利用範囲には向き不向きがあるだろう。また、現状では速度と言う面ではRDBM
「嫌われるオブジェクト指向」のパターン - カレーなる辛口Javaな加齢日記
なぜオブジェクト指向は嫌われているのか？:http://alfalfa.livedoor.biz/archives/51079543.html 憂鬱本なんかの屑本を鵜呑みにして、失敗している人が多いからでは．類書は他にも多数．*1 憂鬱なプログラマのためのオブジェクト指向開発講座 (DDJ Selection) 作者: Tucker出版社/メーカー: 翔泳社発売日: 1998/05/31メディア: 大型本購入: 10人 クリック: 508回この商品を含むブログ (78件) を見るいちばんやさしい オブジェクト指向の本 (技評SE新書 007) 作者: 井上樹出版社/メーカー: 技術評論社発売日: 2007/01/19メディア: 新書購入: 2人 クリック: 57回この商品を含むブログ (38件) を見るオブジェクト脳のつくり方―Java・UML・EJBをマスターするための究極の基礎講座 作
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
https://dl.acm.org/doi/10.1145/96709.96721