オブジェクト指向を教えてくれ！

**デフォルトの名無しさん** · 2021/03/16(火) 17:06:02.41

オブジェクト指向について、調べれば調べるほど疑問が募ります。低レベルで粗末な疑問かも知れませんが、ご教授願いたいです。

・データと振る舞いをまとめる？
まとめると何か良いことあるの？
ファイルあるいはモジュールにはまとまってるよね？
丁度いい単位があるのに、何故わざわざオブジェクトという概念を導入するの？
(Javaには1ファイル1クラスという文化あるらしいけど)

・カプセル化？
モジュールのimport, exportでも実現出来るよね？
(構造体などへのアクセスを制限できれば)

・ポリモーフィズム？
別にデータと振る舞いをまとめなくても実現出来るよね？

・モノのように扱いたい？
モノとして扱いたいときに扱えば良くない？なんでわざわざ全てをオブジェクトにするの？

**デフォルトの名無しさん** · 2021/03/16(火) 17:14:31.50

オブジェクトはクラスのことだとわかるけど
モジュールはなんだろ、パッケージのこと？

**デフォルトの名無しさん** · 2021/03/16(火) 17:17:49.88

> ・データと振る舞いをまとめる？
> まとめると何か良いことあるの？

データが複数ある場合に、データごと振る舞いが
決まっているということが明確になります。

> ファイルあるいはモジュールにはまとまってるよね？
データと振る舞いがまとまっていません

> (構造体などへのアクセスを制限できれば)
それができないから、オブジェクト指向があります

> 別にデータと振る舞いをまとめなくても実現出来るよね？
データごとに振る舞いが変わるということが明確に表現できます。

> モノとして扱いたいときに扱えば良くない？なんでわざわざ全てをオブジェクトにするの？
関数もモノとして扱えば、モノに対して関数を割り当てることが出来ます。

**デフォルトの名無しさん** · 2021/03/16(火) 17:20:32.30

用語に振り回されてプログラムできなくなるアホの典型例

**デフォルトの名無しさん** · 2021/03/16(火) 17:22:59.10

たとえば 4980012345678901 という値は VISAのクレジットカード番号ですが、
これがただの文字列であれば、クレジットカード番号とした正しいかをチェックする
validate() メソッドがあるわけがないことがわかります。

4980012345678901 という値に対してクレジットカード番号というクラスを割り当てると
この値に対する validate() メソッドが存在することが容易に推測できます。

**デフォルトの名無しさん** · 2021/03/16(火) 17:24:31.39

>>2
オブジェクトとクラスごっちゃにして説明してすみません。

モジュールは大雑把にいうとファイルのことを指して言いました。Pythonでいうとfile, Rustでいうとmod module_name { }のことです。node.jsではfileです

**デフォルトの名無しさん** · 2021/03/16(火) 17:47:22.67

>> 3
回答ありがとうございます。

> データと振る舞いがまとまっていません
では、何をまとめたものなのでしょうか？

> それができないから、オブジェクト指向があります
構造体へのアクセスを制限する機能があれば、メソッドをまとめなくとも十分なのでは？という意味です

> 関数もモノとして扱えば、モノに対して関数を割り当てることが出来ます。
曖昧な表現で申し訳ないです。モノというのは値のことではなく、メソッドを生やしたオブジェクトである必要があるのか？という意味です。
この疑問の答えは「データが複数ある場合に、データごと振る舞いが決まっているということが明確になります。」という回答に含まれると思いますが。

**デフォルトの名無しさん** · 2021/03/16(火) 17:50:10.18

> では、何をまとめたものなのでしょうか？

データと振る舞い

> 構造体へのアクセスを制限する機能があれば、メソッドをまとめなくとも十分なのでは？という意味です
構造体へのアクセスを制限するには、データと振る舞いをまとめないと無理

> 曖昧な表現で申し訳ないです。モノというのは値のことではなく、メソッドを生やしたオブジェクトである必要があるのか？という意味です。

関数には名前という属性があります。どのような引数を渡せるかという情報を持っています。
明らかに関数以外の情報を持ったモノです

**デフォルトの名無しさん** · 2021/03/16(火) 17:57:50.12

>>5
回答ありがとうございます。

データに対して、「クレジットカード番号」という型を割り当て、
クレジットカード番号に対して処理できる関数を用意すれば解決なように思えるですが、
わざわざオブジェクトに付属するメソッドという概念を用いるメリットがわかりません。

