2021年の「オブジェクト指向」を考える
きしださんが先日もたのしいお題を投下されていました。 出遅れましたがこのネタについて少し掘り下げてみます。 念のため個人的なスタンスをあらかじめ表明しておくと、オブジェクト指向に対してはそれなりに好意的ですが、別に時代の最先端だとかソフトウェア開発に必須の知識というほどではない（でも知っておくと便利というか、知らないと不便なこともあるかもしれないのでわざわざ避けるのはおすすめしない）というくらい温度感です。 オブジェクト指向 is 何 そもそも「オブジェクト指向」という言葉自体、座りの悪い言葉です。 意味が明確なのは「オブジェクト指向プログラミング(OOP)」、「オブジェクト指向プログラミング言語(OOPL)」、「オブジェクト指向設計(OOD)」「オブジェクト指向分析(OOA)」といった「オブジェクト指向なんとか」の方で、それらをふわっとまとめた（ような気がする）単語が「オブジェクト指向」
オブジェクト指向はすでに粒度が時代にあっていない - きしだのHatena
定期的にオブジェクト指向disを書いてしまってるのだけど。 とりあえずオブジェクト指向の話をすると定義が人によって違いすぎるので、改めてここでの定義を書いておくと 、基本的にはOMTの「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」 に従うのですが 「1990年に流行りソフトウェア開発のすべてを飲み込み、いまとなっては人それぞれ定義が違って技術的議論に使えなくなった、主にオブジェクトを基本単位としてプログラムを整理するやりかたを指すマーケティング用語」 という感じです。 ほとんどの場合で人によってオブジェクト指向の指す範囲が違いすぎて、技術的知見の共有には使えなくなっています。でも、いずれの定義にしろオブジェクトを基本単位にするというのは重要ではないかと。 ソフトウェアの組織化の単位としてオブジェクトを使うというのが大事で、データの搬送に構造体代
オブジェクト指向プログラミング入門
きしだൠ(K1S) @kis オブジェクト指向について、技術的には「オブジェクト指向は差分プログラミングとデータ分類をまぜて考えてややこしくなる。分離せよ。そして差分プログラミングにはラムダを使え。データ分類のときはオブジェクト指向じゃなく型を考えろ」っていう主張になった。 2022-02-28 12:22:33 きしだൠ(K1S) @kis 「オブジェクト指向は差分プログラミングとデータ分類を同時に行う手法」という見方。 もっといえば、継承の用途を差分プログラミングとデータ分類の2種類にわけた。その上でそれぞれについてのオブジェクト指向離れを考えた。 2022-02-28 12:25:12 きしだൠ(K1S) @kis ここから考えると、オブジェクト指向の技術的欠点は差分プログラミングとデータ分類を不可分に考えてしまったところか。 継承を使うと差分プログラミングとデータ分類が同時にできて
オブジェクト指向の呪いと、その避け方 - mizchi's blog
このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(
オブジェクト指向は禁止するべき - きしだのHatena
プログラムがまだ不慣れな人が「プログラムちょっとわかるようになったけど、まだぜんぜんオブジェクト指向とかできてません」のように言ったり、ちょっと慣れた人が「このソース、ぜんぜんだめ。オブジェクト指向ができてない」にようなことを言ったり、まるで、オブジェクト指向ができてるかどうかがよいプログラムかどうかを表すことになってるようだ。 Javaのアルゴリズムの本に、「Javaなのにオブジェクト指向ができていない」のような書評がついているのを見たときには、お前は何を求めてるんだと思ったりもした。 そのようなオブジェクト指向は、窓から投げ捨てるべきだ。オブジェクト指向はプログラムのよしあしの基準にならない。 むだにHogeインタフェースとHogeImplクラスがあったり、むだにnewするだけのcreateメソッドがあったり、どこで値が設定されてるかわからないオブジェクトがひきまわされてたり、ソースコ
新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを
いまさらですが、職業Javaプログラマーなら理解しておいてほしい「継承」の意味について - 達人プログラマーを目指して
正しく意味を理解している方にとっては、まったく常識レベルの話であり、何をいまさらと思われる方々も多いかと思いますが、大規模案件のレガシーコードなど、私が仕事で見かけるJavaのコードを読むと、「このコードを書いたSEやPGの方々は、はたして継承の意味を正しく理解していないのではないか」と思われる設計のコードに出会うことが少なからずあります。現在では改良されましたが（Javaプログラミング能力認定試験の問題がかなり改善されていました - 達人プログラマーを目指して）、以前のJavaプログラム認定試験の問題は、そうした不適切な設計がされている典型的な例となっていたのですが、実際、SI業界ではあのような品質のコードのシステムが今でも現役で多数稼動しているというだけでなく、現在でも新たに生み出されているというのは残念ながら紛れもない事実のようなのです。 確かに新人研修で「哺乳類を継承して犬クラスと
いまさら聞けない「オブジェクト指向設計の3つのコツ」～オブジェクト指向設計問題解説 #objectoriented - CodeIQ Blog
CodeIQ中の人、millionsmileです。 いろいろ経歴を積むと、「いまさら聞けない」ことが増えてきます。「オブジェクト指向」というのもそんないまさら聞けないものの一つでしょうか。 そんなわけで、いまさら聞けないことをイマサラ問題として出題してみました。 問題は、日本のITエンジニアの父と言いたくなるくらい温かみのあるフィードバックをしてくれることで好評な有限会社システム設計の増田亨さんからの出題です。オブジェクト指向設計について2問出題していただきました。総計65名もの方に挑戦いただきました！ 問題の解説記事は、オブジェクト指向設計の3つのコツを中心に説明してくれていますので、読みやすいですし、頭にすっと入ってきます。 ではでは、増田亨さんによる解説記事をお楽しみください。 https://codeiq.jp/ace/toru_masuda/ ◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇
私が愛するオブジェクト指向とそれを使わない理由 - takuto_hの日記
この記事では、私がオブジェクト指向のどこを愛しどこを素晴らしいと感じていて、そのうえでなぜオブジェクト指向を使うことを避けているのかを書き留めておきます。関数型言語使いの方で、「オブジェクト指向の何がいいのかわからない」「オブジェクト指向難しすぎ・複雑すぎ」とおっしゃる方にぜひ読んでいただきたいと思っています。また、「オブジェクト指向言語完璧に理解したわ」と思っている方にも読んでいただきたく思います。 なお、ここでのオブジェクト指向の定義は、「各言語でオブジェクト指向と呼ばれているものすべて」とします。JavaやScalaやJavaScriptやSmalltalkやRubyやCommon LispやOCamlがオブジェクト指向と呼んでいるものすべての総称です。もっとまともな定義が知りたい方は以下の記事がおすすめです。 オブジェクト指向の概念の発明者は誰ですか？(改訂版) - Smallta
オブジェクト指向できていますか？
Visual Studio Users Community Japan #1 で発表した資料になります。 https://vsuc.connpass.com/event/143114/
Javaのクラスとオブジェクトについて再度解説を試みる - 達人プログラマーを目指して
オブジェクト指向プログラミングの考え方については、今までこのブログでも何度か取り上げてきました。 [オブジェクト指向] - 達人プログラマーを目指して オブジェクト指向プログラミングはプログラミング技法のすべてではないとはいえ、Javaのようなオブジェクト指向言語で本格的なプログラムを作るには理解を避けて通ることができませんし、また、関数型言語など他のパラダイムの言語を利用するにしても、オブジェクト指向の考え方をまったく理解しないまま使いこなすということは困難でしょう。オブジェクト指向の考え方はデータ構造やアルゴリズムといったことと同様に、プロフェッショナルなプログラマーが理解しておくべき基本的な素養といってもよいと思います。実際、海外では募集要項でオブジェクト指向の理解を前提とすると書かれていることが普通ですし、プログラマーの面接試験で、アルゴリズムと並んでオブジェクト指向プログラミング
staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて - 達人プログラマーを目指して
何が良いプログラムかという点はもちろん人やコンテキストによって異なりますが、少なくともプログラマーとしての私の信念としては、 機能拡張や変更が容易なプログラム 単体試験によって正しく動作することの検証が容易なプログラム どういった内容が記述されているか理解しやすいプログラム といったものこそ、「品質の高い」プログラムが持つべき性質として、まず真っ先に挙げるべき事項であると考えています。もちろん、前提として顧客の要件に従うということは大切なことです。しかし、一般に要件は長期にわたって変更されるものですし、使い捨てのプログラムを除けば、プログラムを長期にわたって保守するコストという点も見過ごすべきではありません。したがって、ユーザーの目には触れない上記の性質をもっと重視すべきだと思うのです。 DRYの原理 上記のような性質を満たすプログラムを作る上で大切になってくる原理として、DRYの原理とい
クラスが持つ3つの役割 - 西尾泰和のはてなダイアリー
某所のチャットで話題になって、流れ去りそうだったのでもったいないから転載しておいた。事後承諾で。 MIYAMOTO Daisuke: 型の継承と実装の継承を区別する方法がないんだよな。 西尾泰和(nishio.hirokazu): 型を継承させずに実装を継承させたい→それ移譲で ってことかな？ MIYAMOTO Daisuke: そそ。そもそも、クラスに「型としての役割」と「実装としての役割」という複数の責務があることに、俺は長い間気づかなかった。これに気づかないと、型継承と実装継承が頭の中で整理できない。 西尾泰和(nishio.hirokazu): 僕が最近気づいたことも加えると、クラスには「ユーザ定義型」「インスタンスを作成する道具」「実装の再利用の単位」という3つの役割がある。 MIYAMOTO Daisuke: あぁ、インスタンスの生成器ね。 西尾泰和(nishio.hiroka
O/Rマッピングツールに対する誤解をときたい - give IT a try
2010.12.23 追記 本エントリの続編となる「実装編」のブログを書きました。 こちらも合わせて読んでみてください。 O/Rマッピングツールに対する誤解をときたい -実装編 Part1- - give IT a try 本文にコメントすると泥沼に巻き込まれそうなので、ここに書いておきます。。。 http://el.jibun.atmarkit.co.jp/g1sys/2010/05/post-2d1b.html なんかこのコラムのコメントを読んでいると、「O/Rマッピングツール(ORM)はSQLを書きたくない開発者のためのツールだ」と思われているような感じを受けます。 おいらはこれまでORMを使った開発プロジェクトに3回参加しました。 確かに最初のプロジェクトでは「SQLを書かなくてもいいんだよ」とリーダーから説明されたような記憶があります。 しかしその発想は大きな誤解です。 ORMを
コラム「システムエンジニア 生き残りの極意」でちょっとした祭りになっている件 - babydaemons’ blog
"ちょっとした祭り"の実態は？ えーと、ソースはこちらです↓ 気分はstatic！: 実はオブジェクト指向ってしっくりこないんです！ とりあえず現時点でのこのコラムへのコメントのエッセンスを纏めます。 それよりも、ポリモーフィズムがオブジェクト指向の肝だと思います。 ポリモーフィズムをうまく使うと条件分岐の記述を減してすっきりしたコードが書けます。 ぬ様 貴重なご意見ありがとうございました。ポリモーフィズムについては勉強したいと思っております。 ポリモーフィズムについては、私は 「関数へのポインタ（Ｃ言語）のデラックス版を使って、何かをやる」 と捉えています。Ｃ言語において、関数をそのまま呼ぶのではなく、ポインタを通じて呼ぶようにすると、 「たまたまその時、どんな関数がそのポインタに指し示されていたか」 によって、結果がまちまちになりますよね。 この特性を意図的に活用すると面白いことができ
わからないでもない・・・ (#1759554) | 「オブジェクト指向言語でオブジェクト指向っぽいプログラミングをしない」のはNG？ | スラド
業務系、WEB系だと、フレームワークやライブラリがオブジェクト指向だから 恩恵は受けてるはずなんだけど、その恩恵のせいで、逆にオブジェクト指向の 必然性を感じにくくなってるんじゃないかなあ。 何かイベントがありゃ、データかき集めて、しかるべきところに渡すだけ。 リクエストがありゃ、受け取ったパラメータでSQL実行して、結果をそのまま返すだけ。 そんなものを書くのが大半になっちゃう。 つまりほとんどがステートレスで処理単位が小さいから、 あらためて自分で何かモデル化したりカプセル化したりするメリットがあまりない。
- Open-Closed Principle とデザインパターン
1999/09/03 更新 石井 勝 さて，このセクションではデザインパターンを統一的に理解するために，「 Open-Closed Principle (OCP) 」 という設計ルールに基づいてパターンを眺めてみることにします．まず OCP の意味と解説を行い，その後デザインパターンを OCP の観点から見てみます．実は，デザインパターンのうちの多くは OCP を満たすために用意されたものと考えることができるのです．このセクションでは， OCP を理解し，数あるデザインパターンの中からどういう場合にどのパターンを使うのが一番効果的なのかを考えます． GoF のデザインパターンは，全部で 23 個ものパターンがあります．このデザインパターンは，多くの局面で繰り返し現れる設計を抽出したものですから，オブジェクト指向のエッセンスを集めたものだと言えるでしょう．オブジェクト指向には，カプセル化，継
まつもと直伝 プログラミングのオキテ 第10回：ITpro
これまで2回続けてデザイン・パターンについて学んできました。今回は，重要なソフトウエア開発原理として知られるオープン・クローズ原則（OCP）の観点からデザイン・パターンを眺めてみましょう。単なる流用可能なソフトウエア・パターン以上の価値がデザイン・パターンに隠れていることが発見できるでしょう。 昔々，技術者たちは計算機などの機械を「金物」という意味でハードウエアと呼びました。さらに実体のないプログラムのことをソフトウエアと呼ぶようになりました。今ではハードウエアもソフトウエアもすっかりコンピュータ関連用語として定着してしまいましたが，元々は技術者間の俗語のようなものだったのです。 ソフトウエアと呼ぶからには「柔らかい」かというと，実際には柔軟性に乏しいものが多いです。規模の小さなものであれば，変更は簡単で柔らかい感じがありますが，ビジネスに用いられるような大規模ソフトウエアでは各部分の依存
オブジェクト指向AppleScript言語 - ザリガニが見ていた...。
今までAppleScriptに備わっているオブジェクト指向的な仕組みを、あまり積極的に利用していなかった...。アプリケーションの補助的な操作に利用することが多く、シンプルなスクリプトを手順に従って並べるだけで結構満足できていた、ということもある。それに何より、オブジェクト指向的に書く方法、もっと言えばAppleScript自体をあまり良く理解できていなかったというのもある。 いつも、その場限りの必要な知識だけ調べて、動いたらそれまで。試行錯誤のやっつけスクリプトだった。いい加減、ちゃんと理解しておきたい...。 Hello World 「こんにちは」とダイアログで表示するだけの最もシンプルなコードだが、この裏には実に多くの仕組みが隠されていた。 display dialog "こんにちは" 実は、runハンドラ（メソッド）に定義されたコードと同じように解釈されている。（厳密には同じではな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Cでわかるオブジェクト指向一覧
