タグ

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

  • 2021年の「オブジェクト指向」を考える

    きしださんが先日もたのしいお題を投下されていました。 出遅れましたがこのネタについて少し掘り下げてみます。 念のため個人的なスタンスをあらかじめ表明しておくと、オブジェクト指向に対してはそれなりに好意的ですが、別に時代の最先端だとかソフトウェア開発に必須の知識というほどではない(でも知っておくと便利というか、知らないと不便なこともあるかもしれないのでわざわざ避けるのはおすすめしない)というくらい温度感です。 オブジェクト指向 is 何 そもそも「オブジェクト指向」という言葉自体、座りの悪い言葉です。 意味が明確なのは「オブジェクト指向プログラミング(OOP)」、「オブジェクト指向プログラミング言語(OOPL)」、「オブジェクト指向設計(OOD)」「オブジェクト指向分析(OOA)」といった「オブジェクト指向なんとか」の方で、それらをふわっとまとめた(ような気がする)単語が「オブジェクト指向」

    2021年の「オブジェクト指向」を考える
  • オブジェクト指向はすでに粒度が時代にあっていない - きしだのHatena

    定期的にオブジェクト指向disを書いてしまってるのだけど。 とりあえずオブジェクト指向の話をすると定義が人によって違いすぎるので、改めてここでの定義を書いておくと 、基的にはOMTの「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」 に従うのですが 「1990年に流行りソフトウェア開発のすべてを飲み込み、いまとなっては人それぞれ定義が違って技術的議論に使えなくなった、主にオブジェクトを基単位としてプログラムを整理するやりかたを指すマーケティング用語」 という感じです。 ほとんどの場合で人によってオブジェクト指向の指す範囲が違いすぎて、技術的知見の共有には使えなくなっています。でも、いずれの定義にしろオブジェクトを基単位にするというのは重要ではないかと。 ソフトウェアの組織化の単位としてオブジェクトを使うというのが大事で、データの搬送に構造体代

    オブジェクト指向はすでに粒度が時代にあっていない - きしだのHatena
  • 2つのオブジェクト指向ーメッセージ・パッシングと抽象データ型 - Hot Heart, Cool Mind.

    オブジェクト指向には、もともとアラン・ケイが創案したメッセージ・パッシングのオブジェクト指向と、その後、抽象データ型から発展したオブジェクト指向の2つがあって、その2つは、プログラム言語の機構の面からは共通する要素も多いのだけどプログラミングに対するビジョンという点では相当に異なっている、という見方があります。 これに関しては、id:sumim さんが「二つのオブジェクト指向とそれぞれのメリット」という行き届いた論考を公開しておられて、僕などはそれを読んで頭を整理した口です。 その後、それを踏まえて自分なりに両者の違いを考えてツイートしましたが、言葉足らずな点もあったので、内容を整理するとともに加筆しました。 言語機構に惑わされるな この2つのオブジェクト指向は、実現する機構の面では似ています。オブジェクト指向の3要素として「カプセル化、継承、ポリモフィズム」があると言われますが、そうした

    2つのオブジェクト指向ーメッセージ・パッシングと抽象データ型 - Hot Heart, Cool Mind.
  • 単一責任原則で無責任な多目的クラスを爆殺する - Qiita

    この記事は クラウドワークスアドベントカレンダー2020 8日目の記事です。 概要 こんにちは、クソコードを爆殺リファクタリングするのが大好きなミノ駆動です。 今回は単一責任原則の話です。 単一責任原則はSOLID原則のひとつとして有名で、2020年のオブジェクト指向カンファレンスのアンケートでも、SOLID原則の中で最も人気がありました。 皆さんは単一責任原則を遵守した設計をしていますか。 どんな構造が単一責任設計で、一方どんな構造が単一責任でない設計か、明確に意識していますか。説明できますでしょうか。 ところで「単一責任原則とはなんぞや」について、少なくとも私の観測範囲では、概念的な話にとどまっているものが多く、コードレベルで具体的に説明しているものは少ないように感じます。 そうした状況からか、単一責任原則の解釈が人によって違っていたりしているように感じます。 記事は、今一度単一責任

    単一責任原則で無責任な多目的クラスを爆殺する - Qiita
  • オブジェクト指向のその前に-凝集度と結合度/Coheision-Coupling

    Jetpack ComposeとGraphQLによるServer Driven UI/jetpackcompose-grahpql-serverdrivernui

    オブジェクト指向のその前に-凝集度と結合度/Coheision-Coupling
  • オブジェクト指向のハードコア

    オブジェクト指向のハードコアは2019年5月25日にゼロベースサロンで行われたイベントです。「オブジェクト指向」というキーワードについて、プログラミング、デザイン、哲学などの分野を横断しつつ知的な議論ができました。記録映像は必見。 企画意図/招待状 この研究会の企画意図については、私が送った招待状を見ていただくのが早いでしょう: いくつか異なる分野で「オブジェクト指向」がキーワードとして注目されています。昨年からGUIデザインの分野では「オブジェクト指向ユーザーインターフェイス」(OOUI)の議論がホットです。ソフトウェア開発の分野では、数年前からオブジェクト指向の見直しとしての「ドメイン駆動設計」(DDD)が広まっています(※原著である英語版から日語への翻訳は数年遅れています)。さらには「オブジェクト指向存在論」(OOO)も思想業界でブームになっています。 これはもうオブジェクト指向の

    オブジェクト指向のハードコア
  • オブジェクト指向の呪いと、その避け方 - mizchi's blog

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

    オブジェクト指向の呪いと、その避け方 - mizchi's blog
  • Java Generics Hell - オブジェクト指向 - プログラマーの脳みそ

    Java Generics Hell アドベントカレンダー 2日目。 1日目 Java Generics Hell 序章 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 前回は与太話だった。ジェネリクスの話をする前にOOP(オブジェクト指向プログラミング)について整理しておかねばならない。 オブジェクト指向とは オブジェクト指向が何かという点についてはなかなか難しい。 Smalltalkを作ったアラン・ケイが「オブジェクト指向」という言葉を初めて用いたといわれるが、この「オブジェクト指向」はJava言語の教育の過程で一般に教えられる「オブジェクト指向」とはかなりイメージが違う。 アラン・ケイが「オブジェクト指向」という言葉を創った当初は、Smalltalk システムが体現した「パーソナルコンピューティングに関わる全てを『オブジェクト』とそれらの間で交わされる『メッセー

    Java Generics Hell - オブジェクト指向 - プログラマーの脳みそ
  • Elixir から Elm の流れで、いよいよオブジェクト指向に対する懐疑心が無視できないレベルに達した2017年冬。 – ゆびてく

    Elixir から Elm の流れで、いよいよオブジェクト指向に対する懐疑心が無視できないレベルに達した2017年冬。 – ゆびてく
  • オブジェクト指向プログラムのためのパターンランゲージの使用

    以下の文章は、Kent Beck、Ward Cunninghamによる「Using Pattern Languages for Object-Oriented Programs」の日語訳である。Ward Cunningham氏の許可を得て、ここに掲載する。 Kent Beck, Apple Computer, Inc. Ward Cunningham, Tektronix, Inc. Technical Report No. CR-87-43 September 17, 1987 Submitted to the OOPSLA-87 workshop on the Specification and Design for Object-Oriented Programming. 概要 オブジェクト指向プログラミングへのパターンランゲージの適合について概説する。ウィンドウベースのユーザーイ

  • オブジェクト指向が楽しく理解できるように解説しました - (株) クオリティスタート

    プログラミング研修講師として避けては通れない大きな課題が、プログラミングをやったことがない方に「オブジェクト指向」が何であるかを伝えることです。オブジェクトという概念自体が非常に抽象化された概念ですので、抽象化されたものをそのまま伝えても、利用イメージが全く喚起されません。 「そもそも、オブジェクトとは?」はNG この説明を始めてしまうと、ほとんどの物事がオブジェクトになりえるため、オブジェクトとはについての定義付けをしていません。「オブジェクト指向が目指すソフトウエアの世界とは」という哲学論に倒れてしまうと、初心者は全くイメージがつかなくなります。 その為、「オブジェクト指向はプログラムをどう作るかの方法論の1つで、クラス(Class)という単位を最小単位としてプログラムを作るやり方」という前提を置きます。オブジェクト指向を方法論の一つであると割り切れば、「そーゆーやり方があるのか」と割

    オブジェクト指向が楽しく理解できるように解説しました - (株) クオリティスタート
  • オブジェクト指向が難しく、わからないときの勉強方法【分かりやすく学習を進めるコツ】 - コーギーブログ

  • オブジェクト指向とは何だったのか? – ゆびてく

    オブジェクト指向とは何だったのか? – ゆびてく
  • Railsで大規模アプリケーションを正しく設計するために避けるべき3つの機能 - Qiita

    この記事はCrowdWorks Advent Calendar 2016 の24日目の記事です。CrowdWorksのエンジニアが毎日なにかを書きます。 昨日の記事は @suzan2go による「ラーメン屋で考えるRailsのデータモデリング」でした。 はじめに CrowdWorksは、2011年の創業以来、約5年間の開発を続けてきました。サービスの立ち上げ期においては、サービスの継続性・変更容易性を高めることよりも、サービスを成長させ、存続に繋がるフェースまで素早く立ち上げることが最重要な観点です。 一方で、サービス提供も5年が経過し、多くの方にご利用頂く「社会インフラ」に一歩ずつ近づいてきています。そういった環境の変化もあり、「日々改善し続ける」「日々変更し続ける」ことに重要視する観点が移り変わってきました。そのような価値観の変遷に取り組む過程で考えている「大規模で複雑な業務要件を担う

    Railsで大規模アプリケーションを正しく設計するために避けるべき3つの機能 - Qiita
  • オブジェクト指向プログラミングのためのモデリング入門

    オブジェクト指向では、モデリング(分析)、設計、実装は、切れ目のない一体の活動。初期の分析は初期の設計であり、初期の実装。毎日分析し、毎日設計し、毎日実装しながら、一歩一歩、モデルも実装も進化させていく。Read less

    オブジェクト指向プログラミングのためのモデリング入門
  • オブジェクト指向設計(2016年度)

    コンテンツ 第1章 基的な用語 第2章 オブジェクト指向開発 第3章 設計の問題 第4章 オブジェクト指向設計の原則 第5章 単一責任の原則 第6章 Visitor パターン 第7章 LSP、DIP、ISP 第8章 パターン技術 第9章 ユースケース 第1章 基的な用語 クラスとオブジェクトの違い 第2章 オブジェクト指向開発 オブジェクト指向開発 オブジェクト指向分析 機能外要求 User インタフェース Student クラスとTeacher クラス Student クラスのソースコード Teacher クラスのソースコード 演習2-1 UserLocator クラスのソースコード 演習2-2 演習2-2 の解答 Teacher.java UserLocator.class 第3章 設計の問題 演習3-1 演習3-1 の解答1(返却値を利用した方法) 演習3-1 の解答2(条件分岐

  • オブジェクト指向の欠点をカバーする努力 - Qiita

    オブジェクト指向の問題点 インターネッツを良くするポエムというのは、「こういう問題に対して、こういうソリューションでカバーしてきたよ」をみんなでシェアすることだと思うので、ここに挙げられていることの一部に対して、オブジェクト指向界隈が今までこんな工夫をしてきたよとか、僕の目から見えている「技術発展の流れ」について書いてみようと思います。まあ僕も全ジャンルをまんべんなくやっているわけじゃないし、一部想像で補っている部分もあります。他にもあればぜひシェアしてください! 上記のサイトで書かれている内容のうち、 オブジェクトのつながり具合が手続きでしか表現できない/知識表現が手続き側に偏っている 関係性が表現できない ユーザレベルでの部品化再利用に全然なっていない について取り扱います。 オブジェクトのつながり具合が手続きでしか表現できない/知識表現が手続き側に偏っている 元は2項目ですが、内容的

    オブジェクト指向の欠点をカバーする努力 - Qiita
  • オブジェクト指向と20年戦ってわかったこと - Qiita

    この記事の内容 オブジェクト指向と10年戦ってわかったこと Twitterやはてブコメントを見たら、「わかりやすかった」というコメントもあったのですが、どちらかというとネガティブ方面なコメントが多く目につきました。マサカリという用語で忌憚なく意見を言う風潮については別にいいんですが、「わかりにくい」「間違っている」「古い」みたいなコメントは何も生み出さないし、みんなでニコニコポエムを投稿しあうやさしいインターネッツになったらいいなって思ったので、僕もオブジェクト指向について投稿しようと思います。 何原則? 3原則じゃなくて4では?みたいなコメントもあったのですが、別に3でも4でも5でも重要ではないかなって思います。この4原則の出どころがどこかは知らないですが、C++かSmalltalkあたり(このあたりの話を見かけたのはJava登場前だった気がする)をターゲットとしている気がします。Jav

    オブジェクト指向と20年戦ってわかったこと - Qiita
  • オブジェクト指向の概念の発明者は誰ですか? - Smalltalkのtは小文字です

    忙しい人のためのまとめ 一般に「オブジェクト指向プログラミング」と呼ばれる考え方には発案者が異なる二系統がある。(ただし簡単のため、次のうち前者から批判的に派生して生じたプロトタイプベースのオブジェクト指向はここには含めていない) アラン・ケイによる、変化に強い長期運用可能な遅延結合システムを SIMULA67 にあった「オブジェクト」をメッセージの受け手とすることで実現(オブジェクトにメッセージ送信)するアイデアに基づく「メッセージングのオブジェクト指向」と、 ビアルネ・ストラウストラップ(前後して抽象データ型を発案したリスコフ人、オブジェクトクラスを考えたニガードらSIMULA陣営、Eiffelのメイヤーらも同様の着想を得ている)による、ユーザー定義型(抽象データ型)を SIMULA67 にあった「クラス」という言語機能を使って実現(カプセル化、継承、多態性)するアイデアに基づく「抽

    オブジェクト指向の概念の発明者は誰ですか? - Smalltalkのtは小文字です
  • オブジェクト指向の問題点 - ビスケットのあれこれ

    オブジェクト指向プログラミングを神格化するような記事が流れてきたので,僕が知っている問題点について書いてみたいと思います.僕がまだ学生だったころは,オブジェクト指向の評価もまだそれほど定まっていなくて,オブジェクト指向の次はどんなパラダイムが出てくるかとか普通に学生レベルで議論していたものですが,ここまで強大になってしまうとそれを打ち負かそうなんて気にはならないのでしょうか.僕にはオブジェクト指向が普遍的な真理という感じは全然しなくて,ここまで使われてる理由は,現実的なテクノロジーで大きなシステムを作らなければならない必要性のほうを優先した結果であると認識しています.オブジェクト指向がその後の25年ほどもずっと安定してその地位を保てるほど素晴らしいものとは思えないのです. 以下で上げる問題点は,個別に解決している研究はあったりしますし,僕も論文を書いたりしましたけど,実際の言語に導入されて

    オブジェクト指向の問題点 - ビスケットのあれこれ