**デフォルトの名無しさん** · 2021/03/16(火) 18:05:30.02

>>9
文字列はクレジット番号として使えるから～みたいに
文字列に対する操作を追加していったら

文字列に対してできることが膨大になりすぎて
管理できなくなるだろ

**デフォルトの名無しさん** · 2021/03/16(火) 18:06:43.78

オブジェクト指向はグループ分け
グループに分けないと管理が大変になる
オブジェクト指向はクラスを多数定義できるとも言いかえられるな

**デフォルトの名無しさん** · 2021/03/16(火) 18:12:46.48

>>8
> 構造体へのアクセスを制限するには、データと振る舞いをまとめないと無理
たしかRustではプロパティにpubを修飾で制御できたような気がするんですが。
> 関数には名前という属性があります。どのような引数を渡せるかという情報を持っています。
明らかに関数以外の情報を持ったモノです
なるほど。確かにそのような情報をもってますね。失念してました。
しかし例に挙げられた名前や引数などはプロパティであってメソッドが必要ということにはならないような気がします。

>> では、何をまとめたものなのでしょうか？
>データと振る舞い
クラスにデータと振る舞いがまとまっているということでしょうか？私が聞きたいのは、ファイルやモジュールには何がまとまっているのかです。

**デフォルトの名無しさん** · 2021/03/16(火) 18:15:22.40

>>10
だから「クレジット番号という型を割り当てる」って言ってるんやで
文字列型のまま扱うとは言ってない。

**デフォルトの名無しさん** · 2021/03/16(火) 18:20:05.64

>>11
確かに、それはメリットfile単位に対するメリットになりそうですね。
ただ思ったのは、モジュールとか名前空間を定義した方がシンプルな仕様な気がします

**デフォルトの名無しさん** · 2021/03/16(火) 18:46:21.54

>>1
>・カプセル化？
クラスや構造体の内部要素へのアクセス制御のことを指してカプセル化と言ってるなら
そういう機能があればいいだけなのでオブジェクト指向じゃなくてもできる

>・ポリモーフィズム？
これもオブジェクト指向である必然性はないよ
他のやり方でも実現できる

>・モノのように扱いたい？
オブジェクト指向を使うのにモノのように扱いたいという動機はない

**デフォルトの名無しさん** · 2021/03/16(火) 18:59:52.68

>>15
> クラスや構造体の内部要素へのアクセス制御のことを指してカプセル化と言ってるなら
そういう機能があればいいだけなのでオブジェクト指向じゃなくてもできる
なるほど。カプセル化は「クラスや構造体の内部要素へのアクセス制御」を行い、
それらにはメソッドを介して制限するのがカプセル化と思っていたんですが、そうではないのでしょうか？
(この文脈ではメソッドではなくモジュールから提供される関数を指していますが)

> これもオブジェクト指向である必然性はないよ
他のやり方でも実現できる
オブジェクト指向では、ついでにやってるという感じで良いでしょうか？

> オブジェクト指向を使うのにモノのように扱いたいという動機はない
良くネットにある解説記事ではそのように説明していたので、
何かそういう動機もあるのかと思ってました。少なくともそう考えてない方もいるのですね。

**デフォルトの名無しさん** · 2021/03/16(火) 19:00:47.10

オブジェクト指向じゃなくても他のやり方で出来る
→他のやり方でやってる言語は？
→ない、なぜなら他のやり方でできるが、それは冗長で使いにくいから
→つまりやりたいことをやる場合に、オブジェクト指向言語が一番スマートな構文を持っている

**デフォルトの名無しさん** · 2021/03/16(火) 19:01:37.10

C言語を使う理由は？アセンブラでも出来るのでは？
みたいな話

頑張るぐらいなら、オブジェクト指向を使う

**デフォルトの名無しさん** · 2021/03/16(火) 20:21:18.73

全部スタティックなメソッドで作ることを考えてみると少しは分かるかな？

**デフォルトの名無しさん** · 2021/03/16(火) 20:25:15.38

>>17
Lisp系の言語やML系の関数型言語は、オブジェクト指向ではない言語の一例かと。(lispはカッコに問題あると言われてもしょうがないかも知れませんが)

なるほど、オブジェクト指向をすることで、>>1で質問したようなことが実現できるのがメリットなのではなく、それらを最もスマートに実装できることがメリットという主張なのですね。

