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

Javaは、元はSun Microsystemsによって開発された、プラットフォームに依存しない高レベルのオブジェクト指向プログラミング言語です。Javaは現在、2010年にSunを購入したOracleが所有しています。

13
抽象クラスに「抽象」プレフィックスを追加する必要がありますか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 という名前の抽象クラスがあるとしTaskます。 AbstractTask代わりに名前を付けることを提案する標準または規則はありますか?

1
Java 8コードの条件付きカバレッジを測定するのは理にかなっていますか?
Java 8が登場して以来、現在のJava用ツールによる条件付きコードカバレッジの測定は時代遅れではないのかと思っています。Javaの8のではOptionalとStream私たちはしばしば、それが簡単にすべての可能な実行パスをテストすることなく、非常に高い条件カバレッジを取得することができますコード分岐/ループを回避することができます。古いJavaコードとJava 8コードを比較してみましょう。 Java 8より前: public String getName(User user) { if (user != null) { if (user.getName() != null) { return user.getName(); } } return "unknown"; } 上記のメソッドには3つの実行パスがあります。条件付きカバレッジを100%取得するには、3つの単体テストを作成する必要があります。 Java 8: public String getName(User user) { return Optional.ofNullable(user) .map(User::getName) .orElse("unknown"); } この場合、ブランチは非表示になり、100%のカバレッジを得るために必要なテストは1つだけで、テストするケースは関係ありません。カバーすべき3つの論理ブランチはまだありますが、信じています。最近の条件付きカバレッジ統計は完全に信頼できないものになっていると思います。 Java 8コードの条件付きカバレッジを測定するのは理にかなっていますか?十分にテストされていないコードを発見する他のツールはありますか?


