メンバー関数がクラスプロパティ/メンバー変数を使用しない場合、OOP原則に違反しますか？

私は、ファイルを開いたり、読んだり、書き込んだりできる相互作用する既存のクラスを持っています。そのためにファイルの変更を取得する必要があります新しいメソッドを追加する必要があります

これが私のクラス定義で、新しいメソッドを追加したいとします。

class IO_file
{
 std::string m_file_name;
 public:
 IO();
 IO(std::string file_name);

+ time_t get_mtime(file_name);
+       OR
+ time_t get_mtime();
};

2つのオプションがあります-

1. 空のオブジェクトを作成してから、ファイルの変更時刻を取得するメソッドの引数にfile_nameを渡します。

2. オブジェクト構築時にファイル名を渡し、単純にメンバー変数を操作するメンバー関数を呼び出します。

どちらのオプションも目的を果たします。また、2番目のアプローチは最初のアプローチよりも優れていると思います。しかし、私が理解していないのはどのようにですか？メンバー変数を利用しないので、最初のアプローチは悪いデザインですか？オブジェクト指向設計のどの原則に違反しますか？メンバー関数がメンバー変数を使用しない場合、そのメンバー関数は常に静的にする必要がありますか？

メンバー関数がクラスプロパティ/メンバー変数を使用しない場合、OOPプリンシパルに違反しますか？

番号。

OOPは、メンバー関数がクラスプロパティまたはメンバー変数を使用するかどうかを気にしません。OOPはポリモーフィズムに注意し、ハードコーディングの実装には注意しません。静的関数には用途がありますが、関数はオブジェクトの状態に依存しないという理由だけで静的であってはなりません。それがあなたの考えで良いのであれば、その考えはOOPから来たものではないので、OOPのせいにしないでください。

悪い設計はメンバー変数を利用する[しない]でしょうか？

呼び出しごとに状態を記憶する必要がない場合は、状態を使用する十分な理由はありません。

オブジェクト指向設計のどの原則に違反しますか？

無し。

メンバー関数がメンバー変数を使用しない場合、そのメンバー関数は常に静的にする必要がありますか？

いいえ。この考え方には、間違った方向に進むという意味合いの矢があります。

• 静的関数はインスタンスの状態にアクセスできません

• 関数がインスタンスの状態にアクセスする必要がない場合、関数は静的または非静的にすることができます

ここで関数を静的にするかどうかは完全にあなた次第です。しかし、そうすることで、よりグローバルな雰囲気になります。静的になる前に、関数をステートレスクラスでホストすることを検討してください。より柔軟です。

クラスプロパティまたはメンバー変数を使用しないメンバー関数のOOPの例を示します。

メンバー関数（およびステートレスクラス）：

#include <iostream>

class Strategy
{
public:
     virtual int execute (int a, int b) = 0; // execute() is a so-called pure virtual 
                                             // function. As a consequence, Strategy 
                                             // is a so-called abstract class.
};

 
3つの異なる実装：

class ConcreteStrategyAdd:public Strategy
{
public:
    int execute(int a, int b)
    {
        std::cout << "Called ConcreteStrategyAdd's execute()\n";
        return a + b;
    }
};

class ConcreteStrategySubstract:public Strategy
{
public:
    int execute(int a, int b)
    {
        std::cout << "Called ConcreteStrategySubstract's execute()\n";
        return a - b;
    }
};

class ConcreteStrategyMultiply:public Strategy
{
public:
    int execute(int a, int b)
    {
        std::cout << "Called ConcreteStrategyMultiply's execute()\n";
        return a * b;
    }
};

 
実装の選択を保存する場所：

class Context
{
private:
    Strategy* pStrategy;

public:

    Context (Strategy& strategy)
        : pStrategy(&strategy)
    {
    }

    void SetStrategy(Strategy& strategy)
    {
        pStrategy = &strategy;
    }

    int executeStrategy(int a, int b)
    {
        return pStrategy->execute(a,b);
    }
};

 
使用例

