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

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

>>230
RustやJavaにあるような抽象的な契約の考えをZigに持ち込むのがそもそもパターンとして間違ってる

>>231
Zigで型をanytypeと書く暇があったら代わりにinterface名を書けばいいよね
そこでのコードの長さは変わらなくてZigは可読性の低下だけ招いてるような
Zigが節約できたのはinterface宣言つまりmethod名と型signatureを列挙することだけかな
可読性の低下と引き換えにZigが得たものが小さすぎて割に合わない気がする

>>233
間違ってないよ 可読性や保守性の問題は抱えている
それと型安全性とは別の話だよねってこと

Zig方式だと異なるインターフェース相当の同一型メソッドを区別できずに混ざってしまうため型安全性も落ちる

・構造的型付けは性質の一致をみる
・名前的型付けは概念(性質の集合)の一致をみる
ものだとすると、構造的型付けの方がロジックバグを作りやすいのはそのとおりだと思う

型安全という概念はプログラムの実行時に未定義の操作（存在しないメソッドの呼び出しなど）を起こさないというものなのでどちらも型安全ではあるってことなんじゃないかな

型安全じゃないなら何と表現するのが良いのかな、意図安全？

Zigはそのanytypeの時に複数の異なる型がやって来るわけだけど
生成コードは単相化？それとも動的ディスパッチ？

Zigとかどうでもよくね
思想が他と違うだろあれ

>>202
>>177を見れば一目瞭然だけどRustでも問題起きてるよ
Fragile Base Class Problemと同じFragile Trait Problem
Rustと違ってGoでは起きないけどね

それ起きるのなぜかfinalがないRustだけだろ

そもそもRustでは起きない

>>242
どうしてそう考えるの？

>>242
主語や目的語を誤魔化しているところを見ると
「(複おじの考える問題は)Rustでは起きない」ということなんだろう

Rustで起きないならJavaならなおさら起きないけどね

論破されても同じ主張を根拠無く延々と繰り返す
それが複おじ!!

で、お前ら実際にクラス継承なんか使ってんのか？

なるべく使わないがそれが何か

必要がない機能がないなら用足りないっつってもいいが
使いもしない機能が余計についてるだけのことでとやかく語って何が楽しいの？

>>248
お前のその斜に構えた態度がクソダセーって話でお前がいないところでみんな盛り上がってるから心配すんな楽しいぞ

時間の無駄

5ch見て時間の無駄は草

>>249
それどこよ？

>>252
うそやで

>>247
害が少なくて役に立つところには、たまにor稀に使う
そうじゃないと多用したらプログラムがわかりにくくなってしょうがない
拡張などメンテでは解読とあっちこっち目を通して整合させたり手が掛かるし

>>253
だよな
つかはったりもええ加減にせーや

>>254
バグ紛れ込むし見つけにくいし

今まで単に使う場面が無かったから使ったことがないな

みんな仕事したことないのか

いやまあライブラリ作るのでない限り継承が必要になることはないでしょ
お仕事では既存のライブラリを使ってアプリ作るほうが圧倒的に多いだろうしそんなもんじゃないかな

そんな小規模な開発じゃ使わないからw

大規模な開発で濫用すると滅びるぞ

大規模ならインターフェース実装と委譲

traitの中に実装を書くのがそもそもアホ

Unit Test書いてCIする時代なんだし好きに書いたら良い
まさかUnit Test書いてCIしてないやつはいないよな？
俺はどっちもやってないけどな

>>217 >>218 2012年ころ試しに書いたFiizBuzzのPerlコード見つかった

for (1..20) {
　$a = '';
　$a = 'fizz' if 0 == $_ % 3;
　$a .= 'buzz' if 0 == $_ % 5;
　$a ||= $_;
　print "$a\n";
}


$ perl FizzBuzz.pl
1
2
fizz
4
buzz
fizz
7
8
fizz
buzz
11
fizz
13
14
fizzbuzz
16
17
fizz
19
buzz

