問題タブ [library-design]

標準の Java ライブラリとそのクラスを調べていると、それらのクラスのいくつかに、それらのクラスの原因とはほとんど関係のないメソッドが含まれていることに気付きました。

私が話しているメソッドは、たとえば、いくつかの「システムプロパティ」の値を取得するInteger #getInteger 、または名前によって目的が明確に定義されているSystem#arraycopyです。それでも、これらのメソッドはどちらも場違いに見えます。特に最初のメソッドは、何らかの理由でシステム リソースの操作をプリミティブ型のラッパー クラスにバインドします。

私の現在の観点からすると、このようなメソッド配置ポリシーは、基本的な OOP 設計原則に違反しているように見えます。つまり、各クラスは特定の問題のセットを解決することに専念しなければならず、それ自体をスイス アーミー ナイフに変えてはなりません。しかし、Java 設計者がバカだとは思わないので、これらのメソッドを正しい場所に配置するという決定の背後には何らかの論理があると思います。誰かがそのロジックが実際に何であるかを説明できれば幸いです。

ありがとう！

アップデート

Java には、激動の過去の残骸にすぎない非論理的な要素があるという事実をほのめかした人もいます。次に、私の質問を再定式化します。なぜ Java は、そのアーキテクチャ上の欠陥を非推奨としてマークすることをそれほど嫌うのでしょうか。コードを作成しましたか？

最大サイズは特定のオブジェクトに依存しないためstd::vector、静的メソッドである必要があると思います。それでも、標準のプロトタイプは非静的であり、その理由がわかりません。論理的には、オブジェクトを作成する前に最大サイズを確認する必要がありstd::vectorます。

この質問は、基本的に についてのこの質問とは異なることに注意してくださいconstexpr。

確かに、かなり理論的な質問です。

そして、図書館利用者というより、図書館設計者の視点でお聞きしたいです。目標は、ユーザーにとって可能な限り簡単なデザインを提供することですが。

特定のインターフェイスが常にユーザーによって実装されることになっていることを伝える方法のガイドライン/ベストプラクティスはありますか? または、ファクトリ関数が提供されており、そのインターフェイスを実装する合理的なオブジェクトを作成していますか?

もちろん、ほとんどの場合、これは文脈から明らかなはずです。パラメータとしてそのようなインターフェースを期待する別のライブラリ関数は、それをどこから取得するかは一目瞭然です。それは単なるチェーンのリンクになるからです。しかし、かなり進化したシステムやライブラリが、もはやそれほど簡単に理解されなくなっていることを想像できる人もいると思います。

ファクトリ関数がどこかにあるのか、ユーザーが常に独自の実装を提供する必要があるのか​​ という基本的な質問に関して、インターフェースの理解がますます難しくなるのをどのように防ぐことができますか?

答えはコメント、ドキュメント、またはコードにありますか?

ファクトリ関数は常にインターフェイスのすぐ近くで宣言する必要があると思います。そうでない場合は、何もありません。しかし、これが柔らかすぎるガイドラインなのか、それとも常に実現できないのかはわかりません。

Scalaでライブラリを作成しました。これは、さまざまな実装が付属するパーサーです。すべてから抽象化する特性は、次のようになります (簡略化)。

ライブラリによって提供される具体的なパーサーの実装は、上記の特性を拡張します (目を見張るものはありません)。

クライアントが具体的な実装クラスに依存することを望まないので (パッケージを非公開にすることも考えました)、タイプを公開せずにパーサーへのアクセスを提供するトレイトのコンパニオン オブジェクトを使用しています。

ユーザーは、必要に応じて独自のParserトレイトの実装を使用できる必要もあります。

ただし、これが最善のアプローチであるかどうかはわかりません。

• このアプローチには一般的な欠点がありますか?
• アクセス修飾子を使用して 2 つの実装を非表示にするのはどうですか? クライアントの観点から、実装にアクセスする理由はありますか?

これらは、疎結合と抽象化に関する非常に基本的な質問だと思うかもしれません。これは必ずしもそうではありません。私は常に依存性注入フレームワークなどを使用しています。でも; 私はこれまでライブラリを公開したことがなく、誰もが柔軟に使用できるものを複雑にすることなく提供することは非常に難しいと感じています.

最新の C++、つまり 14 または 17 を使用してスパース マトリックス クラスを実装したいと考えています。ストレージと実行時の効率の間にはトレードオフが必要であることはわかっています。現時点では、ストレージ効率の点でさらに最適化したいと考えています。可能であれば、実行時ではなくコンパイル時に行う作業を増やしたいと思います。たとえば、ベクターには多くの実行時チェックがあるため、最適ではない可能性があります。誰かがこれのためのコンテナを提案できますか? 以下の運用をサポートする予定です。

ありがとう！