オブジェクト指向プログラミング -- 1兆ドル規模の大失敗
CodeIQのブログより。🤔 なぜ、OOPから移行する時なのか Ilya Suzdalnitski OOPは、多くの人にコンピューターサイエンスの重要資産と考えられています。コード構成(code organization)に対する究極のソリューション。すべての問題の終焉。私たちのプログラムを書くための唯一の本当の方法。自分自身をプログラムするという真なる唯一神から私たちに授けられました… それまでは、そうではなく、抽象化の負担、そして無差別に共有されるミュータブルなオブジェクトの複雑なグラフによって、人々は屈し始めています。現実世界の問題を解決するのではなく、「抽象化」と「デザインパターン」について考えるのに貴重な時間と頭脳が費やされています。 非常に著名なソフトウェアエンジニアを含め、多くの人々がオブジェクト指向プログラミングを批判してきました。驚くことに、OOP自身の発明者でさえ、今
『オブジェクト指向設計実践ガイド』を読んで - Feedforce Developer Blog
kano-e です。 今年の夏に『オブジェクト指向設計実践ガイド』の読書会を行なっていました。 毎回1章ずつ、ゆるゆると集まってその章に出てきた話で気になったことなどを話し合う感じの読書会でした。 本の内容や設計について話せたのも有意義でしたし、そのまま「今やっているこの実装はどうするのが良いのか」みたいな話になったり、他のプロダクトではこうやってるなどの話を聞いたりもして、とても実りの多い会だったと思っています。 社内で開催した『オブジェクト指向設計実践ガイド』の読書会終わり！今回読むのは2回目。画像の通り、だいぶがっつり読むことが出来たし、業務や個人のコードも良くなって満足。 pic.twitter.com/XUin6wBWpA— Takashi Masuda (@masutaka) 2017年8月24日 以下の文章は『オブジェクト指向設計実践ガイド』を読んでのふんわりとしたエモい感想
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向では、モデリング（分析）、設計、実装は、切れ目のない一体の活動。初期の分析は初期の設計であり、初期の実装。毎日分析し、毎日設計し、毎日実装しながら、一歩一歩、モデルも実装も進化させていく。Read less
『オブジェクト指向設計実践ガイド』を読んだ
本当に良い本でした。読んで良かった。初心者を中心に中級者にも刺さる 本だと思います。輪読などして、チームで読むとオブジェクト指向設計の そもそもの話をしなくて良さそうです。 難しい話が易しく説明されており「あ、そうだったのか」と思うことが度々 でした。ボリュームも全９章とコンパクトで、１日１章読むのに丁度よかっ たです。 読んでメモった箇所を中心にまとめていきます。 第２章 単一責任のクラスを設計する# インスタンス変数へのアクセス方法を誤解していました。 P46 変数はそれらを定義しているクラスからでさえも隠蔽しましょう 今まで他のクラスから隠蔽する時は、直接 @hoge などにアクセスしてい ましたが、中からも attr_reader などで隠蔽する必要があるそうです。 「データではなく、振る舞いに依存する」ためだそうです。 メモ化などでこうした手法は使っていたけど、単純な参照も隠蔽す
責任(関心)を意識したアプリケーション設計 - Qiita
プログラムが上手く組めるようになりたい プログラミングが上手くなりたいと考えたときに、個人的には『名付けを意識』するのと、『アプリケーション設計のときに責任を意識する』考え方を取り入れることをおすすめしております。 今回は『アプリケーション設計のときに責任を意識する』ことについて書いてみたいと思います。 基本的には単一責任原則と、関心の分離のお話になります。 ※ タイトルに『関心』というワードがありますが、アスペクト指向プログラミングの話ではありません 単一責任原則とは まずは単一責任原則とは何かについてです。 よく単一責任原則の説明では「クラスを変更する理由は複数存在してはいけない」というニュアンスの言葉がよく使われます。 例えば、社員管理システムの実装を行いたい場合、一つのクラスに「社員登録」「出勤管理」「給与管理」などの機能を詰め込むと、『社員登録』の変更をする際にそのクラスが変更さ
Perlのオブジェクト指向をつかんだ - the code to rock
経緯 概念 実例 参考書籍 まとめ・展望 経緯 2013年の春にふと「よし、プログラミングやろう」と決めてその夏にYAPC::Asiaに参加して、その直後に買ったのが以下の本。 すぐわかる オブジェクト指向 Perl 作者: 深沢千尋出版社/メーカー: 技術評論社発売日: 2008/06/20メディア: 大型本購入: 12人 クリック: 195回この商品を含むブログ (34件) を見るたしか同YAPCでDeNAの人が大規模新人研修に関する発表をしていて（→）、その最後のほうでお勧め入門書ベスト5みたいなやつを紹介していたのだけど、それがよくある特定の選者が一括で選ぶようなものではなく、研修を受けた側の新人さんたちに聞いたアンケートから抽出されたというリアルなもので、そこに含まれているのを見て興味を持った。 で、先日ようやくそれを読み終わって出た感想。 Perl5によるオブジェクト指向、よう
契約による設計と名前による型づけ, およびオブジェクトの不変性 - 貳佰伍拾陸夜日記
契約による設計と名前による型づけ 最近, 社内で契約による設計の話が雑談として何度か出ていて, id:hakobe932さんが社内勉強会で紹介していたり, id:shiba_yu36さんがWEB+DB PRESSでSmart::Argsで制約をチェックする記事を書いていたり, 活発な議論になっている. インスタンスのファクトリメソッドとオプショナルな型を組み合わせると事前・事後条件を満たすことが保証できて, id:hakobe932さんの資料で言うところの「要求型」と「保護型」の区別も明確になってよいという話を書こうかとおもっていた. (これはそのうち別で書く.) とはいえ, こんな話はもう言っている人がいるだろうと思ってちょっと調べていて, どういう語句で調べたらいいか考えていた. インスタンスの型からそれを生成したファクトリメソッドが特定できて, それによって事前・事後条件が保証される
「関数型プログラミングはオブジェクト指向の正当な後継」なの？ - 檜山正幸のキマイラ飼育記 (はてなBlog)
オブジェクト指向を知っている人々に、「関数型もオブジェクト指向と大差ないよ、大丈夫だよ」とお誘いする記事は大いに存在意義があると思います。 関数型プログラミングはオブジェクト指向の正当な後継である 上記の記事は、そういう目的を持って書かれたのでしょう。その内容（目次）は次のようです（僕のこの記事の目次じゃないよ）。 対象読者 なぜこの記事を書こうと思ったのか？ なぜ関数型プログラミングはわかりにくいのか？ オブジェクト指向の負の遺産を捨てよう 関数型プログラミングの概要 「阿吽の呼吸」とも言うべき使いやすさの拡張 型にまつわる考察 まとめ 最初のほうを読むと、言ってることはまっとうで好感を持てます。が、「5. 関数型プログラミングの概要」の節あたりから雲行きが怪しくなって、ちょっと何言ってるかわかんない（(c)サンドウィッチマン）。 檜山のこの記事の内容： 真面目なポエム モナドっておいし
訳しました:「オブジェクト指向設計実践ガイド」 - 弥生開発者ブログ
こんにちは。Misoca開発チームのtaiki-tです。 先日、本を訳したのでそのことについて書きたいと思います。訳した本は「オブジェクト指向設計実践ガイド ～Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方」。 オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方 作者: Sandi Metz,?山泰基出版社/メーカー: 技術評論社発売日: 2016/09/02メディア: 大型本この商品を含むブログを見る 原著は”Practical Object-Oriented Design in Ruby” です。 Practical Object-Oriented Design in Ruby: An Agile Primer (Addison-Wesley Professional Ruby) 作者: Sandi Metz出版社/メーカー
Games from Within | Data-Oriented Design (Or Why You Might Be Shooting Yourself in The Foot With OOP)
Picture this: Toward the end of the development cycle, your game crawls, but you don’t see any obvious hotspots in the profiler. The culprit? Random memory access patterns and constant cache misses. In an attempt to improve performance, you try to parallelize parts of the code, but it takes heroic efforts, and, in the end, you barely get much of a speed-up due to all the synchronization you had to
Google Sites: Sign-in
Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode
データ指向設計
こんにちは、Cygames Research の多胡です。これまで10年以上コンソールゲーム開発を行ってきていて、最近ではハイエンドゲームエンジンを制作しておりました。Cygames でもハイエンドゲームエンジンの開発に携わることになりました。 ゲームエンジン開発を行う上で重要な考え方にデータ指向設計 (Data Oriented Design) というものがあります。今回はこのデータ指向設計を例を交えながら紹介させていただきます。 背景 データ指向設計の考え方は 2009年頃から有名になりました。 この 30年で CPU の性能は1万倍以上になりましたが、メモリの転送速度は10倍にもなっていません。そのため、プログラムのボトルネックはメモリ帯域となることが多くなりました。ゲームにおいても CPU はほとんどの時間がメモリからのデータの転送待ちになっています。CPU の性能を引き出すために
Best of Functional, Protocol, & Object-Oriented Programming
About the content This talk was delivered live in September 2016 at try! Swift NYC. The video was recorded, produced, and transcribed by Realm, and is published here with the permission of the conference organizers. A Swift application is more than just an Objective-C app translated into Swift. We need to embrace the features and philosophy of the Swift language. In this talk from try! Swift, we b
より良いプログラムを書くための究極の奇策 – 「Data first, not code first」 | POSTD
(訳注：2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) 開発者は嫌うでしょう。 ここでは、標準的なコツや策略について書きますが、本当に興味があるのは、別のことです。究極の奇策を見つけたいと思います。策略をひとつずつ試して、プログラミングの聖域に少しでも近づければ良いのですが。 はじめに 私が初めて書いたビデオゲームは、 Ninja Wars （忍者戦争）でした。 そう、これは、画像で埋めたHTMLのtableです。 src 属性を変えることで、動きを実現しています。JavaScriptファイルの冒頭は下記のようになっています。 var x = 314; var y = 8; var prevy= 1; var prevx= 1; var prevsw= 0; var row= 304; var endrow= 142; var sword= 296; v
クラス設計の原則 — みんなのウェディングエンジニアリングブログ
みんなのウェディングの高井です。 クラスベースのオブジェクト指向プログラミング言語を利用している人であれば、クラスとは、ありふれていて普段から利用するものです。にもかかわらず、良いクラスをつくるというのは、なかなかに難しいことです。 先日、みんなのウェディングでアルバイトをしてくれている学生さんのコードレビューをしていたときにも、それを強く感じました。 実践的プラグマティックには「ソフトウェアの規模や文脈にあわせて、適切に抽象化していただきたい」という以上のことを言っても仕方がないところなのですが、それだけでは経験の浅いプログラマーにとって、まったく分からないという話になってしまいます。 というわけで、今回はクラス設計の原則についてのお話しです。 Bertrand Meyerのクラス設計の原則 Bertrand Meyerは『オブジェクト指向入門 第2版』の中で、クラス設計について章をひと
Haskellでの合成可能なオブジェクトの構成とその応用
Haskellでの合成可能なオブジェクトの構成とその応用 木下郁章, 山本和彦, 2015 Haskellで状態を管理する際は、 一般的に代数データ型や型クラスが用いられるが、 データが拡張できないか、動的な性質を持たない。 そのためHaskellは、 複雑な状態を扱う問題領域には適していないと考えられてきた。 一方で、一般的なオブジェクト指向言語では、 オブジェクトを提供することでこの問題領域で成功を収めている。 本論文では、Haskellの言語仕様を変更することなしに、 オブジェクト指向言語から着想を得たオブジェクトを実現する。 本論文で提案するオブジェクトは圏を構成し、合成を用いて継承を表現できる。 また、終了する運命にあるオブジェクトやストリーミングなどに応用でき、 複雑な状態を扱うゲームの実装にも使われている。 論文をダウンロード(PDF) PPL 2015 発表スライド ここに
再考: GoF デザインパターン - Qiita
本投稿は私の主観によって書かれています。コメントは大歓迎です。もし長くなるようでしたら別途記事に投稿し、リンクを張っていただけると嬉しいです。 概要 GoFのデザインパターンは適当すぎるから、いい加減、修正されるべき。 参考までに各パターンに対するコメントを書く。 GoFのデザインパターン GoFのデザインパターンは適当であり、教科書通りに学ぶべきものではないように思う。 以下がGoFのデザインパターンの良くない原因だろう。 本が出版されたのは1994年であり、Java(1995)が出てくるよりも前だった オブジェクト指向が未成熟な時代にカタログ化された 現代のプログラミングと合致しないものが多い 「オブジェクト指向における～」と断っている以上、OOPに絡める必要があった パターンのいくつかに「多態性を用いると便利」という蛇足がついている 挙げたパターンに根拠がない 「とりあえず、23個ほ
オブジェクト指向の法則集 - Qiita
この記事は、故石井勝さんが1999年に書いた記事を Qiita に転載するものです。オブラブ(objectclub.jp)にて記事をホスティングしていましたが、現代でも十分に読める内容なので、たくさんの方に読んでもらいたいと思い、若干の編集（リンクとコンテキスト追加）を平鍋が行い、転載します。今でも、読みやすく、カジュアルな語り口のよい記事です。 オブジェクト指向の法則集（転載元：http://objectclub.jp/community/memorial/homepage3.nifty.com/masarl/article/oo-principles.html ） なお、この記事の他にも石井さんのオブジェクト指向やRubyに関する多くの記事をオブラブの「まさーるのページ」で読むことができます。では、以下に石井勝さん（旧メールアドレス masarl@nifty.com）の記事を転載します
新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
おすすめオブジェクト指向練習方法 | サイバーエージェント 公式エンジニアブログ
