前スレ
オブジェクト指向システムの設計 172
http://mevius.2ch.net/test/read.cgi/tech/1467992113
類似スレ
手続き型システムの設計 1
http://mevius.2ch.net/test/read.cgi/tech/1500282714
オブジェクト指向システムの設計 173 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
2017/08/08(火) 17:52:14.38ID:4Kd2O+xB603デフォルトの名無しさん
2017/09/18(月) 22:30:51.87ID:IcOpWHLw604デフォルトの名無しさん
2017/09/18(月) 22:32:21.17ID:FKyHuAgC >>542
それは知らないだけだろ
オブジェクトの指向の源流だから
今当たり前に使っている技術も
Smalltalkから生まれてきた
たとえばRubyが「すべてはオブジェクト」だ
っていうのもSmalltalkが元祖
テストフレームワークも
最初にSmalltalkで生まれた
それは知らないだけだろ
オブジェクトの指向の源流だから
今当たり前に使っている技術も
Smalltalkから生まれてきた
たとえばRubyが「すべてはオブジェクト」だ
っていうのもSmalltalkが元祖
テストフレームワークも
最初にSmalltalkで生まれた
605デフォルトの名無しさん
2017/09/18(月) 22:33:28.20ID:FKyHuAgC >>547
それで君はどこの土人だい?
それで君はどこの土人だい?
606デフォルトの名無しさん
2017/09/18(月) 22:41:02.34ID:9UUI5dsL >>603
入門書に書いてあるだろ
入門書に書いてあるだろ
607デフォルトの名無しさん
2017/09/18(月) 22:42:30.53ID:9UUI5dsL608デフォルトの名無しさん
2017/09/18(月) 22:42:59.21ID:FKyHuAgC >>561
>Web開発はサービス単位で遅延結合が出来てる
マイクロサービスが典型的だな
サービスを分けることでマクロに遅延結合できる
だけど別にアランケイが間違っていたわけじゃなくて
むしろその発想を大規模に発展させた結果だよね
Smalltalk誕生の時代にはインターネットなかったから
>Web開発はサービス単位で遅延結合が出来てる
マイクロサービスが典型的だな
サービスを分けることでマクロに遅延結合できる
だけど別にアランケイが間違っていたわけじゃなくて
むしろその発想を大規模に発展させた結果だよね
Smalltalk誕生の時代にはインターネットなかったから
609デフォルトの名無しさん
2017/09/18(月) 22:44:38.63ID:IcOpWHLw610デフォルトの名無しさん
2017/09/18(月) 22:45:57.14ID:nAoTSCTK611デフォルトの名無しさん
2017/09/18(月) 22:49:49.74ID:4Oi7LGiO612デフォルトの名無しさん
2017/09/18(月) 22:51:03.60ID:4Oi7LGiO >>608
> だけど別にアランケイが間違っていたわけじゃなくて
アランケイが間違っていたのはオブジェクト指向や
Smalltalkで実現しようとしていた所
マイクロサービスにSmalltalkもオブジェクト指向も関係ない
> だけど別にアランケイが間違っていたわけじゃなくて
アランケイが間違っていたのはオブジェクト指向や
Smalltalkで実現しようとしていた所
マイクロサービスにSmalltalkもオブジェクト指向も関係ない
613デフォルトの名無しさん
2017/09/18(月) 22:52:02.80ID:9UUI5dsL614デフォルトの名無しさん
2017/09/18(月) 22:55:18.51ID:ACfwNVcC >>603
わざわざ書く必要がないほど自明だからだよ。
だけど初心者には分からない。なぜならOOPは大規模じゃないとメリットが無いから。
だから大きい(10k行以上)の物を書き、保守をしばらく続ければ、誰でもわかるようになる。
例えばCの手続き型で書いたとしても、保守しやすく保てば、だんだんOOPに似てくる。
これが分かっているからJava等では最初から初心者をOOP信者として洗脳しようとする。
ところが初心者にはOOPのメリットが見えるはずもない。これが大体のパターン。
500行程度のプログラムをOOPで書いても大してメリットない。当然理解出来るはずもない。
最低3k行程度、出来れば10k行以上書いて保守してみ。いやでも分かる。
わざわざ書く必要がないほど自明だからだよ。
だけど初心者には分からない。なぜならOOPは大規模じゃないとメリットが無いから。
だから大きい(10k行以上)の物を書き、保守をしばらく続ければ、誰でもわかるようになる。
例えばCの手続き型で書いたとしても、保守しやすく保てば、だんだんOOPに似てくる。
これが分かっているからJava等では最初から初心者をOOP信者として洗脳しようとする。
ところが初心者にはOOPのメリットが見えるはずもない。これが大体のパターン。
500行程度のプログラムをOOPで書いても大してメリットない。当然理解出来るはずもない。
最低3k行程度、出来れば10k行以上書いて保守してみ。いやでも分かる。
615デフォルトの名無しさん
2017/09/18(月) 23:03:49.23ID:FKyHuAgC616デフォルトの名無しさん
2017/09/18(月) 23:04:53.82ID:IcOpWHLw617デフォルトの名無しさん
2017/09/18(月) 23:07:52.17ID:4Oi7LGiO618デフォルトの名無しさん
2017/09/18(月) 23:16:18.54ID:ACfwNVcC >>616
オブジェクト指向の利点が分からず、君がいっぱしのプログラムを書けるというのなら、
その君のやり方で大規模な物を書いて保守してみればいい。
だんだんオブジェクト指向に似てくるから。
500行程度のプログラムを書き捨てするのなら、大してメリットはないし、当然理解も出来ないよ。
プログラミング言語C++とか読めば、いろいろ具体的にハゲが力説してるよ。
ただその意味は初心者には分からないと思うよ。
オブジェクト指向の利点が分からず、君がいっぱしのプログラムを書けるというのなら、
その君のやり方で大規模な物を書いて保守してみればいい。
だんだんオブジェクト指向に似てくるから。
500行程度のプログラムを書き捨てするのなら、大してメリットはないし、当然理解も出来ないよ。
プログラミング言語C++とか読めば、いろいろ具体的にハゲが力説してるよ。
ただその意味は初心者には分からないと思うよ。
619デフォルトの名無しさん
2017/09/18(月) 23:18:19.59ID:IcOpWHLw620デフォルトの名無しさん
2017/09/18(月) 23:20:22.40ID:ACfwNVcC621デフォルトの名無しさん
2017/09/18(月) 23:21:34.19ID:IcOpWHLw622デフォルトの名無しさん
2017/09/18(月) 23:22:51.75ID:IcOpWHLw623デフォルトの名無しさん
2017/09/18(月) 23:24:17.62ID:FKyHuAgC 規模が大きくなるほど
手続き型で保守しにくくなる
大規模プログラムで保守性が高まるのは
オブジェクト指向のメリットのひとつで
いろんな入門書に書いてある
手続き型で保守しにくくなる
大規模プログラムで保守性が高まるのは
オブジェクト指向のメリットのひとつで
いろんな入門書に書いてある
624デフォルトの名無しさん
2017/09/18(月) 23:27:29.49ID:4Oi7LGiO625デフォルトの名無しさん
2017/09/18(月) 23:27:57.21ID:DpRq8b6A626デフォルトの名無しさん
2017/09/18(月) 23:28:42.89ID:9UUI5dsL ID:IcOpWHLwが論点を挙げられないのは
テキトーに否定するだけだったからか
テキトーに否定するだけだったからか
627デフォルトの名無しさん
2017/09/18(月) 23:28:45.85ID:ACfwNVcC >>619
日本語でおk
日本語でおk
628デフォルトの名無しさん
2017/09/18(月) 23:30:22.06ID:IcOpWHLw629デフォルトの名無しさん
2017/09/18(月) 23:31:42.19ID:IcOpWHLw >>626
お前は全くメリット挙げられないクズ
お前は全くメリット挙げられないクズ
630デフォルトの名無しさん
2017/09/18(月) 23:32:46.81ID:IcOpWHLw631デフォルトの名無しさん
2017/09/18(月) 23:34:05.63ID:9UUI5dsL >>629
説明損になるとこだったよ
説明損になるとこだったよ
632デフォルトの名無しさん
2017/09/18(月) 23:35:05.51ID:IcOpWHLw >>631
消えろ邪魔
消えろ邪魔
633デフォルトの名無しさん
2017/09/18(月) 23:36:35.21ID:9UUI5dsL メリットなんてケースによるんだから否定するのは容易い
俺は大規模開発なんてしないもん!とかな
自分の開発対象にあった開発方法をとって、
その上での議論だろ
俺は大規模開発なんてしないもん!とかな
自分の開発対象にあった開発方法をとって、
その上での議論だろ
634デフォルトの名無しさん
2017/09/18(月) 23:37:27.40ID:9UUI5dsL635デフォルトの名無しさん
2017/09/18(月) 23:37:50.84ID:IcOpWHLw636デフォルトの名無しさん
2017/09/18(月) 23:39:45.83ID:9UUI5dsL なんで見えないのにわかるんだ
口からでまかせばかりだな
口からでまかせばかりだな
637デフォルトの名無しさん
2017/09/18(月) 23:44:08.97ID:ACfwNVcC >>624
ちなみに俺はそれもありだと思ってるよ。
具体的に言えばJavaScriptの連中が壮絶に酷くて、OOPどころかそれ以前なんだけど、
実際はそれでも結構動いてしまう。
理由は簡単で、サーバー/クライアント構成でデータ管理は完全に分離されてて、
データクエリはhttpでフォーマットもJSONとお決まりで、何も考える必要なく、
JavaScriptは単にGUIの装飾だけやればいい感じだから。
抽象度もそれなりだから50行位で一機能出来てしまって、
5個くらい(=250行)あればまあまあ見栄えしてしまう。
ああこれでは成長せんなーとは思ったね。
この規模なら毎回コピペ+書き捨ての方が生産性高いし。
ただ、従来はデータ管理等も全部自前でやるから肥大化するのであって、
正直OOPでがんばって自前でやりくりするより、
既製品のDBとか使ってマッシュアップするJavaScript的開発の方が楽だから、
今後はそうなる気もする。
ちなみに俺はそれもありだと思ってるよ。
具体的に言えばJavaScriptの連中が壮絶に酷くて、OOPどころかそれ以前なんだけど、
実際はそれでも結構動いてしまう。
理由は簡単で、サーバー/クライアント構成でデータ管理は完全に分離されてて、
データクエリはhttpでフォーマットもJSONとお決まりで、何も考える必要なく、
JavaScriptは単にGUIの装飾だけやればいい感じだから。
抽象度もそれなりだから50行位で一機能出来てしまって、
5個くらい(=250行)あればまあまあ見栄えしてしまう。
ああこれでは成長せんなーとは思ったね。
この規模なら毎回コピペ+書き捨ての方が生産性高いし。
ただ、従来はデータ管理等も全部自前でやるから肥大化するのであって、
正直OOPでがんばって自前でやりくりするより、
既製品のDBとか使ってマッシュアップするJavaScript的開発の方が楽だから、
今後はそうなる気もする。
638デフォルトの名無しさん
2017/09/18(月) 23:48:22.36ID:ACfwNVcC >>630
> そんなにオブジェクト指向のメリットが常識だって主張するなら
> 書いてあるサイト探してこいって言ってんだよ
これを主張した奴はこのスレ内にはいない。
つまり、日本語でおk
俺が言ったのは「プログラミング言語C++」で、これは本だ。
お前が知りたいのなら、おまえ自身が探してきて、
ここにこんなこと書いてますが合ってますか?と訪ねればいいだろ。
> そんなにオブジェクト指向のメリットが常識だって主張するなら
> 書いてあるサイト探してこいって言ってんだよ
これを主張した奴はこのスレ内にはいない。
つまり、日本語でおk
俺が言ったのは「プログラミング言語C++」で、これは本だ。
お前が知りたいのなら、おまえ自身が探してきて、
ここにこんなこと書いてますが合ってますか?と訪ねればいいだろ。
639デフォルトの名無しさん
2017/09/18(月) 23:52:37.86ID:nAoTSCTK640デフォルトの名無しさん
2017/09/18(月) 23:55:59.34ID:FKyHuAgC >>637
ああそういう所はあるよな
Web(アプリ)って単体のコードは
壮絶に汚くなりがちだし
OOPも退化してる
だがフロントエンドとバックエンドを分けるとか
Webの仕組みが上手くできてるんで
それでも何とかなっちゃうんだよな
ああそういう所はあるよな
Web(アプリ)って単体のコードは
壮絶に汚くなりがちだし
OOPも退化してる
だがフロントエンドとバックエンドを分けるとか
Webの仕組みが上手くできてるんで
それでも何とかなっちゃうんだよな
641デフォルトの名無しさん
2017/09/18(月) 23:56:19.32ID:3rLLB/Qm 張り切ってるヤツは
俺の考えにそぐわない物は間違いである
って主張なの?
俺の考えにそぐわない物は間違いである
って主張なの?
642デフォルトの名無しさん
2017/09/18(月) 23:59:55.60ID:4Oi7LGiO オブジェクト指向は、それ以前から存在する技術も
オブジェクト指向に取り入れた=オブジェクト指向の技術
と言うつもりなんだあろうか?
保守性とか拡張性とか、そんなもんオブジェクト指向以前から有るだろ
例えば金融業界、COBOLなんかの世界で使われてる
全銀フォーマット規格
http://www.kitashin-bank.co.jp/pdf/f-manual/99-02-00_WEB-FB.pdf
こういうのまでオブジェクト指向だって言うつもりなんだろう?
マイクロサービス化におけるAPIは、この全銀フォーマット規格となんもかわらん。
こういうフォーマットでデータ投げれば処理してくれますよーなんだから
オブジェクト指向に取り入れた=オブジェクト指向の技術
と言うつもりなんだあろうか?
保守性とか拡張性とか、そんなもんオブジェクト指向以前から有るだろ
例えば金融業界、COBOLなんかの世界で使われてる
全銀フォーマット規格
http://www.kitashin-bank.co.jp/pdf/f-manual/99-02-00_WEB-FB.pdf
こういうのまでオブジェクト指向だって言うつもりなんだろう?
マイクロサービス化におけるAPIは、この全銀フォーマット規格となんもかわらん。
こういうフォーマットでデータ投げれば処理してくれますよーなんだから
643デフォルトの名無しさん
2017/09/19(火) 00:04:25.20ID:9ArzpmiB 結局こういう論理なんだよな
オブジェクト指向を使うと従来よりも保守性や拡張性が向上する場面が有る
↓
オブジェクト指向は保守性や拡張性をもたらすものである
↓
保守性や拡張性をもたらすにはオブジェクト指向を使ったほうが良い
↓
保守性や拡張性がある=オブジェクト指向である
↓
マイクロサービスとかクラウドとか保守性や拡張性が有るやろ?
それらは全部オブジェクト指向なんやで?
オブジェクト指向とは一体何なのか?
オブジェクト指向を使うと従来よりも保守性や拡張性が向上する場面が有る
↓
オブジェクト指向は保守性や拡張性をもたらすものである
↓
保守性や拡張性をもたらすにはオブジェクト指向を使ったほうが良い
↓
保守性や拡張性がある=オブジェクト指向である
↓
マイクロサービスとかクラウドとか保守性や拡張性が有るやろ?
それらは全部オブジェクト指向なんやで?
オブジェクト指向とは一体何なのか?
644デフォルトの名無しさん
2017/09/19(火) 00:06:29.46ID:H6eyWyRr >>641
っていうか
この技術は効果無しの似非技術で
間違いなくね?
そんなに当たり前の技術なら
メリットなんてググったら
その仕組みから明確なものが出てきていいだろw
こんなに勿体ぶる必要もないし
仕組みがわかれば大きいプロジェクトでないと効果がないも
わかるけどそもそも
正しいオブジェクト指向が反映されたソース自体よくわからんし
っていうか
この技術は効果無しの似非技術で
間違いなくね?
そんなに当たり前の技術なら
メリットなんてググったら
その仕組みから明確なものが出てきていいだろw
こんなに勿体ぶる必要もないし
仕組みがわかれば大きいプロジェクトでないと効果がないも
わかるけどそもそも
正しいオブジェクト指向が反映されたソース自体よくわからんし
645デフォルトの名無しさん
2017/09/19(火) 00:13:23.26ID:H6eyWyRr そもそもなぜここまでメリットの説明できないものを
効果がありそうに言うの?
お前らは
これ役に立たないだろ
だから説明できないじゃん
お前らがアホなんじゃなくて
どの資料にもサイトにも
具体的なメリットおよびその効果をもたらす仕組みの記述がねぇんだよ
だから誰も具体的な話がよくわからないが正解だろこれ
んでオブジェクト単位で分けたところで
書く必要のある処理を書かなくて良くなることはないし
保守だの拡張だのなんてあるわけないし
なんで騙されてるって気が付かないんだ?
効果がありそうに言うの?
お前らは
これ役に立たないだろ
だから説明できないじゃん
お前らがアホなんじゃなくて
どの資料にもサイトにも
具体的なメリットおよびその効果をもたらす仕組みの記述がねぇんだよ
だから誰も具体的な話がよくわからないが正解だろこれ
んでオブジェクト単位で分けたところで
書く必要のある処理を書かなくて良くなることはないし
保守だの拡張だのなんてあるわけないし
なんで騙されてるって気が付かないんだ?
646デフォルトの名無しさん
2017/09/19(火) 00:16:43.07ID:yzSynM5D >>639
使いまわせればそれに越したことはないんだけど、
チョイ変更が必要なときどうするかだよ。
そこを共通モジュール側に変更として取り込むか、使い捨てと割り切ってコピペ+改変で乗り切ってしまうか。
やってみて分かったんだが、GUIって実際に使ってみないと使い勝手が分からないことも多くて、
張り切って作ってもゴミだとか、
或いは一時凌ぎで適当に作ったら意外に使いやすくて拡張していき、おかげで酷いことになるとか結構あって、
どれを取り込むべきか最初には分からないんだよ。
(俺にGUIのセンスが無いといえばそうだが)
だからとりあえずコピペ+改変で組んでしまって、
後で本当に使える場合はもう一度共通側に取り込むほうがましだと俺は判定している。
二度手間ではあるが、変に最初に取り込んで除去する方が死ねるから。
>>640
イエス。
使いまわせればそれに越したことはないんだけど、
チョイ変更が必要なときどうするかだよ。
そこを共通モジュール側に変更として取り込むか、使い捨てと割り切ってコピペ+改変で乗り切ってしまうか。
やってみて分かったんだが、GUIって実際に使ってみないと使い勝手が分からないことも多くて、
張り切って作ってもゴミだとか、
或いは一時凌ぎで適当に作ったら意外に使いやすくて拡張していき、おかげで酷いことになるとか結構あって、
どれを取り込むべきか最初には分からないんだよ。
(俺にGUIのセンスが無いといえばそうだが)
だからとりあえずコピペ+改変で組んでしまって、
後で本当に使える場合はもう一度共通側に取り込むほうがましだと俺は判定している。
二度手間ではあるが、変に最初に取り込んで除去する方が死ねるから。
>>640
イエス。
647デフォルトの名無しさん
2017/09/19(火) 00:18:34.87ID:stFT2Xr6648デフォルトの名無しさん
2017/09/19(火) 00:20:28.09ID:stFT2Xr6649デフォルトの名無しさん
2017/09/19(火) 00:22:36.67ID:H6eyWyRr650デフォルトの名無しさん
2017/09/19(火) 00:24:26.80ID:H6eyWyRr そろそろitproとか日ソフに
オブジェクト指向役に立ちませんでしたって記事書いてほしいけどね
オブジェクト指向役に立ちませんでしたって記事書いてほしいけどね
651デフォルトの名無しさん
2017/09/19(火) 00:24:32.28ID:6o+b/JQG まともに作ったオブジェクト指向プログラムでは
ユーザーの既知の言葉とクラスが対応している
クラスに関わる情報が集約されてる
よって仕様変更に対応しやすい
もっともメリットを享受してるのはここだな
ユーザーの既知の言葉とクラスが対応している
クラスに関わる情報が集約されてる
よって仕様変更に対応しやすい
もっともメリットを享受してるのはここだな
652デフォルトの名無しさん
2017/09/19(火) 00:26:06.13ID:H6eyWyRr653デフォルトの名無しさん
2017/09/19(火) 00:27:06.08ID:yzSynM5D >>639
ああすまん、俺が言っているのは「スニペット」と言うのかもしれん。
(俺自身はあの機能は嫌いだから使ってないが、たぶん意味的にはこれ)
モジュールというよりは「お約束的コード」の塊を持っておき、
それをベースにその都度必要なら改変して使う、って奴。
それで使えると判明したら「お約束的コード」に新しい機能を取り込む。
JavaScriptはGUIの装飾が主だから、割とこんな感じのほうが上手く行く気がする。
ああすまん、俺が言っているのは「スニペット」と言うのかもしれん。
(俺自身はあの機能は嫌いだから使ってないが、たぶん意味的にはこれ)
モジュールというよりは「お約束的コード」の塊を持っておき、
それをベースにその都度必要なら改変して使う、って奴。
それで使えると判明したら「お約束的コード」に新しい機能を取り込む。
JavaScriptはGUIの装飾が主だから、割とこんな感じのほうが上手く行く気がする。
654デフォルトの名無しさん
2017/09/19(火) 00:27:42.18ID:stFT2Xr6 >>649
関数型も完璧すぎるC言語に対抗するためのマーケティングと捉えてる?
関数型も完璧すぎるC言語に対抗するためのマーケティングと捉えてる?
655デフォルトの名無しさん
2017/09/19(火) 00:29:49.11ID:H6eyWyRr656デフォルトの名無しさん
2017/09/19(火) 00:30:54.19ID:stFT2Xr6 >>652
え、どう仕様変更されるかわからないからって仕様変更への対応しやすさはまったくの度外視でシステム作っちゃうのお前
え、どう仕様変更されるかわからないからって仕様変更への対応しやすさはまったくの度外視でシステム作っちゃうのお前
657デフォルトの名無しさん
2017/09/19(火) 00:32:11.91ID:stFT2Xr6 >>655
構造化もマーケティング、手続きもマーケティング、さあどこまで遡ればマーケティングと無縁の世界、お前の桃源郷に辿り着くんでしょうかw
構造化もマーケティング、手続きもマーケティング、さあどこまで遡ればマーケティングと無縁の世界、お前の桃源郷に辿り着くんでしょうかw
658デフォルトの名無しさん
2017/09/19(火) 00:34:11.72ID:9ArzpmiB >>645
> そもそもなぜここまでメリットの説明できないものを
> 効果がありそうに言うの?
メリットというか、人間のメンタルモデルに一番マッチしてるから
使いやすいってだけだよ
小学校入学前の子供であっても、車という種類(クラス)があって
白い車、黒い車、なんて属性(プロパティ)や
走る、止まる、曲がる、なんて処理(メソッド)が
車に紐付いてるって理解してるだろ?
なんかその道のプロは、オブジェクト指向の真のメリットは
継承やカプセル化や多態性とか言ってるけど、
それはオブジェクト指向の応用でできることであって、
オブジェクト指向はわかりやすいっていうのが
(メリットではなく)特徴
> そもそもなぜここまでメリットの説明できないものを
> 効果がありそうに言うの?
メリットというか、人間のメンタルモデルに一番マッチしてるから
使いやすいってだけだよ
小学校入学前の子供であっても、車という種類(クラス)があって
白い車、黒い車、なんて属性(プロパティ)や
走る、止まる、曲がる、なんて処理(メソッド)が
車に紐付いてるって理解してるだろ?
なんかその道のプロは、オブジェクト指向の真のメリットは
継承やカプセル化や多態性とか言ってるけど、
それはオブジェクト指向の応用でできることであって、
オブジェクト指向はわかりやすいっていうのが
(メリットではなく)特徴
659デフォルトの名無しさん
2017/09/19(火) 00:35:21.48ID:H6eyWyRr660デフォルトの名無しさん
2017/09/19(火) 00:38:39.43ID:9ArzpmiB >>656
> え、どう仕様変更されるかわからないからって仕様変更への対応しやすさはまったくの度外視でシステム作っちゃうのお前
仕様変更に対応しやすくするために必要なのは、
コードを書かないこと。これはオブジェクト指向とは関係ない。
コード量が少なければ、仕様変更で書き換えるコードも少なくなる。
オブジェクト指向的にはモジュールを抽象化して、拡張性を持たせることだろうが
それは過剰な設計になって複雑さが増すだけで無駄になることが多い。
最初に作り込むのをやめて、最低限動くコードを書くのが良い。
これもオブジェクト指向とは関係ない話
> え、どう仕様変更されるかわからないからって仕様変更への対応しやすさはまったくの度外視でシステム作っちゃうのお前
仕様変更に対応しやすくするために必要なのは、
コードを書かないこと。これはオブジェクト指向とは関係ない。
コード量が少なければ、仕様変更で書き換えるコードも少なくなる。
オブジェクト指向的にはモジュールを抽象化して、拡張性を持たせることだろうが
それは過剰な設計になって複雑さが増すだけで無駄になることが多い。
最初に作り込むのをやめて、最低限動くコードを書くのが良い。
これもオブジェクト指向とは関係ない話
661デフォルトの名無しさん
2017/09/19(火) 00:40:09.40ID:m+YtWxtc プロトタイプ開発
662デフォルトの名無しさん
2017/09/19(火) 00:40:23.37ID:6o+b/JQG >>652
仕様変更はユーザーの既知の言葉でなされる
仕様変更はユーザーの既知の言葉でなされる
663デフォルトの名無しさん
2017/09/19(火) 00:41:58.60ID:9ArzpmiB ユーザーの既知の言葉はオブジェクト指向ではない
664デフォルトの名無しさん
2017/09/19(火) 00:47:42.06ID:stFT2Xr6 >>659
オブジェクト指向は役に立つね
オブジェクト指向は役に立つね
665デフォルトの名無しさん
2017/09/19(火) 00:48:50.65ID:H6eyWyRr >>664
お前、ミソが腐ってるからな
お前、ミソが腐ってるからな
666デフォルトの名無しさん
2017/09/19(火) 00:53:31.47ID:m+YtWxtc >>665
お前、性根が腐ってるからな
お前、性根が腐ってるからな
667デフォルトの名無しさん
2017/09/19(火) 00:54:13.00ID:stFT2Xr6 >>660
オブジェクト指向と関係ないか
じゃあどんな設計手法となら関係ある?手続き型も関数型も、再利用のしやすさ、仕様変更への対応のしやすさとはまったくの無関係?
どんな設計手法を取ろうと、仕様変更への対応はまったく同じだけのコストがかかる?
オブジェクト指向と関係ないか
じゃあどんな設計手法となら関係ある?手続き型も関数型も、再利用のしやすさ、仕様変更への対応のしやすさとはまったくの無関係?
どんな設計手法を取ろうと、仕様変更への対応はまったく同じだけのコストがかかる?
668デフォルトの名無しさん
2017/09/19(火) 01:00:45.76ID:6o+b/JQG669デフォルトの名無しさん
2017/09/19(火) 01:03:40.84ID:9ArzpmiB >>667
> じゃあどんな設計手法となら関係ある
どんな設計手法とも関係ない。
例えば仕様変更に備えて既存のコードを読みやすくするために
わかりやすい変数名をつけることは、どの設計手法とは関係あるか?と
聞かれてお前、なんて答える?
そういうレベルの話
> どんな設計手法を取ろうと、仕様変更への対応はまったく同じだけのコストがかかる?
場合による。どれが最高とかはない。銀の弾丸はないのだよ君
> じゃあどんな設計手法となら関係ある
どんな設計手法とも関係ない。
例えば仕様変更に備えて既存のコードを読みやすくするために
わかりやすい変数名をつけることは、どの設計手法とは関係あるか?と
聞かれてお前、なんて答える?
そういうレベルの話
> どんな設計手法を取ろうと、仕様変更への対応はまったく同じだけのコストがかかる?
場合による。どれが最高とかはない。銀の弾丸はないのだよ君
670デフォルトの名無しさん
2017/09/19(火) 01:05:01.44ID:9ArzpmiB671デフォルトの名無しさん
2017/09/19(火) 01:08:32.48ID:6o+b/JQG672デフォルトの名無しさん
2017/09/19(火) 01:09:31.94ID:9ArzpmiB ユーザーの既知の言葉をクラス化したというが
じゃあオブジェクト指向以外ではできないと思うのか?
理由はクラスが無いからできないと思ってる?
関数しか無いからユーザーの既知の言葉は関数になると思ってる?
違うな。C言語で作られたLinuxでも見ればわかるだろう。
他の手法ではモジュール(またはファイル)になるんだよ
じゃあオブジェクト指向以外ではできないと思うのか?
理由はクラスが無いからできないと思ってる?
関数しか無いからユーザーの既知の言葉は関数になると思ってる?
違うな。C言語で作られたLinuxでも見ればわかるだろう。
他の手法ではモジュール(またはファイル)になるんだよ
673デフォルトの名無しさん
2017/09/19(火) 01:23:49.02ID:yzSynM5D まあバトるのはいいと思うけど、結局のところsmalltalkの話と似たような事になっていて、
・smalltalkが「遅延結合」で実現しようとしたことは、現在は他の手法で十二分に達成されており、
わざわざsmalltalkを用いる必要はない
・OOPのメリットは、現在では他の手法でも得られるため、OOPに頼る必然性はない。
だからメリットが見えないのなら使わなければいいだけ。
JavaScriptとかの状況だと、OOPで書いてもあまりメリットないのは事実だし。
・smalltalkが「遅延結合」で実現しようとしたことは、現在は他の手法で十二分に達成されており、
わざわざsmalltalkを用いる必要はない
・OOPのメリットは、現在では他の手法でも得られるため、OOPに頼る必然性はない。
だからメリットが見えないのなら使わなければいいだけ。
JavaScriptとかの状況だと、OOPで書いてもあまりメリットないのは事実だし。
674デフォルトの名無しさん
2017/09/19(火) 01:32:29.64ID:y3g67zRP ID:H6eyWyRr
完全なるガイジ
こういうのが現場に一匹でも紛れ込んでいたら
さぞ迷惑だろうな
完全なるガイジ
こういうのが現場に一匹でも紛れ込んでいたら
さぞ迷惑だろうな
675デフォルトの名無しさん
2017/09/19(火) 01:35:21.15ID:6o+b/JQG >>672
それはオブジェクト指向言語でないとできないかという話か?
設計の話をしてんだよ
できるしgtkとかC言語でオブジェクト指向設計で組んだプログラムもある
オブジェクト単位で分けたならオブジェクト指向設計だし、そうでないなら他の設計だろ
モジュールはオブジェクトだったり機能分割だったりより包括的な言葉だ
お前の言っていることは間違えてる
それはオブジェクト指向言語でないとできないかという話か?
設計の話をしてんだよ
できるしgtkとかC言語でオブジェクト指向設計で組んだプログラムもある
オブジェクト単位で分けたならオブジェクト指向設計だし、そうでないなら他の設計だろ
モジュールはオブジェクトだったり機能分割だったりより包括的な言葉だ
お前の言っていることは間違えてる
676デフォルトの名無しさん
2017/09/19(火) 01:49:41.82ID:9ArzpmiB 結局さ、オブジェクト指向が生きるのは実装の話なんだよね。
言語より外に出ないでほしい。
言語より外に出ないでほしい。
677デフォルトの名無しさん
2017/09/19(火) 02:07:01.99ID:OkajuEzq オブジェクト指向言語で実装しやすいように設計したり
オブジェクト指向言語で実装した場合に後でメンテナンスが楽になるように設計するのが
オブジェクト指向設計じゃろ?
オブジェクト指向言語で実装した場合に後でメンテナンスが楽になるように設計するのが
オブジェクト指向設計じゃろ?
678デフォルトの名無しさん
2017/09/19(火) 02:07:22.02ID:6o+b/JQG 弁解せずに話し飛ばして逃げたか
ID:9ArzpmiBが恥を晒すだけのスレになってしまったな
ID:9ArzpmiBが恥を晒すだけのスレになってしまったな
679デフォルトの名無しさん
2017/09/19(火) 02:13:40.15ID:NMSJB/uW 「オブジェクト指向」って言葉自体、色んな意味で使われて混乱の元になっていたのは事実だわな。
最近の本では
「オブジェクト指向でなぜつくるのか」
がそのあたりの状況も含めてすっきり整理して分かりやすかった。
とりあえず
「オブジェクト指向プログラミング」
「オブジェクト指向設計」
「オブジェクト指向分析」
はきっちり分けて会話しないとますます混乱するな。
最近の本では
「オブジェクト指向でなぜつくるのか」
がそのあたりの状況も含めてすっきり整理して分かりやすかった。
とりあえず
「オブジェクト指向プログラミング」
「オブジェクト指向設計」
「オブジェクト指向分析」
はきっちり分けて会話しないとますます混乱するな。
680デフォルトの名無しさん
2017/09/19(火) 02:38:22.83ID:9ArzpmiB >>678
それについて弁解しろと?
それについて弁解しろと?
681デフォルトの名無しさん
2017/09/19(火) 02:45:40.97ID:OkajuEzq >>678
横レスだが君のレスのほうが普通におかしいよ
>まともに作ったオブジェクト指向プログラムでは
>ユーザーの既知の言葉とクラスが対応している
ユーザーの既知の言葉が先にあって
それをオブジェクト指向言語で実装しやすく・メンテしやすくするために
対応するクラスを作ったんだよね?
オブジェクト指向言語以外でも同じように実装しやすく・メンテしやすくするために
対応する関数やデータ型を作るだけじゃないの?
ユーザーの既知の言葉にどの程度対応付けできるかは
実装言語で扱える抽象化の方法にもよるけど
対応付けができるのはオブジェクト指向言語に特有のことではないよ
横レスだが君のレスのほうが普通におかしいよ
>まともに作ったオブジェクト指向プログラムでは
>ユーザーの既知の言葉とクラスが対応している
ユーザーの既知の言葉が先にあって
それをオブジェクト指向言語で実装しやすく・メンテしやすくするために
対応するクラスを作ったんだよね?
オブジェクト指向言語以外でも同じように実装しやすく・メンテしやすくするために
対応する関数やデータ型を作るだけじゃないの?
ユーザーの既知の言葉にどの程度対応付けできるかは
実装言語で扱える抽象化の方法にもよるけど
対応付けができるのはオブジェクト指向言語に特有のことではないよ
682デフォルトの名無しさん
2017/09/19(火) 02:46:40.11ID:9ArzpmiB >>679
一時期オブジェクト指向が目的になってる感があったよね
オブジェクト指向の適用範囲はプログラミング
そして設計のうち基本的な部分までだろう。
基本的な設計というのは具体的に言えばフレームワーク。
そのフレームワークというのは汎用的なもので
フレームワークの利用者に具体的な処理の部分だけを
書けばいいような形に設計するから、オブジェクト指向を意識する必要はなくなる。
またサーバー設計とかデータベース設計(オブジェクト指向データベースは除く)は
そもそもオブジェクト指向とは関係ない
一時期オブジェクト指向が目的になってる感があったよね
オブジェクト指向の適用範囲はプログラミング
そして設計のうち基本的な部分までだろう。
基本的な設計というのは具体的に言えばフレームワーク。
そのフレームワークというのは汎用的なもので
フレームワークの利用者に具体的な処理の部分だけを
書けばいいような形に設計するから、オブジェクト指向を意識する必要はなくなる。
またサーバー設計とかデータベース設計(オブジェクト指向データベースは除く)は
そもそもオブジェクト指向とは関係ない
683デフォルトの名無しさん
2017/09/19(火) 03:07:31.07ID:6o+b/JQG684デフォルトの名無しさん
2017/09/19(火) 04:43:07.90ID:1X4lIwJc685デフォルトの名無しさん
2017/09/19(火) 04:52:13.36ID:1X4lIwJc686デフォルトの名無しさん
2017/09/19(火) 05:09:27.48ID:Js438x12 ・「オブジェクト指向」には「抽象データ型をクラス等でやる(カプセル化・継承・多態性)」と「遅延結合を(メッセージを送ってとかを方便にして)徹底する」という2種類あり混ぜると危険
・「オブジェクト指向」には「〜プログラミング」(前二者の混在)の他に「〜分析」(前者の強い影響下)「〜設計」(後者の強い影響下)があり混ぜるとワケワカメ
って二段階において区別が付かない人間がいるともう議論はおろか会話すら成り立たなくなるといういい例だったな
ついでにこのスレには「遅延システムを言語仕様に持ち込むな」とかいう宗教のSmalltalkアンチ&他人の話は読み飛ばすくせに自分の意見は押し付けるガイジがいて、話がエンドレスエイト
・「オブジェクト指向」には「〜プログラミング」(前二者の混在)の他に「〜分析」(前者の強い影響下)「〜設計」(後者の強い影響下)があり混ぜるとワケワカメ
って二段階において区別が付かない人間がいるともう議論はおろか会話すら成り立たなくなるといういい例だったな
ついでにこのスレには「遅延システムを言語仕様に持ち込むな」とかいう宗教のSmalltalkアンチ&他人の話は読み飛ばすくせに自分の意見は押し付けるガイジがいて、話がエンドレスエイト
687デフォルトの名無しさん
2017/09/19(火) 07:09:47.56ID:H6eyWyRr688デフォルトの名無しさん
2017/09/19(火) 07:52:39.18ID:oNO26kuq689デフォルトの名無しさん
2017/09/19(火) 09:41:53.11ID:baYuuAVc >>687
オブジェクト指向プログラミング(のひとつ)が、抽象データ型(簡単に言うとユーザー定義のデータ型のこと)を
クラスなどで実装するアイデアだというのは、ビャーン・ストラウストラップが次で提唱(厳密には整理)しています
http://www.stroustrup.com/whatis.pdf
大枠としては、Simulaという言語が初めて作った「クラス」という言語機能を使って
整数型や浮動小数点少数型、文字列などといった通常は言語組み込みのデータ型と同様に
プログラマがデータ型を拡張できるようにしようというアイデアです。メリットは、いったん必要なデータ型を定義して
しまえば、そのデータ型やそれ同士の操作というかたちでプログラムの記述を抽象化(換言すると
シンプルに)できるというところにあります。
ストラウストラップのこのアイデア(正確には同時期に抽象データ型の発案者のリスコフ、Simulaの設計者の
ダールとニガードは当然として、Eiffelのバートランド・メイヤーらも同様の発想に到達しています)に準じれば
オブジェクト指向プログラミングのメリットのひとつは抽象データ型(データ抽象ともいう)を実践することと変わりませんから
(もちろんクラスを使うことで追加して継承による差分プログラミング、その結果の多態性を享受できます)、
メリットを検索したければまず"抽象データ型" "利点" などとしてググるとちゃんと出てきます。
まずここまでよろしいでしょうか?
オブジェクト指向プログラミング(のひとつ)が、抽象データ型(簡単に言うとユーザー定義のデータ型のこと)を
クラスなどで実装するアイデアだというのは、ビャーン・ストラウストラップが次で提唱(厳密には整理)しています
http://www.stroustrup.com/whatis.pdf
大枠としては、Simulaという言語が初めて作った「クラス」という言語機能を使って
整数型や浮動小数点少数型、文字列などといった通常は言語組み込みのデータ型と同様に
プログラマがデータ型を拡張できるようにしようというアイデアです。メリットは、いったん必要なデータ型を定義して
しまえば、そのデータ型やそれ同士の操作というかたちでプログラムの記述を抽象化(換言すると
シンプルに)できるというところにあります。
ストラウストラップのこのアイデア(正確には同時期に抽象データ型の発案者のリスコフ、Simulaの設計者の
ダールとニガードは当然として、Eiffelのバートランド・メイヤーらも同様の発想に到達しています)に準じれば
オブジェクト指向プログラミングのメリットのひとつは抽象データ型(データ抽象ともいう)を実践することと変わりませんから
(もちろんクラスを使うことで追加して継承による差分プログラミング、その結果の多態性を享受できます)、
メリットを検索したければまず"抽象データ型" "利点" などとしてググるとちゃんと出てきます。
まずここまでよろしいでしょうか?
690デフォルトの名無しさん
2017/09/19(火) 09:49:26.36ID:H6eyWyRr >>689
え?どこに仕組みが書いてあるの?w
そもそもそいつの理論自体クソなんじゃねコレ
メリットは、いったん必要なデータ型を定義して
しまえば、そのデータ型やそれ同士の操作というかたちでプログラムの記述を抽象化(換言すると
シンプルに)できるというところにあります。
はぁ?
これが本当にメリットになっているか
こんな曖昧な表現で誰も検証してねぇのがそもそもの間違いなんだよ
え?どこに仕組みが書いてあるの?w
そもそもそいつの理論自体クソなんじゃねコレ
メリットは、いったん必要なデータ型を定義して
しまえば、そのデータ型やそれ同士の操作というかたちでプログラムの記述を抽象化(換言すると
シンプルに)できるというところにあります。
はぁ?
これが本当にメリットになっているか
こんな曖昧な表現で誰も検証してねぇのがそもそもの間違いなんだよ
691デフォルトの名無しさん
2017/09/19(火) 09:59:43.63ID:E7A1w6jZ 俺はオブジェクト指向言語でプログラミングを覚えたから、やっぱり設計するときもベースになるのはオブジェクト指向だな
なんかやたらとオブジェクト指向に噛みついてる人がいるけど、勝手に自分がいいと思う方法論でやればいいじゃんっていうw
なんかやたらとオブジェクト指向に噛みついてる人がいるけど、勝手に自分がいいと思う方法論でやればいいじゃんっていうw
692デフォルトの名無しさん
2017/09/19(火) 11:47:50.43ID:baYuuAVc >>690
とりあえず、まずは抽象データ型をクラスを使って実践するアイデアの「オブジェクト指向プログラミング」が
それなりに名の知れた先達のアイデアであり、>>686個人の意見ではないことを言外に了解いただけたことは良かったです
抽象データ型(ユーザー定義のデータ型)のメリットについてはデータ型自体のメリットが当たり前すぎて
それを具体的に意識できないとちょっとピンと来にくいかもしれません
たとえばもし浮動小数点数データ型(float)が言語の組み込みでなかったとしたら
小数同士の演算やそれを入力・表示するためにプログラムを書くときに
どんな不都合が生じるかを考えると逆にメリットをイメージしやすいと思います
そもそもデータ型というのは人間とコンピューターの両方に対しこれから扱おうとするデータが
何を意味するのかについての情報を共有するためのタグのような役割を果たします
浮動小数点数ならその型であるfloatを宣言することで
人間側は変数や関数を通じて浮動小数点数(指数表現付き小数)を扱えることを知ることができ
コンピューター側は変数に代入された、あるいは関数に渡されたビット列データが浮動小数点数として
つまり各ビットが符号、指数部、仮数部のどれを表しているかを知り、ビット列に対し相応しい扱いをすることができるわけです
もしこのデータ型という情報がビット列データや変数、関数に附随させることが出来なかったら
たとえば浮動小数点数同士の加算を行なう関数(仮にadd_float)を呼び出すにも
渡したビット列が果たして本当に浮動小数点数を表すのか
そもそもそのadd_float関数を使うことが適切なのかの判断がしにくくなり
プログラムの正しさを保証・把握しにくくなります
また応用として(こちらの方が即効性のあるメリットですが)変数や関数にもデータ型情報を付加することができれば
同一名の関数や演算子を渡すデータ型ごとに適切に振る舞わせることが可能になり
プログラムの記述をシンプルにすることに役立ちます
a, b が float で、add_float(a,b) の場合、add_int、add_fractionなどというようにデータ型ごとに
いちいち区別せずに単に add(a,b)で済ませることが出来たり
演算子を用いてもっとシンプルに a + b と記述することも可能になります
とりあえず、まずは抽象データ型をクラスを使って実践するアイデアの「オブジェクト指向プログラミング」が
それなりに名の知れた先達のアイデアであり、>>686個人の意見ではないことを言外に了解いただけたことは良かったです
抽象データ型(ユーザー定義のデータ型)のメリットについてはデータ型自体のメリットが当たり前すぎて
それを具体的に意識できないとちょっとピンと来にくいかもしれません
たとえばもし浮動小数点数データ型(float)が言語の組み込みでなかったとしたら
小数同士の演算やそれを入力・表示するためにプログラムを書くときに
どんな不都合が生じるかを考えると逆にメリットをイメージしやすいと思います
そもそもデータ型というのは人間とコンピューターの両方に対しこれから扱おうとするデータが
何を意味するのかについての情報を共有するためのタグのような役割を果たします
浮動小数点数ならその型であるfloatを宣言することで
人間側は変数や関数を通じて浮動小数点数(指数表現付き小数)を扱えることを知ることができ
コンピューター側は変数に代入された、あるいは関数に渡されたビット列データが浮動小数点数として
つまり各ビットが符号、指数部、仮数部のどれを表しているかを知り、ビット列に対し相応しい扱いをすることができるわけです
もしこのデータ型という情報がビット列データや変数、関数に附随させることが出来なかったら
たとえば浮動小数点数同士の加算を行なう関数(仮にadd_float)を呼び出すにも
渡したビット列が果たして本当に浮動小数点数を表すのか
そもそもそのadd_float関数を使うことが適切なのかの判断がしにくくなり
プログラムの正しさを保証・把握しにくくなります
また応用として(こちらの方が即効性のあるメリットですが)変数や関数にもデータ型情報を付加することができれば
同一名の関数や演算子を渡すデータ型ごとに適切に振る舞わせることが可能になり
プログラムの記述をシンプルにすることに役立ちます
a, b が float で、add_float(a,b) の場合、add_int、add_fractionなどというようにデータ型ごとに
いちいち区別せずに単に add(a,b)で済ませることが出来たり
演算子を用いてもっとシンプルに a + b と記述することも可能になります
693デフォルトの名無しさん
2017/09/19(火) 12:15:42.13ID:lAmeNxGf694デフォルトの名無しさん
2017/09/19(火) 12:26:34.99ID:sTkEDscL695デフォルトの名無しさん
2017/09/19(火) 12:45:28.49ID:baYuuAVc >>694
最初の本格的プログラミングが商用Smalltalkというのは羨ましいですね
最初の本格的プログラミングが商用Smalltalkというのは羨ましいですね
696デフォルトの名無しさん
2017/09/19(火) 14:50:14.42ID:OkajuEzq >>685
DDDはオブジェクト指向かどうかに関係ないよ
DDDをF#でやる例
http://www.slideshare.net/ScottWlaschin/domain-driven-design-with-the-f-type-system-functional-londoners-2014
OOPの方が「やりやすい」場合があるのも確かだけど
そういう主張は往々にしてそれはOOPでのやり方しか知らないから
DDDはオブジェクト指向かどうかに関係ないよ
DDDをF#でやる例
http://www.slideshare.net/ScottWlaschin/domain-driven-design-with-the-f-type-system-functional-londoners-2014
OOPの方が「やりやすい」場合があるのも確かだけど
そういう主張は往々にしてそれはOOPでのやり方しか知らないから
697デフォルトの名無しさん
2017/09/19(火) 15:02:00.92ID:OkajuEzq >>692
抽象データ型はOOPじゃなくても
現在に使われてる言語の大半で実現できることなのでそのメリットを長々と語っても意味がない
抽象データ型を”クラス”を使って実現することがOOPの特徴だと言うなら
“クラス”を使うことのメリットを説明しないと
抽象データ型はOOPじゃなくても
現在に使われてる言語の大半で実現できることなのでそのメリットを長々と語っても意味がない
抽象データ型を”クラス”を使って実現することがOOPの特徴だと言うなら
“クラス”を使うことのメリットを説明しないと
698デフォルトの名無しさん
2017/09/19(火) 15:19:08.58ID:6o+b/JQG 設計の話で言語がー言いだす
ガイジは言語スレ行けよ
ガイジは言語スレ行けよ
699デフォルトの名無しさん
2017/09/19(火) 16:11:27.59ID:E7A1w6jZ >>696
F#はマルチパラダイムだけど、いったんそれは置いとくとして、オブジェクト指向言語と非オブジェクト指向言語ではどっちがDDDやりやすいの?
オブジェクト指向言語しか知らないから教えてほしいな
F#はマルチパラダイムだけど、いったんそれは置いとくとして、オブジェクト指向言語と非オブジェクト指向言語ではどっちがDDDやりやすいの?
オブジェクト指向言語しか知らないから教えてほしいな
700デフォルトの名無しさん
2017/09/19(火) 16:31:00.62ID:baYuuAVc701デフォルトの名無しさん
2017/09/19(火) 17:08:27.00ID:1X4lIwJc702デフォルトの名無しさん
2017/09/19(火) 17:13:43.45ID:1X4lIwJc >>696
別にPrologでDDDやってもいいんだよ
でもエリックエヴァンスのDDD本では
オブジェクト指向がメインになってるので
そこを無視して「関係ない」と言ってはいけない
やっぱりOOPの方がDDDをやりやすい
別にPrologでDDDやってもいいんだよ
でもエリックエヴァンスのDDD本では
オブジェクト指向がメインになってるので
そこを無視して「関係ない」と言ってはいけない
やっぱりOOPの方がDDDをやりやすい
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 【サッカー】U-17日本代表、激闘PK戦制す 北朝鮮撃破で6大会ぶり8強入り U17W杯 [久太郎★]
- 「国民の憤りを引き起こした」中国側“高市首相発言の撤回改めて要求” [どどん★]
- 【インバウンド】中国からの“渡航自粛”…ツアー1000人分の直前キャンセル「キャンセル料は免除してくれ」 ことしいっぱいキャンセルに [1ゲットロボ★]
- 【芸能】日中関係悪化でエンタメ業界に大ダメージ… JO1の中国でのイベント中止、邦画は公開延期、STARTOアイドルへの影響も [冬月記者★]
- XやChatGPTで広範囲の通信障害 投稿や閲覧できず [蚤の市★]
- 【サッカー】日本代表、ボリビアに3発快勝 森保監督通算100試合目を飾る…鎌田、町野、中村がゴール [久太郎★]
- 【J SPORTS】FIFA U-17ワールドカップ ★9
- 【J SPORTS】FIFA U-17ワールドカップ ★10
- とらせん IPあり
- 巨専】
- こいせん 全レス転載禁止
- 侍ジャパンシリーズ2025「日本vs韓国」その12
- 自民党議員「高市は先人が築き上げた日中関係を壊した。外務省が謝罪に言ってるが自分で責任を取れ」 [834922174]
- かしこいワンコっていうVtuberの子知ってる?
- カレーライスぐちゃぐちゃに混ぜる奴🤣
- もう寝る
- 女だけど眠れない
- 岡田克也「軽々しく存立危機事態とか言うべきじゃない」高市早苗「台湾で武力攻撃が発生したらどう考えても日本の存立危機事態」 [931948549]
