オブジェクト指向にとって継承とは何か？〜ストラウストラップ「「オブジェクト指向プログラミング」とは何か」〜C++Haskellオブジェクト指向 オブジェクト指向とは何か？ということを真面目に調べていくと、オブジェクト指向には二種類ある、という話に突き当たる。sumim氏のQuora回答などを参照。 Smalltalkの設計者アラン・ケイによる、メッセージング重視のオブジェクト指向 C++の設計者ストラウストラップによる、クラス重視のオブジェクト指向 今回はこの後者のオブジェクト指向について、ストラウストラップの論文「「オブジェクト指向プログラミング」とは何か？」What is "Object-Oriented Programming"?（1991）の内容を（適宜行間を補いつつ）まとめてみる。 当然サンプルコードはC++（ほぼ原論文のコードのコピペです）。 ストラウストラップのオブジェクト指

※追記しました 2018/11/10 サンプルコードの言語について、この記事で触れなかったものとその理由について 2018/11/11 諸注意補足 2018/11/12 コードフォーマット、タイポ修正 2018/11/13 ポリモーフィズムのサンプルが弱いとの指摘を頂き追記 はじめに この記事はオブジェクト指向プログラミング初学者向けの記事です。 記事の内容はオブジェクト指向プログラミングの入り口までを解説しているつもりです。 またオブジェクト指向分析やオブジェクト指向設計については取り扱いません。 オブジェクト指向についてを完全に理解するにはこの記事だけでは足りないと思いますのでその点ご留意願います。 サンプルコードは C# です。 スライドが元ネタになっていて、以下の url がそのスライドです。 もし興味が湧いたらどうぞ。 https://nrslib.com/oop-slide-1

チャールズ・アントニー・リチャード・ホーア（Charles Antony Richard Hoare、1934年1月11日 - ）[1]は、イギリスの計算機科学者。通称はトニー・ホーア（Tony Hoare）またはC・A・R・ホーア。 クイックソート（一般的な場合には最も性能の良い実装ができるとされるソートアルゴリズム）の考案でも知られるが、専門的な業績としては、ホーア論理や、並行プロセスを形式記述するCommunicating Sequential Processes（CSP）などがある。CSP[※ 1]はプログラミング言語Occamに示唆を与えた。 経歴[編集] イギリス領セイロンのコロンボにてイギリス人の両親の元に生まれた。1956年にオックスフォード大学にて西洋古典学の学士号を取得。 その後オックスフォード大に1年残って大学院相当の統計学を学ぶ。1956年から1958年までイギリス

えーっと、長すぎて、ワタシも全部は読み通せていません。 文章の趣旨はインパクトが強いタイトルの通りで、オブジェクト指向プログラミングは1兆ドル規模の災厄であり、もうオブジェクト指向プログラミング（OOP）の先に進むべき時だよ、ということである。 著者は OOP 批判がセンシティブな話題であること、多くの読者を敵に回すであろうことを認めた上で、OOP はその発明者であるアラン・ケイが思い描いたように実装されればよかったと考えている。で、返す刀で現実の Java や C# の OOP へのアプローチを批判する。 OOP が素の手続き型プログラミングよりも優れているという客観的、公平なエビデンスは存在しないと著者は断言している。 ところどころで「Java は MS-DOS 以来コンピューティング分野に生まれたもっとも悲惨な存在だ」というアラン・ケイの言葉や、「C++ はおぞましい言語だ。だからプ

CodeIQのブログより。🤔 なぜ、OOPから移行する時なのか Ilya Suzdalnitski OOPは、多くの人にコンピューターサイエンスの重要資産と考えられています。コード構成(code organization)に対する究極のソリューション。すべての問題の終焉。私たちのプログラムを書くための唯一の本当の方法。自分自身をプログラムするという真なる唯一神から私たちに授けられました… それまでは、そうではなく、抽象化の負担、そして無差別に共有されるミュータブルなオブジェクトの複雑なグラフによって、人々は屈し始めています。現実世界の問題を解決するのではなく、「抽象化」と「デザインパターン」について考えるのに貴重な時間と頭脳が費やされています。 非常に著名なソフトウェアエンジニアを含め、多くの人々がオブジェクト指向プログラミングを批判してきました。驚くことに、OOP自身の発明者でさえ、今