>>265
きたねー言語だなぁ

>>266
綺麗に書いてみて

抽象型やinterfaceやtraitやZigを活用したらどのくらいきれいになるんだろう

そりゃ文字列"fizzbuzz"は直書きせずともcomptimeで生成だろ

>>267
見せてやるよ
オブジェクト指向の真髄ってやつをな
https://paiza.io/projects/jndrJpCJ34RQgtrNFNvG9g?locale=ja-jp

テンポラリ変数嫌いすぎて可読性落とす書き方するやつってけっこういるよな

10行で書けるけどそれだと金にならないから100行に水増ししてかっこいい雰囲気を醸し出せる
それがオブジェクト指向

オブジェクト指向前だって#defineがズラズラ並んでる見づらいコードだったけど

>>270
目的の関数とメイン関数は分けなければいけない
今回は無限FizzBuzzイテレータを返すだけの関数を分離すると望ましい
データ生成とそのデータのビューアーも分離しなければいけない
文字列化するのはビューアーの役目であり途中のデータは可能な限り軽い小さなものにする
固有のロジック部分の分離も望ましい
今回はもちろんFizzBuzzへの変換部分を分ける

>>270
ヒー、よくこんな糞コードを人前に晒せるな
笑いをとるネタでやってるなら役者だわ

凝った技術を使って 後退している感じ
まあ遊びとしてはありかな

>>271
長い数式や条件式がある場合は短く分けて意味が分かる一時変数名を付けることが必須だけど>>270に一時変数が必要な部分はないよ
役目毎に関数を分けて意味が分かる関数名を付ける必要はあるけどね

>>277
この内容で関数分けは逆にやりすぎだよ

>>278
Mainに本体を書くやつは恥
20個という前提にない指定が本体に紛れ込んでいるのも恥

>>279
レビューポイントがずれてるところ見ると例の人か

ビュー部分とロジック部分は分けるべきだろうね

レビュー言ってる人が書くともっとヒデ―んだろうな…

ノウハウが盗まれないように最初から難読化しているのに、
それをextendsがevilだといわれちゃうと心外ですよねぇ笑。
それは単なるtrapだ。trapに引っかかるようなバカは不要という世界。

少なくとも個別テストができるレベルでの関数分けは常に義務付けられる。
データ生成部分とデータ表示部分を分離しなさいという常識も、混在は可読性を下げるだけでなくテストを困難にするためだ。

test firstはtestを先に書け、ということではなく、
testすること/できることを前提に設計しろ、ということ。
Unit testできないもの、integration testできないプログラムはゴミでしかない。

結局、カルトな迷信から抜け出せないのね

文字列への変換はできる限り遅延させて可能なら表示の直前まで遅延させることが望ましいという原則
これは抽象的なデータとして持っていた方が可読性と保守性に勝るだけでなく
高速化や省メモリ化の観点からでもあるね
文字列にして持っていると格納メモリが増えて比較も遅くなっちゃう

Fizz buzzについては、wikipediaのルールを基準として、それを仕様とみなせば、
仕様をみたしていないプログラムが多い（日本語版wikipediaを含む）。
これを試験に出すとすると、仕様というものを理解できていない会社が多い。
結果が同じであればよいのではなく、保守や運用を考えると仕様を満たしていることが必要。

wikipediaのルールが実は違ったらどーすんの？

>>288
FizzBuzzじゃなくてFizz Buzzが正しいんだとかそういうこと？

>>275
…はー…我慢！我慢！

もしかして頑張って書いてくれたんだ、ｺﾞﾒﾝﾁｬｲ

