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

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

6
オブジェクトプーリングは非推奨のテクニックですか?
私はオブジェクトプーリングの概念に非常に精通しており、常に可能な限りそれを使用しようとしています。 さらに、Java自体と他のフレームワークが可能な限りプーリングを使用することを確認したため、オブジェクトプーリングは標準的な標準であると常に考えていました。 最近、私にとってはまったく新しい(そして直感に反する?)ものを読みました。 このプーリングにより、特に同時実行アプリケーションでは特にプログラムのパフォーマンスが低下します。new新しいJVMではオブジェクトのインスタンス化が非常に高速であるため、代わりにオブジェクトをインスタンス化することをお勧めします。 私は本でこれを読みました: Java Concurrency in Practice 本の最初の部分では、新しいインスタンスを作成する代わりにExecutorsその再利用を使用するようにアドバイスされているので、ここで何かを誤解しているのではないかと考え始めていThreadます。 それでは、オブジェクトプーリングは非推奨になりましたか?

5
依存性注入:フィールド注入vsコンストラクター注入?
私はこれが熱い議論であることを知っており、意見はベストアプローチの実践に関して時間とともに変化する傾向があります。 コンストラクターインジェクションの利点についてさまざまなブログ(例:petrikainulainenとschauderhaftとfowler)を読み始めるまで、クラスではフィールドインジェクションのみを使用していました。それ以来、必要な依存関係にはコンストラクター注入を使用し、オプションの依存関係にはセッター注入を使用するように方法を切り替えました。 しかし、私は最近、モック作成フレームワークであるJMockitの作成者との議論に参加しました。彼は、コンストラクターとセッターの注入を悪い習慣と見なし、JEEコミュニティが彼に同意することを示しています。 今日の世界では、注射を行う好ましい方法はありますか?フィールドインジェクションは好ましいですか? ここ数年フィールドインジェクションからコンストラクターインジェクションに切り替えたため、使用するのがはるかに明確になりましたが、自分の視点を再検討すべきかどうか疑問に思っています。JMockit(RogérioLiesenfeld)の著者はDIに精通しているため、コンストラクター/セッターインジェクションに対して非常に強く感じているので、私のアプローチを検討する義務があります。

6
Javaとは異なり、「new」および「virtual + override」キーワードでC#が作成されたのはなぜですか?
Javaではノーがあるvirtual、new、overrideメソッド定義のキーワード。したがって、メソッドの動作は理解しやすいです。場合原因DerivedClassが延びBaseClassのを、同じ名前と同じシグネチャを持つ方法有するBaseClassのその後ランタイム多形で行われるオーバーライドが(メソッドではない提供しますstatic)。 BaseClass bcdc = new DerivedClass(); bcdc.doSomething() // will invoke DerivedClass's doSomething method. C#に来ると、非常に多くの混乱が発生し、newor virtual+deriveまたはnew + virtualオーバーライドがどのように機能するかを理解するのが難しくなります。 なぜ世界DerivedClassで同じ名前と同じシグネチャを持つメソッドを追加しBaseClass、新しい動作を定義するのかを理解することはできませんが、実行時のポリモーフィズムでは、BaseClassメソッドが呼び出されます!(これはオーバーライドではありませんが、論理的にはそうする必要があります)。 以下の場合にはvirtual + override論理的な実装が正しいですが、プログラマが、彼はコーディングの際に上書きするようにユーザーに権限を与えるべき方法だと思うしなければならないのに。これには賛否両論があります(今は行かないでください)。 それで、なぜC#には非論理的な推論と混乱のためのスペースがあるのか。それで、どの現実世界の文脈で、代わりに使用するか、またvirtual + override代わりに使用することを考えるべきかという質問を再構成できますか?newnewvirtual + override 特にOmarからの非常に良い回答の後に、C#デザイナーはメソッドを作成する前にプログラマが考える必要があることについてより多くのストレスを与えたと思います。 今、私は質問を念頭に置いています。Javaのように、次のようなコードがあった場合 Vehicle vehicle = new Car(); vehicle.accelerate(); 後で新しいクラスをSpaceShip派生させVehicleます。次にcar、すべてをSpaceShipオブジェクトに変更したいので、1行のコードを変更するだけです Vehicle vehicle = new SpaceShip(); vehicle.accelerate(); これは、コードのどのポイントでも私のロジックを壊しません。 しかし、C#の場合、if SpaceShipがVehicleクラスをオーバーライドせずにaccelerate使用するnewと、コードのロジックが壊れます。それは不利ではないですか?

