2024/3/24に開催されたObject-Oriented Conferenceでの登壇資料です。 https://ooc.dev/2024/
オブジェクト指向は必要なのか / Is object-oriented needed?
2024/3/24に開催されたObject-Oriented Conferenceでの登壇資料です。 https://ooc.dev/2024/
Dependency Injectionでやりたいことはモジュールimport - きしだのHatena
Dependency Injection(DI)、最近のフレームワークには欠かせない気がする機能になってますね。 そしてDIの説明をみると「依存性の注入」みたいなことが書いてあって、ようわからんになりがちです。 実態としては高機能なimportなので、あまり難しいことを考えなくていいような気がします。 たとえば、こんな感じのMyServiceクラスがあってDIコンテナに管理させるとします。 @Component class MyService { void method() { } } そして、MyServiceを使うMyControllerがあるとします。 @Component class MyController { @Inject MyService service; void hello() { service.method(); } } これって、実際のところMyServiceの
オブジェクト指向 の検索結果 - きしだのHatena
オブジェクト指向言語の話をするときに便利なように、Javaを中心にプログラミング言語をまとめてみました。 Javaに影響与えるか、Javaから影響を受けるか、という感じですね。 Simula オブジェクト指向はここから始まったと言われています。 クラス、オブジェクト、継承、仮想関数(多態)といった、オブジェクト指向の基本要素が備わっていました。 ただし、「オブジェクト指向」という言葉は生まれていません。 Smalltalk Simulaから発想を得て「オブジェクト指向」という… …ろいろ分類した本で、オブジェクト指向言語とはどういう位置づけになるのかという話をするときに確認してもらいたいんだけど、いま中古で4万円。 「アルゴリズムデザイン」も一時絶版状態で、12万とかで売られてるのを見た。 いまは在庫復活して17,000+税になっているけど、買ったときは15,000+税だったな。Amazo
Rustを通して見るオブジェクト指向｜TechRacho by BPS株式会社
こんにちは。yoshiです。夏のTechrachoフェア2022ということで、夏とは何の関係もない記事を書いていこうと思います。 業務ではC++をやっていながら前回、前々回にTechrachoで書いた記事に引き続きRustをやっていく訳ですが、定期的に炎上しがち（？）なオブジェクト指向の話です。みなさん、オブジェクト指向は好きですか？ オブジェクト指向って何だろう？ A. なんもわからん なんて言ってしまったら話が終わってしまうのですが。 歴史的な話をするとオブジェクトという用語はSimulaが初出で、オブジェクト指向はアラン・ケイがSmalltalkで導入したもの、という話になりますが、一方でビャーネ・ストロヴストルップがC++に導入した「カプセル化・継承・ポリモーフィズム」の組み合わせのことを指すことが多く、SmalltalkのそれとC++のそれにも違いがあるので定義が定まらない概念で
オブジェクト指向プログラミングは終わった - Qiita
追記: 振り返りを書いてみました～ -- ここから元記事 別題: 抽象化って言葉もう。。 社内の記事にて、オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES) | アラン・シャロウェイ, ジェームズ・R・トロット, 村上 雅章 |本 | 通販 | Amazonを紹介してもらいました。 取り上げられた、共通性／可変性分析の解説を見て、はっと思うことがありポエムを仕立てました。 共通性／可変性分析 共通性／可変性分析については、書籍を読むかググって頂けると良いですが、社内記事が良かったので引用させて頂きます。 問題領域にある概念を見つける（共通性の分析） その流動的要素を洗い出す（可変性の分析） 流動的要素を見ながら、その概念が持つ責務を果たすための抽象的側面（≒インタフェース）を導く 各流動的要素の実装上の観点から、インタフェースが適切かどうかを見極め、補正する オ
オブジェクト指向は差分プログラミングとデータ分類をまとめて扱おうとしたのが弱点 - きしだのHatena
オブジェクト指向の最大の特徴は、モジュールと型を一体に扱ったことです。 メイヤーの本では次のような「オブジェクト指向の基準」があげられています。 クラスが唯一のモジュールでなければならない すべての型はクラスに基づいていなければならない つまり、クラスはモジュールであり型であるということです。 ここで、モジュールにとって必要な、クラスで実現できる機能は、モジュール間で異なる部分だけをそのモジュールで実装するという差分プログラミングです。 型に求められるのは、データの分類です。 ということは、オブジェクト指向は差分プログラミングとデータの分類を同時に扱おうとしていたということになります。 けれども、データの分類と差分プログラミングを同時に行うのは大変です。 「できらぁ！データの分類と同時に差分プログラミングして、いいソフトウェアができるっていったんだよ！！」 というのがオブジェクト指向だった
2021年の「オブジェクト指向」を考える
きしださんが先日もたのしいお題を投下されていました。 出遅れましたがこのネタについて少し掘り下げてみます。 念のため個人的なスタンスをあらかじめ表明しておくと、オブジェクト指向に対してはそれなりに好意的ですが、別に時代の最先端だとかソフトウェア開発に必須の知識というほどではない（でも知っておくと便利というか、知らないと不便なこともあるかもしれないのでわざわざ避けるのはおすすめしない）というくらい温度感です。 オブジェクト指向 is 何 そもそも「オブジェクト指向」という言葉自体、座りの悪い言葉です。 意味が明確なのは「オブジェクト指向プログラミング(OOP)」、「オブジェクト指向プログラミング言語(OOPL)」、「オブジェクト指向設計(OOD)」「オブジェクト指向分析(OOA)」といった「オブジェクト指向なんとか」の方で、それらをふわっとまとめた（ような気がする）単語が「オブジェクト指向」
オブジェクト指向再入門/オセロを例に考える
非オブジェクト指向的に考えると 既に書いたように、オブジェクト指向について説明するのに、 犬や猫が出てくるようなたとえ話は有害でしかないと思います。 やはり、現実のプログラミングに即した例題を使用するべきでしょう。 そこで、本稿ではまず「オセロゲーム」を例として説明を試みます。 Cプログラマにオセロゲームを作らせたら、 まず、盤面を以下のようなグローバル変数で管理しようとするのではないでしょうか。 #define BLANK_CELL 0 /* 何も置かれていない */ #define BLACK_CELL 1 /* 黒のコマが置かれている */ #define WHITE_CELL 2 /* 白のコマが置かれている */ /* * 「cell」にはExcelなどの「マス目」の意味がありますので、 * ここでは、オセロの盤面のマス目を表現していると思ってください。 */ int cell[
「オブジェクト指向プログラミングと関数型プログラミングは対立するものではなく直交する」という主張があります。私は常々この主張は詭弁であると考えており、それは自己回答で補足します。如何思われますか？
回答 (4件中の1件目) 質問者です。 まず、「オブジェクト指向プログラミングと関数型プログラミングは対立するものではなく直交する」という主張についてです。 このトピックにおいて「直交」という数学的な用語が、自分が知る限り、少なくとも日本国内で表明されたのは、 「関数型言語」に関するFAQ形式の一般的説明 - Qiita という記事が最初であると記憶しています。 ちなみに蛇足を先に処理しておくと、この記事は、モナドって？の章にしてもモナドの定義も説明内容も完全に間違っているし（書き手が理解できていない、モナドについて正しい知識は、30分でわかるJavaScriptプログラマの...
「DIは必ずしも善ではない」| Dependency injection is not a virtue by DHH
DHHの Dependency injection is not a virtue(2013) という記事は有名ですが、ちゃんとした日本語訳が意外とないようなので、書き出してみて思ったことを要約してみた。[1] Rubyのエンジニアの中には、何も考えずに他のモデルのnewを書いてる人の割合が多いという（コードレビュー時のヒアリングによる）体感があり、また8年前の記事なので経験の浅い人は読んだことがない人もいると思う。該当する方は是非読んでほしい。 全部読む時間が無い人は要約へ. 原文と訳文 In languages less open than Ruby, hard-coded class references can make testing tough. If your Java code has Date date = new Date(); buried in its guts,
継承によらないポリモーフィズム実現手法 - Qiita
ポリモーフィズム(polymorphism; 多態, 多相)」というとオブジェクト指向プログラミングにおける継承(インターフェースの継承)による実現手法がよく知られている。 しかし、ポリモーフィズムを実現するための手法はオブジェクト指向的な型階層によるものに限らず様々なものがある。 ここでは、Expression Problemに対する解決策として挙げられる、継承によらないポリモーフィズムの代表的な実現手法として、 型クラス(type class) プロトコル(protocol) マルチメソッド(multimethod) による実装を複数言語で試してみた。 いずれの方法も明示的な継承関係を必要とせず、拡張に対して開いているため、既存の型(例えば言語組み込み型)に対しても容易に拡張可能なことが特徴的で、ある種のインターフェース定義に対する実装を追加することで、いつでも適用範囲を拡大できる。
さようなら、オブジェクト指向プログラミング - Qiita
こちらの記事は、『Goodbye, Object Oriented Programming』の和訳になります。 私は何十年もの間、オブジェクト指向言語でプログラミングをしてきました。最初に使ったオブジェクト指向言語はC ++で、次にSmalltalkを使い、その後.NETとJavaを使いました。 私は継承、カプセル化、およびポリモーフィズムというパラダイムの三本柱の恩恵を活用することに熱狂的でした。これらはパラダイムの三本柱です。 再利用の約束を得ることと、この新しくエキサイティングな環境に私よりも以前に来ていた人々によって得られた知恵を利用することに、私は貪欲でした。 現実世界のオブジェクトをクラスに割当てるという考えに対し興奮を抑えることができず、世界の全てが正しい場所にきちんと収まることを期待していました。 これは、大間違いでした。 継承：倒れる第1の柱 一見すると、継承はオブジェク
Goはオブジェクト指向言語だろうか？ | POSTD
“オブジェクト指向”の意味を本当に理解するには、この概念の始まりを振り返ることが必要です。最初のオブジェクト指向言語はSimulaという言語で、1960年代に登場しました。オブジェクト、クラス、継承とサブクラス、仮想メソッド、コルーチンやその他多くの概念を導入した言語です。おそらく最も重要なのは、データとロジックが完全に独立したものであるとする、当時では全く新しい考え方をもたらしたことでしょう。 Simula自体には馴染みがない方も多いかもしれませんが、Simulaからインスピレーションを得たとされるJavaやC++、C#、Smalltalkといった言語は皆さんよくご存知でしょう。さらにそこからインスピレーションを得たものとしてObjective-CやPython、Ruby、JavaScript、Scala、PHP、Perlなど様々な言語があり、Simulaは現在使用されているポピュラーな
オブジェクトは目的語 - 超ウィザード級ハッカーのたのしみ
オブジェクト指向プログラミング言語ではメソッドを呼び出したいとき、 <インスタンス名>.<メソッド名> とインスタンスを示す変数の名前のあとに、そのオブジェクトに属するメソッドの名前を示します。このプログラミング言語の構文は、誤解も招く良くない構文であったと思います。 <インスタンス名>.<メソッド名> の構文は英語の SV 文型を連想させるので、インスタンスが主語でメソッドが動詞であると勘違いしてしまいます。 しかし、実際にはオブジェクトを目的語とした方が自然な――人間に優しい――プログラムとなるように思います。 Java の標準ライブラリを見ても、オブジェクトが目的語となっているものが多いです。例えば Callable インターフェイスは call() メソッドを持ちます。 "callableObject.call();" とプログラム上は書きますが、英語で書くと "call the
オブジェクト指向は失敗だった - 超ウィザード級ハッカーのたのしみ
オブジェクト指向プログラミングは失敗だった――以前から思っていました。 okuranagaimo.blogspot.com オブジェクト指向プログラミング (OOP) が人類にとって早すぎたか、人類には OOP が向いていなかった。世の中の Java で作られたプログラムのほとんどは、Java に付属する OOP っぽい機能を使うことで余計に複雑になっているように思います。ここでいう複雑さとは、頭が整理されていない状態、頭が構造化されていない状態のことです。例えば、インスタンスなんて作らずに全部 static メソッドでベタ書きされた方がよっぽどわかりやすいのに、それができてしまうからという理由で要らぬ副作用、すなわちオブジェクトの状態の変化が入りこんで、おかしなことになっている様子に出会ったことは何度となくあります。 おそらく原始的で単純な OOP で作られたプログラムはそこまで問題では
Table of Contents · Game Programming Patterns
Table of Contents Game Programming Patterns Acknowledgements Introduction Architecture, Performance, and Games Design Patterns Revisited Command Flyweight Observer Prototype Singleton State Sequencing Patterns Double Buffer Game Loop Update Method Behavioral Patterns Bytecode Subclass Sandbox Type Object Decoupling Patterns Component Event Queue Service Locator Optimization Patterns Data Locality
オブジェクト指向の呪いと、その避け方 - mizchi's blog
このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
関数型プログラミングとオブジェクト指向の抜き差しならない関係について整理して考える
教える側が知らないプログラミングの３つのこと
https://ubiteku.oinker.me/2017/09/08/oo-and-functional-are-orthogonal-or-not/