wikipediaに仕様は書かれていないので、仕様は自分で書き起こすことになる。
そこでhttps://rosettacode.org/wiki/FizzBuzzあたりから仕様を持ってくる。
3の倍数のときはFizz、
5の倍数のときはBuzz、
3と5の倍数のときはFizzBuzz。
このルールの優先順位は不明だ。混乱する。
wikipediaではreplaceすることになっており、さらに混乱は増す。
3つ目のルールは１・２を前提にしておらず、仕様の変更によって別の文言になる可能性がある。
仕様の曖昧さとバージョンアップの可能性を、出題者に確認しないで作り進めた場合は、
0点だろう。
また、確認したら逆切れされた、とかいう場合は、その会社には行かない/やめることが重要だ笑。

>>291
あのフリからのあのコードだから普通の人はネタだと分かるから心配しなさんな

>>293
かたいのはチンチンだけにした方がいいよ

>>278
関数分けされてないことだけが今回のコードの問題点だよ
少なくともテストができるように分離かな
テストではなくprintするだけにしてもメイン側に書いていいことは1から20までやprintのみ

ネタで5chに晒すトイプログラムは、あれこれ欲張って機能付帯するよりエッセンスだけ凝縮したような物でいいと思うがな
極論だが、one linerでも話のネタになればそれでもいいんジャマイカと思う

>>270は普通に書かれているだけでネタには全くなってない

>>295
そっちは硬くならない

結果だけなら無限ジェネレータ、イテレータ使うのがシンプルで無駄ないけど
初学者が分岐と文字列出力駆使してコーディングできるかのお題だから
経験者はあたたかくみまもるのが正解

>>268
Rustはこんな感じ

use std::fmt;

struct FizzBuzz(usize);

impl fmt::Display for FizzBuzz {
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
let fizz = self.0 % 3 == 0;
if fizz {
write!(f, "Fizz")?;
}
let buzz = self.0 % 5 == 0;
if buzz {
write!(f, "Buzz")?;
}
if !fizz && !buzz {
write!(f, "{}", self.0)?;
}
Ok(())
}
}

use v5.26; use feature 'signatures'; no warnings 'experimental::signatures';

my $Y = sub($f){ (sub($x){ $x->($x) })->(sub($x){ $f->(sub(@a){ $x->($x)->(@a) }) }) };

$Y->(sub($r){ sub($n=20){
　$n && $r->($n - 1) . print((('fizz')[$n%3].('buzz')[$n%5] || $n)."\n")
}})->();

>>299
添え木するか ﾄ

ttps://ja.wikipedia.org/wiki/%E4%B8%8D%E5%8B%95%E7%82%B9%E3%82%B3%E3%83%B3%E3%83%93%E3%83%8D%E3%83%BC%E3%82%BF

>>301-303
どれも汚くて読みにくい言語だなぁ

やっぱりBASIC言語がいいな

>>306
はよ

>>301
これは明らかにやっちゃいけない役割分担
>>287や>>300でRustの自演お膳立てしておいてこれはない

オブジェクト指向をバカにしてるやつ(≒苦手にしてるやつ)ほど役割分担下手だよな

>>309
>>268

>>309
めちゃくちゃわかる
脳の使い方に違いがありそう

Javaは書いたことがないけど、>>270の内容は大体分かる（と思う）。分かるんだけど、たとえば>>265みたいなごくシンプルなコードと比べて、コード量が増えたことに見合うだけのメリットがあるのかよくわからない。

>>308
FizzBuzzは数値をあるルールで文字列に変換する問題だよね
そしてRustで文字列に変換する時はDisplayトレイトを実装するのがお約束
>>301のコード以外に適切な方法ある？

>>312
前者は数列処理にFizzBuzzのルールを与えたプログラム
後者はFizzBuzzの問題を解く為に構成されたプログラムという理解
メリットは…なんだろう

>>306
はよ
https://www.jdoodle.com/execute-freebasic-online

>>313
煽られただけだと思うよ

やるとしたらfmt::Displayの実装とFizzBuzz判定の実装を別々に分担するくらいか？
あと個人的にはifじゃなくてmatchでよくね？と