18
なぜ人々はまだJavaが遅いと言うのですか?[閉まっている]
SOや他の場所で長い間、Javaは遅いという評判があります。ジョークから質疑応答における多くのコメントまで、人々はJavaが90年代のJavaの経験だけに基づいて遅いとまだ信じています。 これが私の問題です。Javaが遅いと人々が信じる(ほとんどの)理由を反証しています。小さなこと以外は、Javaは非常に高速です。 それでは、なぜ人々は今でもJavaが高速であると信じることを拒否しているのでしょうか?C / C ++ではないものが遅いというのは彼らの考え方の一部ですか?人々が時間をかけてチェックしないからでしょうか?それは人々が偏っているからでしょうか?
61 java  performance 


8
受信パラメータの変更はアンチパターンですか?[閉まっている]
私はJavaでプログラミングしており、常にコンバーターを次のように作成しています。 public OtherObject MyObject2OtherObject(MyObject mo){ ... Do the conversion return otherObject; } 新しい職場でのパターンは次のとおりです。 public void MyObject2OtherObject(MyObject mo, OtherObject oo){ ... Do the conversion } 私にとっては、着信パラメータを変更しないことに慣れていたので、少し臭いです。この着信パラメータの変更はアンチパターンですか、それとも大丈夫ですか?重大な欠点がありますか?

7
コードカバレッジは未使用のメソッドを強調しています-どうすればよいですか?
私は、既存のJavaプロジェクトのコードカバレッジを増やすように依頼されました。 コードカバレッジツール(EclEmma)が、どこからも呼び出されないメソッドを強調していることに気付きました。 私の最初の反応は、これらのメソッドの単体テストを書くことではなく、ラインマネージャー/チームにそれらを強調し、これらの機能がそもそもなぜあるのかを尋ねることです。 最善のアプローチは何でしょうか?それらの単体テストを作成するか、それらがなぜ存在するのか疑問に思いますか?

10
より良いShow()+ Hide()またはSetVisible(bool visible)ですか?
何が良くて、なぜですか?(インターフェース設計の観点から): A)2持っているShow()とHide()機能を b)1つのSetVisible(bool visible)機能を持つ 編集:たとえば、一部のオブジェクトには可視性の状態があり、この関数を使用して変更します。 C)3つのすべての持っているためにShow()、Hide()、SetVisible(bool visible)機能を
59 java  c++  interfaces 

11
Javaの最新のレビュー[終了]
私は数年前からプログラミングをしていて、Javaを始めました。そして、Javaが何らかの形で劣った言語であると主張するさまざまなソースを見つけました。各言語には長所と短所があることをよく知っていますが、Javaについて読んだ多くのことは時代遅れのようです。 Javaが劣っている最もよく挙げられる理由は、たとえばC ++など、他のネイティブにコンパイルされた言語よりもJavaがはるかに遅いことです。多くの人々は、パフォーマンス部門が明らかに不足しているため、Javaの使用についてゲームデザイナーのノッチ(Minecraftを開発した)を批判しています。当時はJavaの方がはるかに低速でしたが、それ以来、特にJITコンパイルでは多くの改善が見られました。 今日、言語としてのJavaについて客観的な意見を聞きたいと思います。したがって、私の質問には4つの部分があります。 パフォーマンス。 a。今日のJavaの速度はC ++と比較してどうですか? b。Javaを使用して最新のAAAタイトルを作成することは可能でしょうか? c。JavaがC ++より遅いのは、具体的にどのような分野ですか?(つまり、数値演算、グラフィックス、またはその周辺) Javaは現在、コンパイル言語またはインタープリター言語と見なされていますか? 初期の頃から対処されてきたJavaの主な欠点は何ですか? まだ対処されていないJavaの主な欠点は何ですか? 編集: 明確化の目的のために、私はこのJava対C ++を作成していません。明らかに、平均してc ++はJavaよりも少し高速です。この時点で、Javaを言語としての成熟度に関して比較するものが必要です。C ++は永遠に存在しているので、私は比較の良い点になると思いました。


