オブジェクト指向vs関数型プログラミングの壮絶な宗教戦争っていつしてたの……？ - Qiita
なんか荒れてますが、私も一言いいたいです！！ オブジェクト指向がそうであるように、関数型も銀の弾丸ではありません！！！ - 参照透過性はすばらしい この記事をぼやーんと眺めてました。 高精度煽り除去フィルタを通して読むと、関数型のアプローチがよい、と言う話ですね。 実際コードを書いてると、自分の書いたコードに関するバグは、体感、８割くらいが副作用に起因するものです。 副作用があると、呼び出し元が考慮すべきパターンが増えます。Mの状態を持つオブジェクトと、Nの状態を持つオブジェクトをつなぐと、MxNのパターンになるわけです。これはつなぐたびに積算されるため、爆発します。 副作用が無い場合、状態数は1なわけです。1x1は？1です！！よって、状態の組み合わせ爆発は起きません。考慮すべきは、入力値のパターンだけで十分なわけです。 他にもいろいろメリットが！！ すばらしき参照透過性！！関数世界最高で
オブジェクト指向は禁止するべき - きしだのHatena
プログラムがまだ不慣れな人が「プログラムちょっとわかるようになったけど、まだぜんぜんオブジェクト指向とかできてません」のように言ったり、ちょっと慣れた人が「このソース、ぜんぜんだめ。オブジェクト指向ができてない」にようなことを言ったり、まるで、オブジェクト指向ができてるかどうかがよいプログラムかどうかを表すことになってるようだ。 Javaのアルゴリズムの本に、「Javaなのにオブジェクト指向ができていない」のような書評がついているのを見たときには、お前は何を求めてるんだと思ったりもした。 そのようなオブジェクト指向は、窓から投げ捨てるべきだ。オブジェクト指向はプログラムのよしあしの基準にならない。 むだにHogeインタフェースとHogeImplクラスがあったり、むだにnewするだけのcreateメソッドがあったり、どこで値が設定されてるかわからないオブジェクトがひきまわされてたり、ソースコ
新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita
あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを理解することで、よりよいプログラムを書くためのもので、正確なソフトウェア工学の歴史を学ぶためのものではありません。正確な歴史を把握したい場合は、原典をあたるようにしてください。 また、想定している読者は「よくあるオブジェクト指向プログラミングの学習」を既にし
猫型プログラミング言語史観(1) 〜あるいはオブジェクト指向における設計指針のひとつ〜 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
TL;DR 手続き型プログラミングでは手続きを抽象化することで保守性を挙げることに成功したが、データを守ることには失敗してしまった。そこでオブジェクト指向はデータと手続きをひとかたまりにすることでデータを外から守るというコンセプトを打ち出した。 ここから、「手続き型プログラミングで書いてるのに手続きが十分に抽象化されていないのはヤバいね」とか「オブジェクト指向で書いてるのにひとかたまりじゃない雑多なデータに関心をもっちゃってるのはヤバいね」などの設計指針を導くことができるのである。そして純粋関数型言語の場合は……という話です。 はじめに プログラミング言語にはいろいろなパラダイムがあるが、その中で手続き型プログラミング、オブジェクト指向、純粋関数型言語について、わたしなりのひとつの史観を示すのがこの稿の目的である。となんかかっこつけて言ってみたんだけど、要するに、それぞれのパラダイムがどん
オブジェクト指向の概念の発明者は誰ですか？ - Smalltalkのtは小文字です
忙しい人のためのまとめ 一般に「オブジェクト指向プログラミング」と呼ばれる考え方には発案者が異なる二系統がある。（ただし簡単のため、次のうち前者から批判的に派生して生じたプロトタイプベースのオブジェクト指向はここには含めていない） アラン・ケイによる、変化に強い長期運用可能な遅延結合システムを SIMULA67 にあった「オブジェクト」をメッセージの受け手とすることで実現（オブジェクトにメッセージ送信）するアイデアに基づく「メッセージングのオブジェクト指向」と、 ビアルネ・ストラウストラップ（前後して抽象データ型を発案したリスコフ本人、オブジェクトクラスを考えたニガードらSIMULA陣営、Eiffelのメイヤーらも同様の着想を得ている）による、ユーザー定義型（抽象データ型）を SIMULA67 にあった「クラス」という言語機能を使って実現（カプセル化、継承、多態性）するアイデアに基づく「抽
“オブジェクト指向”の本質 - Smalltalkのtは小文字です
「ＯＯ（ＯＯＰ）とは何か？」については、ネタが割れてしまえばそんなに複雑なものではない…と個人的には最近、考えるようになってきています。 リスコフのユーザー定義型（aka、抽象データ型。データと手続きのセット）そのもの、あるいはその「ユーザー定義型」をクラスやそれに準ずる機能で実現しようとするＯＯ（ストラウストラップ。aka、クラス指向。継承を使ったプログラミング）。もしくはそれらを一般化したＯＯ（クック。aka、手続きによる抽象化）。 メッセージングにより動的性を実現しようとするＯＯ（ケイ。aka メッセージ指向） 今回登場した、後者のメッセージングのＯＯのミニマリズムをおしすすめることによって派生的に生じたＯＯ（アンガーとスミスからの 派生 変形。aka、プロトタイプベースＯＯ。フレームとスロット、あとは委譲機構があれば十分…というミニマル化の結果、アンガーとスミスの頃には重要だった“
プロトタイプベースの誤解 - Smalltalkのtは小文字です
クラスベースのOOとプロトタイプベースのOOで決定的に違うのは、プログラムを動かしている最中にオブジェクトが出来ること、すなわちメソッド(method)を追加したり再定義したりできるかだ。 404 Blog Not Found:タイプ・クラス・プロトタイプ - OOの語彙 これはひどい。ｗ オブジェクトに対して動的（実行時）にメソッドやインスタンス変数を追加できることと、“プロトタイプベース”においてオブジェクトがそれが属するクラスによらず独自のメソッドやインスタンス変数を持てることとは別の話です。 あらためて、「プロトタイプベース」という用語自体に問題が多いことを実感させられる記事でもありますね。個人的には、クラスを用いないオブジェクト生成手法の話でないのならば（つまり、「プロトタイプの複製でオブジェクトを生成する」ことが話の本筋でないならば）「プロトタイプベース」ではなく、「インスタン
プロトタイプベース・オブジェクト指向
prototype-based object oriented 。 オブジェクトがスロット（クラスのインスタンスならインスタンス変数やメソッドに相当）の追加をクラスに依存せずに自由にできることを前提としたオブジェクト指向。あるいはそうしたオブジェクトを用いたプログラミングや、それをサポートする機構。 「インスタンスベース」、「オブジェクトベース」とも。 これらへの言い換えは「プロトタイプベース」という言葉が持つ限定的なニュアンスを払拭するのにおおいに役立つ。しかし同時に、前者の「インスタンスベース」において特に、“プロトタイプベースにはクラスがない”あるいは“プロトタイプベースはクラスベースの対極にある（あるいはアンチテーゼである）”といったような教科書的記述に惑わされている人をひどく混乱させるらしく、極端な拒絶反応を示す人もいるので注意。また、後者においては、オブジェクトオリエンテッド＝
Rails、あんたなんか嫌いよ - Rails での OO 設計について - tomykaira makes love with codes
2013-06-25 Rails、あんたなんか嫌いよ - Rails での OO 設計について ruby rails 最近はずっと Rails 書いてるんですが、書けば書くほど嫌いになってくるんです。 倦怠期的なやつなんですが、 Rails さんの悪いところばっかり見えてきて、もう一緒にいたくないんです。 でも別れるほどじゃないし… という愚痴にみせかけた Rails での設計についての議論です。 長いけどコードは一切出てこないので通勤中にでもよんでください。 注意 一部にはげしい言葉遣いがでてくるので、読んで不快になるかもしれません。 不快になったとしても責任は負いかねます。 次のような方の期待に沿う結論はでません。残念でした。 Sinatra, Padrino の人 関数型の人 静的型付けの人 C の人 TL;DR Rails にだまされない。 自分の道を見定める。 欺瞞にみちた Ra
私が愛するオブジェクト指向とそれを使わない理由 - takuto_hの日記
この記事では、私がオブジェクト指向のどこを愛しどこを素晴らしいと感じていて、そのうえでなぜオブジェクト指向を使うことを避けているのかを書き留めておきます。関数型言語使いの方で、「オブジェクト指向の何がいいのかわからない」「オブジェクト指向難しすぎ・複雑すぎ」とおっしゃる方にぜひ読んでいただきたいと思っています。また、「オブジェクト指向言語完璧に理解したわ」と思っている方にも読んでいただきたく思います。 なお、ここでのオブジェクト指向の定義は、「各言語でオブジェクト指向と呼ばれているものすべて」とします。JavaやScalaやJavaScriptやSmalltalkやRubyやCommon LispやOCamlがオブジェクト指向と呼んでいるものすべての総称です。もっとまともな定義が知りたい方は以下の記事がおすすめです。 オブジェクト指向の概念の発明者は誰ですか？(改訂版) - Smallta
状態管理用の変数をインスタンスに持たせるなこのタコって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
たとえば、今、「ユーザーが方向を入力したらプレイヤーが動くゲーム作りたい」みたいなはなしがあるとする。その場合、モデルクラスはまあシンプルな実装として下のようなものが考えられると思う。 「できたよー」って見せにいったら、今度は「あのさー、『高速移動モード』っていうモード欲しいんだよね。そのモードだと二倍速で動くの」って言われたとする。シンプルにやるとこうなりますね。 「できたよー」って見せにいったら、今度は「なあ、すげえ面白いこと考えたんだけど、『蟹モード』って面白くない？横は4倍速で動くんだけど縦は半分の速度で動くの」とか言われたわけです。あなたは「お、おう」と言って、以下のようにコードを修正しました。 これ、ヤバい感じしますね。破滅の匂いがする。「今度は『よっぱらいモード』欲しいな〜。入力に関係なくランダムに動くの」みたいなこと言われたら確実に複雑さが爆発してメンテ不能になり鬱になり死
client-side javascript - ✘╹◡╹✘
JavaScriptのすごく初歩的なことでよくわからないので整理する。よくわかってなくてすごい恥ずかしい感じがするけど書いたら誰か何か教えてくれそうだし書く。client-sideのJavaScriptは、未だあまりよく分からずにもやもやしながら適当に書いてる。もやもや感が説明したいけどなかなか説明しづらい。 例 こういうタブをJavaScriptを使って実装する例を考える。タブをクリックすると、そのタブに切り替わるというやつ。 HTML CSS JavaScript Pattern 1 深く考えずに素朴に実装すると、こういう感じになる。clickイベントに与える無名functionの中に全部詰め込む。こういう風に書いてるJSのコードはよく見る。こういうの大量に書くのはすごい簡単だけど大量にこういうのが書かれてたら読むの辛い感じがする。 懸念 例えばこれまでRubyでコードを書いていたとき
Ruby脳が理解するJavaScriptのオブジェクト指向（その２）
「Ruby脳が理解するJavaScriptのオブジェクト指向 」の続きです。 引き続きJavaScriptのオブジェクト指向における「継承」について学んだので、自分の理解を書いてみます。当然に、間違いが含まれています。ご指摘助かります。 前回のまとめ 前回の記事では、JavaScriptの「オブジェクトの生成」、「プロトタイプチェーン」、「オブジェクトコンストラクタ」、「new演算子」の各概念について順にみました。これらを通したJavaScriptのオブジェクト指向に対する僕の理解は概ね次のようなものです。 すべてのオブジェクトは__proto__プロパティ（非標準）を持っていて、プロパティ探索に関し、ここにセットされたオブジェクトを順次たどりこれを解決する（プロトタイプチェーン）。__proto__にはデフォルトで空オブジェクトがセットされている。 同種オブジェクト（属性値だけが異なるオ
JavaScriptでオブジェクト志向的に、MVC的に書く - 憧れ駆動開発
完全に手続き的に書くというより、すこしMVCというかMVVC的な構造に切り分けてかいたらいいのではという内容。チラ裏に移動させた
Ruby脳が理解するJavaScriptのオブジェクト指向
(追記：2012-12-15) 本記事およびこれに続くその２，その３をまとめて電子書籍化しました。「Gumroad」を通して100円にて販売しています。内容についての追加・変更はありませんが、誤記の修正およびメディア向けの調整を行っています。 電子書籍「Ruby脳が理解するJavaScriptのオブジェクト指向」EPUB版 このリンクはGumroadにおける商品購入リンクになっています。クリックすると、オーバーレイ・ウインドウが立ち上がって、この場でクレジットカード決済による購入が可能です。購入にはクレジット情報およびメールアドレスの入力が必要になります。購入すると、入力したメールアドレスにコンテンツのDLリンクが送られてきます。 購入ご検討のほどよろしくお願いしますm(__)m 関連記事： 電子書籍「Ruby脳が理解するJavaScriptのオブジェクト指向」EPUB版をGumroadか
MOVEは望まれなかった子 - the sea of fertility
なにやらMOVEが話題です。 MVC is dead, it’s time to MOVE on. http://cirw.in/blog/time-to-move-on [翻訳]MVCは死んだ。MOVEするときがきた きしだのはてな http://d.hatena.ne.jp/nowokay/20120704 Twitterで「”MOVEは生まれた瞬間死んだ” って記事まだー？」って騒いでたら「お前が書けよ」の流れだったので息抜きに書きます。息抜きなので図が無いのは勘弁してください。 MOVEが生まれていない理由 この文中ではMOVEが生まれた理由はMVCの問題点に関わるとされており、そのMVCの問題点としてされているのは次の２点です。 MVCではControllerが肥大化する MVCは10年古い技術で設計されていて、最新のプログラミングパラダイムに対応していない。 しかしこの理由のう
やっと理解できた！JSオブジェクト指向プログラミング再入門 | ゆっくりと…
既に多くの方が JavaScript のオブジェクト指向的側面についての解説を記事にされていますが、読み手側から見ると、例えばプログラミング言語への習熟度やオブジェクト指向自体に対する理解度がマチマチなわけで、私自身、「おお、なるほど！」 っていう、頭の中のスイッチがパチンッ！と入るような境地には達していませんでした。 かつて私も オブジェクト指向なJavaScriptプログラミングのススメ なんていう翻訳記事を書いてはいるのですが、正直なところ prototype.constructor の存在は知りませんでしたし、Function.call や Function.apply をどう使えばよいのかなどをちゃんと理解できてはいませんでした。 そんな中、2011年12月に書かれた Doc Center | Mozilla Developer Network の記事 オブジェクト指向 Java
ECMAScript と OOP パラダイム、それに ES.next の議論中 OOP 周りのシンタックス - oogatta のブログ
JavaScript Advent Calendar 2011 (オレ標準コース)4日目の id:oogatta です。どうもどうも、いやどうも。 最近丁度 ES Wiki を眺めていて、面白いことになってるなあ。変態的なことになってるなあ。と楽しく見ていた OOP パラダイム周りのいくつかの手法（定義、継承、 mixin 、 trait ）について、 ES.next または Harmony で議論されているものをご一緒に調べながらご紹介したいと思います。 ECMAScript3 さて、復習としてまずは ES3 での OOP パラダイムの実装についてですが、これはもう Dmitry 先生の ECMA-262-3 in detail. Chapter 7.1. OOP: The general theory. を読んでくださいというか、気持ちよく丸投げしたいところですが、翻訳すると言ってまだ
小人閑居して: 「ぐへへお姉ちゃんパンツ何色」から始めるクラス解説
2011年12月6日火曜日 「ぐへへお姉ちゃんパンツ何色」から始めるクラス解説 「ぐへへお姉ちゃんパンツ何色」はこれ以上ないほどオブジェクト指向であり、しかも理想的な実装をしていることに気づきました。これを用いてオブジェクト指向を説明してみようと思います。 ある人が「ぐへへお姉ちゃんパンツ何色」と質問するのは、お姉ちゃんオブジェクトの保持するpants_color変数を取得しようとする手続きと見ることが出来ます。つまり oneechan.pants_color を取得しようとしているわけです。 ではどうすればいいのでしょうか？ 考えてみましょう。直接パンツを見ればpants_colorを取得することができますね。 クラスを使わないとすればこんな書き方が考えられます。 struct oneechan{ int pants_color; }; 構造体でひな形を宣言します。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
存在しない記事 - 標高+1m
