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

私の会社では、自分で設計し、インターフェイスとして指定するサーバーセントラルサービスを含むWebアプリケーションを構築しています。つまり、インターフェイスはアプリケーション固有であり、その後、時間の経過とともに変更される可能性があるサードパーティのライブラリを使用して実装されます。例外に関しては、サービスによってスローされる例外は、実装固有の例外ではなく、独自のアプリケーション固有の例外でなければならないことに気付きました。 さて、私は私たちの例外がどのように構造化され、相互に関連付けられるべきか疑問に思っています。 まず、一般的な例外について考えますMyAppException。この例外は、予期しない問題が発生したことを示しています。ユーザーにメッセージを表示して、問題が発生し、現在作業中であることを伝えることが最善の方法です。エラーは、データベースがクラッシュしたか、何か類似したものである可能性があります。この例外は、データベースを操作するすべてのメソッドからほとんどスローされます。 次に、例外を検討しますMyAppDuplicateException。この例外は、ユーザーがすでに存在するデータベースに何かを保存しようとしたことを示します。ここでは、より具体的なエラーメッセージを表示できます。この例外は、データベース行を挿入または更新するメソッドからのみスローされます。 アプリケーションにはMyAppDuplicateException、その他の予期しないエラー状況と同様のその他の例外を含めることもできます。例MyAppNotFoundExceptionなど... 今私の質問に： 他の例外は拡張する必要がありますMyAppExceptionか？実はその理由はわかりません。色んなところで見ただけで、目的があるのか​​なと思います。私が見るようにこれの欠点は、try / catch-statementがこの場合の特定の例外を気にする必要がないことです。それは単にトップの例外をキャッチすることができ、そのため、特定の例外を持っていることのほとんどのポイントであった特定のエラーを処理する必要はありません。 他の例外がない場合ではない拡張するMyAppException、すべきMyAppExceptionことjava.lang.RuntimeException？これは、コードを実行してそれをキャッチする必要はありません。例外のポイントは、何か不明なことが発生し、実行中のコードがそれを処理できるように期待されていないということだからです。リクエストのエントリポイントのコードには、キャッチMyAppExceptionしてユーザーにメッセージが表示されることを確認するtry / catchステートメントを含めることができます。 編集などの特定の例外をMyAppDuplicateExceptionチェックする必要があるかどうかは問題ではありません。チェックする必要があります。

9 java  exceptions 

私は最近、開発者がソースコードで完全修飾クラス名とインポートしたクラス名の両方を使用するコードに出くわしました。 例： import packageA.Foo; public class Example { public packageB.Bar doSomething() { final Foo foo = new Foo(); ... } } ソースコードのクラスに完全修飾名を使用したい唯一の理由は、2つの異なるパッケージに同じクラス名があり、2つを区別するために完全修飾名が必要な場合だと私は思っていました。私が間違っている？

9 java  coding-standards 

次の2種類の実装を検討してください。 public int add(int x, int y) { return mysteriousAdd(x, y); } public int add(int x, int y) { int output = mysteriousAdd(x, y); return output; } 私の同僚は、デバッグ中にmysteriousAdd返される変数を見ることができ、スタックに追加の変数を作成するのはそれほどオーバーヘッドがないため、2番目の実装の方が優れていると述べています。今日のほとんどのコンパイラーは、追加の変数なしでデバッグ中に関数の応答を示すことができ、スタックでの追加の変数の作成も回避しているため、最初の実装の方が適切であり、彼のポイントはそれほど有効ではないと思います。 スタックでの参照変数の作成は安価な操作ですか？上記の2つの方法のうち、コーディングに適しているのはどれですか。その理由は何ですか。

8 java  coding-style  coding-standards 

Doorが管理しているsがあるとしDoorServiceます。DoorServiceデータベースに格納されているドアを開く閉じてロックを担当しています。 public interface DoorService { void open(Door door) throws DoorLockedException, DoorAlreadyOpenedException; void close(Door door) throws DoorAlreadyClosedException; /** * Closes the door if open */ void lock(Door door) throws DoorAlreadyLockedException; } lockメソッドにはがありDoorAlreadyLockedException、openメソッドにはがありDoorLockedExceptionます。これはオプションですが、他にも可能なオプションがあります。 1）DoorLockedExceptionすべてに使用すると、lock()通話で例外をキャッチするときに少し面倒です try { doorService.lock(myDoor); } catch(DoorLockedException ex) // door ALREADY locked { //error handling... } 2）2つの例外タイプがDoorLockedExceptionあり、DoorAlreadyLockedException 3）2つの例外タイプがありますが、 DoorAlreadyLockedException extends …

