スレ立てるまでもない質問はここで 164匹目

2023/04/15(土) 11:32:58.89

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
次スレを立てる時は↑を3行冒頭に書くこと（1行分は消えて表示されない為、もう1行は予備）

この板はプログラムを作る人のための板です
どこに書き込んでいいかわからない質問はまずここでしてください
各プログラム言語など専用スレがあるものはテンプレに役に立つリンクがあったりするので、そちらを見て書き込むことをお勧めします
次スレは>>980が立てること
前スレ
スレ立てるまでもない質問はここで 163匹目
https://mevius.5ch.net/test/read.cgi/tech/1670470167/
ﾜｯﾁｮｲ無しスレ
スレ立てるまでもない質問はここで 164匹目
https://mevius.5ch.net/test/read.cgi/tech/1681132438/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2023/09/12(火) 10:30:55.16

一旦？

2023/11/21(火) 11:35:35.06

知るか

2023/12/28(木) 04:24:08.06

フラグ管理の効率的な方法を教えて下さい。
作成中の社内向け事務アプリなんですが、判定要素が多くなりすぎて毎回読む度に悩みます。

ユーザーに割り当てられた権限や日時による分岐がめっちゃ多いです。
例えば、シンプルなやつだと下記みたいな感じです。
※権限には、種類とランクがあります。

・権限Aを持っているユーザーB～Eが、日時F～Gの間に許可した時だけ、
　ユーザーH・Iが日時J～Kの間だけ権限L・Mを付与されて、
　その権限を行使して処理NまたはOを合計2回行った時に、その権限を付与したユーザー(B～E)の権限PをQ～Rの期間降格する。

2023/12/28(木) 09:11:59.14

>>41
・フラグにfindFlagみたいな不適切な名前をつけない
grantedのような過去分詞にする
・真偽値の変数をなるべく減らす
関数のロジックで表現して意味が通る単位で適度に分割する
・権限に関する判定を他のロジックから独立させる
たとえば権限判定クラスを作って、コンストラクタでユーザを与える
他のロジックからは、権限があるか？というメソッドだけを呼ぶ
権限の判定処理に興味があるときはその内側のソースのみを追えば良く、その逆も然りとする

2023/12/28(木) 10:45:50.72

>41
案１：フラグはデータベースで管理する。フラグが変更される度にデータベース内ユーザーフィールドのフラグカラムをupdateで更新する。

案２：フラグ変更のプログラムをサブルーチン化（ユーザー定義関数）させる。Aの挙動の時はhogeフラグ、Bの挙動の時はpiyoフラグ、というようにA/B/C…どんな挙動が行われても対応するフラグを与えられるようにサブルーチンでさせる。

どちらの案にも共通しているのは、「管理を１つにまとめる」「ページをまたいでもフラグを簡潔に保持できるようにする」という点。

2023/12/28(木) 10:49:35.55

>41
この手の内容は運用していくたびに今後もフラグの追加や削除が行われていきそうだから、メンテナンスしやすい可読性の高い先を見据えたプログラム書いてあげるのも重要だねー

2023/12/28(木) 11:06:36.33

業務系のバッチ処理だと割とありそうなパターンだが
先行する複数のジョブが終了して、後続のジョブを起動するとか
そういう時系列的順序性があるのかな？

2023/12/28(木) 12:27:48.58

>>41
一番いいのはきちんとモデリングしてフラグを無くすこと
データベース管理にするかコード上で管理するかは状況次第だけど
複雑になればなるほどデータベース管理のほうが柔軟性も保守性も高くなることが多い

例えば↓こういうテーブル群を用意して
1. ユーザーごとの基本権限
2. 処理ごとの認可ルール
3. 実行回数など動的認可ルールのための記録
4. 実行回数等による降格ルール
5. 降格ルール等により基本権限を上書きするユーザーごとの一時的権限

処理Nが呼び出されるときに呼び出す権限チェック処理では
認可ルール・基本権限・一時的権限を確認することで処理Nを実行可能かどうか判断して
実行可能であれば実行回数等の記録と降格ルールなどの確認と適用を行うイメージ

2023/12/28(木) 12:28:12.86

フラグはグローバル変数、staticに次いで初心者やレガシープログラマーが乱用しがちな三種の神器だと思う
専門用語らしさがあるし使いたくなるんだろうな
StrategyパターンやStateパターン、関数型プログラミングの考え方をざっと覚えるだけでもだいぶ変わると思う

2023/12/28(木) 21:14:58.94

>>41
話を単純化すると、大雑把にユーザー、権限、処理の3種類のカテゴリとする
ユーザーとは
・所有している権限で許可された処理を行える
権限とは
・権限には種類とランクがある
・権限により実行できる処理が決められている
処理とは
・処理はいくつも作成できる
・処理の種類はユーザーへの権限付与や剥奪、処理の許可、その他がある
・処理を実行する時、指定回数や期間等を設定でき、特定条件に合致した時に別の処理を呼び出せる

これを踏まえた各カテゴリの性質
ユーザー：権限(単数、複数)と権限の範囲で可能なユーザーが作成した固有の処理 →可変
権限：種類とランクで可能な処理一覧 →不変
処理：想定する権限、処理内容、条件等の設定できる情報 →不変

以下の処理を作成し、整合性をチェックする
処理1 日時F～Gの間、処理2を許可し、処理1を実行したユーザーを記憶する (権限Aを持つユーザーB～Eに紐付け)
処理2 日時J～Kの間、ユーザーH・Iに権限L・Mを付与する
処理NまたはO 処理実行し処理NまたはOの実行回数が合計2回に達した時、処理3を実行 (権限L・Mを持つユーザーH・Iが実行)
処理3 処理1で記憶したユーザーの権限PをQ～Rの期間降格する (処理NまたはOからの条件付き実行)

2023/12/28(木) 22:20:52.97

何が言いたいか補足すると、必要なフラグというかデータは
1 処理を実行する時のユーザーの所有する権限
2 処理1と処理3を紐付けるユーザーの記録情報、または処理の実行履歴
3 各処理の個別の内容詳細
の3種に絞れると思う
処理は権限に従って実行できるかが決まるようにするとか、上手く設計すれば状態管理は必要なくなるという事が言いたかった

2025/01/27(月) 13:27:45.99

メモリエディタで特定のプロセスを範囲を指定して検索した場合に、
プロセス内での変動をメモリエディタで検索できないようにするのって
別プロセスとかで変動させたりするの？

2025/01/27(月) 19:17:48.20

うん！

2025/01/27(月) 22:29:46.88

他プロセスのメモリにアクセスするのは
一般的にデバッグインターフェース使うから
対象プロセス停止させてるんじゃないか？