オブジェクト指向が最もスマートであるという理由, 根拠が気になりますね。よろしければ教えて下さい。

**デフォルトの名無しさん** · 2021/03/16(火) 20:26:53.20

>>19
メソッドにすることで名前空間を汚染しないよね？ということですか？

**デフォルトの名無しさん** · 2021/03/16(火) 20:27:46.73

>>21
い

**デフォルトの名無しさん** · 2021/03/16(火) 20:30:01.10

>>21
あ、staticメソッドなら全然違うか。

**デフォルトの名無しさん** · 2021/03/16(火) 20:36:56.64

"It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures." - Alan J. Perlis

**デフォルトの名無しさん** · 2021/03/16(火) 20:54:13.16

>>24
どういう意図でこの投稿したんですか？

**デフォルトの名無しさん** · 2021/03/16(火) 20:57:53.35

>>16
内部要素へのアクセス制御を指してカプセル化という人もいれば
データと振る舞いをオブジェクト等の1つの言語要素にまとめることをカプセル化という人もいる
https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)

ポリモーフィズム自体はオブジェクト指向で書く場合でもそうでない場合でもほぼ必須の機能
オブジェクト指向の場合はいろいろあるポリモーフィズムのやり方のうちSubtypingを多く使うというだけ

**デフォルトの名無しさん** · 2021/03/16(火) 21:08:00.17

データとそのデータの処理をひとまとめにしたのがオブジェクト指向
この方法論を使うと大規模プログラミングがよりよくなるという強い信仰がある
宗教に近いかもな
他に変わる方法もないし
なんとなく大規模プログラミングを書くと破綻することはよく知られている
万能ではないけど
いくらでもうまくいかない例は挙げられている

**デフォルトの名無しさん** · 2021/03/16(火) 21:09:27.27

データを振る舞いをまとめたオブジェクトを中心的な単位要素としてソフトウェアを作る/捉えるのがオブジェクト指向
ソフトウェアの要素をまとめる方法の一つなので他の方法に比べたアドバンテージもあればディスアドバンテージもある

例えば画面上のボタンもテキストもリンクもタイトルバーもみんなクリック可能で
クリック時にはそれぞれ別の動きをするとした場合に下記のようなAPIに整理するのがオブジェクト指向的

button.click()
text.click()
link.click()
titilebar.click()

clickableならそれぞれの型がclickメソッドを持ってる(clickメッセージに応答できる)
新しくタブをクリックできるようにする場合に他の要素に影響を与えずtab.click()を実装できる
逆にtouch()にも反応するようにするためにはそれぞれの型にtouchメソッドの実装が必要

**デフォルトの名無しさん** · 2021/03/16(火) 21:24:56.48

click(button)
click(text)
click(link)
click(titlebar)

オブジェクト指向的じゃなく上記のように実装した場合は
受け取る型によってclick関数を多重定義したりclick関数内部で分岐が必要
それにclick関数がどの名前空間・どのモジュールに属するかを別途検討してそれを覚えておかないといけない

**デフォルトの名無しさん** · 2021/03/16(火) 21:28:31.02

クラスやオブジェクトの1箇所(1つの型)にデータと振る舞いをまとめるんじゃなく
Traitとか型クラスと呼ばれるもの(HaskellのType Class, RustやGoのTrait, ClojureやElixirのProtocol等)を使う方法もある

Traitは振る舞いの型をデータの型とは分けて定義して、特定のデータ型に対する振る舞いの実装を書いて紐付けることで
関数の多重定義や関数内部で分岐を不要にできる(Subtypingとは別の形のポリモーフィズム)

**デフォルトの名無しさん** · 2021/03/16(火) 21:38:25.74

>>26
初耳でした。カプセル化と言っても意味に２つの流儀があるのですね。

> オブジェクト指向の場合はいろいろあるポリモーフィズムのやり方のうちSubtypingを多く使うというだけ
本筋からそれるかもしれませんが、なぜオブジェクト指向ではSubtypingを多く使うのでしょうか？

**デフォルトの名無しさん** · 2021/03/16(火) 21:48:05.15

>>27
オブジェクト指向は信仰的な要素も強いのですね

**デフォルトの名無しさん** · 2021/03/16(火) 21:54:18.97

