オブジェクト指向は禁止するべき - きしだのHatena
プログラムがまだ不慣れな人が「プログラムちょっとわかるようになったけど、まだぜんぜんオブジェクト指向とかできてません」のように言ったり、ちょっと慣れた人が「このソース、ぜんぜんだめ。オブジェクト指向ができてない」にようなことを言ったり、まるで、オブジェクト指向ができてるかどうかがよいプログラムかどうかを表すことになってるようだ。 Javaのアルゴリズムの本に、「Javaなのにオブジェクト指向ができていない」のような書評がついているのを見たときには、お前は何を求めてるんだと思ったりもした。 そのようなオブジェクト指向は、窓から投げ捨てるべきだ。オブジェクト指向はプログラムのよしあしの基準にならない。 むだにHogeインタフェースとHogeImplクラスがあったり、むだにnewするだけのcreateメソッドがあったり、どこで値が設定されてるかわからないオブジェクトがひきまわされてたり、ソースコ
私なりのオブジェクト指向プログラミングの定義 - kmizuの日記
きしださんの以下のツイート オブジェクト指向はこの20年だれも再定義せずみんな自分の思うオブジェクト指向を暗黙に仮定して適当に話してるだけなので、技術的な共通認識のもとの議論はほとんどできないんですよ。という話を「オブジェクト指向をきちんと使いたいあなたへ」の記事に書いたのだけど、そろそろ公開するか— きしだൠ(K8S(Kishidades)) (@kis) July 29, 2019 を読んで、そういえば、私が思うオブジェクト指向の定義、についてツイッター以外ではあまり語ったことがなかったなと思い返し、ちょっと記事にしてみることにしました。まず、結論からいうと、私はオブジェクト指向プログラミングとは サブタイピングを活用したプログラミング手法の総称 と考えています。ここで、クラス継承とかインタフェース継承とかダックタイピングとかではなく、単にサブタイピングであるのがポイントです。なお、型
Open Recursion in scala もしくは関数型もオブジェクト指向も仲良くしようよぉのお話 - ろじかるんるんものがたり
追記：これの完全版みたいなのが comfrk vol3 に載ってます。「今夜はお前と俺でマルチパラダイムだからな」とかいうのです。 あまりにもアウトプットしなさすぎなので適当に何か書きます。 フィボナッチ関数を scala で object-oriented な感じで書いてみます。 class Fib { def fib(n : Int) : Int = if (n <= 1) 1 else fib(n - 1) + fib(n - 2) } 簡単ですね。しかし、簡単すぎます。というわけで、お決まりのメモ化を「Fib クラスに手を加えず」に行ってましょう。 class FibMemo extends Fib { import collection.mutable.Map private val table : Map[Int, Int] = Map() override def fib(n
オブジェクト指向が0.05%も理解できない記事
尽く書を信ずれば即ち書無きに如かず 《孟子『尽心下』より》 イントロダクション 「最も理想的なオブジェクト指向を実現しているプログラミング言語は何か？」と問われたとき、君は何と答えるだろうか？ C++、Java、C#。君がそうだと思っているのは表面だけで、たぶん何もわかっていないのだろう。無知であることを知っているのであれば、無知のまま過ごした方が幸せなときもある。 Simula、Smalltalk、Ruby。君は本質をいくらか知っているようだから、引き返すなら今のうちだろう。深淵を覗けば、君もまた怪物にならざるを得ない。 JavaScript、Python、Go。君が真剣にそう答えるなら、私とは異なる真理に辿り着けたのだろう。君と私のどちらかが正しいのではない、どちらも常に正しく、どちらも常に間違っている。 Erlang、Elixir。君は既に答えを知っているようだから、この記事は全く以
『「実はオブジェクト指向ってしっくりこないんです！」から7年』
「実はオブジェクト指向ってしっくりこないんです！」が掲載されてから、今年で７年が経った。コメントを見ると当時多くの方がオブジェクト指向万能主義者であったことが窺える。はたしてポリモーフィズムでプログラムから条件分岐をなくすことができたのか？ もしあなたがポリモーフィズムで条件分岐をなくすプログラマーであったとしよう。それを高い技術力と認め、あなたを高額な給与条件で雇用する開発会社が存在すると思えますか？ そんなわけないだろう！仮にできたとしても、画期的なアルゴリズムでも何でもないのであるから、技術的価値やビジネス的なメリットは少ないですよ。 たいしたスキルを持っていないエンジニアもクラスが書けるというだけで、オブジェクト指向を駆使していると思ってるが、それってモジュールを作ってるだけで、オブジェクト指向の本質と関係ありません。オレオレクラスをボコボコ作ってしまい、誰もメンテンスできなくなる
Haskell vs OOP - あどけない話
「Why Haskell matters?」(なぜ Haskell は重要か？)には、Haskell とオブジェクト指向プログラミングを比較した章があります。日本語訳が見当たらなかったので、必要な部分を訳してみます。 オブジェクト指向プログラミングの優れた利点は、データとそれに作用する関数を一つのオブジェクトにまとめられることではない。優れた利点、それは、(実装からインターフェイスを切り離せる)データのカプセル化と、(型の一群の振る舞いを同じようにする)多相性だ。しかしながら、データのカプセル化と多相性は、OOP の専売特許ではない！ いやぁ、心洗われる文章です。:-) データのカプセル化 Haskell でのデータのカプセル化は、それぞれのデータ型をそれぞれのモジュールで宣言し、そのモジュールからインターフェイスだけを公開することで実現できる。モジュール内部には、内部データに触れる関数群
プログラミング。好きだけど、さようなら。
追記(2015 5/20) 洋食屋にジョブチェンジを果たしました。 --- 1年の間、プログラマとして働いていたが、続けていくことが無理だと思い、さようならする話。 プログラマになる前は、コーヒー屋で働いていた。しかし、色々とあり辞め、職業訓練校に通ってプログラミング(php)を学び、60人ほどのソフトウェア開発会社に就職した。 会社に入ると、まずC#の研修があった。研修と言っても、C#で内製ツールを独りで作るという研修だった。この研修中に「あれ、オレ、プログラム書けねー」と思ったりしたが、研修は終えることができたし、社内の人にも「なかなか良く出来ている」と言ってもらえ、大丈夫だろうと思っていた。 研修が終わり、C#の社内で実際に使われているツールに、機能をいくつか追加する仕事を振られた。前任者にどんな設計になっているのか大雑把に聞き、なんとなくイメージができ、コードを読み始めたのだが、こ
僕にとってMaybe / Nullable / Optional が、どうしてもしっくりこないわけ。 - 亀岡的プログラマ日記
はい、ポエムです。自分が正しかろうとは欠片も考えていません。異論や示唆は歓迎ですが、そう考えろと言っているわけではないので、そこはご容赦を。 前置き終わり。 さて、Nullは50億ドルの過ちだそうですね。 null参照の考案は10億ドル単位の過ち？ | スラド デベロッパー そして、それを回避するため、Maybe / Nullable / Optional などの言語機能が生まれ、各言語に埋め込まれています。 それは、大変喜ばしいこと、だと思います。 なんですが、どうもどうも、僕はどうしてもしっくりこないのです。これら全てに対して。Nullと同じように。 Nullは何がダメなんだっけ？ Nullがダメな理由、ってなんなんでしょう。よく言われる批判として、以下があるのかなぁと思っています。 ①Nullは型ではない Nullと言っていますが、こいつはNullポインタ、でございます。 からの「何
抽象クラスはなぜ必要か？
Javaプログラミングを勉強しています。 抽象クラスについて疑問を持ちました。 結論から言うと、 ・抽象クラスって必要でしょうか？ ・現場でそんなに使っているのでしょうか？ 抽象クラスの特徴としては以下の認識です。 ・インスタンス化できない。 ・サブクラスに継承することを前提に作成される。 ・抽象クラスで宣言された抽象メソッドは継承されたサブクラス側で必ずオーバーライドされなければならない。 その結果、メリットは以下の2点であると思われます。 ・サブクラス定義時にメソッドに間違いがあればコンパイルエラーが起き、コーディングミスを避けられる。 ・複数のクラスで共通の名前や呼び出し方をもつメソッドは抽象クラスで抽象メソッドとして宣言しておき、それをサブクラスで実装させるようにできる。 たしかにこの2点がメリットではあるけれど、現場でそんなに使っているのでしょうか？ 共通で使うなら、具象クラスに
オブジェクト指向でゲームを作るのをやめよう - Qiita
若干釣り気味です、すいません！！！！！！というかまさかり期待してます、ください。 題の通りです。オブジェクト指向パラダイムはゲームプログラミングと相性が悪いです。 どうもプロのゲームプログラマには常識っぽいんですが、ホビーゲームプログラマにはあまり浸透してないみたいです。（調べてようやく認識しました……） ある日曜プログラマの憂鬱 ある日突然モグラたたきが作りたくなりました。なったんです！！ さて、モグラ叩きに登場するオブジェクトを考えます。 モグラが当然いりますね。 というわけでこんな感じに設計しました。 詳細な実装をつめていって、とうとうプロトタイプが完成しました！！ やった！！…と言いたいところなんですが、なんだか物足りないのです。 そこでかんがえました、叩いたらダメなウサギを作ろうと。 出たり引っ込んだりするのは同じなので、モグラを継承することにしました（説明のためわざとです、突っ
Haskellの型クラスを活用する - モナドとわたしとコモナド
Haskellの型クラスは、うまく使えば高いパフォーマンスと抽象度を両立できる、優れた仕組みである。その使い方のコツは、決して理解の難しいものではない。 小さな性質、大きな恩恵 プログラマは大きなものを小さく見せがちだ。オブジェクト指向プログラミングに慣れている人がやりがちなアンチパターンとして、欲しい機能と、それを分割する基準が現実に寄りすぎていて、一つ一つが巨大というものがある。 普通のプログラミングではありえない例かもしれないが、たとえば家を作りたいことを考える。「ベッド」「箪笥」「台所」「冷蔵庫」「トイレ」「風呂」のように設備ごとに分けた抽象化をしたいと考えるだろう。確かにこれは理に適っているように見える。だが、これらの設備を型クラスでまとめるのは悪手だ。 風呂やトイレには水を利用できるという性質が、冷蔵庫には電気が必要だ。部屋と部屋は壁で仕切られ、場合によっては扉があるかもしれな
Haskellでいかに多態を表すか - モナドとわたしとコモナド
オブジェクト指向を行使する心 ではオブジェクト指向の必要性と仕組みについて議論した。 インスタンスは言語によって様々な実装方法があるが、大きく分けて「クラス(処理)のインデックス」か「処理そのもの」のどちらかがインスタンスの内部に隠れている。 と述べたが、Haskellの場合、クラスのインデックスに基づいた表現では、インターフェイスは型クラス、クラスはインスタンス、インスタンスは存在量化された型の値に対応する。…といってもややこしいことこの上ないので、実装例を考えてみよう。 まず、問題となっている愚直な実装は、Haskellではこんな感じだ。 data World = World { … } data SceneId = Menu | Map | Battle draw :: SceneId -> World -> IO World draw Menu = … draw Map = … d
オブジェクト指向を行使する心 - モナドとわたしとコモナド
今日、とあるツイートでプログラミングにおけるよくある問題が顕現していた。 プログラミングしてそうなサークル探したら、ゲーム公開してて、ソースコード公開されてたから見た。 pic.twitter.com/7W09sb9DFa— タコス(祭り) (@tacosufestival) 2015, 4月 4 奇妙な行コメントには目を瞑るとして、このコードは要約すれば以下のような処理を実現していることが窺える。 ゲームプログラミングでは、現在のシーンによって処理を切り替える必要がある。メニュー画面ならメニューの処理を、戦闘画面なら戦闘を、マップならマップの表示をそれぞれ行う。 現在のシーンの種類は変数によって与えられる。 その変数の値によって、対応する処理を選ぶ。 こうしてみると単純だが、caseによる単純な分岐では扱いにくい。新しいシーンを作るたびに場合分けを書き換えなければならないし、何よりそれは
オブジェクト指向関連の不満な点 - モナドとわたしとコモナド
また遅れてしまった…オブジェクト指向 Advent Calendar11日目。 最近いろいろオブジェクト指向について調べていて、やっぱりこの概念はいかがなものか、と思ったことを軽く書く。 継承 まずこれ。オブジェクト指向において「AがBを継承している」というのは、外延的には「任意のBのメソッドはAのメソッドである」であり、実装としては「AはBが持つ内部状態やメソッドの実装を利用できる」ことが多い。しかし、Twitterにも似たようなことを書いたが、「車クラスが乗り物クラスを継承している」みたいなゆるふわな使い方が目立つ。クラス、インターフェイスの用語と、それらの継承の定義ははっきりさせたい。則のない関係に意味なし。 抽象クラス、抽象メソッド 実装のない「抽象メソッド」と実装のあるメソッドをごちゃ混ぜにできるような仕様は害があると考えている。インターフェイスがあるにもかかわらずこのような中途
状態、手続き、OOP - モナドとわたしとコモナド
これはオブジェクト指向 Advent Calendar 2014の7日目の記事です。 入力によって変化する状態をうまく扱うことはプログラミングにおいて重要である。この記事では、状態や手続きを扱うさまざまなアプローチを紹介、比較する。 手続き型プログラミング 命令の列である手続きを「定義」「呼び出し」する記述力を提供する。命令の結果として得られた値に依存して、次に行う手続きを決定するという性質が肝である。 コルーチン 手続きに区切りを設けることで、「途中まで実行された手続き」を値として扱う。手続きが持つ潜在的な状態を閉じ込めることができるため、柔軟性が高い。 第一級手続き型プログラミング 手続きをデータ構造の一つとして表現し、呼び出すだけではなく、手続きそのものに対する操作も可能にする。「手続きの結果として得られた値に依存して、次に行う手続きを決定する」性質に対応するものとしてモナドがある。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Codata in action, or how to connect Functional Programming and Object Oriented Programming
オブジェクト指向とは何ですか？
Elixir から Elm の流れで、いよいよオブジェクト指向に対する懐疑心が無視できないレベルに達した2017年冬。 – ゆびてく
http://kwatch.houkagoteatime.net/blog/2015/09/05/please-be-fair/
Haskellでの合成可能なオブジェクトの構成とその応用
