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

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

いや、Copilotに方針教えただけだw

もうメソッド単位の中身なんてどうでもいいんだよって主張の意味がわかったかな？

>>528
なんだよ。
ひで―設計だと思ったけどｶﾜｲｿｳだから言うのがまんしてたけど
これが彼の言う「機能別にまとめたり同じ概念で扱う」かと
それすら自分で書けなかったかｗ

このPythonコードの何がまずいかワカル？

>>529
何で急にそんな変な主張をいきなりし始めるんだｗ

>>450
>>320ではなくて、
https://paiza.io/projects/OHbT6kBvhYGdSm036ZGHCg
を参照してほしい。
generator部、と変換部と出力部にわけて、オブジェクト指向で、
UnitTestしやすく分割してある。
3つの部分をドットでバインドしている。
Streamにより速さは確保できないが、フロー型の次世代GPUを想定。
ワンクラスにすることで、チップ化も想定。
考え中の「場のオブジェクト指向」によって量子コンピュータでの実行も実験中。
すべてのメソッドが1行の「式」である、というところがミソ。

>>532
正直者ではないおれにはmainしか見えないんだが

>>533
すまんタブがあった

で、なんで実装方法を競うだけの例題にしたの？
だからオブジェクト指向言語の話にしかとれないんだってずっと言ってるし
そんな些末な話題はAIにやらせてもっと本質的な話しなよw

>>535
AI未満がよう言うわ
論点ずらし逃げの一手か
これがおまえのいう「機能別にまとめたり同じ概念で扱う」ということか
口先だけの奴め

ルール拡張も出来るし何が不満なのさw
同じルール概念をまとめてるじゃんw

こんな事に時間を割いても無駄だよw
まあ、暇だから付き合ってやるけどね

>>537
そこ重要か？
そもそもClass使うメリット何よ？
変なコード生成させて悦に入って
実力の底が知れるぞ

>>539
おまえが言ったんだろw

頭硬いか自分以外認めない奴かどっちだろうねw

>>538
俺は忙しいんだよ他のことしながら一瞬の空き時間でレスかいてんだけれどさ

時間があるなら「機能別にまとめたり同じ概念で扱う」といとかおためごかし言ったり
糞コード生成させたりしてないで有意義にすごせよ

FuzzBuzzなんて同じパターンを繰り返し出力するだけのループ処理なのに
どうやってそこにプログラム言語としてのオブジェクト指向以外でオブジェクト指向を盛り込ませるってんだかw

>>540
書かしてみたらあまりの糞コードで
目が潰れると思ったわ

>>543
それがお前はまともに書けなかったんだろｗ
恥ずかしい奴め

プログラムはクライスリトリプルなんだから、
圏論解析によってクライスリトリプル化して設計する。
圏論なんだからオブジェクトと射になるので、（圏論的）オブジェクト指向設計になる。
実装やオブジェクト指向言語はまた別の話。
（ただし圏論解析は、まだスタンダードなものができていない）

>>527
> 複数の倍数を含むときの仕様がない

複数の倍数を含むときはその組み合わせで文字列を作成してください

例：
21 → FizzPop
105 → FizzBuzzPop
15015 → FizzBuzzPopJazzRock

以上で仕様は伝えたよ

>>545
FuzzやBuzzは文字オブジェクトだねw
で、概念はある数で割り切れるって事
ちゃんと共通概念で扱ってるよw

で、何度も聞くけど、何をもってオワコンなの？

>>549
お前のような奴が口八丁インチキ垂れて
カルトな迷信みたいに負の技術遺産になったこと
現在コンピューターサイエンスの暗黒時代

>>547
仕様の確認です。元となる仕様も不備があり、そこがネックになっていました。
3 -> Fizz
5 -> Buzz
...
としたとき、両方の倍数のとき、単体の変換文字列を結合するのか、あるいはたまたま同じになるけど、
独立した文字列に変換するのでしょうか。
意図を明確にしてください。よろしくお願いいたします笑。

>>551
それはFizzBuzzのもとのルール通りです

>>550
ああ、偽OOPがたくさんあるからねw

オブジェクト指向は「機能別にまとめたり同じ概念で扱う」
とか言って実現したコードが>>524じゃどうしようもないだろ
しかも自分じゃ書けず生成AI頼り
オブジェクト指向厨はこんなインチキ野郎バッカ

15 -> 3の倍数の変換文字列と5の倍数の変換文字列を連結したもの or 独立した文字列

>>553
その代表だよ君は

>>547
524ならルール追加するだけだよ
なんならjavaで書き直すかい？

>>557
いらない。目が潰れる

>>555
>>532はどちらで書いたの？ その通りで良いよということ

>>557
AIに聞いたら>>524には致命的なバグがあるって言ってたから
書き直してもなあという気がしている、君が手書きしたものだったら
価値を感じるけど、コパオに書かかせたものならあまり気乗りしない

