オブジェクト指向はオワコン？ part4

過去スレ
オブジェクト指向はオワコン (2023/08/26〜)
https://mevius.5ch.io/test/read.cgi/tech/1721393540/
オブジェクト指向はオワコン？ (2024/07/19〜)
https://mevius.5ch.io/test/read.cgi/tech/1721393540/
オブジェクト指向はオワコン？ part2 (2026/08/13〜)
https://mevius.5ch.io/test/read.cgi/tech/1786599483/
オブジェクト指向はオワコン？ part3 (2026/08/26〜)
https://mevius.5ch.io/test/read.cgi/tech/1787712923/

>>前スレ終盤
あんなものは抽象化じゃねぇってｗ
抽象という言葉の意味すら理解していない無知がカッコつけてそう呼んでいるだけ。
あえていえば相称関数あるいはデータ構造付属メソッド

抽象データ型（ちゅうしょうデータがた、英: abstract data type、ADT）とは、データ構造とその操作手続きを定義したデータ型、またはデータ抽象の方法の1つ。
通常のデータ型であれば変数宣言で変数に束縛されるものは値であるが、抽象データ型の世界において値に相当するものはデータ構造とその操作のまとまりである。

抽象データ型を用いない場合、データ構造またはデータの操作手続きのアルゴリズムの変更を行うとソースコード中にその変更部分が散在してしまい規模によっては修正困難となるが、データとその操作がひとまとめに記載されることになる抽象データ型においては、型の定義における実装部分を変更するだけで修正が完了する。

プログラムが実装されたとき、抽象データ型は実装を隠蔽するインタフェースを表す。
実装は将来において変更されうるので、抽象データ型のユーザーは実装ではなくインタフェースに関心がある。

抽象データ型の強みはユーザーから実装が隠蔽されていることである。
インタフェースのみが公開されるのである。
このことは、抽象データ型がいろいろな方法で実装されうることを意味するが、インタフェースに忠実な限りユーザープログラムは影響を受けないのである。

抽象データ型は各自のプログラムで必要となる固有のものを各自で定義できる。
汎用的な抽象データ型としては、以下のようなものがライブラリとして提供されていることが多い。
Collection
Container
List
String
Set
Multiset
Map
Multimap
Graph
Tree
Stack
Queue
など

>>3,4
その辺の入門的なWebから引用してきたような説明だな

しかし、特に抽象的でないものに対して抽象,抽象
うるせえ野郎だな
中小くらいにしとけ

オブジェクト指向におけるインタフェース抽象型はその抽象データ型をさらに発展させたもの
複数の異なる型に対して共通の振る舞いをインタフェースとして宣言する
そして各型はそのインタフェースを実装する
プログラムの引数や変数などをインタフェース抽象型として記述できることが特徴である
それによって共通の振る舞いを一つのコードで共通コード化できる
そのインタフェースを実装しているならば任意な型で動作することができる
つまり特定の型に依存せずに抽象的なコードを書くことができるようになった

異なるデータ構造に対する処理で
同じメソッド名、引数で呼べる関数があったら
なぜ抽象なのか

型は違えど同じ共通操作をしたいことがプログラミングでは多々あるだろ
それを共通インタフェースとして宣言して各型はそのインタフェースを実装する
そのインタフェース抽象型で記述した関数は抽象的なコードになって各型に横断的に使える
これは抽象的なジェネリックな関数のパラメータ型が、あるインタフェース実装をしている制約を満たす時と同じになる

>>9
具体的データ構造に依存しないから抽象ではあるんじゃね
その抽象が役立つものかどうかは別として抽象ではある
仮にその抽象にモスフングスという名前をつけてみよう
その名前が役立つかどうかは別の話だ

>>9
それだけだとたまたま構造的に同じメソッド名だけかもしれない
構造的なインタフェース型付けではそれでも同じに扱ってしまう弱点がある
一方でインタフェース名を宣言する場合は区別ができてたまたま同じメソッド名と同じ方の引数であってもどのインタフェース名を実装している型はどうかで区別できる
つまりインタフェース抽象型はたまたま同じを確実に排除できる

話は簡単だよ
抽象型を用いずに関数を書くと各々の型ごとに別々の関数を書かなきゃいけない
手間もかかるしほぼ同じ関数が何度も出てきて可読性も悪いし保守性も悪い
よーするに抽象型を使った関数は良いコード

>>12
それは名前的型システムと構造的型システムの違いの話であって、インターフェイス抽象型という概念はそのいずれとも結び付くのだから、最後の「インターフェイス抽象型は……できる」というのは論旨がつながらないと思うけど。
名前的型付けによるインターフェイス抽象型は……ということだよね。

>>11
なるほど、ソースレベルの呼び出し方がデータ非依存であるとを
ある分野では「抽象」と呼ぶことにしたってわけか

抽象型（abstract type）とはプログラミングの型システムのうち、名前的型システムにおける型の一種であり、直接インスタンス化することができないという特徴を持つ。
対義語は具象型または具体型（concrete type）であり、具象型はインスタンス化することができる。

抽象型は実装を提供しないか、あるいは不完全な実装を提供する。
具体的な形態や仕様はプログラミング言語ごとに異なるが、いくつかの言語において、実装を持たない抽象型はインタフェースやプロトコルヤトレイト等と呼ばれている。

クラスを持つプログラミング言語では、抽象型は抽象クラスとして実装される場合があり、具象型は具象クラスとして実装される。
ただし抽象クラスはインスタンス用の変数を持つことができる場合があり、それを持たないインターフェイス等と比べると別の機能が付加されている。

抽象型という概念が、名前的型システムとしか結び付かないということは別にないと思うんだが……。

構造的型システムは問題点が山積みだかららしい
構造が同じだと同一視するから事故が起きまくり
例えばこんな例もあるようだ

https://scrapbox.io/nishio/%E5%90%8D%E5%89%8D%E7%9A%84%E5%9E%8B%E3%81%A8%E6%A7%8B%E9%80%A0%E7%9A%84%E5%9E%8B%E3%81%AE%E5%8B%98%E9%81%95%E3%81%84%E3%81%AB%E3%82%88%E3%82%8B%E5%AE%9F%E8%A9%B1

>>18
それはGoだと発生しないね

>>19
どのような仕組みで防いでいるの？