Ｃの時代
mallocしたメモリのサイズにユーザーが直接アクセスすることはできなかった
それはンパイラによって実装が秘匿されつねに整合性が保たれた
名前すらなかった昔からオブジェクトはモノリスのごとく存在したのだ

**デフォルトの名無しさん** · 2021/03/16(火) 22:00:31.83

>>28
GUIやゲームを作る場合、オブジェクト指向が感覚的にですがしっくりくる感じがしますね。(ゲームは作ったことないですが)

なるほど、オブジェクト指向的アプローチと関数型アプローチには1例には過ぎませんが、そのような違いがあるのですね。

**デフォルトの名無しさん** · 2021/03/16(火) 22:06:51.87

>>30
パラメータ多相性ですよね。
個人的にはトレイトと型クラスのような多相性の方が自然に思えたので、
なあなあにしていたオブジェクト指向にはどんなメリットがあるのだろう、
オブジェクト指向の方が綺麗なプログラムが書ける場合があるのか？と思い調べ始めました。

**デフォルトの名無しさん** · 2021/03/16(火) 23:02:34.82

難しく考えすぎじゃね？
例えばC言語時代ならファイル操作はFILE構造体がファイル操作の中身だった訳だが
C++でクラスに設計しなおすとFileクラスでファイル操作の実装等はブラックボックスで良くなる
これだけだと簡単でそんなに恩恵無いとなるが
次にCSVファイルをもっと簡単に扱いたいなとなるとすると、Fileクラスにgetcsvやputcsvみたいな
csvの1行の操作メソッドを追加してもいいけどあくまでFileクラスなので
CsvFileクラスを新設し、Fileクラスから継承または内包しgetcsvやputcsvを実装した方が
スマートだと思うが、この辺の話が理解出来ないと中々難しいような気がする

**デフォルトの名無しさん** · 2021/03/16(火) 23:12:11.25

オブジェクト指向だと
「ファイル」を「開く」

手続き型だと
「ファイルオープン」で「ファイル」を開く

頭痛が痛いみたいに冗長な表現になる

**デフォルトの名無しさん** · 2021/03/17(水) 00:37:30.95

>>36
たしかに継承はオブジェクト指向独自の機能な気がしますね。オブジェクト指向でないとFileに対する関数を同じ実装でもCsvFileに再度実装する必要があるので。
内包(合成, コンポジション)の場合は、ほぼ同等ですが。

ただ最近は継承の機能が無い言語も出てくるくらいには, なかなか扱いづらい機能なので、そこら辺はどうなんでしょうか？

**デフォルトの名無しさん** · 2021/03/17(水) 00:57:26.31

>>37
なるほど確かに名前が衝突しやすいので冗長になりがちな所はありますね。

データと振る舞いをまとめるメリットの1つに思えます。

(ただこの場合はopen(file)でもそこまで問題ない気がします。getとかは冗長になりやすそうです)

**デフォルトの名無しさん** · 2021/03/17(水) 15:06:30.73

むかしは組み込み関数や簡単なライブラリレベルみたいなものまで
いちいちプログラマが毎回書いてて
「めんどくせえから再利用したい…っつかできないと大規模プログラムできねぇ」と
「中の変数類をどっかわけのわからないとこからアクセスして弄るのは
プログラムの修正方法として手軽だけど、これやってるとわけがわからなくなるわ！」
がどんどん出てきたので

・入口出口を決めてブロック化しようぜ
・ブロック単位で再利用する言語的なしくみを取り入れようぜ

から、さらに

・「ブロックにAを入れてBが出る」じゃやっぱりなんだかわかんなくなるじゃねーか
ここにも人間が読んでわかるクッション入れて
「ファイルを読み込むクラス.読み込む(ファイル名)」とか出入り口書こうぜ

ってなった…あたりがまだ現行かなぁ…
とにかく「俺がわかればいいんだよめんどくせえ！」ってプログラマの思惑と
「それじゃわかんなくなんだよ！」がずっとせめぎあって常に中途半端なとこに仕様がある感じ。
30年以上前のObjctive-Cの「で、おまえはなにができるオブジェクトなんだっけ？」って
動的問い合わせとか「そんなの“実用”じゃ要らん！」ってモダン言語()じゃ削られるしw

**デフォルトの名無しさん** · 2021/03/17(水) 15:16:49.85

