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

前スレ
オブジェクト指向はオワコン？
https://mevius.5ch.io/test/read.cgi/tech/1721393540/

>>882
そうだ、それで良い
必要ないオブジェクトを作るのはオブジェクト指向ではない

オブジェクトを最小限にすることもオブジェクト指向である

Pythonは数値さえもオブジェクトだったりするんだよな
Pythonで書かれたプログラムはすべてオブジェクト指向の賜物

メッセージパッシングがーと言ってるやつは自分で書いてみろ
できないんだったらメッセージパッシングによるオブジェクト指向は
現実では使い物にならないことの証拠である

オブジェクト指向でプログラミングすること
言語の機能やライブラリがオブジェクト指向で実装されていること
この二つは異なる
違いがわからない人はいないと思うが

>>887
同じですね、オブジェクト指向エアプか？

オブジェクト指向がなかったらライブラリも構築できないんだから
オブジェクト指向のライブラリを使うこともオブジェクト指向プログラミングだよ

オブジェクト指向で構築されたライブラリを使ってプログラム書いてオブジェクト指向ではありませんは無理がある
濃厚セックスしておきながら私エッチなことに興味ありませんけどみたいな顔してる女みたいなもの

オブジェクト指向以前からベテランの開発者は優れたデータ構造を選んでコードがシンプルにせよと言ってたんだよな
そのように考えるとオブジェクトは言語機能の代替と考えてそれらを使ってロジックを手続き型や関数型でシンプルに書くのがオブジェクト指向の良いプログラムといえるのではないだろうか

誤：コードがシンプルにせよ
正：コードをシンプルにせよ

>>866はオブジェクト指向プログラミングの要素が1つもないな

>>893
そんなに他人のコードに文句があるなら自分で書きなよ
自分が思う最高のオブジェクト指向プログラムってやつをさ

手段の目的化の極み

>>866
読んでみた
糞コードだと思った点の一つはCallable
それは非常に古い使い方でオブジェクト指向に対応していないC言語などで用いる方法
オブジェクト指向プログラミングに対応した言語はその点を解決している

あーキレ散らかしてるのはJavaで書いた人かｗ

>>896
コメントありがとん。変数名・関数名が分かりづらいとかそういった方向の批判は予想していたんだけど、正直そこにツッコミが入るとは思わなかった。
たとえばwoof_ruleがなかったとして、classic_rule, digits_rule, boom_ruleがいずれも真偽値を返す述語関数だったとしたらどう？　それともコールバック関数を渡すこと自体がダメという感じ？

>>897
そんなことないでしょ。出力例とかだいぶ参考にさせてもらったんだけど。

>>878
車載コンピュータの演算装置とかは
データマトリックスをROMに書いてるんだぜ
８ビットマイコンの乗除演算とか複雑な計算をリアルタイムに近づける工夫さw

なんて言えば良い！！なんて言えばいいのこれ！！？

オワコンっていうかやって当たり前

メッセージを送ってなんちゃらかんちゃら。small talkはうんざりだよ。所詮、コンピュータ上のお遊び

What Killed Smalltalk Could Kill ほにゃらら, Too

BIG MOUTH👄

拡張FizzBuzzも結局Fizzの出力を0回か1回かそれ以上かのバリエーションになっているため
ID:V26zP6ij氏のカウント数を返す抽象化は正しいよ

あとはカウント数を返す抽象メソッドを共通インターフェースとして定めて
各ルールがそのインターフェース実装すればオブジェクト指向になるね

共通インターフェースの例

trait FizzBuzzRule {
fn count(&self, target: usize, number: usize) -> usize;
fn divisible(&self, target: usize, number: usize) -> bool {
target % number == 0
}
fn contains(&self, target: usize, number: usize) -> bool {
target.to_string().contains(&number.to_string())
}
}

count()は各ルールが実装すべき抽象メソッド
残りは各ルールが共通に使える具象メソッド

あとは各ルールがcount()だけ実装すればOK