どうせ使い回しなんか大きな会社でしかやらないから
負の遺産とか言われてもなぁw
そんな話なら流行りのプログラミング言語自体が負の遺産の根源なんだし
おまえの主張は単なるプログラミング言語の問題でしか無いよ

開き直って、日ごろ辛いこと・不満があるんだろうなと予想はつくが
何て言って慰めてあげたらいいか俺には思いつかないな

>>559
元のあいまいな仕様から、実装例から得られる代表的な２つの仕様のどちらにも対応できるように
書いたため、若干冗長です。
まあ、いいでしょう。そこは同じ対処で進めます。
まあ、時間がとれて気分がよければ書いときますが、おそらく夜中に酔っぱらったまま書くでしょう笑。

>>563
夜中までかかるん？ 保守しやすいはずなのに？

あれれーおかしいぞおー（コナンくん

>>560
ま、気が乗ったら手書きしてみるわ
でも自由度にも制限あるよ

>>503
どこでfor i ループが出現しちゃダメなの？
例えば>>318みたいなコードはいいの？

ルール追加する毎に条件分岐増やすなんて愚の骨頂だろ

スレの流れは読めてない
要点も掴んでない
脊髄反射でシコった

>>217 java
https://ideone.com/5mCU0H
素朴だけどこういうことが大事だと思ってる
ヘタに再利用性のないクラスを作っちゃうのは罪なのでメソッドひとつで表現
OOPらしさはObject,String,Integerのみで表現
表示しなさい？　のお題に対してObjectを返してるのはそっちのほうが多少融通効いていいやろ？　程度の判断

>>346 java
https://ideone.com/SG4fxp
再利用性のないクラスつくっちゃった版
実行時にインスタンスに対してヘコヘコ指示出して調整していくのも
OOPらしさの一面ではあるかと？
組み合わせの数が増えてくる場合、こういうのの必要性も出てくると思う
でも本当はFizzBuzzクラスというより、もっと気の利いた抽象的な概念で出来ればよかったけど
一応熟考した結果「そんなもんは特にねえや」「FizzBuzzこそが今回の概念や」となり作成

FizzやBuzzをオブジェクトにしろという要求と、
PopやJazzなど拡張に対応しろという要求があったので、
二つを満たしてオブジェクト指向で書けばいいんだよね？

// FizzやBuzzなどはこのMember型になり hello() で数値に反応して名前を応える
struct Member { number: usize, name: &'static str, }
impl Member {
fn new(number: usize, name: &'static str) -> Self {
Self { number, name, }
}
fn hello(&self, number: usize) -> Option<&'static str> {
(number % self.number == 0).then_some(self.name)
}
}

