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

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

13
C ++にはあるがJavaにはない言語機能を避けるべきですか?
プロジェクトの環境によってC ++の使用に制限されているとします。C ++にはあるがJavaにはないいくつかの言語機能(例えば、多重継承、演算子のオーバーロード)の使用を防ぐのは良いですか? その理由は次のとおりです。 JavaはC ++よりも新しいため、JavaがC ++の機能を提供しない場合、その機能は適切ではないことを意味するため、使用を避ける必要があります。 C ++固有の機能(例:フレンド関数、多重継承)を備えたC ++コードは、C ++プログラマーのみが保守またはレビューできますが、JavaのようなC ++(C ++言語固有の機能なし)を記述するだけで、コードは両方によって保守またはレビューできますC ++およびJavaプログラマ。 いつかJavaにコードを変換するように求められる場合があります 通常、C ++固有の機能を持たないコードの方が保守しやすい すべてのC ++言語固有の機能(例:多重継承)には、Javaで実装する代替手段が必要です。そうでない場合、設計パターンまたはコードアーキテクチャに問題があることを意味します。 本当?
110 java  c++  code-quality 

12
インスタンス変数よりもローカル変数を好む理由は?
私が取り組んでいるコードベースでは、インスタンス変数を頻繁に使用して、さまざまな簡単なメソッド間でデータを共有しています。元の開発者は、これがアンクルボブ/ロバートマーティンによる「クリーンコード」の本で述べられているベストプラクティス、つまり「機能の最初のルールは小さくなければならない」に準拠していると断言します。「関数の理想的な引数の数はゼロ(niladic)です。(...)引数は難しいです。概念的な力を多く必要とします。」 例: public class SomeBusinessProcess { @Inject private Router router; @Inject private ServiceClient serviceClient; @Inject private CryptoService cryptoService; private byte[] encodedData; private EncryptionInfo encryptionInfo; private EncryptedObject payloadOfResponse; private URI destinationURI; public EncryptedResponse process(EncryptedRequest encryptedRequest) { checkNotNull(encryptedRequest); getEncodedData(encryptedRequest); getEncryptionInfo(); getDestinationURI(); passRequestToServiceClient(); return cryptoService.encryptResponse(payloadOfResponse); } private void getEncodedData(EncryptedRequest encryptedRequest) { encodedData = …
109 java  refactoring 

5
Javaでは、パラメータとローカルに「最終」を使用する必要はありますか?
Javaでは、変数(フィールド/ローカル/パラメーター)をとしてマークしてfinal、それらへの再割り当てを防ぐことができます。一部の属性(またはクラス全体)が不変であるべきかどうかをすばやく確認できるので、フィールドで非常に便利です。 一方、ローカルおよびパラメーターではあまり役に立たないことがわかり、通常final、それらが再割り当てされないようにマークすることは避けます(内部クラスで使用する必要がある場合は明らかな例外があります) 。しかし、最近では、できる限りfinalを使用するコードに出会いました。これは技術的に詳細な情報を提供していると思います。 プログラミングスタイルに自信がなくなったので、finalどこにでも適用することのその他の長所と短所は何か、最も一般的な業界スタイルは何か、そしてその理由は何だろう。
105 java  coding-style  final 

5
抽象クラスが既にあるのに、なぜJava 8のインターフェイスにデフォルトおよび静的メソッドが追加されたのですか?
Java 8では、インターフェイスに実装メソッド、静的メソッド、いわゆる「デフォルト」メソッド(実装クラスがオーバーライドする必要はありません)を含めることができます。 私の(おそらく素朴な)見解では、このようなインターフェースに違反する必要はありませんでした。インターフェイスは常にあなたが満たさなければならない契約であり、これは非常にシンプルで純粋な概念です。今では、いくつかのものが混在しています。私の考えでは: 静的メソッドはインターフェイスに属しません。これらはユーティリティクラスに属します。 「デフォルト」メソッドはインターフェースでまったく許可されるべきではありません。この目的には常に抽象クラスを使用できます。 要するに: Java 8より前: 抽象クラスと通常クラスを使用して、静的メソッドとデフォルトメソッドを提供できます。インターフェイスの役割は明確です。 クラスを実装することにより、インターフェイス内のすべてのメソッドをオーバーライドする必要があります。 すべての実装を変更せずにインターフェイスに新しいメソッドを追加することはできませんが、これは実際には良いことです。 Java 8以降: インターフェースと抽象クラス(多重継承を除く)には実質的に違いはありません。実際、インターフェイスを使用して通常のクラスをエミュレートできます。 実装をプログラミングするとき、プログラマはデフォルトのメソッドをオーバーライドするのを忘れることがあります。 クラスが同じシグネチャを持つデフォルトメソッドを持つ2つ以上のインターフェイスを実装しようとすると、コンパイルエラーが発生します。 インターフェイスにデフォルトのメソッドを追加することにより、実装するすべてのクラスがこの動作を自動的に継承します。これらのクラスの一部は、その新しい機能を念頭に置いて設計されていない可能性があり、これにより問題が発生する可能性があります。たとえば、誰かが新しいデフォルトのメソッドdefault void foo()をinterface Ixに追加すると、同じシグネチャを持つプライベートメソッドをCx実装Ixしているクラスfooはコンパイルされません。 このような大きな変更の主な理由は何ですか?また、追加された新しいメリット(ある場合)は何ですか?

12
例外は例外的な場合にのみ使用されるべきだと言われました。私のケースが例外的であるかどうかを知るにはどうすればよいですか?
ここでの私の具体的なケースは、ユーザーがアプリケーションに文字列を渡すことができ、アプリケーションがそれを解析し、構造化オブジェクトに割り当てることです。ユーザーが無効なものを入力する場合があります。例えば、彼らの入力は人を説明するかもしれませんが、彼らは彼らの年齢が「リンゴ」であると言うかもしれません。その場合の正しい動作は、トランザクションをロールバックし、エラーが発生したことをユーザーに伝えることであり、ユーザーは再試行する必要があります。最初のエラーだけでなく、入力で見つかったすべてのエラーについてレポートする必要があるかもしれません。 この場合、例外をスローする必要があると主張しました。彼は、「例外は例外であるべきだ。ユーザーが無効なデータを入力する可能性があるため、これは例外的なケースではない」と言って同意しませんでした。正しいようです。 しかし、そもそも例外が発明されたのはこのためだと私は理解しています。それはあなたがために使用いたエラーが発生したかどうかを確認するために、結果を検査します。チェックに失敗すると、気付かないうちに悪いことが起こる可能性があります。 例外なく、スタックのすべてのレベルが呼び出すメソッドの結果を確認する必要があり、プログラマーがこれらのレベルのいずれかをチェックインするのを忘れると、コードが誤って続行して無効なデータを保存する可能性があります(たとえば)。そのようになりやすいエラーのようです。 とにかく、ここで言ったことは何でも修正してください。私の主な質問は、例外が例外的であるべきだと誰かが言った場合、私の事例が例外的であるかどうかをどのように知ることができますか?

6
Javaのスタックメモリとヒープメモリ
私が理解しているように、Javaでは、スタックメモリはプリミティブとメソッド呼び出しを保持し、ヒープメモリはオブジェクトの格納に使用されます。 クラスがあると仮定します class A { int a ; String b; //getters and setters } aクラスのプリミティブはどこAに格納されますか? ヒープメモリが存在するのはなぜですか?なぜすべてをスタックに保存できないのですか? オブジェクトがガベージコレクションされると、オブジェクトに関連付けられたスタックは破棄されますか?

9
Javaプログラムを「ネイティブに表示」するのが難しいのはなぜですか?
ほとんどのJavaアプリケーションは、C / C ++アプリケーションと同じようには見えません。Swingは、見た目が明確になるように意図的に設計されたかもしれませんが、私が読んだ内容に基づいて、たとえばSWTは「ネイティブに見える」ことを試みましたが、完全に成功しません。 私の質問は: Java言語の開発者がネイティブGUIの外観を正確にコピーするGUIシステムを設計するのが難しいのはなぜですか?ネイティブGUIの違いは何ですか?「ネイティブ」ボタンのように見えるボタンを設計するだけの問題ではありませんか?それともそれよりも深くなりますか?
98 java  gui 

4
Java参照はCポインターとどのように異なりますか?
Cにはポインターがあり、Javaには参照と呼ばれるものがあります。彼らはすべてが何かを指しているという意味でいくつかの共通点を持っています。Cのポインターは、それらが指すアドレスを格納することを知っています。参照には住所も保存されますか?ポインターがより柔軟でエラーが発生しやすいことを除いて、それらはどのように違いますか?
97 java  c  pointers  reference 

17
カプセル化はまだOOPの象の1つですか?
カプセル化により、すべてまたはほとんどすべてのフィールドをプライベートにして、ゲッター/セッターによってこれらを公開するように指示されます。しかし、Lombokなどのライブラリが登場し、1つの短い注釈ですべてのプライベートフィールドを公開できるようになりました@Data。すべてのプライベートフィールドのゲッター、セッター、および設定コンストラクターを作成します。 誰かが私にすべてのフィールドをプライベートとして非表示にし、その後いくつかの余分な技術でそれらのすべてを公開するという意味を説明できますか?なぜパブリックフィールドだけを使用しないのですか?私たちは出発点に戻るためだけに長く困難な道を歩んだと感じています。 はい、ゲッターとセッターを介して機能する他のテクノロジーがあります。そして、単純なパブリックフィールドを介してそれらを使用することはできません。しかし、これらの技術が登場したのは、私たちがそれらの多くの特性を持っているからです-公共のゲッター/セッターの背後にあるプライベートフィールド プロパティがなければ、これらの技術は別の方法で開発され、パブリックフィールドをサポートします。そして、すべてがシンプルになり、ロンボクは今は必要ありません。 このサイクル全体の意味は何ですか?そして、実際のプログラミングではカプセル化は本当に意味がありますか?

10
「役に立たないブレース」を取り除くことを愛するボブおじさんに挑戦したことがありますか?
私は有料のコンテンツを参照するのは嫌いですが、このビデオはまさに私が話していることを示しています。ロバート・マーティンでの正確な12分間はこれを見ています。 そして、彼がこれを次のように変えると、「私がやるべきことの1つは、役に立たないブレースを取り除くことです」と言います。 昔、遠く離れた教育で、そうではないことによって制御されていると考える別のインデントされた行を追加することでバグを簡単に導入できるため、これを行わないように教えられましたif。 ボブおじさんに公平を期すために、彼は長いJavaメソッドを、はるかに読みやすい小さな機能にリファクタリングしています。彼がそれを変更し終えると、(22.18)このようになります: それが中括弧の削除を検証することになっているのかどうか疑問に思っています。私はすでにベストプラクティスに精通しています。この点でボブおじさんに挑戦することはできますか?ボブおじさんはその考えを擁護しましたか?

5
Javaに末尾再帰の最適化がないのはなぜですか?
私が読んだことから:理由は、継承があるためにどのメソッドが実際に呼び出されるかを決定するのは簡単ではないからです。 しかし、なぜJavaには少なくとも静的メソッドの末尾再帰最適化がなく、コンパイラで静的メソッドを呼び出す適切な方法を強制しないのですか? Javaが末尾再帰をまったくサポートしないのはなぜですか? ここに問題があるかどうかはまったくわかりません。 JörgW Mittag 1が説明したように、提案された複製について: もう1つの質問は、TCOに関する質問です。これはTREに関する質問です。TREはTCOよりもはるかに単純です。 また、別の質問では、JVMがJVMにコンパイルしたい言語実装にどのような制限を課しているのかを尋ねます。この質問は、JVMによって制限されないJavaについて質問します。 Javaを設計する同じ人々。 最後に、JVMにはメソッド内GOTOがあり、TREに必要なのはそれだけであるため、JVMにはTREに関する制限さえありません。 1作成されたポイントを呼び出すためにフォーマットが追加されました。

16
若い人はポインターの概念を学ぶ必要がありますか?
CマスターのDennis RitchieがCにポインターを導入したのはなぜですか?そして、なぜVB.NETやJavaやC#などの他のプログラミング言語がそれらを排除したのですか?Googleでいくつかのポイントを見つけました。あなたのコメントも聞きたいです。なぜ現代の言語でポインターの概念を排除するのですか? Cは基本的な言語であり、ポインターはCを強力で際立ったものにし、Cをより現代的な言語と競争させる概念であると人々は言います。それから、なぜ彼らはより近代的な言語のポインターを排除したのですか? 新しいプログラマーにとって、ポインターの知識はまだ重要だと思いますか?最近人々はVB.NETまたはJavaを使用していますが、これはCよりも高度な機能をサポートしており(ポインターの概念を使用していません)、現在見ている多くの人々(私の友人)は、高度な機能をサポートするためCを無視してこれらの言語を選択します。Cから始めるように伝えます。Cでは不可能なVB.NETまたはJavaの高度なことをしているときに、ポインターの概念を学ぶのは無駄だと言います。 どう思いますか? 更新: Googleで読んだコメントは次のとおりです。 初期のコンピューターは遅すぎて最適化されていませんでした。 ポインターを使用すると、アドレスに直接アクセスできるようになり、関数呼び出しでアドレスのコピーを作成する代わりに時間を節約できます。 ポインターを使用するとセキュリティが著しく低下するため、JavaとC#にはポインターが含まれていません。 これらと、さらに私が見つけたもの。私はまだいくつかの貴重な答えが必要です。それは大歓迎です。

17
すべての開発者に同じコード形式を課すことは良い考えですか?
プロジェクトに単一の標準コード形式(Eclipseでの保存アクションを伴う自動形式)を課すことを検討しています。その理由は、現在、複数(10人以上)の開発者が使用するコード形式に大きな違いがあるため、ある開発者が別の開発者のコ​​ードで作業することを難しくしているためです。同じJavaファイルが3つの異なる形式を使用する場合があります。 だから私は利点が明確であると信じています(読みやすさ=>生産性)が、これを課すことは良い考えでしょうか?そうでない場合、なぜですか? 更新 私たちは皆Eclipseを使用しており、誰もがこの計画を認識しています。ほとんどの人が既に使用しているコード形式がありますが、一部の人は独自のコード形式に固執することを好むため、強制されていません。上記の理由により、強制することを好む人もいます。

6
必要なメソッドパラメータにassertまたはIllegalArgumentExceptionを使用する方が良いですか?
Javaでは、どちらがより強く推奨されますか?その理由は?どちらのタイプも例外をスローするため、それらの処理に関しては同じです。assert少し短くなりますが、それがどれほど重要かはわかりません。 public void doStuff(Object obj) { assert obj != null; ... } 対 public void doStuff(Object obj) { if (obj == null) { throw new IllegalArgumentException("object was null"); } ... }

10
ゲッターとセッターをどのように回避しますか?
私は、オブジェクト指向の方法でクラスを設計するのに苦労しています。オブジェクトは、データではなく動作を公開することを読みました。したがって、ゲッター/セッターを使用してデータを変更するのではなく、特定のクラスのメソッドは「動詞」またはオブジェクトで動作するアクションでなければなりません。たとえば、「Account」オブジェクトには、etcなどWithdraw()でDeposit()はなくメソッドなどがありますsetAmount()。ゲッターメソッドとセッターメソッドが悪である理由を参照してください。 たとえば、Name、DOB、Tel、Addressなど、顧客に関する多くの情報を保持するCustomerクラスがある場合、これらすべての属性を取得および設定するゲッター/セッターを回避するにはどうすればよいでしょうか?すべてのデータを取り込むためにどのような「動作」タイプのメソッドを記述できますか?

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