前スレ
オブジェクト指向はオワコン？
https://mevius.5ch.io/test/read.cgi/tech/1721393540/
オブジェクト指向はオワコン？ part2
■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
2026/08/13(木) 14:38:03.02ID:pdAcKRXu558デフォルトの名無しさん
2026/08/22(土) 13:03:54.00ID:06Fuc+wc >>557
いらない。目が潰れる
いらない。目が潰れる
560デフォルトの名無しさん
2026/08/22(土) 13:06:07.62ID:MVi0Z0Uj561デフォルトの名無しさん
2026/08/22(土) 13:07:18.47ID:qikEO/T7 どうせ使い回しなんか大きな会社でしかやらないから
負の遺産とか言われてもなぁw
そんな話なら流行りのプログラミング言語自体が負の遺産の根源なんだし
おまえの主張は単なるプログラミング言語の問題でしか無いよ
負の遺産とか言われてもなぁw
そんな話なら流行りのプログラミング言語自体が負の遺産の根源なんだし
おまえの主張は単なるプログラミング言語の問題でしか無いよ
562デフォルトの名無しさん
2026/08/22(土) 13:09:38.03ID:06Fuc+wc 開き直って、日ごろ辛いこと・不満があるんだろうなと予想はつくが
何て言って慰めてあげたらいいか俺には思いつかないな
何て言って慰めてあげたらいいか俺には思いつかないな
563デフォルトの名無しさん
2026/08/22(土) 13:10:51.18ID:T7yt1axc >>559
元のあいまいな仕様から、実装例から得られる代表的な２つの仕様のどちらにも対応できるように
書いたため、若干冗長です。
まあ、いいでしょう。そこは同じ対処で進めます。
まあ、時間がとれて気分がよければ書いときますが、おそらく夜中に酔っぱらったまま書くでしょう笑。
元のあいまいな仕様から、実装例から得られる代表的な２つの仕様のどちらにも対応できるように
書いたため、若干冗長です。
まあ、いいでしょう。そこは同じ対処で進めます。
まあ、時間がとれて気分がよければ書いときますが、おそらく夜中に酔っぱらったまま書くでしょう笑。
564デフォルトの名無しさん
2026/08/22(土) 13:13:58.93ID:MVi0Z0Uj >>563
夜中までかかるん？ 保守しやすいはずなのに？
夜中までかかるん？ 保守しやすいはずなのに？
565デフォルトの名無しさん
2026/08/22(土) 13:14:44.51ID:MVi0Z0Uj あれれーおかしいぞおー（コナンくん
566デフォルトの名無しさん
2026/08/22(土) 13:17:16.66ID:qikEO/T7567デフォルトの名無しさん
2026/08/22(土) 15:18:04.75ID:Su1GpItk568デフォルトの名無しさん
2026/08/22(土) 15:50:22.89ID:qikEO/T7 ルール追加する毎に条件分岐増やすなんて愚の骨頂だろ
569デフォルトの名無しさん
2026/08/22(土) 17:09:47.31ID:Hal9xLIK スレの流れは読めてない
要点も掴んでない
脊髄反射でシコった
>>217 java
https://ideone.com/5mCU0H
素朴だけどこういうことが大事だと思ってる
ヘタに再利用性のないクラスを作っちゃうのは罪なのでメソッドひとつで表現
OOPらしさはObject,String,Integerのみで表現
表示しなさい？ のお題に対してObjectを返してるのはそっちのほうが多少融通効いていいやろ？ 程度の判断
>>346 java
https://ideone.com/SG4fxp
再利用性のないクラスつくっちゃった版
実行時にインスタンスに対してヘコヘコ指示出して調整していくのも
OOPらしさの一面ではあるかと？
組み合わせの数が増えてくる場合、こういうのの必要性も出てくると思う
でも本当はFizzBuzzクラスというより、もっと気の利いた抽象的な概念で出来ればよかったけど
一応熟考した結果「そんなもんは特にねえや」「FizzBuzzこそが今回の概念や」となり作成
要点も掴んでない
脊髄反射でシコった
>>217 java
https://ideone.com/5mCU0H
素朴だけどこういうことが大事だと思ってる
ヘタに再利用性のないクラスを作っちゃうのは罪なのでメソッドひとつで表現
OOPらしさはObject,String,Integerのみで表現
表示しなさい？ のお題に対してObjectを返してるのはそっちのほうが多少融通効いていいやろ？ 程度の判断
>>346 java
https://ideone.com/SG4fxp
再利用性のないクラスつくっちゃった版
実行時にインスタンスに対してヘコヘコ指示出して調整していくのも
OOPらしさの一面ではあるかと？
組み合わせの数が増えてくる場合、こういうのの必要性も出てくると思う
でも本当はFizzBuzzクラスというより、もっと気の利いた抽象的な概念で出来ればよかったけど
一応熟考した結果「そんなもんは特にねえや」「FizzBuzzこそが今回の概念や」となり作成
570デフォルトの名無しさん
2026/08/22(土) 18:01:23.56ID:NuWpGxo/ 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, })
}
}
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, })
}
}
571デフォルトの名無しさん
2026/08/22(土) 18:04:19.73ID:NuWpGxo/ >>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));
}
}
続き
// 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));
}
}
572デフォルトの名無しさん
2026/08/22(土) 18:09:45.50ID:fbloiAk8573デフォルトの名無しさん
2026/08/22(土) 18:15:38.70ID:NuWpGxo/574デフォルトの名無しさん
2026/08/22(土) 20:20:50.38ID:FMHyOiEd &'static str使うコードはこの程度の仕様変更で柔軟性がない、正直アホかと
10万行コードだったらありとあらゆる所に変更が生じてアワアワする
10万行コードだったらありとあらゆる所に変更が生じてアワアワする
575デフォルトの名無しさん
2026/08/22(土) 20:29:15.43ID:NuWpGxo/ '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>], }
変更は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>], }
576デフォルトの名無しさん
2026/08/22(土) 20:50:18.75ID:T7yt1axc >>564
https://paiza.io/projects/E86OZjZm-JfK2VzqXB40Ng?language=java
酔っぱらって書いているのでbugはあるかもしれん。
暇じゃないのでな。
https://paiza.io/projects/E86OZjZm-JfK2VzqXB40Ng?language=java
酔っぱらって書いているのでbugはあるかもしれん。
暇じゃないのでな。
577デフォルトの名無しさん
2026/08/22(土) 20:54:26.25ID:MVi0Z0Uj >>576
やるじゃん
やるじゃん
578デフォルトの名無しさん
2026/08/22(土) 21:01:59.15ID:oTrAIGCX579デフォルトの名無しさん
2026/08/22(土) 21:05:27.36ID:qikEO/T7 まだやってんの？
暇だねぇ
暇だねぇ
580デフォルトの名無しさん
2026/08/22(土) 21:06:49.77ID:T7yt1axc あいまいな仕様から、あくまでも圏論的オブジェクト指向設計の例なので、
めんどーなことは、やらん。なんにしても酔っていて眠い。寝ると思う笑。
めんどーなことは、やらん。なんにしても酔っていて眠い。寝ると思う笑。
581デフォルトの名無しさん
2026/08/22(土) 22:14:47.24ID:pI2Hq+2i >>574
errorやpathやtest dataなどとりあえず&'static strはよくあるけど変更の対応は大した手間ではないよ
errorやpathやtest dataなどとりあえず&'static strはよくあるけど変更の対応は大した手間ではないよ
582デフォルトの名無しさん
2026/08/22(土) 23:33:06.51ID:Y7IH6tUx >>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")
外から受け取り算出する設計に変えないと
見るに堪えないコードになってるよ
内部がこのマジックナンバーとか
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")
583デフォルトの名無しさん
2026/08/22(土) 23:40:54.46ID:qikEO/T7584デフォルトの名無しさん
2026/08/23(日) 01:30:12.22ID:iasgGq5L へんな時間に寝たのでいちど起きてしまった。
ふ。仕様を逸脱しないようにすると全部書かざるを得ないわけよ。
仕様の不備はおれのせいじゃない、確認したしな。
こういう頭の悪いクライアントは多い。さてまた寝よう。
ふ。仕様を逸脱しないようにすると全部書かざるを得ないわけよ。
仕様の不備はおれのせいじゃない、確認したしな。
こういう頭の悪いクライアントは多い。さてまた寝よう。
585デフォルトの名無しさん
2026/08/23(日) 01:43:05.40ID:6kU/xY28 >>584
仕様は簡単
自然数を1から順に文字列へ変換せよ
3で割り切れる時はFizz
5で割り切れる時はBuzz
7で割り切れる時はPop
11で割り切れる時はJazz
13で割り切れる時はRock
17で割り切れる時はFolk
それぞれを順に並べたものとする
例えば255はFizzBuzzFolkへ変換せよ
いずれにも該当しないときは自然数そのまま文字列にせよ
仕様は簡単
自然数を1から順に文字列へ変換せよ
3で割り切れる時はFizz
5で割り切れる時はBuzz
7で割り切れる時はPop
11で割り切れる時はJazz
13で割り切れる時はRock
17で割り切れる時はFolk
それぞれを順に並べたものとする
例えば255はFizzBuzzFolkへ変換せよ
いずれにも該当しないときは自然数そのまま文字列にせよ
586デフォルトの名無しさん
2026/08/23(日) 09:34:37.37ID:F3OUjFLN >>584
文字列の結合を静的にやるか動的にやるかは設計判断
こういう手順でこうしろと仕様で書かれてるとおりにやればできるならそれはただの作業であって設計ではない
将来を見越して未知のものに判断を下すのが設計、その設計の指針となるのが保守性など
君は文字列を静的に結合してコードに直書きする設計をした
君の設計は条件の追加のコストが高くつくものだった
それが事実
仕様が悪い、クライアントの頭が悪いと言っているけど実際は君の頭が悪い
文字列の結合を静的にやるか動的にやるかは設計判断
こういう手順でこうしろと仕様で書かれてるとおりにやればできるならそれはただの作業であって設計ではない
将来を見越して未知のものに判断を下すのが設計、その設計の指針となるのが保守性など
君は文字列を静的に結合してコードに直書きする設計をした
君の設計は条件の追加のコストが高くつくものだった
それが事実
仕様が悪い、クライアントの頭が悪いと言っているけど実際は君の頭が悪い
587デフォルトの名無しさん
2026/08/23(日) 09:39:21.38ID:RCO/sdz3 そもそもFizzBuzzJazzなどの結合文字列なんか用意する必要はないよな
たまたまFizzとBuzzとJazzだけで割り切れた時に順に追記してFizzBuzzJazzが自然に生成されるだけだよな
たまたまFizzとBuzzとJazzだけで割り切れた時に順に追記してFizzBuzzJazzが自然に生成されるだけだよな
588デフォルトの名無しさん
2026/08/23(日) 09:41:36.69ID:F3OUjFLN589デフォルトの名無しさん
2026/08/23(日) 09:51:42.61ID:SzWuQqoT590デフォルトの名無しさん
2026/08/23(日) 10:24:03.77ID:F3OUjFLN >>589
そういうこと言うな、言わん方が良い、お前のためだ
そういうこと言うな、言わん方が良い、お前のためだ
591デフォルトの名無しさん
2026/08/23(日) 10:40:47.40ID:M+PVsTq+ こんな感じのダサいけど読みやすいコードじゃダメなん？ Pythonユーザーはこんな感じで書く人が多いんじゃないかなと思うんだけど。
https://www.ideone.com/h3xXoq
https://www.ideone.com/h3xXoq
592デフォルトの名無しさん
2026/08/23(日) 10:47:39.45ID:Dec9exUR >>591
それだと本来のFizzBuzzが動かないので失格
いくつまで処理するのか何を表示するのかは外部から与えられる
形式は自由でいいけど3→Fizzと5→Buzzが与えられた時は本来のFizzBuzzの動作
それだと本来のFizzBuzzが動かないので失格
いくつまで処理するのか何を表示するのかは外部から与えられる
形式は自由でいいけど3→Fizzと5→Buzzが与えられた時は本来のFizzBuzzの動作
593デフォルトの名無しさん
2026/08/23(日) 11:00:54.37ID:M+PVsTq+ こういうこと？ 仕様を外部から与えられる方が柔軟なのはわかるけど、読みづらいから個人的にはあまり好きではないかな。
https://www.ideone.com/zSoAzy
https://www.ideone.com/zSoAzy
594デフォルトの名無しさん
2026/08/23(日) 11:18:44.40ID:/SMVVWF/ おまえらコバロより劣るコード書いてんじゃんwww
595デフォルトの名無しさん
2026/08/23(日) 12:00:59.91ID:iH5V9eFJ596デフォルトの名無しさん
2026/08/23(日) 12:13:29.29ID:iasgGq5L597デフォルトの名無しさん
2026/08/23(日) 12:16:09.07ID:iasgGq5L マジックナンバーは、このマジックナンバーの意味がわからないやつは触れるべからずという呪文。
598デフォルトの名無しさん
2026/08/23(日) 12:21:27.38ID:/SMVVWF/ >>596
仕様が誤りって事もあるんだよ？
仕様が誤りって事もあるんだよ？
599デフォルトの名無しさん
2026/08/23(日) 12:30:15.64ID:iH5V9eFJ 特定のリニアな変化に対する局所最適化の話だけになってるから
もう少し違うバリエーションを考えたら？
よくあるのはこういうやつ
- Variation according to digits
- 7Boom
- Fizz-Buzz-Woof
https://xapn.github.io/fizz-buzz/#fizz-buzz-variations
もう少し違うバリエーションを考えたら？
よくあるのはこういうやつ
- Variation according to digits
- 7Boom
- Fizz-Buzz-Woof
https://xapn.github.io/fizz-buzz/#fizz-buzz-variations
600デフォルトの名無しさん
2026/08/23(日) 12:31:16.30ID:iasgGq5L >>568
だからこそ、確認を取ったにもかかわらず、その仕様でGOされたわけ笑
だからこそ、確認を取ったにもかかわらず、その仕様でGOされたわけ笑
601デフォルトの名無しさん
2026/08/23(日) 12:32:45.51ID:LXYwYlQF バカな船頭が自己満で繰り広げたゴミコードの墓場だね
602デフォルトの名無しさん
2026/08/23(日) 12:39:24.70ID:F3OUjFLN603デフォルトの名無しさん
2026/08/23(日) 12:39:48.34ID:M+PVsTq+ >>595
必要というか、fizzbuzzという概念の捉え方次第じゃない？ 上の方の例では大体、1, 2, Fizz, 4,... という出力をするものとしてfizzbuzz概念が捉えられているみたいだったから、Pythonで表現するときにgeneratorにするのは比較的自然な考え方だと思うけど。
595のように、単一の数値を単一の文字列に変換する関数・ルールとしてfizzbuzz概念を捉えるのであれば、それはそれでありだとは思うけど、それだけの話なのでは？
必要というか、fizzbuzzという概念の捉え方次第じゃない？ 上の方の例では大体、1, 2, Fizz, 4,... という出力をするものとしてfizzbuzz概念が捉えられているみたいだったから、Pythonで表現するときにgeneratorにするのは比較的自然な考え方だと思うけど。
595のように、単一の数値を単一の文字列に変換する関数・ルールとしてfizzbuzz概念を捉えるのであれば、それはそれでありだとは思うけど、それだけの話なのでは？
604デフォルトの名無しさん
2026/08/23(日) 12:45:26.71ID:DMCqliCM クソみたいな他人の作った仕様でゴミみたいなサンプルコード書くんじゃなく、自分が普段使いできる簡単なツールでも作れよ
今時の小学生ですら簡単なゲームくらい作ってるんだぞ。情けないなあ
今時の小学生ですら簡単なゲームくらい作ってるんだぞ。情けないなあ
605デフォルトの名無しさん
2026/08/23(日) 12:47:28.81ID:/SMVVWF/ 最小公倍数の範囲で繰り返すだけの出力処理にオブジェクト指向もなにもあったもんじゃ無いだろ
もう使ってる処理言語がオブジェクト指向言語なんだからそれで答えは出てる
ここまで来てもオブジェクト指向がオワコンだと言う事の答えが何も示されていない
もう使ってる処理言語がオブジェクト指向言語なんだからそれで答えは出てる
ここまで来てもオブジェクト指向がオワコンだと言う事の答えが何も示されていない
606デフォルトの名無しさん
2026/08/23(日) 12:48:46.54ID:iasgGq5L 今回は、場のオブジェクト指向の試験を兼ねて作成した。
この試験の結果、出力されるものは２つの異なる（量子）統計が混在するもので、
場（ルール）と合わせて全体をみれば可逆である。
streamは個別の値が流れるわけではなく、streamという全体が演算される。
streamは可逆であり、双対性がある。可逆な中間操作をバインドして繋げばよい。
これはXXXを変えれば演算が行われるということであり、フロー型のさらに次世代を予想させる。
いいすぎな表現だが、簡単にいえば、演算は行われずに演算の結果が得られる。
この試験の結果、出力されるものは２つの異なる（量子）統計が混在するもので、
場（ルール）と合わせて全体をみれば可逆である。
streamは個別の値が流れるわけではなく、streamという全体が演算される。
streamは可逆であり、双対性がある。可逆な中間操作をバインドして繋げばよい。
これはXXXを変えれば演算が行われるということであり、フロー型のさらに次世代を予想させる。
いいすぎな表現だが、簡単にいえば、演算は行われずに演算の結果が得られる。
607デフォルトの名無しさん
2026/08/23(日) 12:49:54.67ID:HWzbbtqX 「>>605は認識能力が足りません」までは読んだ
608デフォルトの名無しさん
2026/08/23(日) 12:50:38.64ID:/SMVVWF/ むしろ設計次第で毒にも薬にもなるって証明にはなったかもな
609デフォルトの名無しさん
2026/08/23(日) 12:53:14.80ID:iasgGq5L610デフォルトの名無しさん
2026/08/23(日) 12:56:45.45ID:F3OUjFLN >>609
仕様がわからないと言い訳たれてんのは君だけ
他の人は言われなくても文字列を動的に結合すれば
仕様変更に強いと自分で判断してそうしてる
プログラマとしての能力を持ってるからできること
そうしてくれと言われてできるのはあたりまえでそれは作業でしかない
自分は確認を取った、それでGOされたというのも作業員でしか通用しない言い訳だよね
君は作業員としてしか仕事したことないんじゃない？
仕様がわからないと言い訳たれてんのは君だけ
他の人は言われなくても文字列を動的に結合すれば
仕様変更に強いと自分で判断してそうしてる
プログラマとしての能力を持ってるからできること
そうしてくれと言われてできるのはあたりまえでそれは作業でしかない
自分は確認を取った、それでGOされたというのも作業員でしか通用しない言い訳だよね
君は作業員としてしか仕事したことないんじゃない？
611デフォルトの名無しさん
2026/08/23(日) 13:03:04.51ID:/SMVVWF/ >>609
仕様→設計→コーディング
仕様→設計→コーディング
612デフォルトの名無しさん
2026/08/23(日) 13:04:01.05ID:/SMVVWF/ コードには設計が現れているだろw
613デフォルトの名無しさん
2026/08/23(日) 13:05:56.08ID:/SMVVWF/ コードが悪い＝設計が悪い
614デフォルトの名無しさん
2026/08/23(日) 13:08:55.68ID:F3OUjFLN >>611
左様
左様
615デフォルトの名無しさん
2026/08/23(日) 13:13:24.37ID:iasgGq5L >>610
仕様を逸脱したら損害が発生するんだよ。会社経営したことないだろ。
仕様を逸脱したら損害が発生するんだよ。会社経営したことないだろ。
616デフォルトの名無しさん
2026/08/23(日) 13:21:09.56ID:F3OUjFLN >>615
君はFizzBuzzの課題で文字列を動的に結合したら仕様を逸脱して損害が発生して会社の経営が危なくなると思っているのかい、大変だね
君はFizzBuzzの課題で文字列を動的に結合したら仕様を逸脱して損害が発生して会社の経営が危なくなると思っているのかい、大変だね
617デフォルトの名無しさん
2026/08/23(日) 13:28:56.47ID:iasgGq5L618デフォルトの名無しさん
2026/08/23(日) 13:29:48.18ID:/SMVVWF/ 理屈に合わない仕様なら、むしろ仕様を訂正させるw
619デフォルトの名無しさん
2026/08/23(日) 13:36:03.60ID:F3OUjFLN >>617
そうかい、その本の余白に俺との思い出も書き残しておいてくれよ
そうかい、その本の余白に俺との思い出も書き残しておいてくれよ
620デフォルトの名無しさん
2026/08/23(日) 13:39:32.97ID:F3OUjFLN 仕様で決めるのは目的であって方法でも手段でもないからね
文字列の結合方法を仕様で決められてもなあ
文字列の結合方法を仕様で決められてもなあ
621デフォルトの名無しさん
2026/08/23(日) 14:04:47.40ID:HWzbbtqX FIzZBuzzで重箱隅これだけもめて、書いたのはゴミコードって
この人たち本当にこの分野で食べているのだろうか…謎
この人たち本当にこの分野で食べているのだろうか…謎
622デフォルトの名無しさん
2026/08/23(日) 14:32:48.12ID:QvCbW4h1 顧客は無知なもんだから
623デフォルトの名無しさん
2026/08/23(日) 14:38:22.96ID:/SMVVWF/ 動けばいいんだよ
だからコバロで書いてコピペして仕事が完了
だからコバロで書いてコピペして仕事が完了
624デフォルトの名無しさん
2026/08/23(日) 14:50:41.16ID:QvCbW4h1 コバロって何
625デフォルトの名無しさん
2026/08/23(日) 14:59:42.81ID:wVoNaoye >>624
無知かアスペかどっちか
無知かアスペかどっちか
626デフォルトの名無しさん
2026/08/23(日) 15:06:20.12ID:HWzbbtqX やっぱなｗナンチャってソフトウエアエンジニアの巣窟だったかｗ
627デフォルトの名無しさん
2026/08/23(日) 15:28:12.05ID:KkX4SDMy 仕様で決めるのは目的であって方法じゃない、って話なら
結局設計って「どの変更をどこに閉じ込めるか」を決めることなんじゃねえの
FizzBuzzなら3→Fizzを7→Pop追加しても一箇所で済むようにするとか
そういうのが保守性の正体だろ
結局設計って「どの変更をどこに閉じ込めるか」を決めることなんじゃねえの
FizzBuzzなら3→Fizzを7→Pop追加しても一箇所で済むようにするとか
そういうのが保守性の正体だろ
628デフォルトの名無しさん
2026/08/23(日) 15:30:54.39ID:KkX4SDMy ただ変更に強いって言い方も雑なんだよな
Fizz Buzz Popが増える変更には強くても
倍数じゃなくて桁に3が入ってたらFizzに変わったら全部崩れるかもしれない
何の変更に対して局所化してるか、まで言わないと意味ない
Fizz Buzz Popが増える変更には強くても
倍数じゃなくて桁に3が入ってたらFizzに変わったら全部崩れるかもしれない
何の変更に対して局所化してるか、まで言わないと意味ない
629デフォルトの名無しさん
2026/08/23(日) 15:33:32.71ID:KkX4SDMy そう考えると設計の良し悪しって
変更するときにどこまで見に行かされるかでかなり決まる気がする
何についてのコードか
何に依存してるか
どこ直せばいいか
何テストすればいいか
これが近所だけ見て分かるコードは楽
変更するときにどこまで見に行かされるかでかなり決まる気がする
何についてのコードか
何に依存してるか
どこ直せばいいか
何テストすればいいか
これが近所だけ見て分かるコードは楽
630デフォルトの名無しさん
2026/08/23(日) 15:34:15.40ID:tl6J+3gQ631デフォルトの名無しさん
2026/08/23(日) 15:37:49.27ID:KkX4SDMy 逆に一箇所直すのに
親クラス見て
interface見て
DI設定見て
Factory見て
Listener見て
どこでoverrideされてるか検索して
みたいになるとキツい
コード量じゃなくて探索範囲がでかい
親クラス見て
interface見て
DI設定見て
Factory見て
Listener見て
どこでoverrideされてるか検索して
みたいになるとキツい
コード量じゃなくて探索範囲がでかい
632デフォルトの名無しさん
2026/08/23(日) 15:39:26.68ID:QvCbW4h1 関数にしてその中でご自由にどうぞでええやん
633デフォルトの名無しさん
2026/08/23(日) 15:44:28.67ID:KkX4SDMy そうなるとあれ
それって昔OOPが解決しようとしてた問題じゃなかったっけ
データとそれを操作する処理をオブジェクトに閉じ込めて
内部知らなくても使えるようにするって話だろ
本来は局所化するための仕組みだったはず
それって昔OOPが解決しようとしてた問題じゃなかったっけ
データとそれを操作する処理をオブジェクトに閉じ込めて
内部知らなくても使えるようにするって話だろ
本来は局所化するための仕組みだったはず
634デフォルトの名無しさん
2026/08/23(日) 15:48:19.79ID:KkX4SDMy なのに実際のOOPコードだと
継承
動的ディスパッチ
DI
Observer
ORM
フレームワークのライフサイクル
とか乗りまくって
そのオブジェクトが何するか知るために全然違う場所見に行く羽目になるんだよな
継承
動的ディスパッチ
DI
Observer
ORM
フレームワークのライフサイクル
とか乗りまくって
そのオブジェクトが何するか知るために全然違う場所見に行く羽目になるんだよな
635デフォルトの名無しさん
2026/08/23(日) 15:50:25.49ID:F3OUjFLN お前らほんまFizzBuzz好きやなあ
俺はそんなお前らが好きだ
俺はそんなお前らが好きだ
636デフォルトの名無しさん
2026/08/23(日) 15:52:04.46ID:KkX4SDMy つまりオブジェクトが情報を閉じ込める箱じゃなくて
依存関係を集めるハブになっちゃったのが問題なんじゃね
UserServiceとかOrderManagerとかいう名前だけ局所的で
中身はDBもメールも決済もログもイベントも何でも触るやつ
依存関係を集めるハブになっちゃったのが問題なんじゃね
UserServiceとかOrderManagerとかいう名前だけ局所的で
中身はDBもメールも決済もログもイベントも何でも触るやつ
637デフォルトの名無しさん
2026/08/23(日) 15:55:00.72ID:KkX4SDMy そう考えるとOOPは変更に強いじゃなくて
カプセル化がうまくいってれば変更に強いなんじゃね
クラス使ってるだけでは何も保証されないどころか
継承とかshared mutable stateで逆に非局所化することもある
カプセル化がうまくいってれば変更に強いなんじゃね
クラス使ってるだけでは何も保証されないどころか
継承とかshared mutable stateで逆に非局所化することもある
638デフォルトの名無しさん
2026/08/23(日) 15:56:09.08ID:/SMVVWF/ 仕様が変われば設計だって変わるのは当たり前だ
なんでも予測して変更に耐えられる設計なんて存在しないから
変更があるとすれば固定値や特定条件とかくらい、それ以上は仕様からやり直し
なんでも予測して変更に耐えられる設計なんて存在しないから
変更があるとすれば固定値や特定条件とかくらい、それ以上は仕様からやり直し
639デフォルトの名無しさん
2026/08/23(日) 15:58:32.65ID:KkX4SDMy で最近のGoとかRustとか見てると
クラスを捨てたというよりデータメソッド、interface、trait、所有権、可変性をバラして必要なものだけ組み合わせる方向なんだよな
昔class一個に背負わせてた責務を分解してるように見える
クラスを捨てたというよりデータメソッド、interface、trait、所有権、可変性をバラして必要なものだけ組み合わせる方向なんだよな
昔class一個に背負わせてた責務を分解してるように見える
640デフォルトの名無しさん
2026/08/23(日) 16:00:04.51ID:F3OUjFLN >>392
そうね、flatMapは平坦化できることと要素数を変えられるのが特徴
モダンな言語だとジェネレータがあるからflatMapの出番はない気がする
ジェネレータがない言語だとflatMapを使うと良い感じ
たとえば組み合わせを列挙するコードはジェネレータで書くとこう
IEnumerable<ImmutableQueue<T>> CombinationGeneratorStyle<T>(ImmutableQueue<T> queue) {
return F(queue, ImmutableQueue<T>.Empty);
IEnumerable<ImmutableQueue<T>> F(ImmutableQueue<T> q, ImmutableQueue<T> r) {
yield return r;
for (; !q.IsEmpty; q = q.Dequeue()) {
foreach (var sub in F(q.Dequeue(), r.Enqueue(q.Peek()))) {
yield return sub;
}
}
}
}
そうね、flatMapは平坦化できることと要素数を変えられるのが特徴
モダンな言語だとジェネレータがあるからflatMapの出番はない気がする
ジェネレータがない言語だとflatMapを使うと良い感じ
たとえば組み合わせを列挙するコードはジェネレータで書くとこう
IEnumerable<ImmutableQueue<T>> CombinationGeneratorStyle<T>(ImmutableQueue<T> queue) {
return F(queue, ImmutableQueue<T>.Empty);
IEnumerable<ImmutableQueue<T>> F(ImmutableQueue<T> q, ImmutableQueue<T> r) {
yield return r;
for (; !q.IsEmpty; q = q.Dequeue()) {
foreach (var sub in F(q.Dequeue(), r.Enqueue(q.Peek()))) {
yield return sub;
}
}
}
}
641デフォルトの名無しさん
2026/08/23(日) 16:00:38.10ID:HWzbbtqX class原理主義・第一主義よりは良くなってきたし面白くなってきたよな
どう発展していくかな
どう発展していくかな
642デフォルトの名無しさん
2026/08/23(日) 16:00:48.79ID:F3OUjFLN >>640
flatMapで書くとこう
IEnumerable<ImmutableQueue<T>> CombinationMonadicStyle<T>(ImmutableQueue<T> queue) {
return F(queue, ImmutableQueue<T>.Empty);
IEnumerable<ImmutableQueue<T>> F(ImmutableQueue<T> q, ImmutableQueue<T> r) {
return new[] { r }.Concat(
For(q, x => !x.IsEmpty, x => x.Dequeue())
.SelectMany(x => F(x.Dequeue(), r.Enqueue(x.Peek()))));
}
}
IEnumerable<T> For<T>(T seed, Func<T, bool> hasNext, Func<T, T> next) {
return hasNext(seed)
? new[] { seed }.Concat(
new[] { seed }
.SelectMany(x => For<T>(next(x), hasNext, next)))
: [];
}
flatMapで書くとこう
IEnumerable<ImmutableQueue<T>> CombinationMonadicStyle<T>(ImmutableQueue<T> queue) {
return F(queue, ImmutableQueue<T>.Empty);
IEnumerable<ImmutableQueue<T>> F(ImmutableQueue<T> q, ImmutableQueue<T> r) {
return new[] { r }.Concat(
For(q, x => !x.IsEmpty, x => x.Dequeue())
.SelectMany(x => F(x.Dequeue(), r.Enqueue(x.Peek()))));
}
}
IEnumerable<T> For<T>(T seed, Func<T, bool> hasNext, Func<T, T> next) {
return hasNext(seed)
? new[] { seed }.Concat(
new[] { seed }
.SelectMany(x => For<T>(next(x), hasNext, next)))
: [];
}
643デフォルトの名無しさん
2026/08/23(日) 16:04:01.11ID:KkX4SDMy じゃあOOPオワコンって
オブジェクトとかカプセル化がオワコンなんじゃなくて
クラス作って継承とポリモーフィズムで世界をモデル化すれば
自然と変更に強い設計になる
っていう古典的OOP観がオワコンなんじゃね？
局所性を作るために生まれたOOPが
使い方次第で非局所性の発生源になった、という話なら割と筋通る気がする
オブジェクトとかカプセル化がオワコンなんじゃなくて
クラス作って継承とポリモーフィズムで世界をモデル化すれば
自然と変更に強い設計になる
っていう古典的OOP観がオワコンなんじゃね？
局所性を作るために生まれたOOPが
使い方次第で非局所性の発生源になった、という話なら割と筋通る気がする
644デフォルトの名無しさん
2026/08/23(日) 16:05:08.08ID:+hvJAYKo クラスは不要
クラスは時代遅れ
クラスは時代遅れ
645デフォルトの名無しさん
2026/08/23(日) 16:10:43.94ID:xuiTfLZn classを全否定するつもりは無いけどstructとmethodだけでいいし特に継承はオブジェクト指向の負の遺産
646デフォルトの名無しさん
2026/08/23(日) 16:14:12.45ID:HWzbbtqX647デフォルトの名無しさん
2026/08/23(日) 16:16:35.09ID:/SMVVWF/ 大きな仕様変更は関係が変わるんだからそりゃあ既存の設計じゃ満たせないのは当たり前
万能な設計なんて無いんだからそれをオブジェクト指向のせいにするのはお門違いだ
万能な設計なんて無いんだからそれをオブジェクト指向のせいにするのはお門違いだ
648デフォルトの名無しさん
2026/08/23(日) 16:19:21.65ID:iasgGq5L classでなくともよいのだが、関係性の集まりを指示できる対象が必要となる。
これを「場」とみなせば、
場のオブジェクト指向は、場にメッセージを投げ入れると何らかの反応があったり/なかったりするもの、
ということになる。
場の演算子が反応すれば、observableが返ってくる/かもしれない。
これを「場」とみなせば、
場のオブジェクト指向は、場にメッセージを投げ入れると何らかの反応があったり/なかったりするもの、
ということになる。
場の演算子が反応すれば、observableが返ってくる/かもしれない。
649デフォルトの名無しさん
2026/08/23(日) 16:24:20.60ID:HWzbbtqX ひー
650デフォルトの名無しさん
2026/08/23(日) 16:32:26.38ID:iasgGq5L 場のオブジェクト指向が目指すところは可逆演算（可逆計算）と量子コンピューティングだ。
場は「局所」ではない。関数型計算の究極形だろう（理想）。
場の計算理論の前に、数学そのものの正体が場の（量子）情報理論であると考え中。
場は「局所」ではない。関数型計算の究極形だろう（理想）。
場の計算理論の前に、数学そのものの正体が場の（量子）情報理論であると考え中。
651デフォルトの名無しさん
2026/08/23(日) 16:32:53.18ID:QbJdGCa2 >>643
>クラス作って継承とポリモーフィズムで世界をモデル化すれば
>自然と変更に強い設計になる
90~00年頃の考え方だよね
変わりやすい部分と変わりにくい部分を見極めて
どういう種類の変更に強くするか取捨選択する必要がある
オブジェクト指向に限った話ではない
FizzBuzzを動的文字列結合で解決する話も
3と5と両方で割り切れるならWYAAAYYY!! にするような変更にはめっぽう弱いのと同じ
>クラス作って継承とポリモーフィズムで世界をモデル化すれば
>自然と変更に強い設計になる
90~00年頃の考え方だよね
変わりやすい部分と変わりにくい部分を見極めて
どういう種類の変更に強くするか取捨選択する必要がある
オブジェクト指向に限った話ではない
FizzBuzzを動的文字列結合で解決する話も
3と5と両方で割り切れるならWYAAAYYY!! にするような変更にはめっぽう弱いのと同じ
652デフォルトの名無しさん
2026/08/23(日) 16:37:17.16ID:QbJdGCa2653デフォルトの名無しさん
2026/08/23(日) 16:45:22.29ID:HWzbbtqX GUI FWは継承がうまくいった稀な応用だと思うが
654デフォルトの名無しさん
2026/08/23(日) 16:50:32.37ID:/SMVVWF/ 特定用途に偏った設計が別の特定用途に整合できるはずが無いんだよね
最初からそれ以外の用途では使わないなら
それは良いも悪いも無いからね
最初からそれ以外の用途では使わないなら
それは良いも悪いも無いからね
655デフォルトの名無しさん
2026/08/23(日) 16:52:50.80ID:/SMVVWF/ オブジェクト指向は万能みたいな夢を騙るから失敗してるとか訳の分からない話をし出す
どんなソフトウェア技法だって万能なんか無い
どんなソフトウェア技法だって万能なんか無い
656デフォルトの名無しさん
2026/08/23(日) 16:55:54.03ID:HWzbbtqX クラス(カプセル化)、動的インスタンス(動的extent)、継承、多態といったもので
プログラムを現すモデルとして実は適していなかったおそれがあると思う
プログラムを現すモデルとして実は適していなかったおそれがあると思う
657デフォルトの名無しさん
2026/08/23(日) 17:10:09.30ID:/SMVVWF/ おまえら、気づかないうちにクラスメソッド使いまくってるじゃんw
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 【X】高市首相、米兵逮捕「極めて遺憾」 [少考さん★]
- 「運動音痴にとって、体育の授業は『公開処刑』」 運動嫌いを生みだす日本の教育の問題点★2 [征夷大将軍★]
- 夫婦の性行為は義務なのか 「したくない」と言ったら？法学者の見解 [おっさん友の会★]
- 【沖縄】米海兵隊の20歳男を強盗殺人容疑で逮捕 那覇市のホテルで女性殺害し財布など奪った疑い 「私は知りません」容疑否認 [ぐれ★]
- 【速報】高市首相の「寝てない」にＳＮＳ賛否「命がけで頑張っている」「アピールはもうけっこう」 海外メディアも注目 (共同通信) [少考さん★]
- 維新議員が″御用達の料亭″のために…！水道局へ圧力、謝罪要求まで「工事代金は税金負担」 [バイト歴50年★]
- 【悲報】高市洋一、2ちゃん発祥の「六韜」デマで岩屋を批判→総ツッコミを食らい「記述はないが示唆する文章はある」と釈明 [834922174]
- 日本料理、アジアで一番不味いとの評価頂く。→日本人なぜか発狂 [668024367]
- 東京のインフレ率3%突破・・・・・ [931948549]
- 【悲報】日本人、気づき始める「あれ？俺たちなんか貧しくなってね？」ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ [379664288]
- 



ハズレのお🏡




- お前らの家のコバエ発生源教えろ