タグ付けされた質問 「static」

私はしばしば、Javaのヘルパークラスまたはutilクラスまたはあらゆる種類の言語に直面しています。それで、私はこれがアンチパターンの一種であり、この種のクラスの存在はソフトウェアの設計とアーキテクチャに欠けているだけかどうかを自問していた。 多くの場合、これらのクラスは、多くのことを行う静的メソッドのみを使用して制限されます。しかし、ほとんどの場合、実際にはコンテキストに依存し、ステートフルです。 私の質問は、そのような種類の静的ヘルパー/ユーティリティクラスについてのあなたの意見は何ですか？利点はもちろんクラス名だけを使用した高速呼び出しであるためです。 そして、これらの種類のクラスの使用を避けるのは、どのような抽象化レベルですか？ 私の意見では、キーワード「static」はクラスの宣言（Java）内でのみ許可され、メソッドでは許可されません。私の意見では、この方法でそれを使用することは、Javaで手続き型パラダイムとオブジェクト指向パラダイムを組み合わせて、キーワードの誤用を回避するための優れた代替手段であると考えられます。 答えによる追加： 最初は、異なるパラダイムを組み合わせたり、マシンまたはvmでコンパイルされたコード内で実行時解釈スクリプト言語を使用したりすることは完全に合法だと思います。 私の経験では、プロジェクトの開発プロセス中に、そのような種類のヘルパーやユーティリティ、または名前が何であれ、コードベースの忘れられた隅々で成長し、使用されています。そして、リファクタリングを行う時間や設計をもう一度考える時間がないため、時間の経過とともにそれをさらに悪化させます。 staticJavaから削除する必要があると思います。特に今では、さらに洗練された関数型言語要素を使用することができます。

19 design-patterns  anti-patterns  static 

最近、統合テストフレームワーク用、Javaプロジェクト用にGroovyでプログラミングを開始しました。Intellij IDEAをGroovyプラグインで使用していますが、非静的でインスタンスフィールドに依存しないすべてのメソッドの警告として表示されて驚いています。ただし、Javaでは、これは問題ではありません（少なくともIDEの観点から）。 インスタンスフィールドに依存しないすべてのメソッドを静的関数に変換する必要がありますか？trueの場合、これはGroovy固有のものですか、それとも一般的なOOPで利用可能ですか？なぜ？

19 java  object-oriented  groovy  static  instance 

数ヶ月前、私は新しいプロジェクトで働き始めました。コードを調べてみると、使用されている静的メソッドの量が多くなりました。としてのユーティリティメソッドだけcollectionToCsvString(Collection<E> elements)でなく、多くのビジネスロジックも保持されます。 私はこの背後にある理論的根拠の責任者に尋ねたとき、彼はそれが春の専制政治から逃げる方法だと言った。この思考プロセスに何かがあります：顧客の領収書作成方法を実装するために、サービスがあります @Service public class CustomerReceiptCreationService { public CustomerReceipt createReceipt(Object... args) { CustomerReceipt receipt = new CustomerReceipt(); // creation logic return receipt; } } さて、この男は、基本的にはクライアントクラスがSpring Beanでなければならないという制限を課しているため、Springによって不必要に管理されるクラスを持つことを嫌うと言いました。最終的にすべてをSpringで管理することになります。これにより、手順を踏まずにステートレスオブジェクトを操作する必要が生じます。ここに記載されている内容は多かれ少なかれhttps://www.javacodegeeks.com/2011/02/domain-driven-design-spring-aspectj.html したがって、上記のコードの代わりに、彼は public class CustomerReceiptCreator { public static CustomerReceipt createReceipt(Object... args) { CustomerReceipt receipt = new CustomerReceipt(); // creation logic return receipt; } } …

13 java  object-oriented  state  static-methods  static 

後者を導入するときに、C ++が静的グローバル（内部リンケージ）と名前のない名前空間のシンボル（外部リンケージですが、外部から参照する方法がない）を区別したのはなぜですか？ これらの理由のいずれかがまだ有効ですか、それとも新しい理由がありますか？ それらがまだ異なる場所が残っていますか？しかし、匿名グローバル（または名前空間スコープ）ユニオンはである必要staticがあるという任意のルール、およびそれらは何ですか？ ボーナスポイントに関して、それらが異なる理由が残っていない場合、それらを同等にするリクエストはありますか？ C ++が名前空間（C ++ 98）、特に名前のない名前空間を導入したとき、静的グローバルは陳腐化し、熱意の中で新しいものよりも劣っていたが、C ++ 11で元に戻された： staticキーワードの廃止…もういや？ C ++ 11より前は、内部リンケージのあるシンボルをテンプレート引数として使用できませんでした。C++ 03が外部リンケージを持つためにテンプレートパラメーターを必要とするのはなぜですか。

11 c++  language-design  history  namespace  static 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 5年前休業。 私はオブジェクトの概念を理解しており、Javaプログラマーとして、OOパラダイムは実際にはかなり自然に生まれてくると感じています。 しかし最近、私は自分自身が考えていることに気づきました。 ちょっと待ってください、実際に静的クラスを使用するよりもオブジェクトを使用することの実際的な利点は何ですか（適切なカプセル化とOOプラクティスで）。 オブジェクトを使用することの2つの利点を考えることができます（どちらも重要で強力です）。 ポリモーフィズム：実行時に動的かつ柔軟に機能を交換できます。また、システムに新しい機能「パーツ」と代替手段を簡単に追加することもできます。たとえばCar、Engineオブジェクトを操作するように設計されたクラスがあり、Carが使用できるシステムに新しいエンジンを追加したい場合、新しいEngineサブクラスを作成して、 このクラスのオブジェクトをオブジェクトに渡すだけで済み Carます。について何かを変更しCarます。そして、実行時にそうすることを決定できます。 「機能を渡す」ことができる：システムの周りにオブジェクトを動的に渡すことができます。 しかし、静的クラスよりもオブジェクトに他の利点はありますか？ 多くの場合、新しい「パーツ」をシステムに追加するときは、新しいクラスを作成し、そこからオブジェクトをインスタンス化します。 しかし、最近立ち止まって考えたところ、静的クラスは、オブジェクトを通常使用する多くの場所で、オブジェクトとまったく同じように機能することに気付きました。 たとえば、アプリにファイルの保存/読み込みメカニズムを追加する作業をしています。 オブジェクトを使用すると、コードの呼び出し行は次のようになります。 Thing thing = fileLoader.load(file); 静的クラスを使用すると、次のようになります。 Thing thing = FileLoader.load(file); 違いは何ですか？ かなり古いことですが、私は、昔ながらの静的クラスがまったく同じように動作するときに、オブジェクトをインスタンス化する理由を考えることができません。しかし、OOシステムでは、静的クラスはほとんどありません。だから私は何かを逃しているに違いない。 リストした2つのオブジェクト以外のオブジェクトには、他に利点がありますか？説明してください。 編集：明確にします。機能を交換したり、データを渡したりするときに、オブジェクトは非常に便利です。たとえば、メロディーを構成するアプリを作成しました。MelodyGenerator異なる方法でメロディーを作成するいくつかのサブクラスがあり、これらのクラスのオブジェクトは交換可能でした（Strategyパターン）。 メロディーもオブジェクトを渡すことができたので便利です。コードとスケールもそうだった。 しかし、システムの「静的な」部分についてはどうですか？それは渡されません。たとえば、「ファイルを保存する」メカニズムです。静的クラスではなくオブジェクトに実装する必要があるのはなぜですか？

9 design  object-oriented  class  static