7
C#またはJavaのような言語で代数データ型をどのようにエンコードしますか?
代数データ型で簡単に解決できる問題がいくつかあります。たとえば、リスト型は次のように簡潔に表現できます。 data ConsList a = Empty | ConsCell a (ConsList a) consmap f Empty = Empty consmap f (ConsCell a b) = ConsCell (f a) (consmap f b) l = ConsCell 1 (ConsCell 2 (ConsCell 3 Empty)) consmap (+1) l この特定の例はHaskellにありますが、代数データ型をネイティブにサポートする他の言語でも同様です。 OOスタイルのサブタイプへの明らかなマッピングがあることがわかります。データ型は抽象基本クラスになり、すべてのデータコンストラクターは具体的なサブクラスになります。Scalaの例を次に示します。 sealed abstract class ConsList[+T] { def map[U](f: T …

4
重複コードを受け入れることができる例外的なケースはありますか?
私は、3つのAPIを構築する必要があるソフトウェアプロジェクトに取り組んでいます。1つはホームバンキングチャネル用、もう1つは代理店チャネル用、3つ目はモバイルチャネル用です。 エージェンシーAPIは、すべての機能を備えているため、最も完成度の高いAPIです。 ここでのアーキテクトは、共通層(すべてのAPIで共有されるクロスチャネルEJBサービス)を作成しました。ただし、APIは異なります。 現在のところ、API間に大きな違いはありません。大きなチームはエージェンシーチャンネルから始まり、現在はホームチャンネルに適応しています。私たちは、単にホームアプリ専用のオブジェクトを強化しています。それ以外の場合、コードはAPI間で95%類似しています。APIはSpring MVCの上に構築されており、(コントローラー、モデル、およびいくつかのユーティリティ)があります。 基本的に、コントローラーはBOをChannelObject(これを行うのに適切な場所ではないようです)、およびいくつかの追加のユーティリティとシリアライザーへのマッピングBOを実行しています。今のところすべてが重複しています。重複の理由は、APIを独立させたいからだと言っています。「明日、私たちが代理店や携帯電話とは異なる行動を家庭で望むなら、私たちは苦労しません!」 重複コードを受け入れる必要がある場合はありますか?
57 java  api  spring 

3
Java 8でラムダ構文の代わりにメソッド参照構文を使用すると、パフォーマンス上の利点はありますか?
メソッド参照はラムダラッパーのオーバーヘッドをスキップしますか?将来的にはそうなるのでしょうか? メソッド参照に関するJavaチュートリアルによると: 時々...ラムダ式は既存のメソッドを呼び出すだけです。これらの場合、既存のメソッドを名前で参照する方が明確な場合がよくあります。メソッド参照により、これを行うことができます。これらは、既に名前を持っているメソッドのコンパクトで読みやすいラムダ式です。 いくつかの理由から、メソッド参照構文よりもラムダ構文の方が好きです。 ラムダはより明確です Oracleの主張にもかかわらず、メソッド参照構文があいまいであるため、ラムダ構文はオブジェクトメソッド参照の速記より読みやすいと思います。 Bar::foo xのクラスで静的な1引数のメソッドを呼び出してxを渡しますか? x -> Bar.foo(x) または、xで引数のないインスタンスメソッドを呼び出していますか? x -> x.foo() メソッド参照構文は、どちらの代わりにもなります。コードが実際に行っていることを隠します。 ラムダはより安全です クラスメソッドとしてBar :: fooを参照し、Barが後で同じ名前のインスタンスメソッドを追加した場合(またはその逆)、コードはコンパイルされなくなります。 ラムダを一貫して使用できます 任意の関数をラムダでラップできます。そのため、どこでも同じ構文を一貫して使用できます。メソッド参照構文は、プリミティブ配列を取得または返すメソッド、チェックされた例外をスローするメソッド、またはインスタンスと静的メソッドとして使用されるメソッド名が同じメソッドでは機能しません(メソッド参照構文が呼び出されるメソッドについて曖昧だからです) 。同じ数の引数を持つメソッドをオーバーロードした場合は機能しませんが、とにかくそれを行うべきではないため(Josh Blochの項目41を参照)、メソッド参照に対してそれを保持することはできません。 結論 パフォーマンスの低下がない場合は、IDEで警告をオフにし、メソッド参照をコードに散在させることなくラムダ構文を一貫して使用したいと思います。 PS ここでもそこでもありませんが、私の夢では、オブジェクトメソッドの参照は次のように見え、ラムダラッパーなしでメソッドに対してinvoke-dynamicを直接適用します。 _.foo()

6
オブジェクトに無効な状態がある場合、ゲッターは例外をスローする必要がありますか?
一般的なOOPの問題だと思っていても、特にJavaでこの問題によく遭遇します。つまり、例外を発生させると、設計上の問題が明らかになります。 String nameフィールドとフィールドを持つクラスがあるとしString surnameます。 次に、これらのフィールドを使用して個人の完全な名前を作成し、ある種のドキュメント(請求書など)に表示します。 public void String name; public void String surname; public String getCompleteName() {return name + " " + surname;} public void displayCompleteNameOnInvoice() { String completeName = getCompleteName(); //do something with it.... } 次にdisplayCompleteNameOnInvoice、名前が割り当てられる前にが呼び出された場合にエラーをスローして、クラスの動作を強化したいと思います。いい考えですね。 getCompleteNameメソッドに例外発生コードを追加できます。しかし、この方法では、クラスユーザーとの「暗黙の」契約に違反しています。一般に、値が設定されていない場合、ゲッターは例外をスローすることは想定されていません。わかりました。これは単一のフィールドを返さないため、これは標準のゲッターではありませんが、ユーザーの観点からは区別が微妙すぎて考えられない場合があります。 または、の内部から例外をスローできdisplayCompleteNameOnInvoiceます。しかし、そうするためには、直接nameまたはsurnameフィールドをテストする必要がありますgetCompleteName。そうすることで、で表される抽象化に違反することになります。完全な名前を確認して作成するのは、このメソッドの責任です。他のデータに基づいて、場合によっては十分であると判断することさえできsurnameます。 だから、唯一の可能性は、メソッドのセマンティックを変更するようだgetCompleteNameとcomposeCompleteName、それをより「アクティブ」の行動と、例外をスローする能力を示唆しています。 これはより良い設計ソリューションですか?私はいつもシンプルさと正確さの間で最高のバランスを探しています。この問題の設計参照はありますか?

2
Google Web Toolkitを使用しない場合 [閉まっている]
社内の主要なWebアプリ開発プロジェクトでGWTを使用することを検討しています。つまり、私の目での主な利点は、Javaスタックへのクロスコンパイルであり、(少なくとも理論的には)技術スタックのサイズを1つ削減するのに役立ちます。 ただし、(ほとんどの開発者と同様に)以前に焼かれたことがありますが、特定の問題ドメイン内での使用を妨げる、または制限するGWTの問題で実際に使用したプログラマーから聞いてみたいと思います。 GWTの使用に反対する論拠は何ですか?
55 java  javascript  ajax  gwt 

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