2024/3/24に開催されたObject-Oriented Conferenceでの登壇資料です。 https://ooc.dev/2024/
オブジェクト指向は必要なのか / Is object-oriented needed?
2024/3/24に開催されたObject-Oriented Conferenceでの登壇資料です。 https://ooc.dev/2024/
オブジェクト指向宗教史
OOC 2024 の発表資料です。後のフィードバックを参考に、より妥当な文言に改訂してあります。 ※ 本コンテンツには、一部特定の宗教思想の迫害に言及する表現がございますが、そのような行いを肯定する意図の内容ではございません。
オブジェクト指向は業務システムで本当に不要なのか？ - Qiita
主旨 以前はシステムの状態をオブジェクト指向でカプセル化し、オブジェクト同士の通信でシステムの制御をしようとしていた しかし、Webアプリケーションのように状態をメモリ上に保持し続けるのが難しい環境が増えると、上記のことがやりにくくなった（ORMのインピーダンスミスマッチの影響が大きくなった） 現在では、システム全体の状態を管理するためにオブジェクト指向を用いるシーンは減っているが、要所要所でシステムを抽象化する道具の一つとして用いるシーンはあり、適材適所で使い続ければ良い はじめに 一時期あれだけもてはやされた「オブジェクト指向」ですが、現在では「業務システム開発においてオブジェクト指向で作るとろくなことがない」、とか、いっそ「不要である」、という意見もよく見かけます。 オブジェクト指向、この記事では特に「オブジェクト指向プログラミング」を対象として話をしますが、その利点は以下の３点に集
継承はなんでダメ？ - まめめも
「オブジェクト指向の継承を使うな」という主張が広まっているようです。なんでダメになったんでしょうか。 インターネットで見かけた「継承はダメ」という主張をいくつか眺めて、友人と議論しつつ、考えてみました。 「コードが読みにくくなる」 継承があると、メソッド呼び出しが実際にどのメソッド定義を呼び出すのか字面でわからない。 デバッガを使って、親クラスのメソッドに飛んだり、子クラスに飛んだりするのを追いかけないと行けない。 つらい。という主張。 めっちゃわかる。わかるんですが、これは「高度に共通化されたコードは読みにくい」という一般的な側面がかなり大きいような。 たとえば継承の代わりに高階関数を使うと、関数呼び出しがどのクロージャに飛ぶか字面でわからなくなる。 ひどいとコールバック地獄になって何が何やらになります。 継承がことさらにまずい理由を想像すると、すべてのメソッド呼び出しがポリモーフィック
時代がstaticおじさんに追いついてきた(追記あり) - きしだのHatena
この文章みてください。 オレはもう20年以上システム業界にいるけどな、その長い経験から言うと、オブジェクト指向なんてものは、理論としては面白いけど、およそ実用的とは言い難いものだな。まぁ、例えばGUIのコンポーネントとかはオブジェクト指向に基づいて作られているようだから、そういうツールとかを作る人には必要なものなのかもしれない。しかし君たちがいずれ作ることになる業務アルゴリズムにはまったく無縁のものだと思ってもらって間違いない。どうもこの業界、オブジェクト指向でなければダメ、というような風潮がまかりとおっているけどな、オブジェクト指向なんか本当に使っている人はほとんどいないよ。オレも少し勉強してみたけど、カプセル化とかポリ何とかとか、どうにも利点が理解できなかったね。実際、実業務で使ったことなどないしな…… 「またお前、オブジェクト指向の話をしてるのか」と思ったかもしれませんが、2010年
「オブジェクト指向設計実践ガイド」を読んだ - Qiita
はじめに オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方 を読みました。 この本は、オブジェクト指向の設計について、Rubyのプログラムをサンプルに、分かりやすく解説されています。 設計について学びたいRubyエンジニアにおすすめできます。 これを学ぶことで、変更しやすい、メンテナンス性の高いコードを書くための考え方が身につけられます。 メンテナンス性の高いコードを書きたいと思っているRubyエンジニアは、個人的には、リーダブルコードの次に読むべき本だなと感じました。 (リーダブルなコードについては前提として知っておいたほうがいいです) どうしてこの本を読んだのか クラスの設計、インターフェースの設計に苦手意識を持っており、元々社内でも多くの人がおすすめしている本だったので、読んでみようと思いました。 今まで、インターフェースを使ったオブジ
戻り値（返り値）とはどういう概念か掘り下げて考えた - Qiita
自己紹介 はじめまして、はると申します。完全異業種からのエンジニア転職を目指して、スクールに通いながら学習をしています。 概要 プログラミングにおける「戻り値」について、Rubyの例を用いて説明します。 注意 私は前職が完全異業種であり、英語も苦手で、スクールに入って初めてプログラミングに触れました。 そんな自分が理解しづらかった部分を、同じように初めてプログラミングの概念に触れた人に向けてまとめました。 自分の復習も兼ねて、超超噛み砕いて書いているため、周りくどい書き方になっている箇所もあるかと思います。 また、初学者のため、間違っている箇所もあるかもしれませんのでその際は教えて頂けると嬉しいです🙇 戻り値とは 戻り値とは、言語に関わらずプログラミングに共通する概念です。 この記事全体を通して説明していきます。 噛み砕いて考える 私が初めて戻り値に出会ったときは、「 あらかじめ定義して
オブジェクト指向をわかりやすく説明してみる。 - Qiita
初めに こんにちは、今回はプログラミングの基本とも言えるオブジェクト指向ですが、 自分の言葉でオブジェクト思考とは何かを表現することによって、 さらに理解をブラッシュアップしていければいいなと思い、この記事を作成しました。 オブジェクト指向に対する解説記事はもう多く出回っている状況ですが、 どなたかにこの記事がお役に立てば幸いです。 オブジェクト指向とは とあるデータとそのデータを制御する処理をひとまとまりのオブジェクト（物）とみなし、 そのオブジェクト同士の関係性を構築していくことで一つの成果物を作成していくプログラミング手法のことを指します。 オブジェクト指向を支える要素たち クラス オブジェクトを生成するための設計書のようなもの。 クラスの中には、それぞれプロパティとメソッドが要素としてある。 プロパティ オブジェクトが保有するデータのことを指す。 メソッド オブジェクトが保有するデ
マリオで学ぶSOLID原則
はじめに 最近オブジェクト指向とデザインパターンについて学び始めたので、勉強しつつ記事にまとめていきたいと思います。 初回はSOLID原則についてです。SOLID原則はオブジェクト指向プログラミングにおいて、開発者にとって読みやすく、メンテナンスが可能なプログラムを作成しやすくするために考えられたルールです。 この記事では、オブジェクト指向プログラミングの重要な開発原則であるSOLID原則について皆さんが想像しやすいマリオのクラス実装を例に解説していきます。 1. S (Single Responsibility)：単一責任の原則 クラスは単一の責任を持つべきと言う原則です。 ここでの責任というのは、オブジェクトが持っている機能のことです。 一つのクラスができる機能（責任）が複数あると、クラス内部の関数が強い結合を起こす可能性が高ま理望ましくありません。 次のマリオクラスを見てみましょう。
オブジェクト指向についてまとめてみた - Qiita
はじめに オブジェクト指向という概念が自分も含め難しいく奥が深いので、自分なりに要約してみました。 はじめてこの概念を聞いた方に簡単にまとめたので参考にしていただけたらなと思います。 前提知識 オブジェクトとは JavaScriptにおけるオブジェクトとは、データや処理を一つにまとめてあるもの。 JavaScriptのデータ JavaScriptのオブジェクトの中でいうデータとは変数のことであり、この変数の中にプロパティというハッシュ形式（キーとバリューの組み合わせ）で格納されている。
猿でもわかるオブジェクト指向とデザインパターン - Qiita
はじめに 本記事では、初学者向けにオブジェクト指向について簡単に解説します。 細かい文法部分については省略していますが、イメージを掴んでもらえたら嬉しいです。 また、本記事ではGoFのデザインパターンについても簡単に紹介します。 今回は、Singleton、Factory、Strategy、Observer、Adaptorパターンについて取り上げます。 初学者の方は、今回紹介するデザインパターンをなんとなくでも理解できたらバッチリです。 前提知識 デザインパターンを学ぶにあたって、オブジェクト指向についての理解は必須になります。 ここでは前提知識として、クラスとインスタンスの関係、オブジェクト指向の3大要素について簡単に解説をしておきます。 不要な方はそもそもデザインパターンとは？から読み進めてください。 クラス と インスタンス クラス クラスのイメージは"設計図"です。 例として、家を
オブジェクト指向で作りたい！クラス実装やリファクタリングする時のヒント - Qiita
はじめに みなさんオブジェクト指向開発してますか？ 大規模な開発であれば実装前にきっちりとクラス設計を行っていることでしょう。 また、大規模でなくても機能を跨いだり、複数の担当者で利用するクラスなどは、事前に慎重に設計すべきです。 開発現場にきちんとクラスの設計ルールがある場合は、この記事は読まなくて大丈夫です。 しかし、小規模の機能追加なんかの場合、クラス設計も実装も個人に任されることがあると思います。何ならオブジェクト指向で作らなくても全然構わない状況かもしれません。 でも、オブジェクト指向で作りたいですよね？ この記事では、オブジェクト指向について基本的な知識がある人向けに、実装の最初の取っ掛かりや、リファクタリングする際の観点とか、そういったヒントを紹介したいと思います。 （注意）チームの開発・設計・コーディング等、各種ルール・規約を遵守してくださいね。 サンプルケース ここではカ
【C#】SOLID原則を学ぼう - Annulus Games
今回の記事はオブジェクト指向プログラミングにおける設計の基本、「SOLID原則」について。 ある程度プログラミングの文法を知っていれば、動作するコードを書くことは可能です。しかし、より良いコードを書きたいのであれば、文法の知識だけではなく、設計に関する知識も必要になってきます。 特にUnityでは、適当にコードを書いていくと目も当てられないようなスパゲッティーコードが容易に出来上がります。「とりあえずシングルトンにすりゃいいや！」みたいなノリで「何とかManager」クラスを作りまくった結果、「あれ？この処理どこに書いたんだっけ？」という状況になったこと、誰しも一度はありますよね…？ 今回は、そんなクソk…良くないコードを書かないための設計原則である「SOLID原則」について紹介します。記事内のコードはC#で記述しますが、言語に関わらずSOLID原則は広く応用の効く考え方なので、是非とも覚
インターフェイス分離原則 - Qiita
案件が多忙過ぎて久々の更新となってしまいました汗 まあそんなことは置いておいて、今回はインターフェイス分離の原則について記述します。 注、以下の図解中の命名は、一旦説明用に意味のない名前にしましたが、 本来はその概念の意図がわかる名前にしなくてはいけません。 背景 今回扱う設計思想は、インターフェイス分離原則。 私は勝手に、目的の分離原則と呼んでます。 ミノ駆動本などでは、単一目的と呼ばれていたりしますね。 で、ここ数か月 ビジネスアーキテクチャの設計方針や方法論を確立し、それをクライアント側に認知させるって内容の案件にアサインされてました。 そこでわたしはUAFというエンタープライズアーキテクチャフレームワークぽいものを使っていたのですが、 これがですね、学習コストは高いものの、本当に設計ノウハウがめっちゃ詰まったものだったんです！！ その中で具体から抽象化する際に、具体１つに対して抽象
オブジェクト指向の３大要素をWebアプリの実装を例に解説【継承・カプセル化・多態性】 - Qiita
【オブジェクト指向ってわかりにくくない？】 オブジェクト指向の3大要素：継承・カプセル化・多態性って何度勉強してもふわっとしか理解できなかったのは私だけでしょうか？ 勉強中はわかったような気にはなるのですが、実際にコードを書く段階でどう使えばいいの？という状態になりました。 継承の説明で「勇者というclassから上位互換のスーパー勇者classを作る」と聞いて、実務で勇者はでてこないしなぁ、良さや使う場所のイメージが難しいなぁと思っていました。 しかし、実務を積んでいくと、良いコードを作る上で大事な考え方であることがわかってきました。 実務に近い内容で説明される方がわかりやすいと思うことが多いので、この記事では具体的なWebアプリの実装を元に継承・カプセル化・多態性を解説していきたいと思います。 【この記事で説明すること】 この記事では、書籍管理アプリを作ることを例にオブジェクト指向の継承
オブジェクト指向はコードを複雑に読みにくくする - きしだのHatena
「オブジェクト指向するとプログラムが読めなくなるから禁止」のような話は昔からあって、新しい技術についてこれない人を揶揄するようなニュアンスで使われていましたが、実際にはこれはオブジェクト指向迷路にうんざりした現場での率直な意見だと思います。 オブジェクト指向は、まじめにやるほどプログラムを読みにくくするという性質をもっています。 ※ 使い方次第というコメントついてますが、だからこそちゃんと性質をしっておく必要があると思います。 オブジェクト指向の代表的な指針を３つあげると次のようなものがあります。 オブジェクト同士の連携としてプログラムを組む 単一責務の原則 インタフェースと実装の分離 まず、オブジェクト同士の連携でプログラムを組むと、コードが飛びまくって追いにくくなります。そして単一責務の原則により、小さいクラスが大量に生成されて、追いにくさがさらにあがっていきます。 ダイクストラ先生が
難解なソフトウェアをデザインする人にこそお勧めしたいOOUI（オブジェクト指向UI）
みなさまこんにちは。ヤフーでデータソリューション事業のUI/UXデザインを担当している、横内です。 2022年11月に弊社が運用するデータ可視化ソフトウェアのDS.INSIGHTで人流データを分析できるPlace機能を大幅アップデートしました。その際使用したOOUIという設計手法から得られた学びをプロジェクトの実例を交えながらご紹介します。 OOUIとは そもそもOOUIとは何者でしょうか。OOUIとは、Object Oriented User Interfaceの略語で、通称オブジェクト指向UIと呼ばれています。 オブジェクトとはその名の通り「役割を持ったモノ」を指す言葉です。例えばお店で買うクロワッサンや、ECサイトでカゴに入れる衣服など、その場の実体あるなしにかかわらず、私たちがモノとして認識できる対象のことを指しています。 この、ユーザーが認識できるモノ（オブジェクト）を起点にUI
オブジェクト指向のメリット・デメリット - Qiita
はじめに この記事は「【マイスター・ギルド】本物のAdvent Calendar 2022」10日目の記事です。 最近、IT業界のトレンドや動向把握のため、面白そうなエンジニア雑誌があれば読むようになりました！ その雑誌の中で、12月24日に発売されるWEB+DB PRESS Vol.132が目に止まりました。その表紙には、「オブジェクト指向神話からの脱却」という文字が大きく掲載されています。 オブジェクト指向信者の私にとっては、脱却する必要はないだろうと思いながら、とても気になる内容で今から楽しみにしてます！ 本を読む前に現時点での私のオブジェクト指向に対する考えについて整理しておきたいなと考え、本記事では個人的なオブジェクト指向のメリット・デメリットを書いていこうと思います。 オブジェクト指向歴 簡単に自身のオブジェクト指向歴を書いておきます。 オブジェクト指向の言語に触れたのはC#が
「オブジェクト指向神話からの脱却」という特集をWEB+DB PRESSで書きました - きしだのHatena
「オブジェクト指向神話からの脱却」というあおり気味タイトルの特集をWEB+DB PRESS vol.132で書きました。 12/24発売！クリスマスプレゼントです WEB+DB PRESS Vol.132 作者:きしだ なおき,加藤 尋樹,斉藤 洸紀,牟田 裕太郎,吉澤 政洋,朝日 リナ,鈴木 僚太（うひょ）,川島 義隆,五十嵐 進士,末永 恭正,佐藤 雄太,吉井 健文,牧 大輔,西山 和広,吉田 花春,古川 雅大,岡林 大,池澤 春菜,和田卓人,日高 正博,はまちや2,竹原技術評論社Amazon 大まかには、「オブジェクト」でソフトウェアをぜんぶ考えるということに無理があったので、パーツそれぞれ適したやりかたでやっていこうぜ！という内容です。 ソフトウェアを切り出したときのパーツとしてのオブジェクトの特性が同質であるという暗黙の前提があって、だから「オブジェクトの話をすればソフトウェア開
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Java 20, 21, オブジェクト指向からデータ指向へ / Java20, 21, Object Oriented to Data Oriented
