タグ

オブジェクト指向に関するrryuのブックマーク (43)

  • オブジェクト指向はコードを複雑に読みにくくする - きしだのHatena

    「オブジェクト指向するとプログラムが読めなくなるから禁止」のような話は昔からあって、新しい技術についてこれない人を揶揄するようなニュアンスで使われていましたが、実際にはこれはオブジェクト指向迷路にうんざりした現場での率直な意見だと思います。 オブジェクト指向は、まじめにやるほどプログラムを読みにくくするという性質をもっています。 ※ 使い方次第というコメントついてますが、だからこそちゃんと性質をしっておく必要があると思います。 オブジェクト指向の代表的な指針を3つあげると次のようなものがあります。 オブジェクト同士の連携としてプログラムを組む 単一責務の原則 インタフェースと実装の分離 まず、オブジェクト同士の連携でプログラムを組むと、コードが飛びまくって追いにくくなります。そして単一責務の原則により、小さいクラスが大量に生成されて、追いにくさがさらにあがっていきます。 ダイクストラ先生が

    オブジェクト指向はコードを複雑に読みにくくする - きしだのHatena
    rryu
    rryu 2023/02/25
    これはFizzBuzzエンタープライズエディションみたいに規模に関わらずフルスペックの抽象化を適用するのが良くないというだけで、C言語でも必ずFILE型みたいに作ったら読みづらくなると思う。
  • インスタンスとオブジェクトの違い - きしだのHatena

    インスタンスとオブジェクトは混同しがちで区別がようわからんになりがちです。 とりあえず某所で説明したものを再構成します。 ※2022/12/10追記: クラスに対するのはインスタンスになるべき(たとえばクラス変数とインスタンス変数)なので、ちょっと修正するべきですが、このエントリはそのまま残してます。 クラス・インスタンス・オブジェクト クラスをインスタンス化(実体化)したものがオブジェクト(物)です。 実際に在るものはクラスとオブジェクトで、インスタンスはそれらの関係です。colorsやsportsが並んでるツリーが「オブジェクト」で、右のパレットに並んでるTreeが「クラス」、Treeからみたときのツリーが「インスタンス」ということになります。 ここでツリーはオブジェクトでもインスタンスでもあります。 このように、同じものをオブジェクトともインスタンスともいうことができるので混同してし

    インスタンスとオブジェクトの違い - きしだのHatena
    rryu
    rryu 2022/09/18
    ややこしいのは言語によって何がオブジェクトで何がそうでないかが違うからで、インスタンスとオブジェクト自体はややこしくないと思う。
  • 私なりのオブジェクト指向プログラミングの定義 - kmizuの日記

    きしださんの以下のツイート オブジェクト指向はこの20年だれも再定義せずみんな自分の思うオブジェクト指向を暗黙に仮定して適当に話してるだけなので、技術的な共通認識のもとの議論はほとんどできないんですよ。という話を「オブジェクト指向をきちんと使いたいあなたへ」の記事に書いたのだけど、そろそろ公開するか— きしだൠ(K8S(Kishidades)) (@kis) July 29, 2019 を読んで、そういえば、私が思うオブジェクト指向の定義、についてツイッター以外ではあまり語ったことがなかったなと思い返し、ちょっと記事にしてみることにしました。まず、結論からいうと、私はオブジェクト指向プログラミングとは サブタイピングを活用したプログラミング手法の総称 と考えています。ここで、クラス継承とかインタフェース継承とかダックタイピングとかではなく、単にサブタイピングであるのがポイントです。なお、型

    私なりのオブジェクト指向プログラミングの定義 - kmizuの日記
    rryu
    rryu 2019/07/29
    もはやOOPで共通化できる概念はComplex typeにメソッドという毛を生やしていくくらいじゃないだろうか。
  • オブジェクト指向にメリットなんて存在しない|古都こと|note

    最近の新人は勉強熱心だ。新しく聞いた概念を貪欲に取り入れようとする様は、はたから眺めていても感心する。私なんて10年前に得た知識でなんとかごまかしごまかし生きているというのに。 もちろん様々な場面で「躓き」は発生する。有名どころではポインタや非同期処理が初心者キラーだ。そして一番の初見殺しは……オブジェクト指向だ。 オブジェクト指向に殺されたプログラマは数知れない。新人からベテランまで、たいてい皆殺しにされている。 なぜそれほどまでに多くのプログラマを混乱させるのだろう。やネットではオブジェクト指向の数々の多大なメリットが列挙されており、実に素晴らしいパラダイムに思える。しかし教通りに組んでみてもどうにもしっくりこない。当に自分はオブジェクト指向のメリットを享受できているのだろうか? 種明かしをしよう。実はそれらメリットとやらは全部全くの嘘で、オブジェクト指向にメリットなんてものは存

    オブジェクト指向にメリットなんて存在しない|古都こと|note
    rryu
    rryu 2019/01/01
    普通に使われているからもうメリットはないというのは何か違うと思う。構造化プログラミングはそれをしない方が難しいほど普通になったけどそれ自体のメリットがなくなった訳ではない。
  • 「オブジェクト指向とは、現実世界を正しく捉えること」という理解はデメリットのほうが大きい

    これは「オブジェクト指向」がよくわかってない人の書いたポエムである。 そういうのが嫌いな人はお帰りください。 はじめに リンクは貼らないが「オブジェクト指向の質とは現実を正しく捉えること」と書かれている記事(以下、元記事)がバズった。 私は正直「オブジェクト指向」の何たるかを理解しているとは言い難い。 しかし、そんな私でも元記事がいくつかの点でおかしい、もっと厳しくいうと開発現場に混乱をもたらす可能性を持っていることは理解できる。そこでこの記事では「オブジェクト指向とは〇〇である」という言及は行わずに、元記事の問題点を指摘するに留める。 長方形と正方形の例 オブジェクト指向プログラミングと現実世界の話というとBobおじさんが『アジャイルソフトウェア開発の奥義』に書いた正方形と長方形の話が有名だ。 話は簡単だ。「正方形クラスは長方形クラスを継承するべきか?」というものだ。 少しだけ詳しく見

    「オブジェクト指向とは、現実世界を正しく捉えること」という理解はデメリットのほうが大きい
    rryu
    rryu 2018/10/09
    まあ、大抵の分類は「〇〇のうち特定の状態のものを□□と呼ぶ」だから、これをそのままクラス階層にするとこの記事の例のようにうまくいかない。
  • JavaScriptのオブジェクト指向は、逆の順番で学んだほうが理解しやすいと思うので…

    ※この投稿は 2011/03/10 に こちら に投稿した記事の転載です。 これを書いた経緯 事の発端というか、きっかけは、id:perlcodesampleさんとid:gfxさんの下のポストを見て、 JavaScriptで一番簡単にオブジェクト指向プログラミングを行う方法 (id:perlcodesampleさん) JavaScriptにおけるオブジェクトの定義 (id:gfxさん) new とか prototype を使うのが推奨されてないとか、直接代入するほうが楽とかじゃなくて、挙動が違うんだよなぁ、と思ったこと。 挙動が違うんだから、もちろん使いどころも違うんですよね。 でも実際、JavaScriptのオブジェクト指向は混乱しやすいと思います。 自分もご多分にもれず、さんざん混乱させられたクチですしね。 わかってしまえば、どってことなくて、とってもシンプルなんですけどね。 せっかく

    JavaScriptのオブジェクト指向は、逆の順番で学んだほうが理解しやすいと思うので…
    rryu
    rryu 2018/10/05
    まあJavaScriptの闇はプロトタイプベースなのにプロトタイプチェーンが直接操作できずnew演算子の副作用でなんとかするところにあるしなあ。
  • JavaScript初心者にclassを伝える - Qiita

    初めに この記事ではJavascriptのclassについてザックリですが解説します。 多くの初心者にとってclassは「何だこれ???」と躓くポイントだと思います。 (実際、自分も最初眺めた時は意味が分からず頭が学級崩壊してました。) なので、記事ではサンプルコードと共に、 「何だこれ???」を「なるほど!!!」に 変えていけるように解説します。 序章 - 基構文 まずはclassの基構文を載せます。 使い方は後々に解説しますので、 とりあえず構文を眺めて美味しいご飯でも考えてください。 意味は深く考えないでいいと思います。 はいど~ん! classの基構文はこんな感じ!これだけ。 大丈夫です、内容も全く難しくないです。 解説すると、 ・NAMEは任意の名前(変数や関数の定義と一緒) ・constructorは必須な関数(classが呼び出された時に最初に実行される関数) ・a,

    JavaScript初心者にclassを伝える - Qiita
    rryu
    rryu 2018/09/17
    オブジェクトは理解できているがクラスは理解できていない人向けのようだが、伝えたくなったということはそういう理解の人がいるということなのだろうか。
  • Getter/Setterを避けて役に立つドメインオブジェクトを作る - かとじゅんの技術日誌

    Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んでます。モデリングに関しては成分薄めですが、よいだと思います。はい。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 作者: Robert C.Martin,角征典,高木正弘出版社/メーカー: KADOKAWA発売日: 2018/07/27メディア: 単行この商品を含むブログを見る 書の大筋から少し逸れるが、「5章 オブジェクト指向プログラミング」の「カプセル化」が面白かったので、これを切り口にモデリングについて考えてみる。 OO言語のカプセル化はすでに弱体化している オブジェクト指向の三大要素の一つである、カプセル化について、以下のようなことが書いてあります。 「カプセル化」がOOの定義の一部となっているのは、OO言語がデータと関数のカプセル化を簡単かつ効果的なものにしているから

    Getter/Setterを避けて役に立つドメインオブジェクトを作る - かとじゅんの技術日誌
    rryu
    rryu 2018/08/14
    C言語の不完全型が完璧なカプセル化なら、Javaの.classファイルとjavadocしか提供しない方式も完璧なカプセル化なんじゃないだろうか。
  • ポリモーフィズムを活用するとなぜ if や switch が消えるのか? - Qiita

    if (売上.勘定科目 == 勘定科目.現金) { // 計算するロジック } else if (売上.勘定科目 == 勘定科目.売掛金) { // 計算するロジック } else if (売上.勘定科目 == 勘定科目.有価証券) { // 計算するロジック } このようなコードはしばしばスパゲッティになりがちですし、 項目が増えるたびに、条件分岐を増やさないといけないので保守も大変です。 売上の課目ごとに計算方法が違いますが金額計算するという振る舞いは同じです。 このコードからif文を駆逐するにはどうしたらいいでしょうか? 型やフラグ、enumによる条件分岐はたいていの場合、ポリモーフィズムによって消し去ることができます。 ポリモーフィズムとは異なる型のオブジェクトを同一視し、そのオブジェクトの型によって動作を切り替えることです。 ポリモーフィズムは動的型付け言語ではダックタイピング、

    ポリモーフィズムを活用するとなぜ if や switch が消えるのか? - Qiita
    rryu
    rryu 2018/08/08
    分岐が消えるのではなく最初のオブジェクトの作り分けのところに集約されるといった方が近いと思う。
  • Elixir から Elm の流れで、いよいよオブジェクト指向に対する懐疑心が無視できないレベルに達した2017年冬。 – ゆびてく

    Elixir から Elm の流れで、いよいよオブジェクト指向に対する懐疑心が無視できないレベルに達した2017年冬。 – ゆびてく
    rryu
    rryu 2018/08/04
    結局、じゃどうすればいいのかということには人類はまだ答えを出せていない。
  • オブジェクト指向は難しくない(「staticおじさんの逆襲」への反論) - acomagu's diary

    qiita.com これを読んでいろいろと言いたいことが出てきたので書いておく。 以下に記事の最後のこの記事で言いたかったことから2つを引用します。 オブジェクト指向は難しい。 (どのあたりのことを「難しい」と言っているのだろう)まず「継承は難しい」旨が書いてあるが、それはオブジェクト指向使いの中でも常識で別に継承無しでもオブジェクト指向はできる。「継承よりもコンポジション」というのは間違っても「オブジェクト指向はダメだ」というメッセージではなく、オブジェクト指向の中での方法の話である。 「デザインパターンが難しい」という話も同じで、別にデザインパターンを意識しなくてもオブジェクト指向は十分にできる*1。 ただ、だからといってオブジェクト指向をやるのが難しくないというわけでもない。「問題を(オブジェクトに)抽象化するのが難しい」と言っているのであればそれはそうで、適切な抽象化を簡単にする方

    オブジェクト指向は難しくない(「staticおじさんの逆襲」への反論) - acomagu's diary
    rryu
    rryu 2018/08/04
    結局、フレームワークでもモナドでも規定の構造に沿って設計するということは難しいということなのだと思う。
  • オブジェクト指向の呪いと、その避け方 - mizchi's blog

    このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(

    オブジェクト指向の呪いと、その避け方 - mizchi's blog
    rryu
    rryu 2018/08/01
    抽象クラスを具象化する以上の継承をするとだいたい無理やり感が出て闇が生じる。
  • 【具体例で解説】パケット交換方式とは?回線交換方式との違いを合わせて理解しよう | ワカテク

    遺言サディスティック #歌うゆいごん司法書士 #遺言書 #ゆいごん書 #相続 #丸の内サディスティック #椎名林檎 #司法書士 #替え歌 #元バンドマン #元パチプロ #紅白に出たい

    【具体例で解説】パケット交換方式とは?回線交換方式との違いを合わせて理解しよう | ワカテク
    rryu
    rryu 2017/08/01
    一歩進んでBuilderパターンの説明になってしまっているような。料理に喩えるとオブジェクトの相互作用が発生するから余計に話がややこしくなる。
  • 俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita

    ちなみに、最初に結論だけ言っておくと、まずSandi Metzの「オブジェクト指向設計実践ガイド」を読め、という話です それだけで終わってしまいたい気持ちはあるが、不親切過ぎるしもうちょっとRails向けの話を書こうと思う。 ただ言いたいことは、よく分かってないのに使うのは止めろということ。 自分もで書いたりした手前、それが参考にされた結果なのかもしれないが、世の中には当に酷いクラスが存在するもので、雑にサンプルで書くと以下の様な感じのコードが存在したりする。 class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.activ

    俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
    rryu
    rryu 2016/12/15
    コントローラの中身がただ単に何とかサービスというクラスに移し変えられているやつは特に悔い改めて欲しい。
  • オブジェクト指向で料理を例える場合,chicken.cut()かchef.cut()か

    実用的で無い内容なのでここで聞いて良いのか悩みましたが,一応クラスの設計の参考になるだろうと思って質問しました。 自分の普段使いがPythonなので,説明用のコードはPython風ですが,どの言語にも共通する問題だと思います。 先ほど友人と,「鶏肉を5つに切る」にはどうすれば良いかという例えばなしをしていました。 これを実装する場合, chicken.cut(5) # chickenは (Foodクラスを継承した) Meatクラスのインスタンス chef.cut("chicken", 5) # chefはChefクラスのインスタンス。あらかじめset_foodなどで{"chicken": chicken}を内部に保持した状態にしておく の2通りが考えられるのではないかと思います。 鶏肉の状態が変化するという意味では,「chickenが5つに分割された状態になる」前者の方が自然であるように思

    オブジェクト指向で料理を例える場合,chicken.cut()かchef.cut()か
    rryu
    rryu 2016/07/28
    プログラミングだと「どのように切られることが可能なのか」を切られる側が定義しないといけないから鶏肉側にアルゴリズムを持たせざるを得ないよなあ。
  • 僕にとってMaybe / Nullable / Optional が、どうしてもしっくりこないわけ。 - 亀岡的プログラマ日記

    はい、ポエムです。自分が正しかろうとは欠片も考えていません。異論や示唆は歓迎ですが、そう考えろと言っているわけではないので、そこはご容赦を。 前置き終わり。 さて、Nullは50億ドルの過ちだそうですね。 null参照の考案は10億ドル単位の過ち? | スラド デベロッパー そして、それを回避するため、Maybe / Nullable / Optional などの言語機能が生まれ、各言語に埋め込まれています。 それは、大変喜ばしいこと、だと思います。 なんですが、どうもどうも、僕はどうしてもしっくりこないのです。これら全てに対して。Nullと同じように。 Nullは何がダメなんだっけ? Nullがダメな理由、ってなんなんでしょう。よく言われる批判として、以下があるのかなぁと思っています。 ①Nullは型ではない Nullと言っていますが、こいつはNullポインタ、でございます。 からの「何

    僕にとってMaybe / Nullable / Optional が、どうしてもしっくりこないわけ。 - 亀岡的プログラマ日記
    rryu
    rryu 2015/11/27
    ウェブアプリで該当するデータがなかったら404を返すという処理は頻繁にあるけど、これをNullObjectで実装するのは明らかに不適切なので、NullObjectで実装できなければおかしいというのは無理すぎると思う
  • そのオブジェクト指向入門は間違っている(大げさ) - Webアプリエンジニア養成読本 AdventCalendar2014 25日目最終日! - uzullaがブログ

    はい、Webアプリエンジニア養成読 AdventCalendar2014です。突然トリをやる事になってしまったので、どうしたもんかとおもいます…。 「最終日だぞ…ちゃんとかかないといけない…しかしネタはない…そうだリンク集を作ろう!」とか思ったんですが、そもそもアドベントカレンダーってリンク集だよねって気付いて愕然としているクリスマスの夜です。現在朝の4時、これを書き終えて寝たい。 さて…何を話そう ここまでWebアプリエンジニア養成読アドベントカレンダーということで続けてきました。そして今日は25日、ついに最終日です! Webアプリエンジニア養成読 Advent Calendar 2014 - Qiita Webアプリエンジニア養成読[しくみ、開発、環境構築・運用…全体像を最新知識で最初から! ] (Software Design plus) 作者:和田 裕介,石田 絢一 (uz

    そのオブジェクト指向入門は間違っている(大げさ) - Webアプリエンジニア養成読本 AdventCalendar2014 25日目最終日! - uzullaがブログ
    rryu
    rryu 2014/12/26
    そもそもクラスとインスタンスの話から入るのが間違っている感じがする。
  • オブジェクト指向は禁止すべき!?なのか つれづれ/shi3z:電脳ヒッチハイクガイド:電脳空間カウボーイズZZ(電脳空間カウボーイズ) - ニコニコチャンネル:生活

    麻布十番でひさしぶりに「もや鍋」をべながらボケーっとしていたら、「オブジェクト指向は禁止するべき」という記事がタイムラインにながれてきていて、「なぬ!?」と思ったのだけど、まともな記事だった。 オブジェクト指向がなぜ優れているのか、というかなぜ世の中はオブジェクト指向を必要としたのか、という点について無視すると、たしかに初心者にオブジェクトの概念教えるのは難しいんだよね。 僕は基的にゲームプログラミングから入っているから、オブジェクト指向というのはびっくりするくらい重要というか、当たり前のものの一つになっている。 ゲームだとオブジェクトというのが画面に現れる。 例えば弾とか敵とかね、あれがひとつひとつオブジェクトだよ、と言われれば納得する。 その昔、ナムコの業務用基盤(ギャラクシアンとか)ではスプライトのことをオブジェクトと呼んでいたくらいだからゲーム=オブジェクト指向は揺るぎないと思

    オブジェクト指向は禁止すべき!?なのか つれづれ/shi3z:電脳ヒッチハイクガイド:電脳空間カウボーイズZZ(電脳空間カウボーイズ) - ニコニコチャンネル:生活
    rryu
    rryu 2014/07/20
    Macの開発言語は元々はObject Pascalで最初からオブジェクト指向だったのだが、途中からC言語が主流になって第1引数に構造体を取る関数呼び出しスタイルになったのが不思議。
  • オブジェクト指向は禁止するべき - きしだのHatena

    プログラムがまだ不慣れな人が「プログラムちょっとわかるようになったけど、まだぜんぜんオブジェクト指向とかできてません」のように言ったり、ちょっと慣れた人が「このソース、ぜんぜんだめ。オブジェクト指向ができてない」にようなことを言ったり、まるで、オブジェクト指向ができてるかどうかがよいプログラムかどうかを表すことになってるようだ。 Javaのアルゴリズムのに、「Javaなのにオブジェクト指向ができていない」のような書評がついているのを見たときには、お前は何を求めてるんだと思ったりもした。 そのようなオブジェクト指向は、窓から投げ捨てるべきだ。オブジェクト指向はプログラムのよしあしの基準にならない。 むだにHogeインタフェースとHogeImplクラスがあったり、むだにnewするだけのcreateメソッドがあったり、どこで値が設定されてるかわからないオブジェクトがひきまわされてたり、ソースコ

    オブジェクト指向は禁止するべき - きしだのHatena
    rryu
    rryu 2014/07/19
    不要な複雑さというのは手続きベースでも関数型でも盛り込めるものだと思うが、オブジェクト指向が顕著なのはクラス階層とオブジェクト間の関連という2軸で絡ませられるからかな。
  • 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い - Qiita

    はじめに 関数型プログラミングとオブジェクト指向の抜き差しならない関係について整理して考えるという記事がkenokabeさんという方が挙げていて、拙著の 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡について言及があったので、補考として挙げておく。 暗黙的状態と明示的状態 これまで、関数を「わかりやすくきれいに書く方法」とオブジェクト指向が「どのようにして生まれてきたか」について話してきた。 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 一見、それぞれ関係ないように思うかもしれないが、実は大きなテーマでつながっている。 『それは「状態」をどのように取り扱い単純化するか。』ということだ。そして、これがいわゆる関数型プログラミングとオブジェクト指

    「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い - Qiita
    rryu
    rryu 2014/07/15
    参照透過程度では関数型プログラミングとは言えないイメージがある。高階関数がガンガン出てきて1行読み解くのに1時間かかるとかで無いと。