0
2
オブジェクト指向について、あちらこちらで当たり前のようにオブジェクト指向という言葉を聞きますが、多分ほとんどの人はオブジェクト指向を理解してないんじゃないかと思うことがあります。
まず、オブジェクト指向のデメリットについて
大規模な開発だとオブジェクト指向を導入するにあたってクラス図やドキュメントを整理しないといけないわけですよね？
これだと、オブジェクト指向を使っているのか、オブジェクト指向に人間が使われているのか、意味不明じゃないですか？
また、中規模、小規模な開発だとオブジェクト指向は色んなところにプログラムを分散させることが出来るというデメリットしかありませんし、従来の手続き型プログラミングのデメリットである、ネストや関数の呼び出しが深くなりすぎて、可読性がない、みたいなことも解消される訳もなく、デメリットが単に増えているだけな気がします。
建前上たくさんのクラスに別れているとか、ソフトウェアアプリケーションを作る上でフレームワークが強要してくるとかならまだ分かるし、そもそもそのレベルなら別にオブジェクト指向云々ってあんまりどうでもいい気がするのですが、
オブジェクト指向って言葉だけが独り歩きしている気がします。
知っていて偉いとか知ってないとダメだみたいな雰囲気すらありますが、考え方のひとつ、選択肢のひとつでしかないですよね？
で、何よりこれだけオブジェクト指向という言葉が広まりながら、ほとんどの人がデメリットにもメリットにも気づいてないのが、1番不可解です。
皆さんのオブジェクト指向に対する見解はどんな感じですか？
なお、こういう内容で必ずカプセル化がどうとか言う人がいますが、カプセル化って処理を隠しているだけでなんの本質的なものでも無いですよね？別にオブジェクト指向じゃなくてもできるし。これをデメリットではなくメリットとしてあげる人は、ニワカだと思います(この考えが間違っていれば指摘お願いします)。
オブジェクト指向を理解していればメリットデメリットの一つや二つは簡単にあげられると思います。
そもそもオブジェクト指向について知らないので見解もないし、代替案を提示してください、等の回答は不要です。
回答17件
#1
退会済みユーザー
総合スコア0
投稿2024/07/31 00:53
プログラマー、エンジニアが嫌いなことは「車輪の再発明」
オブジェクト指向がどうとかなんて話はもう誰もしてない。
オブジェクト指向を覚えたばかりの初心者がやってくる度に毎回毎回同じ話を繰り返してうんざりしている。
今まで誰も言ってないような新しい視点があるわけでもなく毎回全く同じ。
現代では関数型プログラミングも十分普及してオブジェクト指向一辺倒ではない。
Reactは関数型。Laravelでもfunctionalな新しい使い方を導入。フロントでもバックエンドでも関数型概念は普及し始めている。
ネットで見ただけの誰かの言葉を鵜呑みにしてるだけでは最新の変化に追いつけない。
#2
総合スコア11954
投稿2024/07/31 02:11
編集2024/07/31 04:20どうでもいいです．
どうでもよすぎて，何の話をしたいのかがわからないレベルでどうでもいいです．
何らかのプログラミング言語が用意している文法に基づいてプログラミングを行っている際に，「いやー，今の俺のコードって〇〇指向だよね」とかなんとかいちいち考えているんでしょうか？
少なくとも私はそんなこと微塵も考えてないです．
その言語でやれる範囲で一番｛やりやすい/真っ当だと思う/etc...｝な方法でやればいい．
個別の要素が便利なら使うし，不便なら使わない．それだけの話．
そういう選択の理由が「〇〇指向だからどうのこうの」とかいうことは全くないです．
私が書いたコードを見たどっかの誰かが「これは〇〇指向だね」とか「〇〇指向じゃないね」とか評したとして……で？ それが何？って感じです．
（○○指向 とかいう何かにこだわる必要ってあるんですか？ と逆に問いたい）
カプセル化については「間違いを防ぐ手段」「考えることを減らす手段」みたいなものだと捉えています．
なので「このコードに触れる人々というのは完璧な存在なのでそんな補助輪みてぇなのは不要」ということならば不要なのだろうと思います．
多分ほとんどの人はオブジェクト指向を理解してないんじゃないかと思うことがあります。
「ほとんどの人」についてはどうなのかは知りませんが，
まぁ私は「オブジェクト指向とは…！」みたいなのを理解はしてないでしょうね．（そもそもこの言葉の明確な定義がわからん）
で，それだと何か問題あるんですか？
オブジェクト指向って言葉だけが独り歩きしている気がします。
まさにそんな雰囲気をあなたの文面から感じ取っている…みたいな状況です．
#3
総合スコア10130
投稿2024/07/31 05:08
オブジェクト指向がクソかどうかはともかく、上が「オブジェクト指向を採用する」と言えば最低限は知らないといけないので、理解はすべきだと思います。
また、中規模、小規模な開発だとオブジェクト指向は色んなところにプログラムを分散させることが出来るというデメリットしかありませんし、
これもオブジェクト指向とは関係ない話ですが、「分割統治法」という言葉がある通り、出来る限り処理はまとめず分散させるべき、だと思いますが、どうでしょう？
#4
総合スコア1057
投稿2024/07/31 11:10
20年前の議題って感じ。
pcsさん、fanaさんの意見に同意です。
それぞれの言語、それぞれのフレームワークにおける「普通の書き方」で書くだけの話です。
「オブジェクト指向」というキーワードや、それを熱く語っている人を久しぶりに見ました。
毎日、暑いからかな？
#5
総合スコア13
投稿2024/08/01 04:00
編集2024/08/01 04:01うける。みなさん言ってるのと同じで、どうでもいいです。プログラミングを愛しておられるんですね、すごくいいですねー。
では、まず投稿者様が、デメリットとしてあげてるものは、オブジェクト型特有の問題ではないことを指摘しておきます。そしてそのデメリットを解決しようと試みたのがオブジェクト型が出来上がった背景ですので、色々誤解されてますね。
ネストについても然りです。関数方でもネストしますから、それは言語固有の問題ではなく、モジュール間の結合度合いや、再利用度などの問題に一般化されます。結局は何使おうが設計次第なんです。
んで、オブジェクト型であろうがなかろうが、ウォータフォール型の開発において、ドキュメントの整備は必須です。世の中にあるのは唯一無二のプロジェクトですから、オブジェクト型でやったらどれくらいの量のドキュメントになるのか、関数型なら特別にドキュメントが少なくなるのか、比較することにコストをかけたりしませんから主張は根拠がないです。
#6
退会済みユーザー
総合スコア0
投稿2024/08/01 05:09
オブジェクト指向は好き？
というお題についての所感を言っておくと、創業間もない頃の漆ステムズさんあたりの求人広告(掲載誌はJava Worldだったかな？）のキャッチコピーにあったような感じのお題だなあと思いました。
#7
総合スコア17
投稿2024/08/01 11:51
デザインパターンがわかってるかわかってないかの話では？好きか嫌いかで言うと初心者向けなんで好きですが。。。
シフト演算子とか変態は使うしなぁ
#8
総合スコア1
投稿2024/08/05 23:16
オブジェクト指向をプログラミング言語と勘違いしている人にはどうでもいい話ですね。
モデリングとか、抽象化とか、どちらかというと上流工程から一貫してシームレスな開発環境を提供する指向、哲学、考え方というのが正しい表現！
#9
総合スコア406
投稿2024/08/06 01:23
編集2024/08/06 01:35あちらこちらで当たり前のようにオブジェクト指向という言葉を聞きますが
その考え方が登場してから50年以上も経っており、とりわけ80年代以降はソフトウェア工学の世界で主流となる考え方の1つとして採用されてきた経緯を考えれば、当たり前に聞くのは、それこそ当たり前でしょう。
多分ほとんどの人はオブジェクト指向を理解してないんじゃないかと思うことがあります。
あなたの書いた質問を読んで想定できるのは、あなたもそのうちの一人でしょうね。
大規模な開発だとオブジェクト指向を導入するにあたってクラス図やドキュメントを整理しないといけないわけですよね？
「しないといけない」わけではないですし、ドキュメント整理云々はオブジェクト指向とは関係のない話です。
オブジェクト指向は色んなところにプログラムを分散させることが出来るというデメリットしかありませんし
これは日本語がおかしくないですか？「させることが出来る」という表現は、メリットの強調に用いられると思うのですが。「オブジェクト指向は色んなところにプログラムを分散させる」という文章自体も、そもそもオブジェクト指向とは関係のないものですが。
ネストや関数の呼び出しが深くなりすぎて、可読性がない、みたいなことも解消される訳もなく、デメリットが単に増えているだけな気がします。
オブジェクト指向を原因として、ネストや関数呼び出しの可読性がなくなるという結果になるわけではなく、これは単なるプログラム設計や構成、命名の不備などが理由でしょう。
建前上たくさんのクラスに別れているとか（中略）ならまだ分かるし、
建前上というのがよくわかりませんが、そんな理由でクラスを分けることは本来ないですし、仮にあったとしても、それなら「まだ分かる」ということが、分かりません。それ、分かったらダメでしょう。
オブジェクト指向って言葉だけが独り歩きしている気がします。
30年前ならそのようなことを言う人もひょっとしたらいたかもしれませんが、今世紀に入ってからそのような意見を聞いたことはありませんね。あなたの質問文章はまさにそんな感じではありますが･･･
知っていて偉いとか知ってないとダメだみたいな雰囲気すらありますが、考え方のひとつ、選択肢のひとつでしかないですよね？
知っていて偉いというのはないでしょう。知っていて当たり前なので。そして知らないとダメなのは間違いないでしょう。この業界で働くなら。なぜなら現在のソフトウェア開発やプログラミングにおいては、程度の差こそあれ必ず何らかのオブジェクト指向の考え方が関連しているからです。選択肢の一つでしかないのはその通りですが、複数の選択肢から最適な1つを選ぶためには、それら選択肢全てに対してきちんとした理解があることが大前提となります。
何よりこれだけオブジェクト指向という言葉が広まりながら、ほとんどの人がデメリットにもメリットにも気づいてないのが、1番不可解です。
どんな方法論にもメリットとデメリットがあります。むしろ、そのことに気付いていない人の方が少ないのでは。
#10
総合スコア11954
投稿2024/08/06 02:11
あまり（というか，ほとんど）関係ない話ですが……
「オブジェクト指向」とかの「指向」っていう言葉って，どの程度の強さ（強制力(?)とでもいうか？）の意味合いを持ってるんでしょうね？
個人的には全然強くない雰囲気に感じるのですがどうなのでしょう？
「こんな 考え方/捉え方 の方向性でやってみようぜ」程度であり，そこからちょっとでも外れたら「なにやってんだてめぇ，オブジェクト指向って言っただろうが！」とか怒られる感じではない，というか．
ものすごくざっくりとした（ふわっとした）基本方針とでもいうか，その程度かなー，みたいな．
プログラミング関係ではもっと強そうな言葉としては「○○原則」みたいなのがありますね．
「原則」とかいうめちゃくちゃ強そうな言葉が用いられているせいか，これ系も妙に過剰に語られている場合がある（or 「あった」かな？）ような気がしないでもないです．
#11
総合スコア74
投稿2024/08/06 04:05
ドキュメントは、プロジェクトの規模や要求などに応じて必要なものを柔軟に作成すれば良いと思います。
最低限、大きめの粒度のブロック図とデータフローがあれば、全体は掴めると思います。プロジェクトメンバーが全員プログラミングが出来て、客の要求もなければ、この程度で事足りると思います。
カプセル化の本領は、開発人数が増えて大規模化した時にメリットが大きいです。
例えば、開発グループAとBに分かれ、Aの作るブロックからは〇〇という形で出力するので、Bはそれを読み込んで続きのブロックを作ってください。グループA内でも、担当者aと担当者bがいると、同じ思想で開発を分業化できます。
100人規模で1年以上かけて作るソフトもあるのですから、うまく分担するのは必須です。
また、うまくカプセル化しておくと、再利用も容易です。似た機能が必要になったときに、いちいち開発する必要がありません。
カプセル化は、オブジェクト指向のデメリットでもあり、中の構造や状態が外から分かりにくくなります。
そのため、オブジェクト指向と関数型プログラミングの中間のようなデータ指向型プログラミングというやり方も考案されています。
オブジェクト指向に詳しい人が、分解できる最小粒度ま でクラスの実装・継承関係を作り上げ、ネストが深くなり理解しづらくなったりすることがあるかもしれませんが、実際はそこまでする必要性がない事もあり、ケースバイケースでやれば良いと思います。
結局は、最適な設計はソフトによって違いますので、必要な所に必要なだけオブジェクト指向の概念を使えば良いと思います。
#12
総合スコア60
投稿2024/08/06 07:46
オブジェクト指向に限った話ではないですが、ソフトウェア開発では責務をどのように分割するかが重要で、
オブジェクト指向開発はその部分に長けていると考えています
しかしその実、出来上がったコードを見ると責務がぐちゃぐちゃになっているので、
だいたい多くのプログラマは手続き型言語の域をでていません
これを回避するためには、クラス図やシーケンス図を用いた分析、設計をまずおこなって、
コードになる前に指摘するのがよいと思えるので、事前にモデリングをしています
#13
総合スコア464
投稿2024/08/06 18:08
オブジェクト指向は、思考方法として、ざっと三つの方向から考えられます：
- ツリー型のデータモデル（JSON）
- 継承に沿う single dispatch（override or super）
- 遅いもしくは動的なバインディング（late binding）
一つ目、ツリー型のデータモデル、つまり物事を分類して、そして分類を再分類して階級を作る、というのはすごく直感的で、技術職以外の人間からもらう物は大体そんな形になっているから、関係型と比べて、交流するとき変換の手間を省ける。直感の思考にもっと接近する図型もあるけど、自由すぎて説明しづらいから使い手を見つけにくい。
二つ目、継承に沿う single dispatch は多分一番代表的で一番批判される。主流フレームワークがインターフェースに沿う依存注入（DI）を備えてる今は継承の存在感は薄くなってきてる。override するとき母クラスの制約を守らなきゃいけないから間違いやすい。ある意味一番オブジェクトと関係がない。「継承より合成（composition over inheritance）」というのがあるけど、合成の方もオブジェクトでやってるからどうでもいい。
三つ目、遅いもしくは動的なバインディング。コードがコードを織りなす、dispatchをカスタマイズ、もしくは実行中でオンラインデバッグできる、まさに魔法。その代わりに魔法使いしか使いこなせない。LISP気味。
そう、こうやって哲学的になると、LISPもオブジェクト指向です。
#14
総合スコア58
投稿2024/08/07 02:03
オブジェクト指向がサイトみてもイマイチ分からないので教えてください。
#15
総合スコア23
投稿2024/08/09 03:45
オブジェクト指向に対する認識は千差万別で、「これがオブジェクト指向だ！」という固定概念ほどオブジェクト指向を学ぶのを妨げる障害はないです。
まず、オブジェクト指向を「言語」に限定しないほうがよいと思います。「継承」「多態」「隠蔽」がオブジェクト指向の条件なら、これらすべてはオブジェクト指向です。そういった視点でみればオブジェクト指向が身近なものに感じられると思います。
- スクラッチみたいな開発環境
- Wordpressみたいなサイト管理ツール
- WebAPIを多様したシステム開発
- ローコード・ノーコードの開発ツール
- WordやExcelといったオフィスアプリ
- ゲーム
利用者が常にオブジェクト指向を意識することはないでしょうが、システム開発に携わるなら話は別です。オブジェクト指向なんて「if」「変数」「関数」の延長でしかなく、「知っていて当たり前、知らなければプログラマを名乗るな！」レベルの基礎知識だと私は思っています。もちろん順番はあるので、オブジェクト指向より先に関数型プログラミングを学ぶべきですが。
だからといって、常にオブジェクト指向を意識する必要もないし、「継承」「多態」「隠蔽」を常にフル活用なんて決まりはありません。「関数の代わりにメソッドを使っている」程度の使い方でも立派なオブジェクト指向の活用です。
確かに「オブジェクト指向」の概念を理解するのは難しいですが、便利なところから使って徐々にレベルを上げていけばよいと思っています。
#16
総合スコア139
投稿2024/08/15 11:47
一般論としてメリット／デメリットになりやすい特徴はありますが、
実際に何がメリット／デメリットになるのかは環境によって違うでしょう。
一度公平な視点で考えてみるのがよいかと。
また、あえて余談とさせていただきますが、
カプセル化を「コードを別の所に書いて隠蔽するだけ」と捉えているのであれば、ちょっと違うと思います。
個別の話題として質問してみるとよいかと。
#17
総合スコア17
投稿2024/08/24 08:55
以下は、個人的な推測を元に回答します。
おそらく質問者の現場では、井の中の蛙が井の中の蛙を拡大再生産する現象が起きているのではないかと考えています。
例えば、クラスのメンバ変数のアクセス修飾子をパブリックにしてたとかで、上司や先輩が大上段で『オブジェクト指向がわかってない』とか『カプセル化って知ってる？』と指摘するようなやらかしをしてしまったのではないかと。
今回の質問はそういったダメな指導や指摘を受けてしまった質問者が、救いを求めてさらに間違った方向で質問をしてしまったように見えます。
まず、前提として言っておきたいのですが、知っていることは偉いことではないし、知らないことは恥ずかしいことではありません。
「知らない」というのは単なる状態に過ぎないので、指導者や指摘者は本人に何らかの知識や技術が不足していることを気づかせて、それを「知っている」という状態に変化させる助力をするべきで、そのためには言い方や伝え方に細心の注意と最大限の工夫を凝らすべきです。
推測で書いているので、明後日の方向の回答をしていたら申し訳ありませんが、上記のような現場で視野の狭い人たちの視野の狭い指摘や発言を受けての質問であるのならば、質問者自身がそれに対する反発によって、このような公共の場で視野の狭い質問を投げてしまっているのは、まさに蛙の子は蛙という状況に陥っています。
厳しいコメントが多いのですが、内容的には賛同するものがほとんどです。
もしも、質問者さんが現場で受けた指導や指摘の内容ではなく、その方法について納得がいかないのであれば、いったんそのことは別の場所においておいて、オブジェクト指向とはどんなものを意味して、どんな特徴があるかをサラッと浅く広く理解しておいて損はないと考えます。
個人的な解釈としては、オブジェクト指向プログラミングとは？をあまり突き詰めて考える必要はなくて、技術的な側面として「クラスを用いたクラスプログラミングのお作法」「クラスを用いたライブラリの使い方」「クラスを用いたフレームワークの設計理解」などを理解し、実践していくことが大切だと考えています。
ただ、諸々のコンピューティングの知識があるとプログラミングの幅や理解の解像度が上がるように、オブジェクト指向とは？を理解することで成長できる部分はあります。それが「知識」というもので、「知識」の正しい身に付け方と使い方を推奨します。
「知識」はあくまでも手段です。（もちろん、それを個人的に目的化する自由もあります）
最後に繰り返しますが、知っていることは偉いことではないし、知らないことは恥ずかしいことではありません。
つまらないプレッシャーに負けて、自分自身が知識を得たときに、それを正しく後進に伝えることができないようなエンジニアとならないことを祈ります。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。