回答 (5件中の1件目) この質問にかなり先行して2015年、Quora（本家）で投げかけられた質問として、 Why do some functional programmers criticize design patterns in OOP languages as a sign of language deficiency, while Monad is also a design pattern? なぜ、関数型プログラマらは、オブジェクト指向(OOP)言語のデザインパターンを、言語の欠陥の象徴だと批判するのでしょうか？モナドもデザインパターンじゃないんですか？ があります。...

Swift Advent Calendar その2の23日目の記事です。 Swiftはマルチパラダイム 私がiOS開発に手を出し始めたのはおよそ4,5年ほど前、当時はまだSwiftは存在せず Objective-Cによる開発で、ちょうどMRCからARCに切り替わる手前ぐらいに初めて出会いました。 当時は元々アプリエンジニアがほとんど社内にいない中、Android開発をもくもくと開発しており オブジェクト指向はなんぞや？という所からJava先生にいろいろ教えて貰っていた所だったので、 その名の通りオブジェクト指向ベースであるObjective-Cにはretainカウントに発狂する以外はある程度キャッチアップできていました。 Swiftはマルチパラダイム言語と呼ばれています。 Objective-Cゆずりのオブジェクト指向、そして関数型を取り入れ、 また各言語に散らばっていた素晴らしい機能(N

プロトコル指向プログラミングという概念について、調べたことをまとめてみました。 プロトコル指向プログラミングとは ものすごくざっくりいうと、プロトコル(Javaでいうインターフェース)を使ってプログラミングしようという概念です。 なんでプロトコル？ オブジェクト指向の問題を解決するためです。 どんな問題かというと、以下の点が問題でした。 オブジェクト同士が他のインスタンスを共有していることを知らずに参照してしまう（暗黙の共有） 親クラスのメソッド、プロパティをそのまま引き継ぐため、初期化や上書きなどの調整が必要になる 複数のサブクラスを作ってもそれらを関連付けする方法がないため、 型が統一できない このような問題点がオブジェクト指向にはあるため、プロトコルを使ってクラス関係の壁をなくそうということで、プロトコルを使うのです 実際にやってみた 概念だけだとわかりづらいので、実際のコードで説明

以下の記事の続きです。 blog.penginmura.tech 制御構文 Go言語の制御構文としては次のものがある。 if switch for ゴルーチン・チャネルにおいて利用できる select という制御構文もあるが、それは後ほど触れることにする。 if 文 基本的な書き方は Swift とほとんど変わらない。次のコードは Go言語 / Swift ともにコンパイルできる。 if 0 <= x && x < 100 { } else { } Go言語では if 文において事前にローカル変数を宣言することができ、これは Go言語におけるエラー処理のパターンで多用される。前編において 0除算された場合にエラーを返すDiv関数を呼び出した例として、次のようなエラー処理を記述した。 n, err := Div(6, 2) if err != nil { panic("error!") }

コード構造における重要な問題として、複数のクラスを共有する場合に合成と継承のどちらを用いるかという点があります。“has a”の関係と、“is a”の関係と言われる2つの対比です。例えば、“ソファには綿が入っている”と、“ソファは家具である”という違いのようなものです。この例では2つの違いは非常に明白ですが、実際には、“has a”の関係でも“is a”の関係でも意味を成すケースがたくさんあります。ゲームのキャラクターについて、これはコリジョンボックスを持っているかと聞くのと、これは衝突可能なオブジェクトかと聞くような場合です。この2つは全く同じことではありませんが、それぞれが（または両方一緒に）衝突を処理する主構造として用いられ、どちらの方がよいかは必ずしも明白ではありません。私の経験では、直感的には継承の方がよいと思うことも多いのですが、それだと問題がたくさんあって結局は合成の方がよか

今日本を読んでいて、「なるほど！そうすりゃ良かったんだ！」という小さな気付きを得ました。 プログラミングElixir 作者: Dave Thomas,笹田耕一,鳥井雪 出版社/メーカー: オーム社 発売日: 2016/08/19 メディア: 単行本（ソフトカバー） この商品を含むブログを見る プログラムはデータを変えるもの UNIXシェルのパイプラインのように、単純な機能をつなげて複雑な処理を実現 当たり前といえば当たり前で、別に普通のことですが、改めて考えてみると、「自分に足りなかったパズルのピースだった！」とひらめきました。 迷宮になるコード プログラムを設計して、コードを書いて実装すると、最初は調子が良いのですが、コード量が多くなってくると段々コーディングのスピードが落ちてきます。 最初の頃の半分以下のスピードになってくると「何でこんなに生産性が下がるんだろう？」と悩みます。 自分の