20年ぐらい前に学生の頃に聞いたエージェント指向
初めて聞いた時に、オブジェクト指向にメタ情報つけただけじゃん
メタ情報つけた所で、問題解決できるオブジェクトが存在してなきゃ意味ないじゃん
とか思っていたが、やっぱり流行らなかったな

**デフォルトの名無しさん** · 2021/03/17(水) 15:29:29.24

open(file) と file.open() は書き順が違うだけで意味は同じ。

文法的にはopenは動詞、fileは対象語。
対象語は英語でいうとオブジェクト。
file.open() は対象語が先に来るからオブジェクト指向で良いかと

**デフォルトの名無しさん** · 2021/03/17(水) 15:41:05.53

だがopenという名前をグローバルに定義しないといけなくなる
open(database)という使い方ができない

**デフォルトの名無しさん** · 2021/03/17(水) 16:16:04.31

>>40
クッションというのは
・ファイルを読み込むクラス
・読み込む
のどちらですか？ファイルを読み込むクラスに関して、モジュールと解決する問題の領域が被っている感じしますね。(当時は無かったということでしょうか？)
Objective-Cは詳しくないのでよく分かりませんが、今は静的解析によってエディタが補完してくれるので関数(データ)よりもデータ.関数の方が便利には感じます。

**デフォルトの名無しさん** · 2021/03/17(水) 16:17:58.81

>>41
私が言っているものがそのエージェント指向というものに近いということですか？

**デフォルトの名無しさん** · 2021/03/17(水) 16:22:35.13

>>42
open(file), file.open()の意味が同じなのは理解しています。(機能としてメソッドにはオブジェクトへのアクセスができるという点は異なりますが)
つまり、オブジェクト指向かどうかは記法で決まると言うことでしょうか？

**デフォルトの名無しさん** · 2021/03/17(水) 16:34:45.58

>>43
名前空間を汚染しないというのは、オブジェクト指向のメリットだと思います。

たしかに、異なるデータに対して使いたいときはオーバーロードするか、fs.open(file)とか書く必要あるので、やはり名前空間の解決のメリットは大きいですね。

**デフォルトの名無しさん** · 2021/03/17(水) 16:49:12.98

現在、オブジェクト指向を使う主な利点は、
・データが名前空間になる
・継承で記述量が減る
の2点で、他の機能については様々な実現方法はあるものの、言語の一貫性、統一性のために、独自の機能が備わっている。

といった認識で良いでしょうか？

**デフォルトの名無しさん** · 2021/03/17(水) 16:51:27.50

>>48
もちろん歴史的経緯は違いますが

**デフォルトの名無しさん** · 2021/03/17(水) 16:58:25.89

>>48
「いや、他にもあるわ」
って方いたら教えて下さい

**デフォルトの名無しさん** · 2021/03/17(水) 19:00:06.81

カプセル化の意義が理解出来ないアホに何言っても無駄だし
それだけでも分かればスレタイのようなことをいちいち聞かない
ポリモーフィズムの意義について理解したければ
ローカルファイルシステムも
ネットワークファイルシステムも
似たように操作できる利点と
その実現方法に想いを馳せれば充分
下らないスレを建てたことを自覚しろ
目の前の言語の機能をまともに使え
ライブラリのインターフェースから常識を学べ
机上の空論をダラダラ並べるな

**デフォルトの名無しさん** · 2021/03/17(水) 19:21:27.08

>>51
カプセル化, ポリモーフィズムの意義がわからないとか一言も言ってないんだがw

**デフォルトの名無しさん** · 2021/03/17(水) 19:38:17.66

>>52
おう、>>1 を読んでなかったわ
適当にスレタイと直近のレスの雰囲気だけ見て
タイトルの疑問に答えてやった
obj.method()ではなくmethod(obj)みたいな記法なら
オブジェクト指向ではないみたいな
しょうもない戯言はとっくの昔に頭から追い出してるから
あんな下らないことが >>1 にダラダラ書いてるとは思わなかったわ
そういう扱いが妥当な疑問だってことだよ
それぞれの記法のメリット、デメリットぐらい
見れば分かるだろうが
いい加減にレスして悪かったな

**デフォルトの名無しさん** · 2021/03/17(水) 19:45:08.36

>>52
スレタイが悪い
名前の重要性が分かったろう
こんなガバガバなセンスでネーミングされた
モジュールやメソッドが山ほどあるシステムを想像してみろボケナス

**デフォルトの名無しさん** · 2021/03/17(水) 19:52:05.44