>>19
Javaでも起きないよ(小声

>>18
OCamlだと名前的型と構造的型の使い分けができるみたい。

多重継承は？

静的型付けがなぜ重視されるのか？
それは型が異なるものが間違って使われることを100%防げるため
人間はミスや混乱するものだからコンパイル時点で100%防げることは大きい

名前的インターフェイスによる抽象型の型付けも同様
その名前のインターフェイスが実装されている型だけを受け入れる
間違いを100%防ぐことができる

一方で構造的な場合はどうか？
100%防ぐことは絶対にできない

>>24
実装するインターフェイスを間違える可能性だってあるでしょうが!!

インターフェイス毎に別の名前が付いてるから大丈夫やろ
インターフェイス毎に実装すべきメソッド一覧も異なるからそこでも気付く

そんなガバガバな理由で100%防げるなら関数名や変数名で構造的型付けの問題も100%防げるんちゃう？

構造的型付けは利用する複数のライブラリと自作の間で入り乱れたら詰むよな
インターフェースに名前があれば万が一でも別名指定もできるから確実に安心だ

ガバガバおじさんｗ

>>28
ガバおじさんは構造的型付けの場合はインターフェースに名前が無いと思ってるのか
脳内設定がガバガバだな

>>30
C++やTypeScriptは名前なしでも構造が一致すれば使えるぞ

>>30
構造的型付けはインターフェース宣言が不要で名前無くても大丈夫だよ
名前的型付けは名前を持つインターフェース宣言が必要だけどね

Pythonは名前的型システムをベースにしつつ、特定の属性を持つことを「◯◯プロトコル」と呼んで構造的型システムの要素を加味していたりするし、両者の組み合わせというアプローチもあると思うな。

抽象型には名前があるべきだ
名前があると可読性が格段に良くなりコンパイラによるエラーもわかりやすくなる
名前のない構造的な抽象型はデメリットが多すぎる

名前のない抽象型ってどんなの？
見たことないんだけどどんなコードのこと？

ケースバイケースで判断したらええ
どちらでも良いことをこちらじゃないとダメだと
思い込むのはアスペ仕草でしかないぞ

たとえばPythonでは__next__属性と__iter__属性を持つオブジェクトはイテレーターとされるけど、構造的型付けの一種とみて良いんじゃない？　iteratorプロトコルと称されるけど、iteratorという名前をコード上に書くわけではない。
名前的型システム+継承によるサブタイピング多相だけで全てを賄おうとすると継承ツリーが巨大になって管理困難になるということで、いろいろなアプローチが試みられているところだと思うけど。

>>34さんはダックタイピング、ジェネリックプログラミング/テンプレートプログラミングに対してどこか独特な善し悪しの境界線を持っていそうだね

>>37
それはduck typingだね
duck typingをstructural typingの一種と見て良いんじゃないかということだけど区別したほうがいいんじゃない？
特にこういう議論においては

>>37
継承ツリーが巨大になる？？
それはクラス継承だけでやろうとするバッドパターンでしょ
インターフェースを使いましょう

>>39
構造的型付けという概念は、静的型付けとも動的型付けとも結び付く概念だから、ダックタイピングを構造的型付けの1種とみなすことに問題があるとは思わないが。
ま、37は>>35に対する1つの考え方として提示したものだから、35自身がたとえば静的型付けしか念頭に置いてなかったということであれば、その期待に沿うものでなかったということなんだろうけど。

>>40
インターフェイスも継承によるサブタイピング多相に他ならない。継承ツリーが大きくなるというのは、たとえばPythonで現在◯◯プロトコルとして実現されているところを全て明示的な抽象基底クラスの継承を必要とするようにすることもできなくはないけれども、そうするとその分、プロトコル的アプローチでは必要とされない継承が増えてしまうということね。むろん得失はあるから、プロトコルのような構造的型付け的なアプローチの方が優れているというわけでは必ずしもないけれども、抽象クラスなりインターフェイスなりから継承してサブタイピング多相をやっておけば万事解決というほど簡単なことではなさそうだという認識がある程度共有されているからこそ、現在、構造的型付けのようなアプローチが模索されているということだと思うよ。

>>41
インターフェースは継承ツリーを招きません
ツリーになるのは実装継承のクラスだけ
巨大な継承ツリーはクラス継承によってのみ構成されます

Java等でいうインターフェイスの実装というのは、C++でいう抽象クラスからの継承に概ね相当する概念であって、インターフェイスは継承ツリーを作らないというのは単なるレトリックでしょ。C++で継承といっていたものを、用語上「継承」と「（インターフェイスの）実装」等に分けただけ。
本質的なのは、サブタイピング多相を実現するのに明示的なクラス名（インターフェイス名）の指定を必要とするという点なんだけど。

>>43
それあんた逆だよ
C++はインターフェースがない不完全な言語だから抽象クラスで代用して禁断の多重継承を許している
Javaはインターフェースがある正しい言語だから多重継承は禁止されていてインターフェースをいくつでも好きなだけ実装できる

>>44
時系列的におかしいような。

>>45
時系列的に合ってるよ
C++(インターフェースのない不完全な言語)→Java(インターフェース登場)の順

Javaのようなinterface方式はクラスを修正してinterfaceを実装しないといけないから修正不可能なクラスの共通処理を実装できないのがネックだな

>>47
それはJavaが不完全なインターフェースの実装指定言語だからだよ
インターフェースの実装を分離したその後の言語ではその問題は起きない

>>48
たとえばどういうのよ？

>>46
Modula-3のinterfaceがあって、c++ではhpp/cppと純粋仮想関数によってのちのjava系interfaceの
ようなことはできている。
javaは多重継承を禁止する必要性から、c++で可能だった機能をinterfaceキーワードにまとめた。
このへんは、大きなクラスをつくれないようにする分出公理のやりかたに似ている（個人的感想です）。
c++の時点では、不完全というより、精錬されていないという感じ。

公理的プログラミング言語を考えると、そのひとつとしてクライスリトリプルであること。
モナド系であれば、純粋モナドである必要はないがモナド則に反しないこと。
これは圏論的プログラミングであり、オブジェクト指向のメッセージングを「射」と考えれば、
オブジェクト指向プログラミング＝圏論的プログラミングだ。

>>50
多重継承は問題点が多すぎるため、クラス継承は一つに限る、つまり多重継承禁止がスタンダードになった
親クラスとその子クラスは『1対多』になる

インターフェースは対極的な位置付けで、各機能毎にインターフェースをいくつも実装する
インターフェースとそれを実装するクラスは『多対多』
ある1つのクラスから見ると『多対1』になる

>>41
型同士の互換性を型の構造から判断する型システムが構造的型付け

`def foo(x: Sequence) -> Sequence`という関数を`foo(a)`で呼び出した時
aがSequenceと互換性があるかどうかをSequenceとaの型の構造から判断するのが構造的型付け
ダックタイピングはそういう判断自体をやってない

特に動的か静的かをイメージしてたわけではなく
>>34の書きぶりから匿名抽象型みたいなものがある言語の例を期待してた

複おじはいつも原因と結果がごちゃ混ぜなんだよな
巨大な継承ツリーを作らないように設計してるから巨大な継承ツリーにならないというだけで
クラスだからとかインターフェースだからという話じゃ全然ない

Pythonはクラスの多重継承をサポートしてるわけだけど
クラスを使っても巨大な継承ツリーを作らないように設計すれば巨大な継承ツリーにならない
当たり前だな

>>53
名前のない匿名な抽象型の例としてはC++かな
例えば以下のコードは構造的にobject.size()を使っていることで型付けされて
型パラメータTは構造的に無名な抽象型になる

template<class T> void print_size(T object) {
cout << "size: " << object.size() << endl;
}

その構造的に無名な抽象型を満たす任意の具象型で使うことができる

int main() {
std::string s = "abcde";
print_size(s); // size: 5

std::vector<int> v = {100, 200, 300};
print_size(v); // size: 3
}

もちろん名前がないために
多数の構造やその多段など複雑に込み入ってくると可読性が悪すぎたりコンパイルエラーがわかりにくい問題点も多いけどね

>>53
「ダックタイピングはそういう判断自体をやっていない」と言えるかどうかは型付け・型検査の概念の広狭に依存する。
型付け・型検査の概念を狭く解釈すればそのようにいうことができるけど、一般に「ダックタイピングは構造的型付けの一種である」と言われるとき、ダックタイピングで想定された特定の属性をレシーバーのオブジェクトが持っているか否かは、型付け・型検査の一部として観念できる。

>>55
それもダックタイピングだね
抽象型がプログラム上に型としては現れない
脳内にのみ存在するイマジナリー型なので匿名型とは違う

ちなみにそれをconceptで型制約する形にすれば
ダックタイピングじゃなく構造的型付けになる

>>56
Sequenceの必須メソッドは__len__と__getitem__なんだけど
`def foo(x: Sequence) -> Sequence`の中身が例えば`return [x[1], x[2]]`だったとしたら使われるのは__getitem__だけ
__getitem__呼び出し時にそのメソッドがあるかないかは判定はしてるがxの型がSequenceと互換性があるかどうかは判定していない
これがダックタイピング

>>57
そのC++の構造的静的型付けをダックタイピングと呼ぶのはやめよう
それは正しくない

静的ダックタイピングと呼んだらええやん頭高市かよ

>>60
プログラマーって右翼多すぎる界隈じゃん昔から
論理的な思考、演繹的な解法ができない人が多いというか

動的な構造的型付け＝動的なダックタイピング
静的な構造的型付け＝静的なダックタイピング

>>58
言わんとするところは理解できるんだけど、プロトコルを基礎づける特殊メソッド全ての存在チェックがないから構造的型付けではないという理由で線を引くのであれば、
たとえば、そのコードでfooの中に__len__を参照するコードもあった場合とか、プロトコルを基礎づける特殊メソッドが単一の場合とかなら構造的型付けになるのかという話になる。
仮にそれらの場合もダックタイピングではあるが構造的型付けではないと整理するなら、それは結局、型付け・型検査がそのようにされるべきだという主張ということになる。
構造的な型の方の粒度をプロトコルより狭く設定する（たとえば、SupportsGetitemみたいな感じで）という構成も可能だろうし、あまり本質的な線引きにはなっていないように思うかな。
「動的型付けは型付けではない」という考え方自体は昔も今も非常に有力にあるし、結局、そういう言う考え方なんだろうなと思うけど。

>>63
そういう線引きをしてるんじゃなくて型レベルのチェックはしてないよって話

線引きはシグニチャで要求される型と渡された値の型が互換性があるかどうかを型のレベルでチェックしてるかどうか
let x: Sequence = y; としたときにyの値の型がSequence型と互換性があるかどうかを型レベルでチェックしてるかどうか
そのチェックが構造的なら構造的型付けという線引き

匿名抽象型の話だけどOCamlはそれっぽい表現ができるみたいだね

let use_object
(x : < print : unit -> unit;
name : string;
reset : int -> unit >) =
print_endline x#name;
x#print ();

xは指定されたprint, name, resetメソッドを持つ必要がある
resetは実際使われてないが持ってないとコンパイルエラー

>>58 を >>64 のつもりで書いていることは分かっているし、その上でそこでいう線引きの基準（64でいう「型レベルのチェック」）は、
型付け・型検査の概念や型の粒度をどう設定するかに依存する相対的な概念だよねっていうことで>>63のように書いたんだが、あんまり伝わらなかったか。
ただ、Pythonのように名前的型システムをベースにしている言語におけるプロトコルを構造的型付けの1種として見ることができるのではないかという
題材というか話の切り口じたいがあまり良くなかったのかもなというのは反省。

オブジェクト指向って解析しずらいから嫌い。

名前的と構造的の境界はどこにあるんだろうな
>>55のC++と>>65のOCamlを比べると
どちらも制限された型しか受け付けない抽象型だけど
型に直接の公開名はついていない
しかしC++の方は関数内のコードの構造を見るまでは型が制限されないのに対して
OCamlの方は先に関数の入り口の構造と指定で制限される
しかも関数内のコードの構造よりも強く制限された抽象型になってる
内部構造と無関係なresetの制約を受ける理由はresetという『名前』で指定しているためと解釈することもできる

>>68
ダックタイピングと構造的型付けの境界だよね？

C++がコンパイル時に匿名抽象型的なものを内部的に作ってその型と渡された値の型の互換性をチェックしていたのならシグニチャには明記されないが構造的型付けと言うことはできたかもしれない
でも実際はそんなことはしてなくて渡された値の型でとりあえずテンプレートをインスタンス化してインスタンス化されたコードのコンパイルをしてみてメソッドが呼べなければエラーになるだけ

コンセプトを使えばインスタンス化される前に型レベルの互換性チェックが構造ベースで行われる

>>69
一段ズレてるぞ
こうだ
コンセプトなし＝構造的型付け
コンセプトあり＝名前的型付け

>>67
オブジェクト指向でリファクタしたらええやん

Aの複雑さとBの複雑さを
同じ箇所にごちゃごちゃ書いたらわかりにくいだろ
オブジェクト指向ではAの複雑さをAの中に閉じ込める
Bの複雑さをBの中に閉じ込めるということをやって
複雑さをコントロールするんだよ

Aを修正したいときはAだけに集中してBは気にしなくて良いというのが理想

>>69
構造的型付けを理解してなさすぎ
構造的とは実行コードだけ見て逆算で抽象型が決まるの

一方でそこで使われる役目のコンセプトはRustだとトレイトつまりJavaのインターフェースに近いポジション
コンセプトによる名前的型付けになる
これらは実行コードを見なくても先に抽象型が決まるの

>>74
あー、nominalとstructuralの違いからして理解してなかったのか
そりゃ話が全く通じないはずだわ

nominalは何らか型を制約する名称を用いて型付けされる。プログラムの構造が合致してなければコンパイルエラー。
structuralはプログラムの構造から型付けされる。名称はない。

名前的型付けと構造的型付けの対比は静的型付けと動的型付けの対比とは独立した話だから、名前的型付けと構造的型付けの対比の文脈のはずなのにコンパイルとかコンパイラという言葉が出てきて、それで両者の違いを説明しようとするのは、それだけで一般的な説明としてはアウトだと思うわ。

静的にエラーと言うべきだよな

細かい規約とかはどうでもいいが最低限変数、オブジェクトの型を用途別に区別が付くようにしろ。連想配列にしても使える候補を限定して定義し、コンパイル時にタイポチェックできるようにしろ。
何でもintかvoid*にしとけばOKだったCのオブジェクト指向とかは御免だ。

用途別というのをどれくらいの細かさのレベルで捉えるのか、ドメイン固有の仕様をできるだけ型システムに取り込んで型で表現できるようにするのを良しとするか、そうしないのかっていうのは結構考え方が分かれるところじゃない？　
AdressとかPhoneNumberみたいな型をstringとは区別して定義して、型で仕様を表現するという考え方は本とかではしばしば見る。逆に関数型言語（の一部？）ではデータ型の種類は増やさず汎用的な関数でいろいろやるのが好まれるという主張も見る。どちらの方向性が良いのか、個人的な定見はないんだけど。

関数の引数として受け取る場合

名前的型付け
・関数のシグネチャを見れば型がわかる/確定する
・関数内のコードを解読する必要がなく型がわかる/確定する
・そのため関数の開発者にも利用者にも理解がしやすい
・関数内のコードを解読して食い違いがあれば関数単体で実行前にエラーを出すことができる
・そのため開発時も保守更新時も効率がいい

機能的型付け
・関数のシグネチャで何も指定がない
・そのため関数の開発者はお手軽に使いやすい
・利用者にはわかりにくい
・関数内のコードを解読すれば型がわかる/確定する
・そのため関数を利用する側の各コードと突き合わせれば実行前にエラーを出せる可能性がある
・関数単体ではエラーは出ない

ここで「型がわかる/確定する」とは「具象型」または「特定の操作(群)が可能な抽象型」であることがわかる/確定するという意味である
名前的型付けの場合でもその抽象型に名前が付いているとは限らない
例えばインターフェースAとインターフェースBの両方を満たす抽象型はそれ自体の名前を持たないが抽象型としては確定する

>>81
スマソ
肝心なところをミス
「名前的型付け」と「構造的型付け」です

型の識別をする際、名前的型付けは型の名前を基準とし、構造的片付けは型の構造を基準とする。部分型関係を定義するのに、名前的型付けは明示的な宣言（クラスやインターフェイスの継承など）を必要とするのに対し、構造的型付けは構造の包含関係等で判定できるので必ずしも明示的な宣言を必要としない……というのが基本的な違いだと思うけど。

構造的型付けだからといって型に名前を付けられないわけじゃないから、関数等の引数の型は普通に指定できるでしょ。自分はTypeScriptを書かないのでその型システムをきちんと知っているわけではないけれど、TypeScriptで関数の引数の型を指定できないなんて聞いたことがないし。
「実行前に〜」云々は静的型付けのことしか想定していないから、そもそも名前的型付けと構造的型付けの比較点として持ち出すのは的外れ。

>>83
それは型に対してメソッドなどを定義あるいは実装するときの話
>>81は関数の引数として受け取るときの型付けの話
それぞれ別の話であることに注意

何を言いたいのかよく分からないんだが、関数の引数の型付けという場面なら、構造的型付けの言語（たとえば、TypeScript）では引数の型の指定ができないという主張なの？

Pythonでもあるまいし

>>85
型を明示的に指定したら名前的型付け

>>85
あなたの勘違いがわかった
言語によって構造的型付けや名前的型付けが定まるわけじゃないよ
型付けの使われるシーンで定まるんだよ

>>87
名前的型付けと構造的型付けという用語は、一般的には型の識別を型の名前によって行うか、型の構造によって行うかを指す用語として使われており、型に名前を付けているか否かを指す語ではないはずだけど。
というか、用語・概念の最初の定義の時点で一般的な理解から外れているのってどうなの……。

>>88
場面に応じて、名前的型付けと構造的型付けとが併用されることがあることは別に否定しないけれど、TypeScriptにおける関数等の引数の型は、基本的には構造的型付けで判定されるはずだよ（細かい仕様としてはいろいろあるみたいだけど）。少なくとも、関数等の引数の型を指定した場合に、そのことによって名前的型付けになるということはない。

>>55のC++の例は引数を束縛する名前がなく構造的型付けで静的ダックタイピングだけど
conceptを定義してその名前で束縛してやると名前的型付けになる

template <typename T>
concept HasSize = requires(T a) {
{ a.size() } -> std::convertible_to<std::size_t>;
};

void print_size(const HasSize auto& object) {
cout << "size: " << object.size() << endl;
}

>>89
interface名を使う時点で型は確定するため名前的型付けだよ
一方でその名前的型付けされた型に値が構造的にマッチングできるというだけ

C++のテンプレートみたいなのはどうなん？

>>90
コンセプトはそもそも制約条件の記述であって、型じゃないでしょ。

>>91
オレオレ定義で押し通そうとするのは何なん。検索するなり、AIに聞くなりして「名前的型付け」「構造的型付け」の意味を確認するところから始めた方が良いと思うが。
たとえば、関数の引数がインターフェイスA型のオブジェクトを受け取るシグネチャになっているとき、名前的型付けであれば、Aと同じ構造を持つが名前が異なるインターフェイスB型のオブジェクトは引数として渡せないことになるが、TypeScriptはそういう仕様になっている？　それともオレオレ定義の名前的型付けでは、そういう名前の異なる型同士の間でも同一性・互換性を認めるってするの？

似てるようで別なこと

型推論
不明な型の変数がその後の使われ方で逆伝播して具象型が定まること

構造的型付け
不明な型の変数がその後の使われ方の構造によって制限されて抽象型が定まること

構造的マッチング
既に型が定まってる変数に対してその型と同じ構造のデータがマッチングないし代入されること

構造的型付けとダックタイピングはWikipediaの型システムの解説が良く整理されていると思うけど、これをベースに考えればいいんじゃない？
https://ja.wikipedia.org/wiki/%E5%9E%8B%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0

オレオレ定義を使うなら、Wikipediaとの差分と、Wikipediaと違う定義にする理由くらいは明示してほしいところ。

>>93
コンセプトによって型が制約されて抽象型が生じる
インターフェースによって型が制約されて抽象型が生じるのと同じ

>>90
print_sizeの引数として渡されたobjectの型が明示的にHasSizeを実装してると宣言してある場合だけ互換性がある型として扱われるのならnominal typing
実際はobjectの型が構造的にHasSizeを満たしていれば互換性がある型として扱われるのでそれはstructural typing

>>92
C++20からのconceptが使われない限り
C++のテンプレートは構造的型付けであり静的ダックタイピングとも言われるとどの記事やサイトの説明にも書かれてるね
ところがTypeScriptの意味での構造的型付けとはまるで異なるようにみえる
例えば>>55はC++テンプレートの構造的型付けの典型的な事例だけどstring型とvector型が同じ型として扱われてるよ

C++のテンプレートは構造的型付けであると断言するものより、構造的型付け「に近い」とか構造的型付け「的」とか、ちょっと留保の余地を残した書き振りの説明の方が多くない？
名前的型付けと構造的型付けの対比は主にサブタイピング多相の文脈でクローズアップされるのに対し、テンプレートはパラメトリック多相の系譜だからちょっと区別されているのかなという印象だけど。
stringとvectorは同じ型とされているわけじゃないけど、sizeを持つという点で同じ構造を持っており、それによりprint_sizeとの関係では互換的に使うことが認められる。その意味で構造的型付け「的」ではあるけれども部分型関係があるわけじゃないから、名前的型付けと構造的型付けの対比として典型的に持ち出される場面とはちょっと違う……ということだと思うけど。

>>54
クラスとインターフェースはツリーと言っても向きが真逆だよ
ツリーと言うからには多重継承を許す極一部の言語を除く場合だろうけどその時
クラス継承のツリーは下方向に多数になり得る
一方でクラスから見てインターフェースは上で上方向が多数になり得る

いうほど真逆か？

>>100
構造的型付けを勘違いしていたことを自覚したので他の話題に切り替えたい模様

継承の向きを揃えると逆だね
多対1　多数のインターフェイス→自分
1対多　自分→多数のサブクラス

>>99は反省してるようだからイジメてやるなよ

>>83
実行前に分かるかどうかは一番重要なことだろ
開発したことないんか？

>>105
実行前に分かるかどうかが重要であるとかないとかいう話ではなく、名前的型付けと構造的型付けの違いにはならないと言っている。
>>95で紹介されているWikipedia辺りにちょっと目を通すだけでも、>>81が一般的な理解とかけ離れたことを書いているということは分かりそうなものだが。

>>106
実行前に分かるか分からないかで2つに分かれてるなら致命的な違いに見える

「分かれてるなら〜」じゃなくて自分で調べたら？
名前的型付けと構造的型付けの対比は、静的型付けと動的型付けの対比とは独立している。したがって、名前的型付け・構造的型付けのいずれであるにせよ、静的型付けと動的型付けのいずれとも結び付き得る。
たとえばPythonは、（プロトコルなどはあるものの）名前的型付けが基本の動的型付け言語、TypeScriptは構造的型付けが基本の静的型付け言語。>>81がどれだけナンセンスなことを書いているのか、いい加減に理解してよ。

>>107
さっき上げたwikipediaにまとまってるけど、
「名前的型付けとは、システムが保持しているプログラム要素の参照情報上の型の名前を見て、データ値の型を識別するスタイルである。
構造的型付けとは、参照情報上の型の名前を見ないで、データ値本体の分析でデータ値の型を識別するスタイルである。」

型の互換性判定で名前を見るか型の構造を見るかの違いだよ。

その結果、名前的型付けは名前同士の関係を実際に使用する前に明示する必要があって、型同士の依存関係をコーティング早期に強くする必要がある。
構造的型付けと名前的型付けの違いが効いてくるのは設計の話で、実行前か実行時かはあんまり効いてこないかと。

>>108
Pythonはダックタイピングだから構造的型付け

>>83
TypeScriptは構造的部分型だよ

>>108
君が相手にしてるのは複製おじさんと言って
いつも技術的に間違ったことばかりを書いて
指摘されても一切反省しない荒らし的なやつなので
まともな議論になると思ってはいけないよ

>>110
ダックタイピングが可能な範囲で一種の構造的な型（プロトコルはその一種）を観念するのは、個人的には支持したい考え方ではあるが、Pythonの言語仕様において「型」とされるのはそのような観念的な型ではなく、Pythonの型（言語仕様上の型）はあくまでも名前によって識別される。Pythonが名前的型付けを基本とする言語とされる所以。

>>111
そうだよ。部分型関係の有無を構造の包含関係等で判定できるって>>83で書いているとおりだが。

>>112
ありがとう。いつまでも付き合ってはいられないので、適当なところで切り上げます。

構造的型付けは欠陥だらけなので採用しているプログラミング言語は片手で数えられる
ほとんどの言語は欠陥だらけの構造的型付けを採用しなかった

ハルシネーション治せる？

構造的型付け言語でまともな開発するわけではないから特に問題はない
スクリプトとして使う分には合ってる

まともな言語なら構造的型付けと名前的型付けを併用できるだろ。
OCamlみたいに構造的部分型などを活用して設計を後回しにできるメリットは大きい。

構造的型付けを採用しているのはTypeScriptとかGoといった比較的新しい言語だし、名前的型付けの言語でも構造的型付けの要素を追加する動きは少なくない。たとえばPythonは3.8でtyping.Protocolを追加している。

構造的型付けにはしばしば指摘されている欠点があるのでそれに対応する必要はあるものの、クラスやインターフェイスの継承といった明示的な宣言をしなくても部分型関係を作れるというのは非常に大きなメリットだと思うよ。既存の継承ツリーに手を加えられるとは限らない（仮に手を加えられたとしてもその分ツリーは大きく複雑になる）からね。個人的には『ロバストPython』に出ていた飲食店のメニューを表す継承ツリーにSplittableという要素を追加するという例が面白かった。

>>118
問題はその手を加えられない既存の継承ツリーだということに気付かなきゃ
既存の継承ツリーなんてものがあるために変な対応をしなきゃいけなくなってる

クラス継承のツリーが癌
健全なオブジェクト指向には不要だった部分

間違ったオブジェクト指向を教えられアンチオブジェクト指向になった人と
構造的型付けとは静的なダックタイピングだという間違った知識いまだに信じてる人と
構造的型付けと名前的片付けの区別がつかない人が
きれいに重なってるのが面白い

原因はやっぱり20年以上前から知識をアップデートできてないからだろうな

構造的型付けは型システムの安全性を失くす危険因子
安全性を重視するなら絶対に導入してはいけない

構造的型付けを導入してしまったTypeScriptは苦しんでるよな
構造が同じなら同じ型になるのは型安全性を乱す致命的な間違いだった
そこでTypeScriptは型を区別するために隠しフィールドを増やすという本末転倒な方法を編み出した

構造的型付けを安全にするのは簡単だよ
①構造に名前を付ける
②同じ構造でも名前が異なるなら区別する
③各型やクラスはどの構造を持っているのか名前で宣言する
これで安全になるよ
①②③は必須だよ

構造体もそれぞれ目的が違うんだから同じ内容に見えても別名にするだろうし、名前だって目的に沿った名前にするから当然違う名前になる

>>125
その通りなんだけど
構造的型付けの間違いは「一部分でも同じ構造を持つなら同じ抽象的な型として扱う」ことにしたこと

>>126
それは最悪だな、機能追加や変更がやりづらいw

構造的型付けでもその構造型に名前をつけることはよくあるけれども、型の区別を名前で行うならばそれはもはや構造的型付けではないでしょ。
構造的型付けのメリットを活かしつつ、欠点をどうフォローするかは構造的型付けを取り入れた各言語で模索中ってところじゃないの。Pythonみたいな言語で部分的に構造的型付けを取り入れているだけの分にはほぼメリットしか感じないけど、TypeScriptみたいな純粋な構造的型付け言語でどうなのかというのは、自分はTypeScript を知らないので分からないな。結構苦労するのか、それともそれなりに対処法が確立されているので実際的にはさほど問題にならないのか。

>>126
その「一部分でも同じ構造を持つなら同じ抽象的な型として扱う」は>>124の①②③を満たせば型安全にすることができる
だから本質的な問題は①②③を満たせているかどうか

プリミティブなレベルでの構造的型付けならいいが
そんなものは言語ライブラリレベルでしか成立しなくて
アプリ階層の構造なんてそれこそ流動的で開発終了した後でさえ変更が入るってのにw

>>128
TypeScriptでは構造的型付けの問題点を解決するために安全なプログラムでは名前で区別するようになったよ
ブランディングと呼ばれる手法が用いられていて構造に名前を入れることを必須にしてその名前によって構造を区別してるよ

interface UserId {
__brand: "UserId";
id: number;
}

interface ProductId {
__brand: "ProductId";
id: number;
}

構造的型付けは欠陥品であることが明白になった

同じ構造でも名前が違うなら区別する（②）というときの「名前」が型の名前ならそれは構造的型付けではないし、型安全性みたいな用語をふわっと使うのもどうかと思うけど……。

>>131
型の識別のためだけのダミーな属性を入れるということなので、構造的型付けの理念からは一歩後退ということになるんだろうけど、少なくとも構造的型付けオンリーでやるのはちょっと厳しいというのは共通認識になっているということなんだろうね。

バカの論理やめえやｗ
それはうなぎの血をがぶ飲みしたら体を壊すからうなぎは体に悪いと言ってるようなものだろうがバカがｗ

例えが意味不明

意味不明という言葉を使うやつ例外なくバカです、うなぎでバカが釣れました、リリースします

>>131
それが①②③を満たしているか確認してみると

>>124
＞①構造に名前を付ける

interface UserId と
__brand: "UserId"; で二つも名前がついてるから合格
しかし二重に名前を付けざるを得ない点は辛いところだね

＞②同じ構造でも名前が異なるなら区別する

構造の中に __brand: "UserId"; という名前を持ったことで区別できるようになったので合格

＞③各型やクラスはどの構造を持っているのか名前で宣言する

これは各型やクラスに __brand: "UserId"; を持つことになるのだろうから合格

①②③を満たしているね
interfaceで名前を二重に持たざるを得ない欠点があるから100点はあげられないけれど

構造的型付けの欠陥を対処したら名前的型付けになりました草

柔軟性が失われてて大爆笑

>>131
なんでUserIdやProductIdをinterfaceにするの？
バカなの？

どんな道具でも不適切な使い方をすれば問題が起きるのは当たり前

>>140
例だから知らんけど
UserIdを持つ型は様々あるから共通インタフェースとしてinterfaceにすることはあるだろ

>>121
オブジェクト指については諸説紛々だけと
間違ってないオブジェクト指向なんてものがはたしてあるの？

学校のテストのように正解があると思ってるんだろ
いつまで学生気分でいるんだ

>>140
TypeScriptではそのブランディング手法をインタフェースだけでなくブランド型として実現する方法も行われてるよ

type UserId = number & { __brand: "UserId" };
type ProductId = number & { __brand: "ProductId" };

この方法でも型名と構造のための隠しフィールドで二重に名前を持たせる点は同じ
それ以外も同じで結果的に構造を比較するときに名前を比較することになって名前的型付けになる仕組み
構造的型付けの敗北だね

名前的型付けにもなれるなら構造的型付けの勝ちじゃね？
だって名前的型付けは構造的型付けになれないわけでしょ

名前的型付けではできないことが依然としてできるわけだから名前的型付けになっているわけではないが、いろんなクラスでそういうダミー属性を書かなきゃいけないということになるとちょっとしんどいね。名前的型付けをベースにしつつ、構造的型付けの機能を追加するくらいなのがやっぱり良い塩梅なんかね。

>>145
名前的型付けになっているわけじゃないでしょ。型の識別に使われるのは構造としてのダミー属性の型であって、型名ではないんだから。
というか、名前的型付けと構造的型付けの概念をまだ理解できていないのか……。

>>146
構造的型付けは別の意味なのに同じ構造があちこちに出現して型安全性がない
そのために苦肉の策として隠しフィールドで擬似的に名前的型付けを実現して使っている

>>148
ほうほう、型安全性とはどういう意味ですかな？

名前的型付けは構造的型付けと同じくらい柔軟性があってなおかつ安全ですというのなら名前的型付けが最強ですねと言えるんだけどそうじゃないよね

安全と引き換えに柔軟性を失ってるわけではたしてそれって良いことですかという疑問が残る

>>150
名前的型付けの言語の中でも柔軟性が高いか低いかは分かれる

>>151
だから何だハゲ、しばくぞ

型安全性が何なのか説明しろよ

そんなことも知らんやつおるんかw

>>154
言ってみ、俺が審査員だ

知ったかしてるだけのアホに不合格を突きつけるのが俺の使命だ

AIにも聞いたけど、ざっくりいえば「型付け・型検査をパスすれば、実行時型エラー（型の不整合に起因して意味論に従った操作ができない状態）にならないことが保証されていること」くらいの意味。ちゃんと定義するなら保存性とか進行性とかといった概念が必要みたいよ。

ま、でも、148みたいにふんわりと意味不明な使い方がされていることが多いよね。名前的型付けと構造的型付けの対比で型安全性という観点が出てくるのは正直よくわからんのだが。構造的型付けだから型安全性を欠くとか聞いたことがないけどね。

TypeScriptで隠しフィールドが用いられるようになった理由も構造的型付けが型安全性を欠くため

>>158
で、型安全性とは何かね？ おーん？ｗ

TypeScriptにおけるオブジェクトの型ってのはobject shapeのこと
typeやinterfaceはobject shapeのaliasでしかない
名前的型付け脳はまずここでつまづく

「型安全性」とやらに着目してはいけない
少し引いてみるといつも同じ構造になってる
いつもいつも同じ構造になってる

〇〇凄い→〇〇を備えてる言語凄い→Rust凄い→Rust応援隊の俺も凄い

これやりたいだけだからその子は
みんなも薄々見抜いてて遊んでんだろこれ

Rust凄いがやりたいなら、構造的型付けは型安全性を欠くみたいな意味不明な戯言ではなく、Rustのトレイトのような機能がある言語では、構造的型付けの強みは相対的に価値が低くなるとか、そういった方向性の立論にするのがふつうじゃない？

>>160
というよりも他の言語と違ってJavaScriptのオブジェクトは形は違えど1種類の型しかないことが敗因だよな
TypeScriptでもそれぞれの型注釈をそのまま直接書くかinterfaceやtypeで名前付けするくらいしかできないことが本質だよな

PythonだとJS/TSのプリミティブ相当まで全てがオブジェクト
しかしオブジェクトにきちんと型があって分かれているからJS/TSのような酷い状況になってない

オブジェクトに型の名前を付けて区別する機能が元々のJavaScriptにないんだよ
唯一できる区別が構造による区別だね
TypeScriptは構造的型付けが優れているから選んだのではなく仕方なくそうせざるを得なったに過ぎないんだよ

>>162
Pythonがiteratorを導入する時に後からiterator用の新たなABCを適用できないため
構造的に__next__と__iter__を持つオブジェクトをiteratorにした話も該当することに気付いた
Rustのトレイトはインタフェースや抽象クラスと違って後から新たなトレイトを適用できる柔軟性があるから
そのケースも構造的型付けにしなくて済むね

>>163
誰がどう見ても複おじのオツムが最大の敗因

あたまの悪さなのか
こころの病気なのか
いずれにせよ
気の毒なもんですよ

>>166
クラス継承がないから柔軟に適用できる
クラス継承が悪い

オブジェクト指向プログラミングに不要なクラスの継承を付けてしまったことはJavaの生みの親も後悔してた

名前的型付けで(型にしろインターフェイスにしろ)継承以外で互換性を指示する方法はないんじゃないんかな。
構造的型付けをサポートすれば解決するけど。

>>170
お前はそれを知ってどう思った？

昔は
・Interfaceを作る
・Interfaceを実装するAbstract Classを作る
・Abstract Classを継承してClassを作る
というのが一連の流れじゃったなあ
Abstract Classを挟むのはInterfaceのメソッドをClassごとに実装するのが大変だったから
いまは簡単になったんかいの？

現代のオブジェクト指向プログラミング
・クラス継承は使わない
・共通の変数(群)がある時はそれを独立させて合成して委譲する
・他に共通のメソッドがある時は共通インタフェースを作ってそれを実装する

…簡単に…なったの…？

>>175
逆

何を簡単と呼ぶかの差かな～
クラス継承をしていくと密結合にデブって複雑なモノリシックになるから
最近は簡単に分けてクラス継承を使わずに合成しましょうって感じ

>>171
名前的型付けと構造的型付けで違いが出るのはサブタイピング多相の文脈だけじゃない？　テンプレートなどのパラメトリック多相とか、Rustのトレイト（アドホック多相の一種？）とかは、特に両者の対比とは関係ないと思う。

クラス継承はほんと害悪だが
人にもコンピュータにも

分散パイプラインという現実の工場と同じ流れになった
それ以外は些末
ベルトコンベアを詰まらせないことが至上命題

>>173
Beansっていつから言われなくなったのか

>>178
もちろんそんなことはない

>>178
型の同一性に関する話だからサブタイピングだけじゃないよ。

型の別名みたいに対称律が成り立つかどうかは大きく違うところ。

WindowsのGUIパーツが継承だらけなんだが

隠し名前フィールドまで設けて構造的型付けを使う必要性がないもんな
メリットなし

>>181
Java BeansはGUIアプリの技術だからな
GUIアプリがWebアプリで代替されるようになって
GUIコンポネント自体が廃れたのよね
Java Beansは20年前に死にました

Windowsを作ってるMicrosoftでさえ
WindowsのGUIよりもWebアプリを選んで
VSCode作ってるくらいだからな

ちなみにVSCode作ったのはオブジェクト指向のデザインパターンを考えた
GoFの一人エリック・ガンマ

もう自分じゃ書かないからどんなに記述がめんどくても実行パフォーマンスで最適なら構わん
AIにとって管理しやすいわけわからん言語になるんだろうなあ

道具にはそれぞれに適した用途と使い方があるにも関わらず
不適切な用途に使ったり不適切な使い方をしたりして
不都合な結果が出るとこの道具は使えないなどという結論を出す

もちろん本当に使えないのは道具ではなくて複おじのオツムです

AIにRustで書かせる例がどんどん増えてるね
メモリ消費が少なく速くて安全な言語が一番いいみたい

俺もRUSTにしてる、自分で見たくならないから

>>183
同一性の判断基準が異なるというのはもちろんだけど、>>171で話題にされているのが型の互換性だったからね。
型の別名というのが型エイリアス（処理系によって同視される型）のことなら名前的型付けと構造的型付けとで違いはないでしょう。ニュータイプ型の別名ならたしかに違いが出てくるけど、それは構造的型付けの方は余計に一手間掛かるという方向の違いだよね。
いずれにせよ名前的型付けにおいて、型の互換性を指示する方法として継承以外のものがあるという点は変わらないと思うけど。
個人的には名前的型付けの型システムに構造的型付けの機能を追加することについては、比較的好意的に捉えているけどね。Rustみたいな言語だとあまり必要性はないのかもしれないけれど、Pythonとかではかなりありがたい。

>>191
＞型の別名～～名前的型付けと構造的型付けとで違いはないでしょう。

ちょっと脱線してるけど、
(名前的型付け)名前で宣言しないと等価(置換可能)にならない
(構造的型付け)宣言しなくても構造が一緒なら等価(置換可能)
の違いがあるよ。

異なる名前を使っているのなら、
名前的型付けの場合は(名前の等価性を宣言しないと)別物。
構造的型付けの場合は名前ではなく構造を見るから等価性を宣言する必要が無い。

>>190
>自分で見たくならないから
そういうの大事よね

>>192
>>191で「名前的型付けと構造的型付けとで違いはない」と書いたのは、>>183の対称律の話ね。たしかにそこはちょっと言葉足らずだったかも。
192の内容は別に間違っていないけど、それは型システムの枠組みにおいては、結局サブタイピングの話でしょ。一般的な型システムにおいて、すべての型は自分自身の部分型（サブタイプ）なわけだから。プログラミング言語の構文としては通常区別されているから、別の話だとするのが間違いというつもりはないけどね。

> 娘の足が13.5になったから洗ってしまおうとして

ここから急激に難しくなるよな…

誤爆しましたごめんなさい
ついでと言ってはなんですが解読お願いします
i.imgur.com/rt3L9BV.jpeg

>>191
それはPythonにインターフェースを後付けできないから困っただけで名前的か構造的かは関係ないと思うんだよね
Rustのように後から新たなインターフェースをプリミティブ型に対しても実装できれば十分だよね
その件でも構造的型付けは不要だよ

// Rustはtraitがインタフェース相当
trait Hello {
fn hello(&self);
}

// 既存の数値型i32にHelloを実装
impl Hello for i32 {
fn hello(&self) {
println!("Hello! {self}");
}
}

// 既存の文字列型strにHelloを実装
impl Hello for str {
fn hello(&self) {
println!("Hello! {self}");
}
}

fn main() {
123.hello();
"abc".hello();
}

// 実行結果
// Hello! 123
// Hello! abc

構造的型付けはビルド時に勝手にコンパイラが適応出来る場合にやってくれればいいだけで
マは名前的で全部やってればいいんだよ

>>197
その例だとRustはもっと楽ができるぜ
実装コードがどれも同じなのでジェネリックにこれだけだ

impl<T: std::fmt::Display> Hello for T {
fn hello(&self) {
println!("Hello! {self}");
}
}

ちなみにprintは表示が可能な型が来ないと静的にエラーにしてくれる
それゆえ表示が可能な型＝Displayトレイト境界を与えてる

>>191
>いずれにせよ名前的型付けにおいて、型の互換性を指示する方法として継承以外のものがある
ある？
例えば？

>>197
Rustのトレイトのような機能があれば構造的型付けの強みはほとんどカバーできるという点は別に反対しないが、「名前的か構造的かは関係ない」というのは>>191のどの内容に対するコメントなのかよく分からないな。

>>200
>>176でテンプレートとかRustのトレイトとか挙げてるやん。

176じゃない、>>178だわ。

>>200
横からだが継承の定義がよくわからん
Rustだとその「型の互換性を指示する方法」は>>199のトレイト境界だよな

>>194
部分型は基本的に反対称律を持つから同値関係じゃなくて(半)順序関係だよ。

「Ｌ１はＵの別名、Ｌ２はＵの別名」としたとき、Ｌ１とＬ２は同じＵだから置換できるけど、
「Ｌ１はＵの部分型、Ｌ２はＵの部分型」としたとき、Ｌ１とＬ２は同じかどうかわからないから(Ｌ１、Ｌ２として)置換できるかもしれないしできないかもしれない。

>>171がどういう意味で継承を使ったのかは本人に聞いてみないと分からないが、自分は「型システム上の部分型関係を作ることを目的とした構文」くらいの意味で使っているけど。
構造的型付けの主な強みは、明示的な継承構文を使わなくても部分型関係が作れるところにあって、明示的な継承構文を使わないと部分型関係が作れない言語では構造的型付けの機能があると重宝する。ただ、Rustのトレイトみたいな機能がある場合は、既存の型に手を加えずに互換性のある型を定義するという同じことができるので、構造的型付けの強みは大幅に減殺される……というイメージ。

>>204
部分型関係が半順序関係であることを否定しているつもりは別にないのだけれど。対称律というのは183の関心点がそこにあるようだったから言及しただけで。
「名前的型付けで部分型関係を作るには継承等の明示的な宣言が必要、構造的型付けで部分型関係を作るにはそういう明示的な宣言は必ずしも必要ない」という基本理解の枠組みの中に>>192も位置付けることができるねというのが>>194の趣旨だけど、何かおかしい？

Pythonで開発している人たちによるPythonのProtocolについての説明記事を見ると
仕様を勧めないとか積極的に使わないと書かれてる
理由は構造的型付けだから

具体的にはProtocol名を用いて定義しないため分かりにくい可読性が低い保守性が低い
構造的に同じものが他にあると混乱する誤作動する安全でない
メリットよりデメリットの方が上回る

可読性ｗ
保守性ｗ

童貞が女の口説き方教えてくれとるわｗ

構造的型付けはProtocol名を用いて記述しなくても指定の構造さえ記述すれば済むというメリットがある！
と言いたいところだがそれを上回るデメリットを引き連れてしまうよな
構造的型付けを採用する言語が少ないのも仕方ないか

>>207
Protocolは実行時にメソッドがなくてエラーになってたのを
型チェッカーで実行前に洗い出せるようになるよってものなので
君が言うところの型安全ｗにはなると思うけどねえ
大きなメリットじゃないか

>>209
TypeScriptもPythonも動的型付けによるダックタイピングとの相性を考えて構造的型付けを採用してるわけ
少なくともTypeScriptやPythonではメリットの方が大きいと判断されてるというのは理解しようよ

>>205
継承についてはちょっと違って、
名前的型付けで上位型−部分型の関係を構成する方法
ということで「名前的型付け」がポイント。
構造的型付けの強みは表記の話もあるけど、それよりも「実際に部分型にするまで部分型を用意する必要がない」という設計上の柔軟性。

Rustは使ってないので間違えているかもしれないけど、拡張トレイトやジェネリックは動的多態できないし、トレイトオブジェクトはスーパートレイトを取り込む必要があるので「大幅に減殺される」という感じは無いなぁ。

Qiitaのこの記事？　「Pythonのtyping.ProtocolとABCの違いと実務的な考察」（https://qiita.com/sagong_ryung/items/140cc8ea35157fd184f5）
個人の見解みたいだけど、「人たち」による別の記事もあるのかな？
ちなみに、『ロバストPython』という本の13章（といっても10ページ程度）にProtocolについて分かりやすい説明がある。公式リファレンス以外の解説としては、個人的にはこちらの方を勧めたいかな。

自分は正直、上記のQiita記事があまり説得的とは感じないけど（もっとも、外部ライブラリや既存コードで使うのが良いとする点は妥当だろう）、個人の感想はいろいろだからね。推奨しないという人も居るんでしょう。

静的型付け言語にはメリットがないという主張なのね

>>212
貴方が動的多態の意味を勘違いしている

>>215
具体的には？

>>201
>テンプレートとかRustのトレイトとか挙げてるやん。
その2つはどっちも反例になってないでしょ
テンプレートは名前的型付けじゃないしRustのトレイトはインターフェース継承と同じで定義を継承してる

>>212
>>拡張トレイトやジェネリックは動的多態できないし、

Rustは拡張トレイトも静的ディスパッチと動的ディスパッチの両方できる
ジェネリックはC++でもRustでも静的ディスパッチで単相化するための文法
Rustではジェネリックにせずとも可能
普通の関数で静的ディスパッチと動的ディスパッチそれぞれを選んでどちらも使える
そんな至れり尽くせりの言語は他にないでしょう

>>トレイトオブジェクトはスーパートレイトを取り込む必要がある

Rustはスーパートレイトも含めてどれだけ大量のトレイトを指定しても静的に一つのvtableに取り込むことができるため柔軟性があるとともに動的ディスパッチが最も速い、が正解
これができない言語は複数のvtableを動的に見ていくことになって遅い

Rubyをdisるのはよせ

>>217
継承という語は、一般に部分型関係を作ることを目的とする構文という意味で使われるが、Rustのトレイトは部分型関係を作るものではない。一般的にもRustのトレイトが継承であるとは説明されない。
C/C++のテンプレートやPythonのプロトコルなんかを一種の構造的な型として観念する考え方は個人的には結構好きだが、言語仕様としての型（これらの言語において通常の意味での型とされる名前付きの型）と同様の扱いがされるわけではない。テンプレートが構造的型付け「に近い」とか、構造的型付け「的」とか、「一種の」構造的型付けといった、ちょっと含みのある表現で説明されることが多いのはなぜかを考えてみるとよい。

大体、そんなオレオレ定義・解釈を前提に「名前的型付けには型の互換性を指定する方法が継承しかない。だから、構造的型付けの方が優れている」とやっても誰も聞いてくれないでしょ。名前的型付けと構造的型付けの比較の文脈で、「テンプレートは構造的型付けだから構造的型付けの方が優れている」と主張することがどれだけ無意味か考えてみたら分かりそうなものだが。そんなことをしなくても構造的型付けには一定の価値は認められているよ。

オブジェクト指向で抽象メソッド/仮想メソッドを使うと便利でわかりやすくなるけど
実行が遅くなるため面倒でわかりにくい方法を選ぶ
という本末転倒な言語が存在する現実があるもんな
便利かつ速いの両立は重要

>>220
その通り
2種類の構造的型付けの用法がそこでなされていることに注目
1つ目は本来の構造的型付けで
「構造的に同じオブジェクトが同じ型とみなされ動く」
2つ目は構造的型付けではなく
「『あるメソッド』または『あるフィールド変数』が使われている関数では、それらを持つオブジェクトが動き、持たないオブジェクトはエラー」
ようするにダックタイピングであり構造的型付けとは明白に異なる

小さなプログラムではダックタイピングもお手軽で良いものだ
しかし大きなプログラムでは足を引っ張る存在になる
通過条件を名前で明瞭に指定できる方が好ましい

単純な例
関数fを通過できるxはhello()とbye()を持っていなければならないとすぐにわかるが
これがもっと大量に多段に複雑になると見通せなくなる
function f(x) {
f1(x)
f2(x)
}
function f1(x) {
x.hello()
}
function f2(x) {
x.bye()
}

fなんて名前つけてるからわかりにくいだけ

>>218
拡張トレイトって、
異なる複数のトレイトをあるトレイトTと同じになるように拡張トレイトで調整して、それら複数のトレイトを同じLIST<T>にトレイトオブジェクト無しに突っ込むとかできたっけ？

あとスーパートレイト～～は実行効率じゃなくて設計時の柔軟性(設計効率)の話だから、vtable云々はあんまり関係ないよ。

>>220
意図は>212の「設計の柔軟性」だから、上位型を早期に確定しないで後付けで部分型を使う反例があればぜひ。
普通はアダプタパターンだけど、言語レベルでサポートしてるの見たことないんだよね。

>>225
何に対する反例なのか、話の流れが見えないんだが。
名前的型付けにおいて、型の互換性を指示する方法として継承以外のものがあるか否か（>>171）という話だぞ。

>>220
テンプレートが名前的型付けじゃないことはわかったみたいだね

>Rustのトレイトは部分型関係を作るものではない
Rustのトレイトは部分型関係を作るためのものだよ
というかそのために存在してる
impl MyTrait For MyStructという宣言は
MyStructという型とimpl MyTrait/dyn MyTraitという型との部分型関係を作るもの

>だから、構造的型付けの方が優れている
これは曲解だね
俺はそんなこと全く思ってない
それぞれの特徴を理解して使い分ければいいだけ
最初に継承しかないと書いた人の意図は知らんけど

>>226
おっと、勘違いか。
無視してちょうだい。

>>225
拡張トレイトがExtention Traitの日本語訳ということなら
既存の構造体を拡張するのに新しくMyTraitを定義して
impl MyTrait for ForeignStructとすることで
ForeignStructに新しいメソッドを生やす手法のこと

>>227
C++のテンプレートは、それ自体としては名前的型付けでも構造的型付けでもないぞ。テンプレートによって観念される構造的な型を言語仕様上の型（C++における通常の型）と見てよいなら構造的型付けといってもよいが、C++の仕様はそうなっていない。
Rustのトレイトは部分型関係を作るというオレオレ定義がやりたいならどうぞご自由に。検索するなりAIに聞くなりして、Rustのトレイトは継承か、部分型関係を作るか、サブタイピング多相の一種かと聞いてみたらよいのに。

>>222
これぞ複オジメソッド！

>>220の二段目は普通のオツムをもってたら理解ができる文脈なんだが
>>227「これは曲解だね」と答えてるところからなんか可哀そうなものを感じる

オレオレ解釈を前提にしても誰も話きいてくれないよ？
逆に考えてみて？
こうだったらこうでしょ？
こうだったらこうでしょ？

↑この構造が理解できてないのは怖い
ひょっとしたら日本人じゃないのかもしれないねあの子は

具体的に>>197のtrait Helloの例を考えてみると
i32型はHelloの部分型になったと解釈することは可能で
str型もHelloの部分型になったと解釈することは可能であるが
問題はHelloを定義もしくはuse パス::Hello;したモジュール空間でしか部分型の関係が有効でないという点だ
つまりi32型が本質的にHelloの部分型になったとは言えない
このようにRustのtraitは柔軟性が高くて従来の枠組みで解釈しにくい

「Rustのトレイトは部分型関係を作るためのものだよ
というかそのために存在してる」

複クン語録がまたひとつ増えたな

>>234
Rustのトレイトを実装するとその型はそのトレイトの部分型関係になるのは事実
ただし有効範囲がそのトレイトの利用を宣言した範囲のみ
だからどちらも正しい
「本質的に部分型になったわけではない」
「その空間では部分型になっている」

つまりRustは既存のコードに全く影響を与えることなく
自分の空間内で新たな抽象型(trait)を導入して既存の型をその部分型にすることが可能
という柔軟性を持っていることになる

crate A の trait を
crate B の struct に
実装したいんだが

>>237
それは既存コードに影響を与えるから直接の実装は禁止されている
ラッピングして自分の型にして実装できる

自由度を失ってる

自由度ってなんだ？
何が失われている？

拡張メソッドはオブジェクト指向なのか？

>>197の例は既存のi32型のオブジェクトとstr型のオブジェクトが共にHelloという抽象型オブジェクトとしても扱えるようになった
オブジェクト指向プログラミングの利点の一つであるコードの共通化が可能になった

例えば抽象型Helloを受け付ける関数
fn hello_twice(x: impl Hello) {
x.hello();
x.hello();
}

共通してi32型もstr型もどちらも使える
hello_twice(123);
hello_twice("abc");

>>241
メソッドがすでにオブジェクト指向

>>242
HelloにFrom<i32>とFrom<&str>と
i32にInto<Hello>と
&strにInto<Hello>も実装するんやで

そんな悪手教えんなよ

>>243
メソッドと拡張メソッドは違うでしょうに
拡張メソッドはオブジェクト指向として邪道なのでは？

>>246
拡張メソッド ⊆ メソッド

なぜオブジェクト指向としては邪道だと思うの？

やっぱClassなど使わん方がすっきり書けるな

use v5.38;

package Hello {
　sub new ($class, $x) { bless \$x, $class }
　sub hello_twice ($self) { say "Hello! $$self" }
}

Hello->new(123)->hello_twice;
Hello->new('abc')->hello_twice;

use v5.38;
sub Hello ($x) {
　sub { say "Hellow! $x" }
}
Hello(123)->();
Hello("abc")->();

意図が全く伝わってなくて芝生える

うん、書いてて俺もそう思った

hello_twice()は2回helloだよ

>>244
そのHelloは抽象型
From/Intoは具象型同士の変換だよ
ではどうすればよいか？
二つの方法があります

一つ目は既に>>242に出ているimpl Helloで受け取る方法
fn hello_twice(x: impl Hello) {
x.hello();
x.hello();
}
これは単相化されて静的ディスパッチつまり普通の関数呼び出しになる
そのためインライン化などの最適化も行なえるから最も有利だね

呼び出す側は既に出ているようにそのまま渡せる
hello_twice(123);
hello_twice("abc");
これは値をそのまま渡しているけど
受け取り側をx: &impl Helloにすることで参照を渡すこともできるよ

もう一つの方法は&dyn Helloで受け取る方法
fn hello_twice2(x: &dyn Hello) {
x.hello();
x.hello();
}
これは動的ディスパッチになる
dynはもちろん動的の略
>>254の単相化とは異なりこの関数の実体が一つになることがメリット

呼び出しは引数のサイズを揃えないといけないから参照で渡す
hello_twice2(&123);
hello_twice2(&"abc");
そのため受け取り側も&が付いてx: &dyn Helloになってるよ

しかし動的ディスパッチは実行時にvtableを引くため遅いうえに
インライン最適化ができないためかなり遅い
それでもdyn Helloにしかできない魅力もある分かるよね

やりたいことに対して一番パーフォーマンスが出るものでやればよい
再利用なんてする必要もなくなった

動的ディスパッチのdyn Helloを使うのは実行時ガチャな時だな
どの具体型が返ってくるかわからないガチャ関数やガチャ式
あとはベクタ等へ混在して突っ込んで要素が実行時ガチャになる時
焦点はそこじゃなくてほとんどのプログラミング言語は抽象型の抽象メソッドが動的ディスパッチになって遅くなることだろ
一方でRustはガチャでなければdyn Helloをimpl Helloに変えるだけで静的ディスパッチになってインライン最適化も起きて劇的に速くなる

仮想メソッドは動的ディスパッチになって遅くなるから使うな！
という本末転倒の流儀まであるから草生える

これ>>256
人間が小さなワーキングメモリで考えやすく書きやすいように
人工的に小さく区切って部品化する必要がなくなってる

しかしAIなら多少区切りを大きく出来るとは言え完全になくすことは出来ないけど

>>256
パーフォーマンスが出る静的ディスパッチを選べない言語では、パーフォーマンスを断念するか、オブジェクト指向による抽象化を断念するかの二者択一になることがある

>>256
再利用ではなくて抽象型オブジェクトによるコードの共通化が必須
コードの読みやすさやメンテのしやすさがまるで違ってくる

C++はテンプレート使えば単相化静的ディスパッチになるけど
抽象型名を伴わない静的ダックタイピングな点や仮想関数による動的ディスパッチの時とコードが全く違ってくる点が残念だよな
Rustはトレイトの仮想関数そのまま静的ディスパッチと動的ディスパッチを簡単に切り替えられる点が大きい

何言ってるのかよく分からない
#include <concepts>
void hello_twice(std::derived_from<Hello> auto* x) {
x->hello();
x->hello();
}
でstd::derived_from<T, Hello>な型Tがfinalなら静的ディスパッチ、じゃなければ動的

動的ディスパッチが許されるのはメモリにメッセージをキューするときだけ
xをそれぞれのhellohelloのキューバッファにプッシュするときだけだ

上の例で言えばfinal以外は害悪
つまり継承は害悪

>>263
finalでなければ動的ディスパッチされる点でC++は敗北している
Rustとの違いが分かったかい？

そもそも既存のプリミティブ型を
>>197のように自分で作ったHello抽象型に属させることが出来ない言語と出来る言語があるような気がする

>>248は面白いぞ
数値型や文字列型をHelloの子供にする話なのにフィールドに入れてる

>>268
どうして数値をhelloの子どもにするんです？
オブジェクト指向ではないと思います

拡張メソッドは拡張にメソッドが生えてるだけでオブジェクトメソッドではない、オブジェクト指向において拡張メソッドは絶対悪

スタティックメソッドもオブジェクト指向ではない

オブジェクト指向の目的はカプセル化とコードの共通化
後者は異なる型に対して同じメソッド名で共通に呼べる多相性により実現される

具体的には例えば異なる具象型Aと具象型Bを一つの抽象型Xに所属させることで共通のメソッドを使えるようにする
これによりコードの共通化が実現される

抽象型Xの実現方法は各プログラミング言語それぞれの方法で構わない
たとえばクラスを用いる場合やインターフェースを用いる場合など各言語に適した方法が使われる

>>274
何も知らないなら何も言わないほうが良いぞ
馬鹿がバレるから

AとB二つの別々の型のオブジェクトに共通のコードを書く時
両オブジェクトを受け付ける抽象型を使ってコードを書いてるね

>>275
プログラミング言語は色んなのかあってピンキリだから各言語に適したやり方を許容するしかないんじゃない

うちはABCで抽象型を作ります

>>275
抽象型はclassよりinterfaceを使った方が好ましいだろうけどclassしかない言語もあるんだよ

プロトタイプしかない
後からclass表記も使えるようになったけど糖衣構文にすぎないため仕組みが違う

抽象化は自然言語の曖昧さが必要
実装言語にはいらない

同じaddが、時には要素の追加、時には文字列の接続、時には算術的な加算
てんでバラバラな結果になるんだが
そんなのが抽象化と言うのだろうか？

関数型の弊害なのかねぇ
メソッドレベルの会話だけってのは…

昔から解釈違いで変な設計して公開しちゃったりする人は一定数おるしな

>>282
加法を射とするモノイド（あるいはモノイドに見立てることができるもの）ですから。

まぁた圏論かよ

プログラム言語で本を書くやつはいない
つまり人間には自然言語が一番理解しやすい
自然言語で抽象化すればよい

例のアレをイイ感じで仕上げておけよ

>>286
せっかく抽象化してもプログラミング言語によっては制限がキツくてその抽象化を実現できないとか制限で抽象化が捻じ曲げられてしまうとか

言わなくてもわかってるよな？
ちゃんとやっとけ

阿吽な。

一昨日の簡単な抽象化の例
①抽象メソッドhelloを持つ抽象型Helloを作る
②数値型と文字列型を抽象型Helloへ入れる
③抽象型Helloのみ受け付けてhelloを2回実行する関数hello_twiceを作る
④数値と文字列を混在した抽象型Helloの配列を作る

こんな簡単な例すらperlの人のコードは>>248になってしまった
プログラミング言語が柔軟に対応できないと難しいのではないか

プログラミング言語の柔軟性が必要なことの説明になってないやんけ
数値型と文字列型はHelloではありません
そういうわけのわからんことして悦に入るからオブジェクト指向は嫌われます
いいかげんにしてください

Perlは古い言語だからしかたない
Javaより古いんだぜ

オブジェクト指向はもっと素朴であるべきだ
Plain Object Oriented Programming
これからのオブジェクト指向はPOOP

Perlがリリースされたの1987年だってよお前らまだ精子にもなってないんじゃね？

>>292
あなたはオブジェクト指向の単純な抽象型Helloすら実現できないのですか？
プログラマー失格ですね

>>296
できないですよ
私を貶めてもオブジェクト指向が良くなるわけじゃないですし
あなたの頭が良くなるわけでもないですよ
いつまで子どものようなこと言ってるんですか

オブジェクト指向をマウンティングの道具に使ってるようじゃダメだよね

怒り狂ってるからな、謝罪するならいまのうちだぞ
なんと謝罪すれば良いかは言わなくてもわかるな？
頭がバグっててあんなにオブジェクト指向でごめんなさい
この言葉を私は待っています

> プログラマー失格ですね

絶対に許さないからな

オブジェクト指向プログラミング苦手なプログラマや理解できないプログラマもいるんだよ
連投してる人はそのタイプ

>>301
あ、そうやって客観視して逃げようとしてもダメよ
俺はブチギレてるから、人を怒らせるってそういうことだからね

自分は人を怒らせるようなことしたんだと自覚して謝罪しないとダメよ
誤魔化したりして逃げようとするのは三歳児くらいの幼児にはよく
見られる傾向なんだけど大人なんだからちゃんと謝れるよね

> プログラマー失格ですね

こういうこと言ったらダメだよね
これはダメだよ、あー、5chで一線超えて来たなと思ったよ

>>291
�@抽象メソッドhelloを持つ抽象型Helloを作るw
�A数値型と文字列型を抽象型Helloへ入れるww
�B抽象型Helloのみ受け付けてhelloを2回実行する関数hello_twiceを作るwww
�C数値と文字列を混在した抽象型Helloの配列を作るwwwww

いつもながら複おじは反面教師としてならめちゃくちゃ優秀

ようはデザインパターンを実装できるかどうかだろ

抽象という言葉を都合よく勝手に濫用し過ぎ

継承元の既定を抽象と言い始めたことがそもそもの間違いの元か

複数ライブラリを使ったりテスト用モックと入れ替えたりする時は共通の抽象型を用意して使うのが必須だな
依存性逆転の原則

人間は自然言語で考えて自然言語で表現すれば良い
それ以外のことはやる必要ないよ
もう自然言語でやりたいことは表現できてるんだから
アーキテクチャやスケールに合わせるの人間がやる必要はない

>>308
昔から日本でも世界でも抽象型(abstract type)と呼ばれているよ
異なる具象型(concrete type)に対して共通の機能を提供するのが抽象型

>>249 の亜種だけど
上のレスをろくに縦読みもせずまた書いちゃうと

use v5.38;
package Hello {
sub hello($self) { say "Hello! $$self" }
}

my $i = 123;
bless(\$i, 'Hello')->hello();
my $s = 'abc';
bless(\$s, 'Hello')->hello();

つか、そうしたら回りくどいぜい肉そぎ落として

use v5.38;
sub hello($self) { say "Hello! $self" }
hello(123);
hello('abc');

でいいジャンって思っちゃう俺ガイル

>>313
Helloという抽象型を関数の引数型や戻り型で使えないと本末転倒じゃけ

>>314
ほう、型自身をか。
しかし何のためにだろう
Perlだと’Hello’とう文字列がPackage名（≒Class名≒構造型名）そのものなので
引数や戻り値に引き回して、変数を点かいときに所属させればそういうこともできるが…
上記の例だとありがたみが感じないというか
回りくどいだけの記述になっちまいそう

>>315
変数を点かいとき
↓
変数を使うとき

だから、そんなHelloメソッド実際使い道無いだろって話だわ

use v5.38;
package Hello {
sub hello($self) { say "Hello! $$self" }
}
sub f($class, $x) {
bless(\$x, $class)->hello();
}
f('Hello', 123);
f('Hello', 'abc');

※上にある多くのレス応酬はほとんど見ずに書いてます

>>317
それを言っちゃーお仕舞よ
オブジェクト指向もデザパタも

>>317
単なる例だろ
メソッド関数自体の存在を否定するならともかく

こんな意味の無いクラスメソッドがあるものか
だいたいクラスで扱うデータタイプは決まるんだから
メソッドが複数のデータタイプに違う振る舞いをする実装なんてナンセンスだろ

>>321
決まってるのは結果論
共通に使うために追加は必ず起こる

現実には機能追加更新があるからね
メソッド追加は日常茶飯時だよ

>>321
interface使ったことないの？
異なる型に同じメソッド名で異なる実装をするために使う

>>324
デバッグ用のスタブ作る以外はこんな事しない
最初から実装するからな

>>325
システムに機能追加の案件はよくあるよ

>>326
そんなつまらない案件なんかした事無いし
ベースから追加修正出来る環境だからなぁ

>>325
将来を全て見通せる神じゃないんだから最初から全て実装は難しいでしょ

俺としては、できると必要は別だと思うがな

なんのためにツギハギするのか分からないw

柔軟に対応できる人とできない人
柔軟に対応できる言語とできない言語
色々あるんですよ
できない人は言い訳する

柔軟に対応したつもりがクラス構成が複雑になってしまうだけw

>>332
新たなクラスを増やす話は出てきてないように見えるけど

インターフェースもクラスなんだがそこに新たなメソッド持ってれば複雑な関係になるよな？

>>334
インターフェースとクラスを同一視するおバカさんはあんただけや

>>332
final classだけを使えば複雑にならない
そこへinterfaceをいくつ実装しても複雑になることはなく他へ影響を与えない

このスレいつも同じ結論ね
クラス継承は害悪

クラス継承は密結合で雁字搦めに複雑化させる張本人だよ

>>327
これが全てだよ
視野が狭い

>>339
そいつの書き込み>>334見てみろ
インターフェースもクラスだと言ってる何も分かってない人

interfaceとclassは異なりますが、どちらも集合論的なクラスとして機能します（させます）。
その意味においてinterfaceとclassはどちらも、（わたしは）クラスとして認識しております。
interfaceを（classで）実装せずに使うことが多いですね。（個人的感想です）

interfaceってほぼ抽象classをリネームした物じゃねえの？
巨大なclassを作る時ある程度のサイズの機能ブロックに切り分けて作りやすく保守しやすくするんだと思ったんだが。

interfaceは変数を持たない点で全く異なる
そのため多数のinterfaceを実装しても問題は起きない
classと似ている点は1つもない

巨大なclassを作るのは初心者

interfaceは異なる型に共通のインターフェースを持たせるためにある
それはコードの共通化を可能にする
interfaceを実装する型の一つとしてクラスがあるかないか程度の関係しかない

classを持たないプログラミング言語でもinterface相当を持つことが多いからinterfaceの方が本質的に必要な機能なんだろうね

コードの共通化を金科玉条のように血道をあげて手段が目的化し
コードをややこしくるる愚か者
↓

内部隠蔽とかコードの共通化とかオブジェクト指向プログラミングの目的やさか

なるほど、そもそも目的が不適切だったんだな
それにみんなコロッとだまされてオレオレオブジェクト指向の妄想爆発させてたのが
あれ？なんか変だな　←いまここ

>>346
アセンブラでもサブルーチンエントリーアドレスのテーブルをインターフェースとして共通処理から個別処理を呼び出すってやってたから伝統芸だぞ。
たいていのCPUで割り込みベクタテーブルとして専用命令が用意されてるレベルだ。

その程度とプログラミング言語のinterfaceは千差万別や

共通化にやっきになって継ぎ足し継ぎ足しで老舗旅館の別館みたいにするなw

オブジェクト指向の目的をコードの共通化と定式化すること自体に問題がある。オブジェクト指向はコードベースを整理しやすい形でモジュール化する手法の一つであって、結果としてコードの共通化になることは多いが、コードの共通化それ自体を一次的な目的としているわけではない。
コードの共通化をオブジェクト指向の目的として強調するのは、ひと昔ふた昔前に流行った、継承と多相性がオブジェクト指向の本質であるという考え方そのものでしょ。このスレには、クラスをインターフェイスに差し替えた上でなら、継承と多相性がオブジェクト指向の本質であるという考え方を維持できると考えている手合いが居るが、「継承より合成」等の標語で批判対象にされている継承にはインターフェイスの継承・実装も含まれているという認識が不足している。インターフェイスを作ってサブタイピング多相をやっておけば万事解決というような単純な問題ではない。

>>353
実装継承と型継承(シグネチャ継承)の区別もつけずに継承を語っているアホがいる
性質がまるで異なるこの二つを区別することから始まったのも知らずに

>>353
「継承より合成」はクラス継承のみを批判しているよ
「『親クラスを継承した』自分のクラス」ではなく「親クラス」＋「自分のクラス」の合成にして親クラスの実装へ委譲しましょうという話
なぜインターフェースは無関係なのかというと「親インターフェース」はインスタンスを持てないから合成できないしそこへ委譲もできないからだよ

>>355
もちろんクラス継承のみじゃないよ
実装継承が対象なので実装が含まれるインターフェース継承なんかも対象だよ

>>354-355
クラスであれインターフェイスであれ、サブタイピングによる多相性を利用する場合には、部分型は上位型の不変条件のすべてを常に遵守する必要がある。型レベルの互換性だけでなく、振る舞いレベルでの互換性（要するにリフコフの置換原則）を厳密に維持・遵守しなければならない。
インターフェイスを使えば遵守しなければならない不変条件を減らせるので、サブタイピングによる多相性を利用する場合にはインターフェイスを使う方が良いとはいえるが、それはあくまでもサブタイピング多相性を利用する場合という前提条件下でのベターな手法ということに過ぎない。サブタイピング多相性の上記のような意味論的制約を本質的に免れることができるわけではないということね。

>>356 >>357
インターフェイスは「継承より合成＆委譲」の対象ではない
具象型ではないので合成も委譲も不可能
もし理解できないのなら自分でコードを書けば不可能なことに気づくだろう

インターフェイスでもdefault methodで実装の継承はできるからなあ
クラス継承がダメじゃなくて実装の継承がダメといわないとダメなのでは!?

>>359
インターフェイスがdefault methodを持っても「継承より合成＆委譲」の対象ではない
具象型ではないのでそもそも合成することができない
ダメなのは具象型のクラス継承だけ

>>360
前スレか前々スレで脆い基底クラス問題はRustでも起きるよねって言われてたじゃん、忘れたの？

「継承より合成」という標語における「継承」はクラス継承のみを指してインターフェイス継承は含まないという捉え方もたしかにあるようで、その意味で>>353でインターフェイスの継承・実装も含まれているという解釈が唯一のものであるかのように述べたのはやや語弊があったかもしれない。
ただ、「継承より合成」という標語は、現在は357で述べたようなサブタイピング多相に伴う負担（要するにリスコフの置換原則を常に気にしていなければならないのは負担が重すぎる）という文脈で使われることが多い。「クラス継承は問題が多いけどインターフェイス継承なら何の問題もない」というこのスレでしばしば見かける論調に違和感があるのはそこで、インターフェイスの継承・実装というのはサブタイピング多相に伴う負担を相対的に軽減するための一種の手法に過ぎないのに、クラス継承と本質的に異なるものであるかのように有り難がっているのは変だろうと。言ってみれば、C++における一種のデザインパターン（抽象クラスパターン）をJavaとかで言語機能に昇格させただけよ。

>>357
サブタイピングを型で保証するのはCoqのような証明支援システムを使えばできるんかね
大変そうだけどね

>>355
>「継承より合成」はクラス継承のみを批判しているよ
あれだけ丁寧に書いてもこういう間違った理解をするやつが多すぎたからGoFはあの本のアップデートは諦めたって言ってたな

>>361
Rustにクラスはないはず
そういう言語は必然的に合成＆委譲の書き方になる

>>365
バカなのかお前はｗ Rustのトレイトでクラスの継承で起きる問題が起きるよねって話してただろ
本当に覚えてないのか？ ダチョウなみの記憶力だな

>>362
クラス継承を禁止して合成＆委譲にすることを勧めている標語だ
インターフェイス継承を禁止して合成＆委譲にすることは不可能だと気付け

複製おじさんが同じことを言い続けるのって新しいことを記憶することができないからなのかな？
そういう病気あるよね

意味の無い煽りばかりの人がw

>>364
「継承より合成」はクラス継承のみ批判されている
インターフェイスを合成することはできない

>>360
>具象型ではないのでそもそも合成することができない
じゃ継承できるから「継承より合成＆委譲」の対象だねｗ
バカもほどほどにｗｗ

>>366
Rustのトレイトもインスタンスを持てないようだからインターフェイスと同じく合成できないだろう
「継承より合成」の対象ではない

手法がどうであれ
変な継ぎ足しして設計思想をダメにするなって話だよ

>>371
インターフェイス継承を辞めて代わりに合成＆委譲するコードを書いてみろ
不可能なことがわかるだろう
インターフェイスは「継承より合成＆委譲」の対象ではない

>>373
お前が言ってることは「継承より合成」の対象ではない

同じことを言い続けても議論は深まらないのかもしれないな
オブジェクト指向と同じようにアップデートしていかないとな

>>376
この違いが重要だよな
クラス継承を辞めて合成＆委譲にすれば良いコードになるという標語
インターフェイス継承を辞めて合成しようとしてもそんなコードは書けずに不可能

>>377
何言ってんのかわからない、ちゃんと説明して

暴れてらw

>>379
何わろとんじゃおらあ！！！マジメにやれ！！！お前のように話を茶化すやつが一番のクズだ！！！このボケカスが！！！

はぁ…もう少し冷静に議論できないもんかね…

プリミティブなレイヤーから具象化されたレイヤーに階層的に構成される設計思想の中で
各レイヤー間の連絡方式がどうのこうのなんてのはオブジェクト指向プログラミングでの瑣末な作法でしか無いんだからイキってどちらが優秀かなんてやる必要は無いんだがなぁ

アーキテクチャの異なるシステムへの並行展開を考えたら各レイヤーのどの階層ではインターフェースが有効か考えるくらいかなぁ

「継承より合成＆委譲」とはデブになるクラス継承を使うのはやめましょうってこと
代わりにその親クラスと子クラスになるはずだった2つのクラスを継承関係を持たせずに並べて持つことを「合成」と呼んでる
そして親クラスになるはずだったところへ必要な機能を委譲するので「合成＆委譲」
これはクラス継承のみが対象
インターフェースは実体がないから「合成」できない

委譲コードだらけの栄養失調なヒョロガリクラスならOKということか

ドメインロジックと関係ないコードを書きまくらないといけないのか
いまのオブジェクト指向は大変なんだな

瑣末な作業はAIにでもやらせておけばいいんだよ
俺らは設計思想をしっかり持つ事
システムの全体像と各ドメインモデルを書いて後はAIにやらせれば終わり

バカにやらせても問題の起きにくいルールを決めてバカよりマシなAIにやらせる時代が来るのか。

プログラマーがみんなプロジェクトリーダーになれる時代だよw
つか、そうしなきゃ居場所が無くなる

>>386
内部で使うなら自分のメソッド呼び出すのも委譲先のメソッド呼び出すのも同じでコードは増えない
委譲先のメソッドを自分のメソッドとして公開したいならばプログラミング言語によって簡単にできる方法もあってコードは増えない
ドメインロジックに集中できる

>>386
That’s exactly the object-oriented programming.

>>391
日本語になってない

まずきちんとした日本語を使うところから始めようか

>>389
船頭多くして船山に登るという言葉があってだな
何をリードしてるんですかねえ

まずレス推敲して言いたいことまとめろよ
長いわ連投するわ典型的なレスバ脳じゃねぇか

>>394
ひとりで一つのプロジェクトだぞw