20年代のオブジェクト指向言語
アダム・ネルソンのブログより。 オブジェクト指向プログラミングは、今やすっかり廃れてしまいましたが、しばらく前からそうなっています。新しいプログラミング言語が意図的にオブジェクト指向(OO)を採用することはほとんどありません。そして、これには正当な理由があります。OOは多くの場合、多くの定型文を必要とし、コードを不自然なオブジェクト階層に押し込め、隠れたミュータブル状態を助長します。 しかし、もし2021年にJavaやC#のような静的型付けされた新しいOO言語をゼロから作ったとしたら、関数型プログラミングから学んだ全てのことと、10年以上にわたる厳しいOO批判を受けて、この問題を解決することができるでしょうか? 特に、レガシーコードとの互換性を期待していない場合はどうでしょうか? まず、新しいOO言語が持つべき、いくつかの明白な譲れないものがあります。 null安全 安全なキャスト オプシ
オブジェクト指向プログラミング -- 1兆ドル規模の大失敗
CodeIQのブログより。🤔 なぜ、OOPから移行する時なのか Ilya Suzdalnitski OOPは、多くの人にコンピューターサイエンスの重要資産と考えられています。コード構成(code organization)に対する究極のソリューション。すべての問題の終焉。私たちのプログラムを書くための唯一の本当の方法。自分自身をプログラムするという真なる唯一神から私たちに授けられました… それまでは、そうではなく、抽象化の負担、そして無差別に共有されるミュータブルなオブジェクトの複雑なグラフによって、人々は屈し始めています。現実世界の問題を解決するのではなく、「抽象化」と「デザインパターン」について考えるのに貴重な時間と頭脳が費やされています。 非常に著名なソフトウェアエンジニアを含め、多くの人々がオブジェクト指向プログラミングを批判してきました。驚くことに、OOP自身の発明者でさえ、今
Java Generics Hell 序章 - プログラマーの脳みそ
気合が続くか分からない Java Generics Hell アドベントカレンダー 1日目。 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 導入 JavaのジェネリクスはJavaが設計された当初(Javaは1995年に発表されている)から検討はされてはいたものの、実装が追いつかず、導入はJava5(2004年)を待つこととなった。後方互換の都合からいろいろと不便な部分もある。Javaに限らず、ある程度、歴史の長いプログラミング言語は、改定の都合からいろいろと不都合な部分が生じるものである。後方互換性を犠牲にして一新すれば言語仕様もさっぱりするが、非互換の壁でバージョンアップできないという闇を抱えたりとそれはそれで大変だ。 後方互換、つまり、より新しいバージョンは、昔作ったモノも動かせる、ということを前提にした場合、プログラミング言語の仕様というのはどんどん肥大してい
DSLは“超高級言語”（DSLなどについて整理するメモ、その２） - たなかこういちの開発ノート
以前の記事で、DSL（Domain Specific Language）の仕組みの在り方のバリエーションを整理してみた。今回は、DSLの成立過程についての私の見立てを記す。なお、本記事中で単に「DSL」と云った場合、「外部DSL」を意味する。 ◇ プログラミング言語高級化の流れと、その先端に位置付くDSL アセンブラは低級言語で、Cは高級言語（High-Level Language）、Javaはさらに高級な言語、という言い方がある／あった。DSLはこの考え方の延長に置かれるものと捉える。つまり、現時点で考え得る「最高級」、もしくは「“超”高級」の言語、という訳だ。 より「高級」であるとは、目的の“ドメイン”のセマンティックスをより直接的に記述できる言語要素を持つ、ということである。アセンブラで、「レジスタをPushしてJump」と記述していたのは、「関数（サブルーチン）」を表したかったから
契約による設計と名前による型づけ, およびオブジェクトの不変性 - 貳佰伍拾陸夜日記
契約による設計と名前による型づけ 最近, 社内で契約による設計の話が雑談として何度か出ていて, id:hakobe932さんが社内勉強会で紹介していたり, id:shiba_yu36さんがWEB+DB PRESSでSmart::Argsで制約をチェックする記事を書いていたり, 活発な議論になっている. インスタンスのファクトリメソッドとオプショナルな型を組み合わせると事前・事後条件を満たすことが保証できて, id:hakobe932さんの資料で言うところの「要求型」と「保護型」の区別も明確になってよいという話を書こうかとおもっていた. (これはそのうち別で書く.) とはいえ, こんな話はもう言っている人がいるだろうと思ってちょっと調べていて, どういう語句で調べたらいいか考えていた. インスタンスの型からそれを生成したファクトリメソッドが特定できて, それによって事前・事後条件が保証される
「オブジェクト指向入門 第6章 抽象データ型」を読んだ - $shibayu36->blog;
オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング) 作者:バートランド・メイヤー翔泳社Amazon 「オブジェクト指向入門 第3章モジュール性」メモ - $shibayu36->blog; の続きで、「第6章 抽象データ型」を読んだ。 この章では、オブジェクトを適切に表現する記述として、抽象データ型というものを紹介している。これが非常に参考になったので軽く読書メモをとっておく。 抽象データ型とは 抽象データ型の仕様の記述とは以下の4つを記述することであるようだ。 TYPES(型) FUNCTIONS(関数) -> その抽象データ型に適用可能な操作の集合 AXIOMS(公理) -> その抽象データ型が必ず満たす条件 PRECONDITIONS(事前条件) -> 部分的な関数のソース集合の定義域 STACKの例を見
Swiftにおけるプロトコル指向プログラミング
WWDCにて、C++/Boostで知られ、現在はAppleでSwift Standard Libraryグループのリーダを務めるDave Abrahams氏が、Swiftをプロトコル指向言語として紹介し、プロトコルがコード改善にどう使えるのか説明した。 プロトコル指向プログラミングというのは、OOP（オブジェクト指向プログラミング）のパラダイムの一つで（注：Abrahams氏はそうは言っていないとのこと）、クラスよりもプロトコル（インターフェイスに相当）と構造体の利用を好んでいる。 クラスは素晴らしい？ OOPで知られているように、クラスは以下を提供するのに使われる。 カプセル化 アクセス制御 抽象化 名前空間 表現力 拡張性 実のところ、これらはすべて型の特性であり、クラスは型を実装する一つの方法にすぎないとAbrahams氏は言う。だが、クラスはプログラマに多大な犠牲を強い、次のような
Haskellでいかに多態を表すか - モナドとわたしとコモナド
オブジェクト指向を行使する心 ではオブジェクト指向の必要性と仕組みについて議論した。 インスタンスは言語によって様々な実装方法があるが、大きく分けて「クラス(処理)のインデックス」か「処理そのもの」のどちらかがインスタンスの内部に隠れている。 と述べたが、Haskellの場合、クラスのインデックスに基づいた表現では、インターフェイスは型クラス、クラスはインスタンス、インスタンスは存在量化された型の値に対応する。…といってもややこしいことこの上ないので、実装例を考えてみよう。 まず、問題となっている愚直な実装は、Haskellではこんな感じだ。 data World = World { … } data SceneId = Menu | Map | Battle draw :: SceneId -> World -> IO World draw Menu = … draw Map = … d
Haskellオブジェクト指向に触れてみよう〜中級編〜 - Creatable a => a -> IO b
PRITZサラダ味は神、異論は認めない。 はいどうも、直接本題に入ったら負けだと思っているタイプのHaskeller、ちゅーんさんですこんにちは。 今日も前回に引き続き、「Haskellでオブジェクト指向」と題しまして、objectiveを紹介したいと思います。 本題に入る前に 前回の記事に、objective開発者の@fumievalさんからコメント頂きました。 最新のobjectiveでは`stateful handle s where handle` …の代わりに、 {-# LANGUAGE LambdaCase #-} stringObject :: String -> Object StringObject IO stringObject s = s @~ \case GetString -> get SetString s -> put s PrintString -> get
Haskellオブジェクト指向に触れてみよう〜初級編〜 - Creatable a => a -> IO b
RITZクラッカーは神、異論は認めない。 はいどうも、直接本題に入ったら負けだと思っているタイプのHaskeller、ちゅーんさんですこんにちは。 今日は、「Haskellでオブジェクト指向」と題しまして、objectiveというライブラリを紹介したいと思います。 いんとろだくしょん objectiveは日本人によって開発されたHaskellでオブジェクト指向を行うためのライブラリです。いちおうまだ研究段階といった感じではありますが、 色々といじくり回してみた限り、かなり期待が持てる内容になっているため、紹介します。 近い将来には、Lensくらいには手軽に、 Haskellプロジェクトにオブジェクト指向プログラミングを導入できそうです。 手っ取り早く実装レベルで知りたい人は以下の日本語の論文を読むとよいでしょう。 http://fumieval.github.io/papers/ja/20
objective
objective Paper: https://fumieval.github.io/papers/en/2015-Haskell-objects.html This package provides composable objects and instances. Introduction The primal construct, Object, models object-oriented objects. Object f g represents an object. newtype Object f g = Object { runObject :: forall x. f x -> g (x, Object f g) } An object interprets a message f a and returns the result a and the next obj
Haskellでの合成可能なオブジェクトの構成とその応用
Haskellでの合成可能なオブジェクトの構成とその応用 木下郁章, 山本和彦, 2015 Haskellで状態を管理する際は、 一般的に代数データ型や型クラスが用いられるが、 データが拡張できないか、動的な性質を持たない。 そのためHaskellは、 複雑な状態を扱う問題領域には適していないと考えられてきた。 一方で、一般的なオブジェクト指向言語では、 オブジェクトを提供することでこの問題領域で成功を収めている。 本論文では、Haskellの言語仕様を変更することなしに、 オブジェクト指向言語から着想を得たオブジェクトを実現する。 本論文で提案するオブジェクトは圏を構成し、合成を用いて継承を表現できる。 また、終了する運命にあるオブジェクトやストリーミングなどに応用でき、 複雑な状態を扱うゲームの実装にも使われている。 論文をダウンロード(PDF) PPL 2015 発表スライド ここに
状態、手続き、OOP - モナドとわたしとコモナド
これはオブジェクト指向 Advent Calendar 2014の7日目の記事です。 入力によって変化する状態をうまく扱うことはプログラミングにおいて重要である。この記事では、状態や手続きを扱うさまざまなアプローチを紹介、比較する。 手続き型プログラミング 命令の列である手続きを「定義」「呼び出し」する記述力を提供する。命令の結果として得られた値に依存して、次に行う手続きを決定するという性質が肝である。 コルーチン 手続きに区切りを設けることで、「途中まで実行された手続き」を値として扱う。手続きが持つ潜在的な状態を閉じ込めることができるため、柔軟性が高い。 第一級手続き型プログラミング 手続きをデータ構造の一つとして表現し、呼び出すだけではなく、手続きそのものに対する操作も可能にする。「手続きの結果として得られた値に依存して、次に行う手続きを決定する」性質に対応するものとしてモナドがある。
私が愛するオブジェクト指向とそれを使わない理由 - takuto_hの日記
この記事では、私がオブジェクト指向のどこを愛しどこを素晴らしいと感じていて、そのうえでなぜオブジェクト指向を使うことを避けているのかを書き留めておきます。関数型言語使いの方で、「オブジェクト指向の何がいいのかわからない」「オブジェクト指向難しすぎ・複雑すぎ」とおっしゃる方にぜひ読んでいただきたいと思っています。また、「オブジェクト指向言語完璧に理解したわ」と思っている方にも読んでいただきたく思います。 なお、ここでのオブジェクト指向の定義は、「各言語でオブジェクト指向と呼ばれているものすべて」とします。JavaやScalaやJavaScriptやSmalltalkやRubyやCommon LispやOCamlがオブジェクト指向と呼んでいるものすべての総称です。もっとまともな定義が知りたい方は以下の記事がおすすめです。 オブジェクト指向の概念の発明者は誰ですか？(改訂版) - Smallta
DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticism
この記事はartima developerに掲載されている、Trygve Reenskaug氏とJames O. Coplien氏による記事「The DCI Architecture: A New Vision of Object-Oriented Programming」を、著作権者であるBill Bennrs氏の許可を得て翻訳したものです。本文内の図の著作権はArtima, Inc.に帰属します。（原文公開日：2009年3月20日） 要約 オブジェクト指向プログラミングはプログラマとエンドユーザの視点をコンピュータコードにおいて統一するものと考えられていた。この恩恵はユーザビリティとプログラムの分かりやすさの両面にわたる。しかし、オブジェクトは構造をとらえるのに長けている一方で、システムの動作をとらえることができていない。DCIはエンドユーザのロールに関する認識モデルとロール間の関係を
Perlオブジェクト指向プログラミング
-> 趣旨と注意書き -> 身近なpackage -> なんのためのpackage ? -> What's `new' ? -> bless ( reference => package ) -> Hello, Module World! -> オブジェクト？ -> main パッケージと関連付けてみる -> クラスとメソッド -> オブジェクト指向 -> オブジェクトがリファレンスなら… -> -> を連続する -> 継承 -> 多重継承 -> 多重継承をやめる -> 多重継承をやめる(もう少し簡単に) -> 情報源(書籍等) <- モドル 趣旨と注意書き これを読んでも、あんまりきちっとした知識は、身に付きません（^^; オブジェクト指向の概念はほんの少ししか説明しません。ここで述べるのは、Perlでどうやるかってのが主です（それも不十分＆嘘まじりかも）。 とりあえず、モジュールを作り
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. を読んでくださいというか、気持ちよく丸投げしたいところですが、翻訳すると言ってまだ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Elixir から Elm の流れで、いよいよオブジェクト指向に対する懐疑心が無視できないレベルに達した2017年冬。 – ゆびてく
https://qiita.com/tokomakoma123/items/fb7530232912dc4176c4