struct Classic;
impl FizzBuzzRule for Classic {
fn count(&self, target: usize, number: usize) -> usize {
self.divisible(target, number) as usize
}
}

struct Digits;
impl FizzBuzzRule for Digits {
fn count(&self, target: usize, number: usize) -> usize {
self.contains(target, number) as usize
}
}

struct Boom;
impl FizzBuzzRule for Boom {
fn count(&self, target: usize, number: usize) -> usize {
(self.divisible(target, number) || self.contains(target, number)) as usize
}
}

struct Woof;
impl FizzBuzzRule for Woof {
fn count(&self, target: usize, number: usize) -> usize {
self.divisible(target, number) as usize + self.contains(target, number) as usize
}
}

>>881
そしたらなぜ君の書くプログラムはそんなに分かりにくいのよ？

>>907
そこは謎のままで良いじゃないですか、謎のままにしときましょう

オブジェクト指向という幻想

概念はわかりやすい理想的なものだが
実装したところで無駄ばかりで趣味の世界

なんていうか、猿でも作れるツクール的な感じ
だけどツールでもないしな

プロでも作れないオブジェクト指向のための言語になってる

>>909
無駄じゃないだろ

>>911
削り落とせるぞ

CPUはかなり遠回りで無駄なことをしてるんだよ
人間様用の高級言語のせいでね

つまり0721か

>>912
それが無駄な作業なのでは?

オブジェクトをなくしたところで状態が必要なくなるわけではないからなあ、状態を管理しようと思ったらオブジェクトで操作とセットにしておけばわかりやすいだろ、その努力こそがオブジェクト指向なんだよ

状態も操作もバラバラにあっちこっちに散りばめたら管理できなくなる、100億を超える大規模なシステム開発が失敗して損害賠償の裁判が起きたという話をたまに聞くだろ、ああいうのも元をたどればオブジェクト指向が原因なんですか？

>>599 ruby
https://ideone.com/TZGLeB
・>>846の委譲でなんとかするやつの移植
・Javaの発想からスタートしたからRubyっぽくないかも

>>884
> オブジェクトを最小限にすることもオブジェクト指向である

かもね
やっぱクラスにせよインスタンスにせよ不必要に増やしたらあとで苦しいよ

異なる種類のオブジェクトを共通のインターフェースに結びつけることは
オブジェクトの意味と立ち位置をはっきりさせる
オブジェクト間の関係もはっきりさせる

それらを使う側から見ると
インターフェース抽象型として同一に扱える
つまりコードの共通化ができる
インターフェースを実装してないオブジェクトに間違って適用してしまうバグも防げるため型安全性もある
C言語の関数ポインタやPythonのCallableと比べると使い勝手も安全性も格段に良くなっている

インターフェースを用いたオブジェクト指向プログラミングは可読性も保守性も良くなりバグも減らす

>>919
最初の3行はいいこと言ってると思うがコードが>>905じゃ説得力が無いな

>>920
もっと良いコードを示してくれるなら歓迎するよ
そのコードはID:V26zP6ij氏の>>866のコードのCallableを使っているルール部分をインターフェース化したもの

>>915
それなら最初から無駄を付けない・省くのが最強だろ

プログラマじゃなく管理する側に都合のいいのがオブジェクト「至高」
プログラムを書かないのでどんな処理をするにはどんな書き方があるとか分かって無いけど、オブジェクト指向なら纏められるってので飛びついてオブジェクト指向が目的となってる

インターフェイスを共通にするというのは良いとしても、コールバック関数で済むことなら個人的にはわざわざオブジェクトにはしたくないとやっぱり思っちゃうかな。
Pythonならユーザー定義クラスを作って継承するなりtyping.Protocolを使うなりすることはできるけど、特に状態管理が必要な場合等でなければコールバック関数の方が好ましいと思っちゃうな。

>>924
全てオブジェクトなのにオブジェクトにしたくないとはどういう意味？

>>920
言葉に酔って本質を見失うタイプでしょｗ