>>54
確かに、スレタイと>>1の質問の仕方は悪かったなとは反省してる。聞きたいことそんまま書いたら誰も反応しなくて埋もれると思ったんや。

メソッドが山ほどあるのはきついが、モジュールは構造化されてれば問題ないし
、そういう言語が大半だろ

**デフォルトの名無しさん** · 2021/03/17(水) 20:15:10.51

クラス指向の言語はなんだかんだでヘルプが見やすい
Microsoftが膨大なライブラリを公開する上で
他の選択肢なんかあり得るのか具体的に細かいところまで想像してみろ

**デフォルトの名無しさん** · 2021/03/17(水) 20:22:00.46

>>53
記法に関して言うと、>>42の回答の意味, 主張を確認しただけであって、別にそうだと思ってない。そして記法にメリットとデメリットが存在するのは自明だし、どっちもどっちだと思ってる。

あくまで疑問としては、オブジェクト指向のメリットとして挙げられるものに、他にシンプルな実現方法があるのに、それでもなおオブジェクト指向であるメリットは何なのか、だった。

**デフォルトの名無しさん** · 2021/03/17(水) 20:32:53.65

>>57
ローカルで無駄なくシンプルにするならすればいい
プログラムで世界の発展を目指していったらオブジェクト指向が
効果的ってこと

**デフォルトの名無しさん** · 2021/03/17(水) 20:34:26.35

>>57
お前の言うのオブジェクト指向では無いものって何のことだよ
せいぜいクラス指向じゃ無いもの程度の意味じゃないのか
カプセル化とポリモーフィズムがあれば
記法や語順がどうであろうとオブジェクト指向と呼んで良い
何が知りたいのかハッキリしろ

**デフォルトの名無しさん** · 2021/03/17(水) 20:48:14.98

優劣で考えるからわからなくなるので
プログラム界の政治的な方針と考えればいいんじゃ
作る側としては０と１をコントロールできたほうが
無駄のないものができる

**デフォルトの名無しさん** · 2021/03/17(水) 21:05:28.52

>>59
クラス指向あるいはプロトタイプ指向を指して、オブジェクト指向と呼んでる。

ちなみに俺の言うカプセル化は「直接アクセスを制限するための言語機能」という意味。

**デフォルトの名無しさん** · 2021/03/17(水) 21:09:42.08

>>61
要はデータと振る舞いをバンドルすることをオブジェクト指向と呼んでる。

**デフォルトの名無しさん** · 2021/03/17(水) 21:11:18.49

ポリモーフィングとか知らんけど
オブジェクトを継承しすぎてわけがわからなくなる
から上の方でまとめるってことだろ

**デフォルトの名無しさん** · 2021/03/17(水) 21:13:44.06

>>58
>>60
歴史的な経緯でオブジェクト指向良いよねという政治的方針が固まった。

そのときのプログラム界の方針に合わせて、一貫性や統一性を重視したほうが良いプログラムになるってことでしょうか？

**デフォルトの名無しさん** · 2021/03/17(水) 21:16:11.94

>>64
「歴史的な経緯」だけでなく、歴史的経緯及び世界的情勢

**デフォルトの名無しさん** · 2021/03/17(水) 21:27:15.70

>>64
歴史とか政治とか比喩だし
上流から見たらオブジェクトを作れば下々も扱える
ようになるという
一種のプログラミングだね

**デフォルトの名無しさん** · 2021/03/17(水) 21:30:01.79

別に手続き型でも変わらないという意見は分かるけど
細かい事だがVSCodeなどでインテリセンスで表示されるパブリックなメソッドやプロパティの候補が
全てが分かるのは効率良いかと思う
これが手続き型では、どういう関数があるかを覚えてないといけない点は何気に違うかなと

クラスにまとまっている方が何かと美しいし、メソッド名も冗長にしなくて良いという点も価値があると思う
fopen()とFileクラスのopen()ではオブジェクト指向の方が個人的にはすっきりすると思う
DIでモックとか作ったりする場合もinterfaceでメソッドだけ宣言して実際のクラスの実装が切り替えられるような
使い方が出来るのも何気に便利だと思うし、一度使いだしたら今更手続き型の方法で機能を提供する意味が無いかなと

**デフォルトの名無しさん** · 2021/03/17(水) 21:45:10.18

>>66
それはメソッドというインターフェイスがあることによって、オブジェクトの使用者も余計なことを考えずに使えるという意味でしょうか？