>>301は最小限のコードを書いたので
もう少しFizzBuzzオブジェクトに肉付けすると

#[derive(Clone, Copy, PartialEq, Eq, PartialOrd, Ord)]
struct FizzBuzz(usize);

impl FizzBuzz {
fn is_fizz(&self) -> bool {
self.0 % 3 == 0
}
fn is_buzz(&self) -> bool {
self.0 % 5 == 0
}
fn iter() -> impl Iterator<Item = FizzBuzz> {
(1..).map(|x| FizzBuzz(x))
}
}

impl fmt::Display for FizzBuzz {
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
if self.is_fizz() {
write!(f, "Fizz")?;
}
if self.is_buzz() {
write!(f, "Buzz")?;
}
if !self.is_fizz() && !self.is_buzz() {
write!(f, "{}", self.0)?;
}
Ok(())
}
}

他の例のように20まで表示したい時は

fn main() {
for z in FizzBuzz::iter().take(20) {
println!("{z}");
}
}

>>317
FizzBuzzのルール
3で割り切れる時はFizzと言い
5で割り切れる時はBuzzと言い
結果として15で割り切れる時はFizzBuzzと言うことになる
これをそのまま実装したのが>>318

// java21, import略, rosettacodeの仕様による。3と5の倍数の場合、3や5のwordと関係ないものとみなして独立。改行詰め,、改行が多いだと！
public class FizzBuzz {
private static final int IntMin = 1;
private static final int IntMaxClosed = 100;
private static final String Fizz = "Fizz";
private static final String Buzz = "Buzz";
private static final String FizzBuzz = "FizzBuzz";
private static final BigInteger bigInteger15 = BigInteger.valueOf(15);
private final int value;
private FizzBuzz(int value) { this.value = value; }
static Stream<FizzBuzz> generator() {
return IntStream.rangeClosed(IntMin, IntMaxClosed).mapToObj(FizzBuzz::new);
}
int gcd15() {
return BigInteger.valueOf(value).gcd(bigInteger15).intValue();
}
String toText() {
return switch (gcd15()) {
case 3 -> Fizz;
case 5 -> Buzz;
case 15 -> FizzBuzz;
default -> toString();
};
}
@Override
public String toString() { return Integer.toString(value); }
public static void main(String[] args) { generator().map(fb -> fb.toText()).forEach(System.out::println); }
}

これは想定外の重症度
汚コード複製おじさん酷すぎだろ

immutableなclassとstreamでmonadicに、各methodは1行の式とした例。
改行制限と空白制限で、ちょっとおかしな表記になっている。

>>320
100までとか
main関数とか
なぜclass FizzBuzzの中にあるんだよ草

くすくす。仕様を満たすためだよ。

ここはオブジェクト指向でFizzBuzzを書くとどうなるかの話だよな
class FizzBuzzに属するものと外部のものを分けないとな

generator込みの完結したclassだがね。UnitTestにも対応してるし。
プログラム書いたことある？

>>318は改行しまくりスカスカでも収まってるのに
>>320は改行を詰めてぎっしりコード量が多くて見にくいのはなぜ？

糞言語ってことよ

>>320はgcd最大公約数を求めてるけど
その方が速いとか有利とか何かあるの？

https://paiza.io/projects/zW-QQAk1SV2qaU7Iv3Kqtw
FizzBuzz classがMain classになっちゃったけど、しかたない。
最大公約数で扱ったほうが楽だし、意味的にはGCD使ったほうが正しい。

generator().map(fb -> fb.toText()).forEach(System.out::println);
generator()で発生させたFizzBuzz(Main)オブジェクトをtoText()してprintlnの関手を与える。
ただそれだけ。
toText()は15とのGCD取って、結果でFizz,Buzz,FizzBuzz,その他の文字列を返すだけ。
return switch (gcd15()) {
case 3 -> Fizz;
case 5 -> Buzz;
case 15 -> FizzBuzz;
default -> toString();
};