1

私はJavaの本を読んでいました。そこでは、異なるクラスの変数にアクセス/変更するときは、get/setメソッドを使用してそれらを操作する必要があると書かれていました。

私の質問は、残業や大規模なプロジェクトでgets / setsを使用しても、アプリケーションのパフォーマンスが危険にさらされることはないということです。

同様の質問ですが、通常、配列はキャッシュに適しているため、より抽象的なデータ型（インスタンスの類似リストなど）を犠牲にして配列を使用することをお勧めします。

4

5 に答える 5

5

組み込みデバイスで実行する必要のある高効率アルゴリズムのクリティカルセクションを作成している場合を除き、最初の目標は、シンプルで読みやすく、保守しやすいコードを作成することです。OOPは、カプセル化などのいくつかの機能に関して、この点で役立ちます。ゲッターとセッターは、いくつかの動作をカプセル化することを可能にします。これらは、いくつかのJavaテクノロジ（JSP EL、さまざまなスクリプト言語、IDEなど）で使用される標準でもあります。一般に、パフォーマンスを主要な設計要素にすることはできません。

Javaジャストインタイムコンパイラは本当に賢く、ゲッターとセッターへの呼び出しをインライン化します。

Javaコレクションのような高レベルの抽象化も、より単純で安全なコードの記述に役立ち、テストおよび最適化されています。それらが提供するすべての配列を再実装すると、保守が難しく、非効率的なコードになります。間違いなくJavaコレクションを使用し、配列よりもそれらを優先します。

効率的な誤ったコードは、少し遅い正しいコードと比較して役に立たないことを忘れないでください。

于 2012-11-03T12:56:30.230 に答える
2

私の質問は、残業や大規模なプロジェクトでgets / setsを使用しても、アプリケーションのパフォーマンスが危険にさらされることはないということです。

いいえ。これはデータのカプセル化を促進し、OOの優れたプラクティスです。

ソフトウェアオブジェクトは、概念的には実際のオブジェクトに似ています。それらも状態と関連する動作で構成されています。オブジェクトは、その状態をフィールド（一部のプログラミング言語では変数）に格納し、メソッド（一部のプログラミング言語では関数）を介してその動作を公開します。メソッドはオブジェクトの内部状態で動作し、オブジェクト間の通信の主要なメカニズムとして機能します。内部状態を非表示にし、オブジェクトのメソッドを介してすべての対話を実行することを要求することは、データカプセル化として知られています。これは、オブジェクト指向プログラミングの基本原則です。

JavaTrailから。

配列は通常、キャッシュに適しているため、より抽象的なデータ型（インスタンスの類似リストなど）を犠牲にして配列を使用することをお勧めします。

これはユースケースによって異なります。
キャッシュフレンドリーとは、メモリ効率が高いことを意味すると思います。要素を削除する際に断片化が発生し、アレイは特定の初期容量で設計されます。10ArrayListから始まり、必要に応じて継続的にサイズを変更します。

ただし、配列を使用することの良い点は、インデックスによって要素にアクセスできることです。

于 2012-11-03T12:59:32.950 に答える
1

言葉はカプセル化です。を使用するgetとset、変数へのアクセスを簡単に制御できます（たとえば、値が範囲内にあること、同期、変更時の制御（並行プログラミングの競合状態に役立ちます）、変数を使用するスレッドにそのためのアクセス許可があることを確認します）。等。）。特に大きなプロジェクトの場合、これは小さなオーバーヘッドよりも重要です。

また、getはset、多くのフレームワーク（JPA、JSFなど）で使用されるJavaBeanの定義に含まれています。

配列は問題ありませんが、配列の正確なサイズがわからない場合は、空のセルのメモリを浪費するか、頻繁にサイズを変更する必要があり、コードが複雑になります。

于 2012-11-03T12:51:11.900 に答える
1

前回Javaで配列を使用したのが思い出せません。私はいつもArrayList似たようなコレクションを使っています。配列は、画像のような生のバイトを操作するときによく使用されます。内部的には、コレクションは配列を使用して実装されるため、、、、、 removeなどaddの追加putのメソッドを使用しても基本的に同じです。get

質問に答えて、getter/setter他の人が使用するライブラリを作成する場合は、ゲッターとセッターを使用する必要があります。ユーザーが使用するインターフェイスまたはレイヤーには、単純なプロパティ（new A().property）を介してアクセスしないでください。何もカプセル化していないため、非常に悪い設計です。モジュールがプライベートであり、アプリケーションでのみ使用されている場合でもgetters/setters、フロントエンドレイヤーで使用する必要があります。クラスが内部にあり、モジュール/パッケージの外部からアクセスできない場合は、プロパティを介してクラスにアクセスできますが、カプセル化することをお勧めします。プロパティを介してアクセスする唯一のケースは、パブリッククラス内にプライベートクラスがある場合です。プロパティを使用して、パブリックからプライベートクラスにアクセスします。例：

public class A{
    B b = new B ();

    private class B{
        String asd = "asd";
    }

    public String a (){
        return b.asd;
    }
}
于 2012-11-03T13:11:04.943 に答える
1

取得および設定するフィールドを持つことを唯一の目的とするデータオブジェクトを構築している場合は、ゲッターとセッターを使用することをお勧めします。必要に応じて検証と同期を行うことができ、古いコードを壊すことなく（フィールドを変更してAPIを一定に保つことで）フィールドを変更することもできます。

ただし、他のすべてではないにしてもほとんどの場合、ゲッターとセッターは悪い考えです。問題はパフォーマンスとは何の関係もありません。問題は、前述のデータオブジェクトの外部では、ゲッターとセッターが、基になる変数自体を直接公開するのとほぼ同じくらいひどくカプセル化を破ることです。 表示可能な変数が必要な場合は、get/setメソッドを使用します。ただし、ほとんどの場合、表示可能な変数は必要ありません。

コンシューマーは、クラスに含まれる変数について気にする必要はなく、ほとんどの場合、知っている必要もありません。これがカプセル化の本質です。「ゲッターの背後にある変数を非表示にする」という誤った概念ではなく、「変数を非表示にする、期間」です。あなたは間違いなくそれらを設定するべきではありません。変数を管理するのはクラスの責任であり、ユーザーが使用する前にクラスの操作パラメーターを設定する必要がある場合、クラスは破損します。メソッドを呼び出した後に呼び出し元がしなければならない場合はgetAnything()、メソッドのシグネチャが間違っています。彼らが得ているものは戻り値でなければなりませんでした。

ゲッター/セッターを介して、またはフィールドを公開するだけで、メンバー変数を公開することは、そのフィールドがデータである場合にのみ検討する必要があります。他のすべての状況では、より良いカプセル化が必要です。

配列とコレクションについては、状況によって異なります。私は個人的に両方が理にかなっているときにコレクションを使用するのが好きですが、それは個人的な好みです。キャッシュの局所性などは、これを決定する際の主な関心事ではありません。ただし、ArrayListほとんどの場合、は単純な古い配列と同じようにキャッシュに適していることに注意してください。取得して返すものを定義する場合Listは、特定のサブタイプがニーズにより適していることがわかったので、リストサブタイプをほぼ自由に切り替えることができます。既存のコードを壊さずに、APIの配列の戻り値をリンクリストに切り替えてみてください。:)

于 2012-11-03T13:49:39.823 に答える