OOPでは、メソッドをできるだけ頻繁にオブジェクトに変換する必要がありますか？

Question

// OOP =オブジェクト指向プログラミング

私は過去にJavaで遊んでいましたが、最近私はそれを深く知り、自己指導のOOPを体験しています。私は現在、テキストベースのゲームを作成しています。タスクを実行するメソッドを作成するときに、私が望むなら、そのメソッドをオブジェクトに変換することができます。

ランタイムやスペアリングのリソースについてよく分かりませんので、必ずしもこれらの変数を考慮する必要はありませんが、私のコードのために、ここにはいくらかスペースがあるように思えます。しかし、裏返しに、私は私のディレクトリを混乱させるかもしれないと感じる多数のクラスを作成します。

~~ たとえば、プレーヤーのプロファイルを作成するための別のクラスを作成しました。それには、3つの重要な方法があります。プレーヤーの名前選択を処理するためのもの、プレーヤーのクラス選択を扱うもの、そしてプレーヤーの決定を確定するもの。

これらのメソッドに対して3つのオブジェクトを作成し、コード内のスペースをクリアするこのクラスを呼び出すことができます。

別々のオブジェクトを作成したり、そのまま残したりするのはもっと賢明でしょうか？

Answer 1

答えはそれに依存します。

OOPでは、カプセル化と抽象化を促進するためにクラス（インスタンス化されるときはオブジェクト）が使用されます。詳細はSO postを参照してください。

抽象は、クラス階層（IS-A Bの関係）とクラス組成物（B HAS-A関係）を介して実証される共通の特徴をオブジェクト考えです。

カプセル化は、共通の状態とその相互作用が、よく定義された入力と出力を持つ単一の単位（またはクラス）と見なされるべきであるというアイデアです。

OOPは、プログラマーが簡単にコーディングできるようにするためのものです。これは、プログラム内でのやりとりを見極めようとする精神的なオーバーヘッドを減らし、目に見えてきれいで理解しやすいコードになります。

---

ケーススタディ

あなたの場合、あなたはのはPlayerProfileManagerそれを呼びましょう、プレーヤーのプロファイルの作成を処理するクラスを持っています。カプセル化によれば、プレーヤプロファイルの作成に直接関係するすべての動作（すなわちメソッド）は、PlayerProfileManagerにあるはずです。

抽象化を見ると、物事は面白くなります。

PlayerProfileManagerプレーヤープロファイルを作成し、その情報をどこかに保存します。プレーヤーのプロファイルのすべてのデータを保持するPlayerProfileクラスを作成してから、PlayerProfileManagerにPlayerProfileオブジェクトのコレクションを内部的に格納することは意味があります。管理しているプロファイルと呼んでください。

PlayerProfileManager は、HAS- PlayerProfile

をあなたはすべて取得し、プロファイルデータとプロファイルオブジェクト内のデータ管理ストアの設定を行うには上司との対話します。

他のタイプのプロファイルはありますか？

もしそうなら、任意のプロファイルに必要なすべてのプロファイル情報を持つProfileクラスが必要かもしれません。次にPlayerProfileはProfileから継承し、すべてのプレーヤ固有のデータを追加します。

PlayerProfile はプロフィール

-され、その後、あなたは一般的なプロファイルデータを管理するための一般的な方法を持っているProfileManagerクラスをしたいことがあります。

PlayerProfileManager は、IS-のProfileManager

今、私たちは、polymorphismのOOPの主要な技術を活用することができます。 すべてのプロファイルデータで何かをしたい場合は、すべてがProfileクラスから継承されているため、多態性を使って非常にうまくいくようにすることができます。詳細はリンクを参照してください。

ただし、の抽象化は、コードがで動作しやすくなった場合にのみ意味を持ちます。 1つのタイプのプロファイルしか持たず、1つのタイプしか持たない計画がある場合は、余分なレイヤーを追加するのは意味がありません。

---

結論

コードがきれいで、そして一緒に属しているものが一緒に（separation of concernsに関連する）ある限り、何も正しい答えはありません。

さまざまなレベルの抽象化を使って、あまりにも少なすぎるという利点や落とし穴を理解することをお勧めします。

Answer 2

オブジェクトのインスタンスを多数作成する必要がない場合や、オブジェクトをうまく処理できる場合は、グループで作業し合意する必要がない限り、コードスタイルは必ずしも変更されません。

また、linkを介して最初に「クラス」と「オブジェクト」が何であるかを明確にすることをお勧めします。基本的に、状態とメソッドを含むクラスからオブジェクトが作成されます。

私の例では、オブジェクトではなくクラスのコントローラビューが表示されます。MVCについて聞いたことがありますか？あなたが "クラス"と "モデル"について考えていたよりもはるかに明確にすることができるので、linkをチェックしてください。

私はあなたが悪いとは思っていないことを願っていますが、どうしたの。

Answer 3

最良の方法は、コードの維持、理解、および拡張が最も簡単な方法です。あなたが記述する3つのメソッドはおそらく正しい場所にあるでしょうが、それはクラス自体が表現するものに依存します。

のプロファイルはと記述します。記述する3つの方法はすべて、そのプロファイルに固有のデータを操作するため、これまでのアプローチは問題ありません。

最も重要なこと：コーディングを続けてください。このような細かいところでは諦めないでください。彼らは通常、教科書や教室のプレゼンテーションのように重要ではありませんし、他のものよりもアプローチを好む熱狂者ほど信じられないほど重要ではありません。コードは（ほとんどの場合）常にリファクタリングすることができ、（通常は）完全に一度も修正することはありません。

このような質問には、自分の方法が「最良の方法」または「正しい方法」であることを誰かが指摘している場合は、無視して他の人から助言を求めてください。

Answer 4

KISS（Keep it simple、stupid）を覚えています。常にインターフェイス、スーパークラス、複数のメソッドなどにすべてを抽出する必要はありません。リファクタリングには良いですが、コードが単純なことをするときには単純すぎるはずです。

Answer 5

あなたの質問と他の回答を読む私はプロファイルに関連するすべてを扱う単一のプロファイルクラスを提案します。より多くの情報が役立つかもしれませんが、あなたのコードを投稿してください。

単語の選択に注意してください。混乱することがあります。私がProfileクラスと言うときは、関連するメソッドと変数を持つProfileクラスを含む単一のProfile.javaファイルを意味します。

仮説のProfile.javaクラスには、プロファイル名、クラスなどの関連する変数が含まれている可能性があります。決定が確定したことを示すブール値かもしれません。あるいは、ユーザーにプロンプ​​トを出した後、最初にコンストラクタにすべてのデータを1回取り込むことができますか？

さらに、現在このファイルで3つの異なるファイルに分割しているすべてのメソッド（名前の選択、クラス選択、ゲッター、セッターなど）を持つことができます。これはうまくいけば物事を簡素化し、1つの場所にすべてを持つことができます。