あー、ごめん、ユーザー定義クラスのインスタンスにはしたくないというニュアンスで受け取ってもらえれば。関数1つで済むところを、その代わりにクラスを作ってメソッドを定義するというのは、もちろんメリットもあるのだろうけど、本当に手間に見合うだけのメリットなのかというくらいの感じ。

>>924
そこで使えるコールバック関数一覧をどうやって管理するのかな

FizzBuzzの拡張ルールくらいならそんなに多くはならないだろうし、仮に数十個、数百個になるというなら、専用モジュールを作ってそれに放り込んでおけばいいんじゃない？

インターフェースは異なる型に対して共通のメッセージを送れる仕組み
一般的にはコールバックに置き換えられない

インターフェイスが一般的にはコールバックに置き換えられないというのはもちろんそうで、今疑問を提示しているのは、コールバックで済むような場合に、わざわざインターフェイスを持ち出す必要はないのではないかということね。

コールバックが複数あってそれぞれに異なる名前を付けるということは複数のオブジェクトを作っているのと同じだね
それならメソッドとして実装した方が型安全性もよいかな

本当は君らプログラミングやソフトウエア開発が苦手なんじゃない？
苦手なのにその自覚がないだけなんじゃない？

プログラミングで一番大事なことは型安全だからラップして別の型に

違うだろ、もっとも必要なものは合理的な考え方だろ

全てをイミュータブルにすることが大切

関数定義はユーザー定義クラスを定義する等してオブジェクトを作るより簡単だし、コールバック関数は渡された関数内で呼ばれるだけだから、呼び出そうとしたメソッドが存在していなかったという類の問題はもともと生じないと思うんだけど。
たとえば、Pythonの組み込み関数sorted（あるいはlist.sort）は引数keyとしてコールバック関数を取るんだけど（str.lowerなんかを指定する）、これを、特定のインターフェイスを備えたオブジェクトを受け取る形に変更した方が望ましいということにはならないと思う。

>>936
話は聞かせてもらいました
https://paiza.io/projects/CjTaDF7rHaOKmYUeN_Vavw

