orange @[email protected]

完全にそれはそうなので、だからこそ気持ち悪い書き方に見える＞＜(主処理と順に実行する関数をわけて欲しい＞＜)

あと、そういう例だとC# の場合はインタフェースが使われる構造になる気がする＞＜

たとえば子クラスで必ず前処理と終了処理が実装される事を要求する場面ならば、前処理、主処理、後処理の関数として、主処理だけ親クラスに書いた上で、前、主、後って順に呼ぶ実行関数を別にする方がよくない？＞＜
スライドの書き方だと必須なんだかオプショナルなんだかよくわかんない構造に見えるし、変更にも弱そう＞＜

前後の処理をabstractな関数で定義しておく書き方になってる例も、オレンジには気持ち悪いコードに見えた＞＜
オレンジだったら、対象の関数をオーバーライドして親クラスの関数を呼ぶコードの前後に前後の処理を書くってするから＞＜
ていうか、順に実行する必要があるものであれば、真ん中部分の関数から前後を呼ぶなんて気持ち悪い書き方しないで順に呼ぶ関数を分ける＞＜

さっきの記事の筆者、著書のレビューにも書かれてたけど、static多用しまくるのが好きらしいけど、スライドの例みたいなのでも、スライドの例より複雑な状況だと引数がとんでもない量になったり、関数が余計に分割されまくりでコード量が爆発的に増えたり、引数がとんでもなくならないように引数用の複雑な構造体を作りまくったりってなるじゃん？＞＜
オレンジも開発初期の試行錯誤コードはそんな感じでぶっちゃけ恥ずかしいけど、そういうのを解消するようにリファクタリングしてオブジェクト指向な環境が提供する機能に頼って簡潔にしたコードにしてくってしてるよ＞＜

でも、本当にキレイに書いてないと恥ずかしくて大々的にコードを公開するのは恥ずかしいので、ちゃんと清書したやつしか公開してない＞＜；
(頼まれたりお節介で作ってあげた時には、コードもzipで固めて一緒に渡すことが多い＞＜)

オレンジが頼まれたりお節介で超高速で数時間とかでWindowsアプリ作れるの、それまで作ってきたアプリが多少汚く書かれてても(＞＜；)、「ちょっと違うアプリも簡単に作れるようになってるフレームワーク」の上に作るみたいなやり方で作ってきた蓄積があるから、
「そういう目的だったらあのアプリのあの部分と、あっちのアプリのあの部分を持ってきたらすぐ書けるかも＞＜」って事がそこそこ多かったのもある＞＜

ちなみに夕方書いたこれはこの場面では間違ってた＞＜；(のでその後書き換えた)
https://mstdn.nere9.help/@orange_in_space/112149301949664511
これだと別のキーでソートする時に、前のキーで反転させると続けて反転になっちゃう＞＜；
これだと一般的なlistviewの挙動と違う＞＜；

NAudio自体のプロセス別のループバック対応、開発者の人が一人頑張ってるんだけど、なんか苦戦してるっぽい＞＜

で、作ってる録音アプリもアプリ自体が目的じゃなくあくまでデバッグ用であって、選択したプロセスからの音のみをループバックするのを簡単に出来るようにするフレームワークで、将来的にはNAudioとも組み合わせて使えるようにする予定＞＜

https://mstdn.nere9.help/@orange_in_space/112150087575341229

オレンジが今作ってるこれの対象プロセス選択部分も、対象プロセス選択部分を直接作ったんじゃなく、Windows Core Audioのセッション群を簡単に扱えるフレームワーク(簡単に音量ミキサ自作できるフレームワーク)をまず作ってそれを流用してるし、
そのフレームワークも12年前に作りかけたレベルメータのフレームワーク部分を参考に清書したもの＞＜

[B! オブジェクト指向] オブジェクト指向は必要なのか / Is object-oriented needed? https://b.hatena.ne.jp/entry/s/speakerdeck.com/kishida/is-object-oriented-needed

なに言ってんだこいつ＞＜(素直な感想)
ウェブ界隈の方々って、フレームワークを作り上げていくようなやり方はせずに、他のものに流用しづらいコードを書くようなやり方をするのが普通なの？＞＜
フレームワーク作るなら必要だけど作らないなら不要って、それで不要っていうならつまりフレームワークを作るようなやり方はしてないってことでしょ？＞＜