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

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

>>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();
};

>>330
class Mainとclass FizzBuzzに分けようぜ

plaza.ioは複数class書けるね。しばらくはこれを使おう。java18らしいし。
でも、本来はclass FizzBuzzひとつのオブジェクト指向の例なので、
MainはFizzBuzzに読み替えてほしい。

1文字でFizzBuzz解ける言語があるらしいな

>>330
意味的にGCDを使うのは間違っている
さらにGCDは計算時間がかかり不利だ
途中で除数が定数でなくなるためDIV命令が必要になるためだ
普通に3で割る余りと5で割る余りの計算ならDIV命令が不要で速い

定数で割った時の余りは掛け算とシフトと引き算で済むから速いんだよな

DIV命令？　あったっけ？

めんどくさいのでBigInteger#gcd(BigInteger)使ってるけど、
15とのGCDで3,5,15の判定だけなので自作すればもっと速いだろう。しかし、速さの指定は仕様にない。
意味的には15との最大公約数で振り分ける。保守しやすい。
if文が２つ以上あるとバグが出やすくなる笑。

CPUの割り算命令DIVは遅いんだよ
ただし定数での割り算は掛け算とシフトで代替できるから速い

その前にだな、
まともに見れるコードも書けんくせに
オブジェ指向で蘊蓄垂れていたのか君らは

GCDアルゴリズム実装ではなくCPUのDIVの話ね。
アルゴリズムならマルチコア上で速そうなのを考えてみよう。少しだけ思いついたので。

https://paiza.io/projects/BA7H5VNcMAbOvwmXRnPAmw

compactの前に.lazyわすれた
遅くなるけど概念的にそうしたい

FizzBuzzのように定数で割る時
商は魔法により掛け算とシフトで求まる
余りはさらに商に掛け直して元から引き算で求まる

ところがだ
FizzBuzzで余りを求める必要ないのだ
余りが0かどうか判ればいい
強力な魔法を使うと掛け算と比較で求まる

Fizz判定は x % 3 == 0 が真かどうか
xがeaxレジスタに入っている時
imul eax, -1431655765
cmp eax, 1431655766
この結果CFフラグ=1ならFizzだとわかる
強力な魔法のおかげで実は速い

>>320
Fizz、Buzzに加えてPop、Jazz、Rockに対応してください

3 → Fizz
5 → Buzz
7 → Pop
11 → Jazz
13 → Rock

>>322
> immutableなclassとstreamでmonadicに、各methodは1行の式とした例。

モナドを使ってないのにモナディック ( ⊙ω⊙ ) !!?

オブジェクト指向じゃないほうがシンプルに作れるものを
オブジェクト指向で作ろうとするのは無駄でしかなく、オブジェクト指向の啓蒙にはならない

AI時代に最適な言語とは

>>348
英語、次点で日本語

日本語は文字圧縮率高いからAIに向いてるよな

>>350
向いてない

対AIの情報圧縮率は情報量/文字数じゃなくて情報量/トークン数なので日本語の情報圧縮率はむしろ低い
日本語に最適化された生成AIが出てきたとしても今の汎用生成AIで英語を使うのと同じレベルにはまずならない
ちなみに文字数ベースの情報圧縮率で言えば日本語より中国語のほうが上

言語ってやれることに縛りがないマシン語一択よ

バイナリなんて扱いが面倒で
しかもCPUやOSによって全く使い物にならないから
それだけは無い

>>345
余りで場合分けしたりGCD求めるより素直に判定する方がええんか

>>354
数値リテラルならな
>>346の様な(素数，表示文字列)のリストを受け取る形式にすると
3とか5が定数じゃなくなってコンパイラが>>345の最適化をしてくれない

「FizzBuzzのプログラム書いて」の指示だけで済むのになに前時代的なことやってんの?ｗｗｗ