>>938
ミュータブルを使うな
for (var i = 1; i < to + 1; i++) {

>>939
バカ乙

>>937
メソッドが一つならともかく
複数のメソッドがあるとその組み合わせを毎回渡すことになってしまうぞ
各オブジェクトを渡す方がよい

Woofのルールは303ならFizzFizzじゃなくてFizzFizzFizzみだいたよ

>>938
toやdivやinがイミュータブルで作られていない
やり直し

>>942
キャー助けてー

>>943
バカ乙

>>938
オブジェクト指向のスレなのにMainしかなくて酷いコード草

>>946
酷いのはお前の頭で大草原、シマウマさんが走ってるわ

>>942
そうなの？　だとすると、>>866のwoof_rule関数は、
if str( given_nubmer ) in str( i ): satisfied_count += 1 の行を
satisfied_count += str( i ).count( str( number ) ) に修正する感じかな。

ついでに引数名もちょっと変えてみた。本質的な変更ではまったくないのだけれど。
https://paiza.io/projects/0xwLMmS5rjnLke8sh9ExMg

>>938は関数型プログラミングをわかっていないのだと思われる
foldやreduceを知らない

>>941
コールバック関数を渡す設計にするのは、1つの引数に1つの関数を渡すというケースだと思うけど。複数のメソッドを持つオブジェクトを渡すことが必要な場合ならもちろんオブジェクトで渡すけれども、sortedのkey引数のように単一の関数を渡せば済むようなケースで、あえて単一メソッドのオブジェクトを作って渡す必要はないんじゃないかと思う。

>>949
バカ乙

>>950
メソッドを通常関数に置き換えるにはオブジェクトの値も必要だよ
オブジェクトの値はどうやって渡すの？

オブジェクト指向はオワコン？ part3
https://mevius.5ch.io/test/read.cgi/tech/1787712923/

>>953
ありがとー仕事が早い

オブジェクトの状態を変えられるか否かが可変性(ミュータブル/イミュータブル)
変数への再代入ができるか否かが再代入可能性(リアサイナブル/ノンリアサイナブル)
これらは異なるものなんよ

>>952
たとえば、Pythonの組み込みソート関数sortedの引数keyには、引数を1つとって1つの値を返すコールバック関数を渡すんだけど、このコールバック関数の引数になるのはソート対象のコンテナの各要素なので、イメージとしてはコンテナの各要素に対して（コンテナの各要素を引数として）コールバック関数を呼び出す感じになる。
で、このコールバック関数を仮にオブジェクトのメソッドに置き換えるとした場合、何をレシーバーにする（どのオブジェクトに属するメソッドにする）のが、設計上無難なのかというのは、コールバック派の自分にはよく分からないかな。何らかの管理用オブジェクトを作ってそのメソッドにする方向になるのかなとも思うけれども。

メソッドのレシーバーをどのように渡すのかという問いに対しては、そもそもどういったものがレシーバーとして想定されているかがよく分からないのでそれを明らかにしてもらえると助かるかなという感じなのだけれど。

>>955
バカだろ
オブジェクトを変数に入れれば書き換えてもいいんだな

>>957
何をデスカ？
オブジェクトがイミュータブルならオブジェクトを変数に入れてもオブジェクトの状態は書き換えられませんよ
変数への代入とオブジェクトの状態を変える操作はまるで違うものだということを理解したが良い

>>956
その例は既に暗黙の引数として対象コンテナがsortedに渡されているからたまたま上手くいってるってことなのね
sortedは例として良くない例ですね
他の例を持ってきましょう

>>958
そこは言語によって千差万別だから意味のない主張
さらに全てがオブジェクトの言語もあれば
言語仕様にオブジェクトの概念が存在せず型とその値とそれを格納する変数しか存在しない言語も多い
オブジェクトだけがイミュータブルという主張こそ馬鹿げている

「コールバック関数で済む場合に、わざわざオブジェクトを渡す設計にする必要はないよね」という主張なので、「コールバック関数で済む場合もたしかにあるね」ということになると、主張の対立するポイントがなくなって話は終わってしまうのだけど。別に何でもかんでもコールバックでやりましょうと言いたいわけではないので。

>>960
イミュータブルなオブジェクトを変数に代入しても
オブジェクトが可変になるわけじゃないでしょ

> オブジェクトを変数に入れれば書き換えてもいいんだな

と言っておられたからオブジェクトの状態は書き換えられないよってこと
再代入しても良いかという問いならやりたければやれば良いと思う、が僕の主張だよ

言語によって千差万別だというのが君の主張だね
その主張に意味があるとは僕は思えないな、シマウマ追っかけてた方がまだ有意義だよ

>>961
横からだが
特化した処理部分をコールバック関数という形で受け取って処理するか
インターフェースを実装したオブジェクトを定義して特化した処理をメソッドの中に書くか
を比較してるんじゃないのかな？

>>961
コールバック関数が一つだけなら大丈夫だよ
しかし今回は多数の種類があるから話が別かな
多数ある関数が同じ場所で使われる同類だとコード上で示す必要があるよ
たまたま同じ型の関数が間違って使われることを防ぐことも必要だね
それらを一気に解決する方法としてラップがあるよ
値オブジェクとも言われてその値だけをラップしたオブジェクトを作る方法
今回の場合はコールバックとして使われる関数をすべて同じオブジェクトとしてラップだね
もちろんメソッドは要らないし他の値は持たないから手間もかからないよ
これだけで同種のオブジェクトとしてコード上に明示されると共に型安全性も保証されるメリットがあるよ

>>938
大量にミュータブル変数があるなあ
全てをイミュータブルにすることが大切

>>964
色んな種類の関数を受け取れるようにするためにコールバック関数があるんだから多数の種類がない場合なんてない

>>965
ローカル変数がミュータブルでも関数が純粋であることには変わりはないから
変数への再代入を禁止することが大切だというのはただの君の思い込み
君は昔から思い込みが激しい、僕のコードを100回読んで心を浄化したが良い
礼はいらないよ、僕のコードで君が救われるなら本望だ

ミュータブル変数と言った場合は変数の型がミュータブルであることを表すから
再代入できるという意味なら可変束縛の方が良いかもね

>>966
内部利用ならそれで全く問題ない
しかし今回は色んなグローバル変数にコールバック関数が入っているから区別して型安全にする義務があるところ

>>963
その比較で「コールバック関数で済む場合もある」と「オブジェクトを渡す方が常に優れている」との違いというのが見解の実質的な対立点かなと。

>>964
同種の機能・役割を果たすことを示すための箱・入れ物としてオブジェクトを使うというのは、（それしか道具立てがない言語なら仕方ないのかもしれないけれど）ちょっと抵抗感があるかな。もし本当にそうすることが必要なら（そのような場合がどの程度あるのかというのも考え方が分かれそう）名前空間なりモジュールなりを使うのが最近の言語の考え方なのかなと。
たまたま同じ型の関数が誤って呼ばれることを防ぐということを型安全性と呼ぶなら、もしそれが本当に深刻な問題になるようなケースなら、Protocolとかインターフェイス的なものを使うことになると思うけれども（ラップはうーん……どうなんだろう）、そんなケースがどの程度あるのかな。少なくとも、ソートのkey引数に指定するのが裸のコールバック関数なのは型安全性に欠けて困ると思ったことはないけど。

>>967
純粋関数かどうかは副作用がなく参照透過であるかどうかということであって別の話
イミュータブルで書く能力がないために言い訳ばかりしてるようだな

>>971
そうだよ、別の話だよ
だからこそ再代入を禁止する意味がないよねって論旨だよ
意味は自分の思い込みを他人に押し付けようと必死だね

> 意味は
君は

>>970
型安全性のためのラップはオブジェクトやオブジェクト指向とは独立してそれ以前からある技術です
受け付ける側がラップ型しか受け付けなくなるためラップして持つだけで型安全性が保証されます
生で扱うのはやめましょう

まだやってんの？
手続き型で数十行で済んじゃうコードを
わざわざ複雑にしてw
オブジェクト指向プログラミングってのは
そんな馬鹿な使い方の為にあるんじゃ無いのにw

>>974
そのラップというのは、メンバー・属性として持ついわゆるhas-a的なものという理解でいいのかな。
正直、そこで想定されているような意味での型安全性が深刻な問題になる場合がどの程度あるのかという点についてかなり懐疑的に思っているんだけど。
sorted( some_iterable, key = wrapped_cb ) と書きなさいということでしょ。その方が良いよと言われても、にわかにうんとは言いづらいかな……。

>>975
>>599 やってみ、お手並み拝見

>>975 が手続き型で数十行で書けるってよ、みんなで見ようぜ

引数が値だけの関数だけではなく

引数にミュータブルなオブジェクトの不変参照を渡しても
その時のオブジェクトの値が使われるだけなので問題ない

同様にミュータブルなオブジェクトの可変参照を渡しても
その時のオブジェクトの値が使われるだけであり
変更が反映される対象は使う側が可変参照を渡したオブジェクトだけに限定されるためこれも問題がない

問題が起きるのはグローバル変数の変更だ
使う側から見て指定していないものが変更されるからである
これを副作用と言う
副作用を持たない関数を純粋関数と呼ぶ
オブジェクトがミュータブルかどうかは関係ない話だ

>>978
ばーか
手続き型で45行で書けることは既に>>948で示した

948を書いた者としては、「示された」としてもらえたらよりありがたかったかな。手続型ベースと評価されるのは別に構わないんだけど、一応、オブジェクト指向で設計された組み込みライブラリを利用しているよ。

>>981
オブジェクト指向でブログラムを書くことと
ライブラリを使うことは全く別の話
4つの組み合わせ全てが可能