3
コレクションを通常返す場所にストリームを返すのは正気ですか?
レガシーコードに関連付けられていないAPIを開発しているとき、結果を収集することで純粋にStreamsパイプラインで終了するメソッドを作成していることがよくあります。このように: ImmutableSet<T> deriveSomethingMeaningfulFromPrivateState() { return myPrivateThingies.stream() .map(this::ownerOfThing) .map(Owner::socialStatus) .filter(SocialStatus::isHeAFineMatey) .collect(MyCustomCollectors.toImmutableSet()); } さて、このクラスのほとんどのクライアントは通常、要素を検索してそれを反復処理するためにコレクション(この場合はImmutableSet)を必要としますが、一部のクライアントはその上にいくつかの操作をパイプできるようにストリームを持つことで利益を得ることができますコレクションから新しいストリームを取得する必要のないストリーム。したがって、ストリームを返すと、コレクションを持っている場合のオプションのスーパーセットがクライアントに提供されます(結局、常にcollect()ストリーム自体を使用できます: Stream<T> deriveSomethingMeaningfulFromPrivateState() { return myPrivateThingies.stream() .map(this::ownerOfthing) .map(Owner::socialStatus) .filter(SocialStatus::isHeAFineMatey); // No collect } このアプローチは、潜在的な欠陥が見当たらないため、試してみたいと思います。しかし、どのライブラリでもこのアプローチを見たことはありません(おそらく、Java 8の登場後にリリースされたライブラリが多くなかったためです)。既存のライブラリクラスは、通常、プライベート状態から何かを派生するときにコレクションを返します。 Java 8より前の自分がコレクションを返す場所にストリームを返すことにした場合に発生する可能性のある悪いことがありますか?または、私はここで私的状態から派生したすべてのものでアンチパターンの何かをしていますか?

4
「クラスの代わりにマップを使用してデータを表現する」-リッチヒッキー
でリッチヒッキーことで、このビデオ、Clojureの作成者、彼はJavaで行ったように、代わりにそれを表現するためにクラスを使用してのデータを表現するためにマップを使用することを助言します。単にマップとして表されている場合、APIユーザーはどのように入力キーを知ることができるのか、私はそれがどのように改善できるのか理解していません。 例: PersonAPI { Person addPerson(Person obj); Map<String, Object> addPerson(Map<String, Object> personMap); } 2番目の関数では、APIユーザーはどのようにして人を作成するための入力を知ることができますか?
19 java  design  class  clojure  map 

8
Java 7で文字列をオンに切り替えることの利点は何ですか?
この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 6年前に移行され ました。 Javaでプログラミングを始めたとき、switchステートメントが文字列を受け取らないという事実にイライラしました。その後、列挙型を使用すると、型の安全性(リファクタリングが容易になる)と他の開発者にとってわかりやすい値を渡すのではなく、列挙型を使用するメリットを実感しました。 SE7では、Enumではなく、文字列を入力として使用するスイッチを使用することにした状況を考えるのに苦労しています。文字列全体を切り替えることで実装されている場合(たとえば、部分一致または正規表現の一致ではなく)、コードが変更される理由が少なくなるようには見えません。 また、IDEツールとコーディングの読み取り/書き込み比率により、文字列値を渡すよりも余分なEnumを自動生成する方がはるかに幸せです。 彼らはプログラマーとしてどのような利益をもたらしますか?ボイラープレートが少ない? この機能のために言語が泣き叫ぶような気はしません。たぶん私は見落としているユースケースがあります。

4
データベースの設計が不十分なリレーショナルデータベース駆動型アプリケーションでより良いオブジェクト指向コードを作成する方法
私は主に、すべてのページに複数のテーブルとそれらのテーブルに適用されるフィルターがある類似したページの束で構成されるJava Webアプリケーションを作成しています。これらのテーブルのデータは、SQLデータベースから取得されます。 私はmyBatisをORMとして使用していますが、データベースの設計が貧弱で、mybatisはデータベース指向のツールであるため、私の場合はこれが最良の選択ではないかもしれません。 データベースの設計が貧弱であるため、クエリが非常に異なる可能性があるため、類似したものに対して異なるクエリを作成する必要があるため、多くの重複コードを記述していることがわかりました。つまり、クエリを簡単にパラメータ化することはできません。これは私のコードに伝播し、単純なループでテーブルの列に行を入力する代わりに、次のようなコードがあります: 取得Aデータ(P1、...、PI); get B Data(p1、...、pi); Cデータの取得(p1、...、pi); Dデータの取得(p1、...、pi); ... そして、異なる列を持つ異なるテーブルがある場合、これはすぐに爆発します。 また、ページ内のhtml要素へのオブジェクトのマッピングである「ウィケット」を使用しているという事実も複雑さを増しています。そのため、私のJavaコードはデータベースとフロントエンドの間のアダプターになります。これにより、ロジックが混在した大量の配線、定型コードが作成されます。 正しい解決策は、ORMマッパーを、dbへのより均質なインターフェースを提供する追加レイヤーでラップすることでしょうか、または私が書いているこのスパゲッティコードを処理するより良い方法はありますか? 編集:データベースに関する詳細情報 データベースは、主に電話情報を保持しています。貧弱なデザインは以下で構成されています: ドメインの知識とは関係のない人工キーを主キーとして持つテーブル。 一意のトリガー、チェック、または外部キーは一切ありません。 さまざまなレコードのさまざまな概念に一致する一般的な名前のフィールド。 条件が異なる他のテーブルと交差することによってのみ分類できるレコード。 文字列として保存される数値または日付である列。 まとめると、散らかった/怠zyなデザインです。

7
モジュール式プログラミングは計算時間に影響しますか?
誰もがコードをモジュール化する必要があると言っていますが、より少ないメソッドではなく、より大きなメソッドを使用するよりも多くのメソッド呼び出しを使用すると効率は低下しませんか?その点で、Java、C、またはC ++の違いは何ですか? 特にグループでは、編集、読解、理解が簡単になります。それで、コードの整頓の利点と比較して、計算時間の損失は重要ではありませんか?
19 java  c++  c  efficiency 

4
コードで数学ロジックを文書化する
まれですが、コードに数学ロジックを含める必要があります。使用される概念はほとんど非常に単純ですが、結果のコードはそうではありません-不明な目的を持つ多くの変数、およびそれほど明白ではない意図のある操作。コードが判読不能または保守不能であることを意味するのではなく、実際の数学の問題よりも理解が難しいというだけです。私は理解が最も難しい部分にコメントを付けようとしますが、それらをコーディングするのと同じ問題があります- テキストには数学の表現力がありません。 複雑なコードの一部、できればコード自体の背後にあるロジックを説明する、より効率的で理解しやすい方法を探しています。私はTeXを検討しました-ドキュメントを書き、コードとは別に生成します。しかし、それから私はTeXを学ぶ必要があり、ドキュメントはコード自体にはありません。私が考えたもう1つのことは、紙/ホワイトボードに書かれた数学表記、方程式、図の写真を撮り、それをjavadocに含めることです。 より簡単で明確な方法はありますか? PS 変数に(のtimeOfFirstEvent代わりにt1)わかりやすい名前を付けると、実際にはコードがより冗長になり、読みにくくなります。

6
単純型の新しい制限を定義できるプログラミング言語
多くの言語が好きC++、C#とJavaあなたのような単純な型を表すオブジェクトを作成できるようにするintegerかをfloat。クラスインターフェイスを使用すると、演算子をオーバーライドし、値が100のビジネスルールを超えているかどうかをチェックするなどのロジックを実行できます。 一部の言語では、これらのルールをアノテーションまたは変数/プロパティの属性として定義することが可能かどうか疑問に思っています。 たとえば、C#次のように記述できます。 [Range(0,100)] public int Price { get; set; } または多分C++あなたは書くことができます: int(0,100) x = 0; このようなことが行われたことは一度もありませんが、保存前にデータ検証に依存するようになったことを考えます。この機能が言語に追加されていないのは奇妙です。 これが可能な言語の例を挙げていただけますか?

5
Joda Time vs Java Time
Jodaは豊富な機能を備えており、標準のJava時間よりも洗練されていますが、常に使用するのが最善とは限りません。JavaコードでJoda TimeとJava Timeのどちらを使用すべきかを判断するにはどうすればよいですか? 要件に応じて適切なガイドラインを選択する方法を示すガイドラインがありますか?
19 java  api  joda-time 

1
サードパーティのMaven依存関係のライセンスを含める方法
私は、Javaプロジェクト用に配布可能なバイナリを作成しています。次の2つの方法でリリースしています。 メイヴン・セントラル Googleコードで配布可能なzip形式 私のプロジェクトは、Apache 2.0ライセンスの下でライセンスされています。私は少数のサードパーティを使用していますが、そのうちの1つはMITライセンスです。ライセンスの次のテキストに基づいて、プロジェクトのユーザーにライセンスの内容を認識させることが私の義務だと思います。 上記の著作権表示およびこの許可通知は、ソフトウェアのすべてのコピーまたは大部分に含まれるものとします。 私の情報源と配布物内でこれをどのように参照するのが最善ですか?私は現在考えています: 私のソースファイルは何も参照する必要はありません。それらには、Apache 2.0の定型的な通知が含まれています。 Apache 2.0ライセンステキストを含むLICENSE.txtファイルをプロジェクトのルートに追加します。 zip形式の配布可能ファイルについては、コンポーネントがMITライセンスされていることを示すものも追加する必要があります。おそらくNOTICEファイルですか? Maven Centralディストリビューションでは、アーティファクトが依存関係を宣言するだけで、実際にはそれらを含めないため、何もする必要はありません。 これは有効な計画のように思えますか?もしそうなら、誰でもポイント3を達成する方法をアドバイスできます。

3
Javaの例外の例外サフィックス
例外クラスで例外の接尾辞を指定すると、コードの匂いがします(冗長な情報-名前の残りの部分はエラー状態を意味し、例外から継承されます)。しかし、それは誰もがそれをしているようで、良い習慣のようです。 私はこれが良い習慣である理由を理解したいと思っています。 私はすでに例外がクラス名に接尾辞例外を持っているのはなぜかという質問を見てきました 質問はPHPに対するものであり、応答はおそらくJavaに対して有効です。他の引数はありますか、それとも明示的に区別するのと同じくらい簡単ですか? 前の質問の例を取り上げると、FileNoFound例外ではない名前のクラスが実際にjavaにあるでしょうか?可能であれば、接尾辞を付ける必要がありExceptionますか? の日食の簡単な階層を見るとException、確かに、それらの大部分は例外の接尾辞を持っていますが、いくつかの例外があります。javassist例えば-接尾辞なしでいくつかの例外を持っていると思われるライブラリの一例であるBadByteCode、BadHttpRequestなど BouncyCastle のような例外を持つ別のライブラリです CompileError 私はこの問題に関する情報がほとんどないので、少しグーグルで調べました。

3
デカップリングはRESTのDRYに勝りますか?
既存のJava APIのほとんどの機能を公開するREST APIを構築しています。両方のAPIは、組織内で使用するためのものです。外部で使用するために設計する必要はありません。私は両方のAPIに影響を及ぼしていますが、REST APIを実装しています。Java APIは引き続きローカルアプリケーションに使用されます(「非推奨」ではありません)が、重要な新規開発にはREST APIが使用されます。 Java APIクラスの一部は単なるデータです(プロパティ、ゲッター、セッターを持つBean)。そして少なくともこれらのいくつかは、REST APIを介して(何らかの形で)データ(XMLまたはJSONにマーシャリングされる)として送信するのに意味があります。たとえば、サーバーマシンに関する情報を格納するクラス。これらのデータクラスについて、次の選択に直面しています。 元のJavaクラス(またはサブクラス)をREST APIで直接公開する、または REST API専用の新しいデータ転送クラス(DTOパターン)を作成しますか? いずれにせよ、RESTデータ転送クラスがあります。問題は、オリジナルに注釈を付けるか、新しいものを作成するか(オリジナルのコピーに近い場合があります)です。他の選択肢もありますが、主にこれら2つに焦点を当てます。 #1の引数: DRY(繰り返さないでください) 実装が速い REST APIのアップグレードが簡単 #2の引数: REST APIをJava APIとは別にバージョン管理する必要がある場合はどうなりますか?(これは多少可能性があります。) プロパティの削除、動作の追加、クラス階層の変更など、Javaデータクラスに大幅な変更があった場合はどうなりますか?(これも多少可能性があります。) 要するに、DRY(#1)とデカップリング(#2)の間のトレードオフのように思えます。 #1から始めて、その後#2に移って問題が発生した場合は、必要なことを証明できないものを構築しないというアジャイルガイドラインに従っています。これは悪い考えですか。とにかくそこに行き着くかもしれないと思うなら、私は#2から始めるべきですか? 私のリストに欠けている主要な議論/結果はありますか?
19 java  api  rest  coupling  dry 

3
小さなオープンソースのJavaプロジェクトに選択するパッケージ名は何ですか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 Javaで小さなオープンソースライブラリを公開したいと思います。どのパッケージ名を選択すればよいのでしょうか?私は会社ではなく、命名規則に従ってパッケージの命名の基礎として使用できるドメインがありません。それでも、偶然の衝突を防ぎ、物事を標準に保つために、どういうわけか命名規則に従いたいと思います。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.