int main()
{
    ConcreteStrategyAdd       concreteStrategyAdd;
    ConcreteStrategySubstract concreteStrategySubstract;
    ConcreteStrategyMultiply  concreteStrategyMultiply;

    Context context(concreteStrategyAdd);
    int resultA = context.executeStrategy(3,4);

    context.SetStrategy(concreteStrategySubstract);
    int resultB = context.executeStrategy(3,4);

    context.SetStrategy(concreteStrategyMultiply);
    int resultC = context.executeStrategy(3,4);

    std::cout << "\nresultA: " << resultA 
              << "\nresultB: " << resultB 
              << "\nresultC: " << resultC 
              << "\n";
}

出力：

Called ConcreteStrategyAdd's execute()
Called ConcreteStrategySubstract's execute()
Called ConcreteStrategyMultiply's execute()

resultA: 7       
resultB: -1       
resultC: 12

そして、すべてのexecute()オブジェクトの状態を気にすることなく。Strategyクラスは、実際にステートレスです。状態のみContextです。ステートレスオブジェクトは、OOPでは完全に問題ありません。

このコードはここにあります。

get_mtimeここでは、staticここで示したのではなく、スタンドアロン関数または関数としてより意味があります。

mtimeファイルのはへの呼び出しから、ほとんどのシステムでは、読み取りであるlstatか類似し、それがインスタンス化されるクラスのメンバ関数としてそれを持ってしても意味がありませんので、開いているファイルディスクリプタを必要としません。

2番目のオプションが本能的に優れている（そしてIMO、ISが優れている）理由は、最初のオプションが実際には何も表さないオブジェクトを与えるためです。

ファイル名を指定しないことにより、IO_fileクラスは実際にはたまたま具体的なファイルに似た抽象的なオブジェクトになります。メソッドを呼び出すときにファイル名を渡す場合は、代わりにメソッド全体をリフローして純粋な関数にリファクタリングすることもできます。それを使用するためだけにインスタンス化する必要があるオブジェクトに関連付けておくことには、実際の利点はありません。これは単なる関数です。オブジェクトのインスタンス化のボイラープレートは、不便な追加のステップにすぎません。

一方、ファイル名を指定すると、そのオブジェクトに対して呼び出すメソッドは、Thingの特定のインスタンスに関するクエリに似たものになります。あなたのオブジェクトには実際の意味があり、それゆえに実用性があるので、それはオブジェクト指向です。

これをCに翻訳してみましょう。最初に私たちのクラス-今では構造体です：

struct IO_file {
    char* m_file_name;
};

スニペットを簡単にするために、コンストラクター関数を定義しましょう（今のところメモリリークは無視しています）。

struct IO_file* IO_file(char* file_name) {
    struct IO_file* obj = malloc(sizeof(struct IO_file));
    obj.m_file_name = file_name;
    return obj;
}

オプション＃2は次のようになります。

time_t get_mtime(struct IO_file*);

次のように使用します：

time_t mtime = get_mtime(IO_file("some-file"));

オプション＃1はどうですか？まあ、それはこのように見えます：

time_t get_mtime(struct IO_file* this, char* file_name);

そしてそれはどのように使用されますか？基本的に、あなたは最初のパラメータとしてジャンクを渡すように求めています：

time_t mtime = get_mtime((struct IO_file*)1245151325, "some-file");

あまり意味がありませんね。

C ++のオブジェクトシステムはそれを非表示にしますが、オブジェクトはメソッドの引数でもある-という暗黙のポインタ引数thisです。これはオプション＃1が悪いことです-定義によって未使用の引数があります（たまたま未使用の引数ですが、オーバーライドで使用される可能性がありますがOK）。そのような引数は、関数のシグネチャ、定義、使用法を複雑にし、引数が何をすることになっているのかについて疑問を残しているコードの読者を混乱させる一方で、何も貢献しません。 junk / NULL/ emptyオブジェクトをそれに渡すことが、彼らが現在解決しようとしているバグの原因です。ネタバレ-そうではありませんが、その可能性を探るのに時間を浪費することになります。

ジャンクの引数が暗示的であるという事実は、影響を軽減する可能性がありますが、それはまだ存在しており、メソッドを作成することで簡単に回避できstaticます。