8 java  exceptions  class-design 

プロセスの存続期間中実行し続けるデーモンスレッドを生成するオブジェクトが必要です。議論のために、それは組み込みシステムのスレッドであり、いくつかの診断ポートでコマンドを受信して​​処理するのを待機しているとしましょう。しかし、それは本当に何でもあり得ます。主なアイデアは、長期間にわたって何かを見ているということです。一連のタスクを実行していません。 一般的なJavaの知恵によると、「インスタンス化しないThreadでくださいExecutorService。代わりに使用してください」です。（例えば、この答えを見てください）しかし、利点は何ですか？単一の長期実行スレッドを作成する手段としてスレッドプールを使用しても、意味がないようです。私がこれを書いた場合よりどのように良いでしょうか？ class Foobar { public Foobar() { this.threadFactory = Executors.defaultThreadFactory(); ... } public Foobar(ThreadFactory threadFactory) { this.threadFactory = threadFactory; ... } public void start() { fooThread = threadFactory.newThread(new Runnable() { ... }); fooThread.setDaemon(true); fooThread.start(); } ... } 注：この質問は私の質問に似ていますが、答えはスレッドプールの使用方法のみを示し、理由は述べていません。

8 java  design  multithreading 

私のチーム内での最近の議論は私を不思議に思いました。基本的なトピックは、機能/統合テストでいくら、何をカバーするかということです（確かに、それらは同じではありませんが、例は重要ではないのでダミーです）。 次のような「コントローラ」クラスがあるとします。 public class SomeController { @Autowired Validator val; @Autowired DataAccess da; @Autowired SomeTransformer tr; @Autowired Calculator calc; public boolean doCheck(Input input) { if (val.validate(input)) { return false; } List<Stuff> stuffs = da.loadStuffs(input); if (stuffs.isEmpty()) { return false; } BusinessStuff businessStuff = tr.transform(stuffs); if (null == businessStuff) { return false; …

8 java  unit-testing  testing  test-automation  integration-testing 

ドメインモデルがあり、それを永続化レイヤーから読み取って保存したいとしましょう-現在のところ、それはjsonファイルの可能性がありますが、将来的にはxmlまたはデータベース（タイプも変更される可能性があります）になる可能性があります）。 永続化レイヤーからドメインモデルを生成するために、たとえばgetAll()とsaveAll()メソッドを含む簡単なインターフェイスの実装を用意しました。別のタイプの永続化に切り替えたい場合は、インターフェースの実装を変更するだけです。ただし、実装内では、完全に異なるソリューションを使用してデータを読み取り、保存するため、他のライブラリの異なるオブジェクトを使用してデータを処理する必要があります。 最初の実装でJsonシリアライザーを使用するとします。次に、そのシリアライザーのインスタンスを私の実装で直接インスタンス化します。これは、そのシリアライザに依存する私の実装に直接つながります。別のシリアライザを与えることはできません。しかし、シリアライザ（またはあらゆる種類の永続化）のユニバーサルインターフェイスがないため、これはいずれにしても不可能です。したがって、別のシリアライザを使用したい場合、私ができる唯一のことは、外部から別のシリアライザを渡すのではなく、完全に新しい実装を記述することです。 この場合、依存関係をハードコードしても大丈夫ですか？またはより良いオプションはありますか？

8 java  dependencies  persistence 

私のアプリケーションは非常に大きな整数のコレクションで動作するため、Eclipseコレクションはプリミティブなコレクションであるため、非常に便利なフレームワークのように見えます。私はすでにテストしましたが、パフォーマンスとメモリの大幅な改善が見られて嬉しいです-JDKコレクションを完全に廃止することを検討しているほどです（アプリケーションの一部で、改善がまったく目立たない場合でも）-ほとんど一貫性を保ち、1つのコレクションフレームワークのみを使用するため。 しかし、それは本当であるには良すぎるように聞こえるかもしれません-多分私はEclipseのJDKのコレクションを捨てることに関して重要な欠点を見逃しています。 私に起こる唯一のことは、コレクションに関して将来のJavaの更新/機能が何であれ、Eclipseがそれに適応するまで、Javaを利用できない可能性があるということです。 Eclipseコレクションに完全に移行したくない理由はありますか？

8 java  performance  frameworks  collections 

私の文字列はタイプであり"abacsdsdvvsg"、"a a a a a a a" 使用していますString[] stringArray = s.split("");か、または上記の分割のString[] stringArray = s.split(" "); 複雑さは何O(string length)ですか？ PS：コードが指定されている場合、O（...）を計算する方法を知っています。ここでは分割関数のアルゴリズムがわかりません。

8 java  strings  java8 

いくつかの理由で、私は子供優先ClassLoaderです。そのようなClassLoaderものはJDKには存在しないので、私はそれを書いています。これは私のユースケースの主要なコンポーネントであるため、徹底的にテストしてほしい。動作を壊さずに変更されないようにするために、私は非常に徹底して、テスト可能なすべてのものを自動的にテストしたいと考えています。 どうすればテストできますか？基本的な単体テストを行うにはどうすればよいですか？（特にsuper各メソッドに少なくとも1つの呼び出しがあるため）どこから始めればよいかわからず、開始するためのガイドラインを探しています。 私の主なアイデアは次のとおりです。何か問題がありますか？ /src/main/resources/parent.jar child.jar ファイルparent.jarにcom.example.Exampleは、基本的なSupplier戻り値であるクラスが含まれています"parent"。ファイルchild.jarにcom.example.Exampleは、基本的なSupplier戻り値であるクラスが含まれています"child"。 の標準URLClassLoaderを作成しparent.jar、カスタムClassLoaderを使用してをロードしますchild.jar。それから私は、クラスをロードしたいcom.example.Exampleと、それは実際に戻っていますことを確認してください"child"代わりに"parent"。 より複雑なテストケースが考えられますが、開始するには確認が必要です。これで基本的なテストはこれで十分ですか？これは本当に単体テストでテストする必要があるのですか？そうでない場合、何ですか？ これにはコードは必要ないと確信していますが、好奇心旺盛な方のために、こちらに示しておきます。 import java.io.*; import java.net.*; import java.util.*; class ChildFirstClassLoader extends URLClassLoader { ChildFirstClassLoader(ClassLoader parent) { super(new URL[0], parent); } @Override // Make this method available in this package. protected void addURL(URL url) { super.addURL(url); } @Override protected Class<?> loadClass(String name, boolean resolve) …

8 java  unit-testing 

ここでは、RESTful APIの認証と承認のメカニズムを扱う多くの質問がありますが、アプリケーションレベルで安全なサービスを実装する方法の詳細については触れていません。 たとえば、私のWebアプリケーション（Javaを念頭に置いていますが、これは実際にはすべてのバックエンドに当てはまります）に、APIのユーザーがユーザー名とパスワードでログインできる安全な認証システムがあるとします。ユーザーがリクエストを行うと、リクエスト処理パイプラインの任意の時点でgetAuthenticatedUser()、ユーザーがログインしていない場合はnullユーザー、またはログインしているユーザーを表すユーザードメインオブジェクトを返すメソッドを呼び出すことができます。 APIにより、認証されたユーザーはデータにアクセスできます。たとえば、GET /api/orders/はそのユーザーの注文リストを返します。同様に、GET to /api/tasks/{task_id}はその特定のタスクに関連するデータを返します。 ユーザーのアカウントに関連付けることができるいくつかの異なるドメインオブジェクトがあると仮定します（注文とタスクは2つの例であり、顧客、請求書などもある可能性があります）。認証されたユーザーだけが自分のオブジェクトに関するデータにアクセスできるようにしたいので、ユーザーがを呼び出すときは、ユーザーが/api/invoices/{invoice_id}そのリソースにアクセスすることを許可されていることを確認してから、サービスを提供します。 私の質問は、この承認の問題に対処するためのパターンや戦略は存在するのでしょうか。私が検討しているオプションの1つは、ヘルパーインターフェイス（つまりSecurityUtils.isUserAuthorized(user, object)）を作成することです。これは、リクエストの処理中に呼び出して、ユーザーがオブジェクトをフェッチすることを許可されていることを確認できます。これは、これらの呼び出しの多くでアプリケーションのエンドポイントコードを汚染するため、理想的ではありません。 Object someEndpoint(int objectId) { if (!SecurityUtils.isUserAuthorized(loggedInUser, objectDAO.get(objectId)) { throw new UnauthorizedException(); } ... } ...そして、少し面倒かもしれませんが、すべてのドメインタイプにこのメソッドを実装するという問題があります。これが唯一のオプションかもしれませんが、私はあなたの提案を聞いて興味があります！

8 java  rest  security  backend 

新しいjava.timeパッケージでは、コアクラスはofパブリックコンストラクターの代わりにファクトリメソッドを使用しています。ofメソッドの外観は好きですが、コンストラクターを使用しない理由はわかりません。私が見つけたドキュメンテーションは、これが事実であることを説明しているだけであり、それがなぜそうであるのかについては本当に入りません。 チュートリアルからの引用： Date-Time APIのほとんどのクラスは、不変のオブジェクトを作成します。つまり、オブジェクトの作成後は変更できません。不変オブジェクトの値を変更するには、元のオブジェクトの変更されたコピーとして新しいオブジェクトを構築する必要があります。これは、Date-Time APIが定義によりスレッドセーフであることも意味します。これはAPIに影響し、日付または時刻オブジェクトの作成に使用されるほとんどのメソッドには、コンストラクターではなく、of、from、またはwithがプレフィックスとして付けられ、setメソッドはありません。

8 java  java8 

try-catchステートメントをネストするとコードの臭いになることがよくあると聞いたので、この状況が例外かどうか疑問に思います。そうでない場合、リファクタリングするためのいくつかの良い方法は何でしょうか？ 私のコードは次のようになります： try{ X x = blah; otherStuff; for (int i = 0; i < N; i++){ try{ String y = Integer.toString(i); f(x); } catch(Exceptions1 e1){ System.err.println(... + y + ...); System.exit(0); } } catch(Exceptions2 e2){ ... } Exceptionsここではマルチキャッチを示すために使用しています。 e2初期化xおよび実行によってスローされた例外をキャッチするために使用されますotherStuff。理想的には、2つの行だけをtry-catchで囲んでいたはずですがx、ループ内で使用し、try-catchの外側でnullに初期化することによって引き起こされる「未使用の割り当て」警告を回避したいと考えました。 e1e2反復の詳細に関する情報をユーザーに提供したいため、ループ内にキャッチブロックが必要だったため、マルチキャッチされませんでした。

8 java  coding-style  code-quality  coding-standards 

Javaガベージコレクションは、ヒープ上のデッドオブジェクトを処理しますが、時々世界を凍結します。C ++ではdelete、作成したオブジェクトをそのライフサイクルの最後に破棄するために呼び出す必要があります。 これdeleteは、非凍結環境に支払うには非常に低価格のようです。関連deleteするすべてのキーワードを配置することは、機械的な作業です。新しいブランチが特定のオブジェクトを使用しなくなったら、コードを移動して削除を実行するスクリプトを作成できます。 では、ガベージコレクションのJavaビルドインとC ++ diyモデルの賛否両論は何ですか。 C ++対Javaスレッドを開始したくありません。私の質問は違います。 この全体的なGCのことは、「単純に、作成したオブジェクトを削除することを忘れないでください。専用のGCは必要ありません。それとも、「C ++でオブジェクトを破棄するのは本当にトリッキーです。私の時間の20％をそれに費やしますが、それでもメモリリークは一般的な場所です」

8 java  c++  garbage-collection 

クリーンアーキテクチャのほとんどの例（Androidプロジェクトはほとんどですが）では、ユースケース/インタラクタークラス（機能をカプセル化するユニット）が、ここやここのように、基本クラス/インターフェースを共有することが多いことに気付きました。他のものは（hereまたはhereのように）しません。代わりに、インタラクターがいくつかのパラメーターを受け入れることを許可し、その後、いくつかのロジックを実行するために使用されます。 これらのアプローチのいずれかが他よりも優れていますか？たとえば、ユーザー入力を必要とする何かのユースケースをパラメーターなしのアプローチがどのように処理するかに特に興味があります。たとえば、ユーザーにエンティティを編集させてサーバーに渡したいとします。同じエンティティをユースケースとそれを呼び出す人に注入することもできますが、その場合は変更可能である必要があるため、変更は両方の場所に反映されます。ただし、不必要なモデルを作成することはできません（スレッド化の問題などのため）。そのような場合の対処方法は？ ユースケース/インタラクターという用語を誤って使用した場合はご容赦ください。ただし、これはAndroidランドでの使用方法であり、確かにデザインパターンで少し遅れている可能性があります。

8 java  architecture