// 上述Memberたちのまとめ役がOrganizer型
struct Organizer { members: Vec<Member>, }
impl Organizer {
fn new(info: &[(usize, &'static str)]) -> Self {
Self { members: info.iter().map(|&(number, name)| Member::new(number, name)).collect(), }
}
fn number_to_string(&self, number: usize) -> String {
let hellos = self.members.iter().map(|member| member.hello(number)).collect::<Vec<_>>();
format!("{}", NumberToString { number, hellos: &hellos, })
}
}

>>570
続き

// Organizerの下請けでhello()結果に基づき数値を文字列化を分離
struct NumberToString<'a> { number: usize, hellos: &'a [Option<&'static str>], }
impl std::fmt::Display for NumberToString<'_> {
fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
let mut is_done = false;
for hello in self.hellos.iter() {
if let Some(name) = hello {
write!(f, "{}", name)?;
is_done = true;
}
}
if !is_done {
write!(f, "{}", self.number)?;
}
Ok(())
}
}

// お好みの設定でOrganizerを作って数値の文字列化を依頼する
fn main() {
let organizer = Organizer::new(&[(3, "Fizz"), (5, "Buzz"), (7, "Pop"), (11, "Jazz"), (13, "Rock")]);
for number in 1.. {
println!("{}", organizer.number_to_string(number));
}
}

>>571
(3, "Fizz"), (5, "Buzz"), (7, "Pop"), (11, "Jazz"), (13, "Rock")
は直書きせず、コマンドラインで

>>572
UIやDBなどからAPI指定データへの変換は今回の件とは無関係な外部の話
ご自由にやってください

&'static str使うコードはこの程度の仕様変更で柔軟性がない、正直アホかと
10万行コードだったらありとあらゆる所に変更が生じてアワアワする

'staticを消して任意で受け付けるように変更したよ
変更はMemberのみStringにして後は'staticを消去
差分の方が分かりやすいと思うので

2c2
< struct Member { number: usize, name: &'static str, }
---
> struct Member { number: usize, name: String, }
4,5c4,5
< fn new(number: usize, name: &'static str) -> Self {
< Self { number, name, }
---
> fn new(number: usize, name: &str) -> Self {
> Self { number, name: name.into(), }
7,8c7,8
< fn hello(&self, number: usize) -> Option<&'static str> {
< (number % self.number == 0).then_some(self.name)
---
> fn hello(&self, number: usize) -> Option<&str> {
> (number % self.number == 0).then_some(&self.name)
15c15
< fn new(info: &[(usize, &'static str)]) -> Self {
---
> fn new(info: &[(usize, &str)]) -> Self {
25c25
< struct NumberToString<'a> { number: usize, hellos: &'a [Option<&'static str>], }
---
> struct NumberToString<'a> { number: usize, hellos: &'a [Option<&'a str>], }

>>564
https://paiza.io/projects/E86OZjZm-JfK2VzqXB40Ng?language=java
酔っぱらって書いているのでbugはあるかもしれん。
暇じゃないのでな。

>>576
やるじゃん

>>576
2つの問題
手動組み合わせよりも漏れが起きない自動計算へ
固定一覧の内蔵よりも外から任意の注入へ

まだやってんの？
暇だねぇ

あいまいな仕様から、あくまでも圏論的オブジェクト指向設計の例なので、
めんどーなことは、やらん。なんにしても酔っていて眠い。寝ると思う笑。

>>574
errorやpathやtest dataなどとりあえず&'static strはよくあるけど変更の対応は大した手間ではないよ

>>580
外から受け取り算出する設計に変えないと
見るに堪えないコードになってるよ

内部がこのマジックナンバーとか
private int gcd15015() {
var num1 = this.value;
var num2 = 15015;

この大量の手書きとか
Map.entry(3 * 5 * 7 * 11, "FizzBuzzPopJazz"),
Map.entry(3 * 5 * 7 * 13, "FizzBuzzPopRock"),
Map.entry(3 * 5 * 11 * 13, "FizzBuzzJazzRock"),
Map.entry(3 * 7 * 11 * 13, "FizzPopJazzRock"),
Map.entry(5 * 7 * 11 * 13, "BuzzPopJazzRock"),
Map.entry(3 * 5 * 7 * 11 * 13, "FizzBuzzPopJazzRock")

>>576
頭悪w
組み合わせで済むだろうにw

へんな時間に寝たのでいちど起きてしまった。
ふ。仕様を逸脱しないようにすると全部書かざるを得ないわけよ。
仕様の不備はおれのせいじゃない、確認したしな。
こういう頭の悪いクライアントは多い。さてまた寝よう。

>>584
仕様は簡単
自然数を1から順に文字列へ変換せよ
3で割り切れる時はFizz
5で割り切れる時はBuzz
7で割り切れる時はPop
11で割り切れる時はJazz
13で割り切れる時はRock
17で割り切れる時はFolk
それぞれを順に並べたものとする
例えば255はFizzBuzzFolkへ変換せよ
いずれにも該当しないときは自然数そのまま文字列にせよ

>>584
文字列の結合を静的にやるか動的にやるかは設計判断

こういう手順でこうしろと仕様で書かれてるとおりにやればできるならそれはただの作業であって設計ではない

将来を見越して未知のものに判断を下すのが設計、その設計の指針となるのが保守性など

君は文字列を静的に結合してコードに直書きする設計をした
君の設計は条件の追加のコストが高くつくものだった
それが事実

仕様が悪い、クライアントの頭が悪いと言っているけど実際は君の頭が悪い

そもそもFizzBuzzJazzなどの結合文字列なんか用意する必要はないよな
たまたまFizzとBuzzとJazzだけで割り切れた時に順に追記してFizzBuzzJazzが自然に生成されるだけだよな

>>585
余裕でした
https://paiza.io/projects/EQ6Ekb-JbXcRHV3gg290tg

>>588
最悪なコードだな
漏れがあるかどうかも不明
保守性も悪い

>>589
そういうこと言うな、言わん方が良い、お前のためだ

こんな感じのダサいけど読みやすいコードじゃダメなん？ Pythonユーザーはこんな感じで書く人が多いんじゃないかなと思うんだけど。
https://www.ideone.com/h3xXoq

>>591
それだと本来のFizzBuzzが動かないので失格
いくつまで処理するのか何を表示するのかは外部から与えられる
形式は自由でいいけど3→Fizzと5→Buzzが与えられた時は本来のFizzBuzzの動作

こういうこと？ 仕様を外部から与えられる方が柔軟なのはわかるけど、読みづらいから個人的にはあまり好きではないかな。
https://www.ideone.com/zSoAzy

おまえらコバロより劣るコード書いてんじゃんwww

>>591
generatorにする必要ないでしょ

for i in range(1, 21):
　print( fizzbuzz(i) )

spec/ruleを受け取るときは1回だけ処理するために
generatorにするのもありかもしれないけど>>593はそうなってない

>>587
そういう考えで勝手に仕様を変更されるからバグが発生するのですよ。
仕様どおりに作らないと検収もあがらない。

マジックナンバーは、このマジックナンバーの意味がわからないやつは触れるべからずという呪文。

>>596
仕様が誤りって事もあるんだよ？

特定のリニアな変化に対する局所最適化の話だけになってるから
もう少し違うバリエーションを考えたら？
よくあるのはこういうやつ
- Variation according to digits
- 7Boom
- Fizz-Buzz-Woof
https://xapn.github.io/fizz-buzz/#fizz-buzz-variations

>>568
だからこそ、確認を取ったにもかかわらず、その仕様でGOされたわけ笑

バカな船頭が自己満で繰り広げたゴミコードの墓場だね

>>600
君のいう仕様とはどういうこと？
どう実装すればいいかを他人に教えてもらうことが仕様なの？
君は自分ができなかったことを他人のせいにしてるだけだよ

>>595
必要というか、fizzbuzzという概念の捉え方次第じゃない？　上の方の例では大体、1, 2, Fizz, 4,... という出力をするものとしてfizzbuzz概念が捉えられているみたいだったから、Pythonで表現するときにgeneratorにするのは比較的自然な考え方だと思うけど。
595のように、単一の数値を単一の文字列に変換する関数・ルールとしてfizzbuzz概念を捉えるのであれば、それはそれでありだとは思うけど、それだけの話なのでは？

クソみたいな他人の作った仕様でゴミみたいなサンプルコード書くんじゃなく、自分が普段使いできる簡単なツールでも作れよ
今時の小学生ですら簡単なゲームくらい作ってるんだぞ。情けないなあ

最小公倍数の範囲で繰り返すだけの出力処理にオブジェクト指向もなにもあったもんじゃ無いだろ
もう使ってる処理言語がオブジェクト指向言語なんだからそれで答えは出てる
ここまで来てもオブジェクト指向がオワコンだと言う事の答えが何も示されていない

今回は、場のオブジェクト指向の試験を兼ねて作成した。
この試験の結果、出力されるものは２つの異なる（量子）統計が混在するもので、
場（ルール）と合わせて全体をみれば可逆である。
streamは個別の値が流れるわけではなく、streamという全体が演算される。
streamは可逆であり、双対性がある。可逆な中間操作をバインドして繋げばよい。
これはXXXを変えれば演算が行われるということであり、フロー型のさらに次世代を予想させる。
いいすぎな表現だが、簡単にいえば、演算は行われずに演算の結果が得られる。

「>>605は認識能力が足りません」までは読んだ

むしろ設計次第で毒にも薬にもなるって証明にはなったかもな

>>604
仕様と設計をごっちゃにしてるね。
ちゃんと会社やって仕事したことないんじゃない？

>>609
仕様がわからないと言い訳たれてんのは君だけ

他の人は言われなくても文字列を動的に結合すれば
仕様変更に強いと自分で判断してそうしてる
プログラマとしての能力を持ってるからできること

そうしてくれと言われてできるのはあたりまえでそれは作業でしかない
自分は確認を取った、それでGOされたというのも作業員でしか通用しない言い訳だよね
君は作業員としてしか仕事したことないんじゃない？

>>609
仕様→設計→コーディング

コードには設計が現れているだろw

コードが悪い＝設計が悪い

>>611
左様

>>610
仕様を逸脱したら損害が発生するんだよ。会社経営したことないだろ。

>>615
君はFizzBuzzの課題で文字列を動的に結合したら仕様を逸脱して損害が発生して会社の経営が危なくなると思っているのかい、大変だね

>>616
くすくす。
手元に詭弁の本があるけど、教科書通りの展開だね笑。

理屈に合わない仕様なら、むしろ仕様を訂正させるw

>>617
そうかい、その本の余白に俺との思い出も書き残しておいてくれよ

仕様で決めるのは目的であって方法でも手段でもないからね
文字列の結合方法を仕様で決められてもなあ

FIzZBuzzで重箱隅これだけもめて、書いたのはゴミコードって
この人たち本当にこの分野で食べているのだろうか…謎

顧客は無知なもんだから

動けばいいんだよ
だからコバロで書いてコピペして仕事が完了

コバロって何

>>624
無知かアスペかどっちか

やっぱなｗナンチャってソフトウエアエンジニアの巣窟だったかｗ

仕様で決めるのは目的であって方法じゃない、って話なら
結局設計って「どの変更をどこに閉じ込めるか」を決めることなんじゃねえの
FizzBuzzなら3→Fizzを7→Pop追加しても一箇所で済むようにするとか
そういうのが保守性の正体だろ