私自身プログラムを書く場合、とにかくコードを書く量を制限したいという思いが強く、多少でも共通化できる箇所がある場合はなるべく共通化するようにしておりましたが、時と場合によっては過剰に共通化したことによって可読性が下がり、結果として保守しにくくなるということもありました。(特に可読性が落ちることが多いです。まとめ直近で悩んだテーマ類似のクラス例えばDogとCatみたいなクラスがあるとします(あえて内部にどのようなメソッドがあるかはここでは書かずに説明させていただきます。)共通化してAnimalのようなクラスにしてしまうDogとCatの親クラスを作り、継承するDogとCatをのクラスをあえて共通化させず残す上記のような3つの選択肢があり、私としては1(妥協して2)の選択肢が最適と考えることが多かったですが、正しいかどうかはケースバイケース(DogとCatの類似性)になります。コードを書くときは書く以上に、読みやすいか(仕様がわかるか)というのも同じぐらい大切になってきます。コードを書く量で考えると3>2>1のようになることが多いですが(3が一番ダメで1がベスト)、可読性も3>2>1(3がベストで1がダメ)になることがあり得ます。変数の統合また編集画面などで大量の入力項目がある際に以下のように引数がずらずら並ぶのは基本的にNGでなるべく少ない変数にした方がいいと考えて案1→案2のようなケースを考えておりました。この場合変数が増えることが往々にして多く、案1の場合、その度に修正が発生します。resist(personal_arr)ただ案2の方が優れた書き方かというとそんなことはありません。確かに変数が増えるなどの影響には強いのですが、デメリットとしては「連想配列だと内部にどんな変数が入っているかがわからず、内部構造を隠蔽されてしまい、他者からは分かりにくい」というデメリットがあり、一概に推奨はできないです。変数を統一することで、可読性が減ってしまっているというデメリットがあります。その場合、personalのようなオブジェクトを作るという選択肢もありますが、そうしますと案1と同等になり、コードを書く量としてはそれほど大差ないかと思います。動的な呼び出しメソッドを呼び出す場合に類似性が高かったり、数が多いとループから動的な関数あるいは変数を作ったりすることも多かったのです。することで一気にコード量を減らすことは確かにできますし、類似の変更があったときに、メンテが非常に楽ということもありますが、定義元が変更した場合に修正の影響をエディタの補完機能などでさがせないというリスクもあります。まとめこのように抽象度を上げたりすると一般的にコードの量は減るのですが、その分可読性が減るというデメリットもあります。大切なことは保守性(メンテナンスのしやすさ、修正時間)テストのしやすさ可読性(他者が読んで読みやすいか)統一性(可読性の一種ですが、他の箇所と処理が統一されているか否か)を考慮してそれぞれにメリット、デメリットを考えられることかと思います。コメントをキャンセルメールアドレスが公開されることはありません。*サイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。依存関係の管理オブジェクト指向シリーズ。読みにくい本が多い中でオブジェクト指向設計実践ガイドは勉強になるなー。OSに対する命令文を不正に紛れ込ませて攻撃させる手法。...ログ対策(どのように情報を抽出するか)現在、現場でテストをやってるんですが、やることは昔と変わらずテストデータ作り、ログ、エラーハンドリングになります。3年近くまえに↓のような記事をかいてました。...APIに関してRESTAPIのルーティングで気をつけることなんぞを。直近のプロジェクトではRESTAPIを作ることが多かったんですが気をつけることなんぞを。第5・6章はコメントについて。ここは結構賛否両論になるところではないかと思います。