**デフォルトの名無しさん** · 2021/03/17(水) 21:48:00.61

メジャーな多くの言語に生き残っている記法のメリットが本気で分からないなんてのは頭おかしいレベルだからな
大抵のケースで最適解なんだよ
単なるメンバアクセスと計算を伴うプロパティ取得を
同じインターフェースに統一可能で
それが最小限の記述で出来る文法が前提で…
というだけでも、もう色んな選択肢が限られてくる

**デフォルトの名無しさん** · 2021/03/17(水) 21:54:23.00

>>67
補完機能に関しては、単純に文法の問題であって、型推論に完全性があれば機能すると思うのですが。もしかして私が何か勘違いしているでしょうか？

メソッド名に関するメリットには>>48等に書いたとおり同意できます。
interface等については、データと振る舞いのバンドルという概念を用いずとも、ポリモーフィズムを実現する方法があるので、そちらのほうが良いのでは？というのが私の疑問です。

ちなみに、私は手続き型派というよりどちらかというと関数型派です。

**デフォルトの名無しさん** · 2021/03/17(水) 22:01:39.82

オブジェクト指向言語というのは「オブジェクト指向ができる言語」ではなく
オブジェクト指向をするための構文が備わってて「オブジェクト指向がしやすい言語」という意味

**デフォルトの名無しさん** · 2021/03/17(水) 22:05:11.08

>>71
それは理解していますが、そのオブジェクト指向をする目的はなんですか？

オブジェクト指向のメリットに挙げられるものが、よりシンプルに実装可能なのになぜオブジェクト指向する必要があるの？という質問, 疑問です

**デフォルトの名無しさん** · 2021/03/17(水) 22:10:51.20

>>72
LINEとかいろいろなもの
ホームページすらできないよ
個人的なクレーム言ってるだけなんじゃ

**デフォルトの名無しさん** · 2021/03/17(水) 22:14:50.88

>>73
できますよ。LINEを作ったことはないですが。
クレームですか。それでもなおオブジェクト指向である理由があるなら、納得しますよ？というかそれが知りたくて聞いてるんです。

**デフォルトの名無しさん** · 2021/03/17(水) 22:19:27.77

>>69
記法のメリットには同意してます。一つのオブジェクト指向のメリットであると思います。

「単なるメンバアクセスと計算を伴うプロパティ取得を
同じインターフェースに統一可能」このようにする利点を教えてくれないですか？
モジュールによるカプセル化ではなにかデメリットがあるんでしょうか？

**デフォルトの名無しさん** · 2021/03/17(水) 22:33:58.22

モジュールとカプセル化は知らんけど
好きにすればいいんじゃ
知らんけど

**デフォルトの名無しさん** · 2021/03/17(水) 22:50:44.23

>>72
>よりシンプルに実装可能

その例をコードで示してくれれば議論が進むんでないの？

**デフォルトの名無しさん** · 2021/03/17(水) 23:00:22.40

>>77
まぁそうですね。でも面倒くさい気持ちあるんで(不毛な議論続けるよりマシか？)、ポリモーフィズムは継承やinterface以外の方法もあるんやぞで納得できないかな？いやどっちも見せた方早いでしょうか？

**デフォルトの名無しさん** · 2021/03/17(水) 23:09:24.27

>>72
オブジェクト指向は人間のメンタルモデルに一致してるからわかりやすい

俺の机の横には卓上時計というモノがある。
卓上時計には、いろんな機能がある。
それらの機能は、そのモノ特有の機能である。

という文章をモノを排除して説明してみ

**デフォルトの名無しさん** · 2021/03/17(水) 23:25:10.41

>>79
>>1の最後の「モノとして扱いたい」という考え方したいということで間違ってないですか？

**デフォルトの名無しさん** · 2021/03/17(水) 23:29:53.38

カプセル化についてはこんな感じです。

mod hello {
type NameString = String;

pub struct User {
pub name: NameString,
age: usize,
}

pub fn the_user() -> User {
User { name: String::from("Alex"), age: 10 }
}

pub fn get_age(user: &User) -> usize {
user.age
}
}

fn main() {
use hello;

let user = hello::the_user();
let age = hello::get_age(&user);
println!("name: {}", &user.name);
println!("age: {:?}", age);
println!("age: {:?}", &user.age); // private field!
}