ゲームユニットがプレイヤーか敵かを確認するためのコードは次のとおりです。これらは唯一の2つのカテゴリです。私はisEnemyメソッドを削除し、if（！isPlayer）のように敵のすべてのチェックを実行することができますが、個人的には（isEnemy）がコードの意図を明確にすると感じます。この種の状況について何か言いたいことがある確立されたコーディングスタイルはありますか？可読性を向上させるには、冗長コードを使用できますか？
public boolean isPlayer(Unit unit) {
return unit == player;
}
public boolean isEnemy(Unit unit) {
for (Unit e : enemies) {
if (unit.equals(e))
return true;
}
return false;
}
私は両方の方法を受け入れることができると思います。 ！isEnemy（）== isPlayer（）私のようにisEnemyを（）実装を検討したい場合：
public boolean isEnemy(Unit unit) {
return !isPlayer(unit);
}
この方法であなたは）（あなたがisPlayerを調整することができているかのように自分自身を繰り返し、必ずしも2つの特定のメソッドを有するがないの可読性を獲得します両方の方法に影響します。
私の意見では、それは絶対に受け入れられます。特に大きなプロジェクトでは、読みやすさは非常に重要です。また、将来的に3番目の役割を追加すると、if（！isPlayer）を使用できなくなることも考慮してください。
個人的には!isPlayer()としてisEnemy()を実装しますが、実際には敵であることを確認するためにループを実行するassertがあります。
あなたの場合、可能な状態は2つのみです。敵でも、プレイヤーでもあります。彼らが選手であれば、彼らは敵ではありません。それを表現する最もクリーンな方法は!isPlayerです。
他の可能性のある状態がある場合は、他の状態の列挙を調べることができます。
親指の一般的なルール：Don't Repeat Yourself。複製したコードの一部が変更された場合（おそらくバグを修正するため）、そのバグが発生するたびに変更する必要があります。それはメンテナンスの悪夢に変わることがあります。
あなたのコードを見ることで、敵がコレクション「敵」に存在する場合、その敵を識別しています。あなたのために、敵は本質的にプレーヤーではない人ではありません。このセマンティックを適用したい場合は、isEnemy（）メソッドを使用しないでください。
isEnemy（）メソッドが必要な別の理由は、別の型の可能性があるとわかっている場合です。 isEnemy（）メソッドを使用すると、その追加が簡単になり、よりクリーンになります。
しかし、上記の2つの条件が有効でない場合は、それを取り除いてください。彼らはYAGNIと言う通り：
IMHO目的を持ってコードを書くと、そこにある必要のないものは混乱します。あなたは、明らかに1つを持つものよりも目的のないものの目的を見出そうとするより多くの時間を無駄にすることができます。あなたの例では、一方のメソッドをもう一方のメソッドに置き換えることはできません。 –