1

同僚との設計上の意見の相違に直面しており、オブジェクト コンストラクタの設計について意見を求めています。簡単に言うと、どのオブジェクト構築方法を好みますか?またその理由は? 

    public class myClass
    {
        Application m_App;

        public myClass(ApplicationObject app) 
        { 
             m_App = app;
        }  
        public method DoSomething 
       { 
         m_App.Method1();
         m_App.Object.Method();
       }
    }

または

    public class myClass
    {
        Object m_someObject;
        Object2 m_someOtherObject;

        public myClass(Object instance, Object2 instance2) 
        { 
             m_someObject = instance; 
             m_someOtherObject = instance2;
        }  
        public method DoSomething 
       { 
         m_someObject.Method();
         m_someOtherObject.Method();
       }
    }

裏話は、今日のオブジェクトの構築に関して根本的に異なる見方に見えるものに遭遇したことです。現在、オブジェクトは、アプリケーションの現在の設定 (イベント ログの宛先、データベース文字列など) をすべて含む Application クラスを使用して構築されます。したがって、すべてのオブジェクトのコンストラクタは次のようになります。

public Object(Application)

多くのクラスは、この Application クラスへの参照を個別に保持しています。各クラス内では、アプリケーションの値が必要に応じて参照されます。例えば

Application.ConfigurationStrings.String1 or Application.ConfigSettings.EventLog.Destination

最初は、両方の方法を使用できると思いました。問題は、コール スタックの下部でパラメーター化されたコンストラクターを呼び出し、スタックの上部で、新しいオブジェクトがアプリケーション オブジェクトへの参照がそこにあることを期待しているときに、多くの null 参照エラーに遭遇し、設計上の欠陥。

すべてのクラスを設定するためにアプリケーション オブジェクトを使用することについての私の感覚は、それが各オブジェクトのカプセル化を破り、アプリケーション クラスがすべての情報を保持する神のクラスになることを可能にするということです。この方法のマイナス面を考えると、問題が発生します。

public object(Application)必要な引数のみを受け入れるようにオブジェクトコンストラクターを変更して、 に変更したかったのpublic object(classmember1, classmember2 etc...)です。これにより、テストが容易になり、変更が分離され、渡す必要のあるパラメーターが難読化されなくなります。

現在、別のプログラマーは違いを認識しておらず、設計を変更する例や正当な理由を見つけるのに苦労しています。それは私の本能であり、私が知っているオブジェクト指向の原則に反するだけであると言うのは説得力のある議論ではありません. 私は私のデザイン思考のベースから外れていますか? どちらか一方を支持して追加するポイントはありますか?

4

4 に答える 4

2

私の見解では、クラスがその仕事をするために必要な「もの」の最小のセットをクラスに与えるということです。「アプリケーション」方式の方が前もって簡単ですが、すでに見てきたように、保守の問題が発生します。

于 2008-12-29T23:02:03.113 に答える
2

地獄、なぜ「Do」と呼ばれる1つの巨大なクラスと「It」と呼ばれるその上の1つのメソッドを作成し、宇宙全体をItメソッドに渡すのではないでしょうか。

Do.It(universe)

物事をできるだけ小さくしてください。Discreteとは、必然的に問題が発生した場合にデバッグが容易になることを意味します。

于 2008-12-29T23:05:46.803 に答える
1

スティーブ・マコーネルが非常に簡潔に述べていると思います。彼は次のように述べています。

「「利便性」の哲学と「知的管理性」の哲学の違いは、プログラムを書くこととプログラムを読むことの違いに要約されます。スコープを最大化すると、プログラムは確かに書きやすくなるかもしれませんが、どのルーチンでも任意のプログラムを使用できるプログラムいつでも変数を理解するのは, 十分に因数分解されたルーチンを使用するプログラムよりも難しい. そのようなプログラムでは, 1 つのルーチンだけを理解することはできない. そのルーチンがグローバルデータを共有する他のすべてのルーチンを理解する必要がある. そのようなプログラムは.読みにくく、デバッグしにくく、変更しにくい」[マッコネル 2004]

于 2009-01-15T10:38:44.180 に答える
0

Applicationオブジェクトを「神」クラスと呼ぶところまでは行きません。それは本当にユーティリティクラスのようです。他のクラスが自由に使用できるパブリック静的クラス（または、より良いのはクラスのセット）ではない理由はありますか？

于 2008-12-29T23:03:40.910 に答える