高洛峰2017-04-18 10:37:44
そうですね、特に OO 思考と組み合わせた場合、メソッドを操作することで実際にできることがたくさんあります - タイプは重要な情報です。
さらに、これは標準であり、Java Beanはまさにその通りであり、多くのフレームワークやサードパーティのライブラリ (最も有名なものは Spring) の「通常の動作」もそれに依存しています。 「Java Empire の Java Bean」に関連する記事を検索できます。
セッター記述ロジックのような回答には強く反対します。このようなコードは非常に誤解を招きます。経験豊富な人は、ロジックを 層 (通常はモデル層に対応する) には記述できませんが、少なくともサービス層 (一般的な 3 層アーキテクチャに従って) には記述できないことを知っています。したがって、この場合の Setter はそれほど重要ではありません。要約すると、Setter でのロジックの記述に関する答えはすべて間違っています。 "bean"
存在には合理性があるとおっしゃった方にコメントさせていただきますが、「存在には合理性がある」とは一体どういう意味なのか、理解していただければ幸いです。
私を批判してくれた方々に正式に返答したいと思います——セッターで論理を語る人もいますし、他人を説得するために「誤った理論」に依存する人もいます。
1年前、私が初めてコミュニティに来たときの話をしてください。比較的高得点の達人のサインプレートにゴミSF！と書いてあるのを見たことがあります。 、私は彼の評判記録に気づきました (当時、評判記録は GitHub のコミット記録に似ていましたが、1 年ほど長くはありませんでした)、 ほぼすべての問題が反対票を投じられていました 、明らかに - これは悪意のある。
コミュニティに1年以上いると、時々このような状況に遭遇します。しかし、同様に、私はまだそれが非常に上手であることを認めます。今、この状況は私にとって耐え難いものです - あなたが間違っているとしても、あなたは間違っており、それでも他の人を誤解させなければなりません
。面接中にこのような基本的な質問に失敗したために、他の人が選別されてしまったら、残念です! 最後に皆さんに伝えたいこと:
回答で +1 ポイント、トレンドに従うと 1 ポイントのみ。踏まれると2点です。このような回答が増えるにつれ、コミュニティの質はますます悪くなるでしょう。その頃には、たとえ 1W の評判があったとしても、チャットやコミュニケーションの際に誇らしげに言うと、他の人はただ冷笑するだけになるでしょう。 そのコミュニティは質が高くなく、ただトレンドを追いかけているだけです。
怪我咯2017-04-18 10:37:44
それぞれの言語には異なる哲学があります。 Java は完全にオブジェクト指向であり、コーディング時のコードの高度な柔軟性とスケーラビリティを提唱しています。 Go のような言語はコードの究極の単純さを提唱しているため、次のように struct を定義するだけで済みます。 Go语言提倡的又是代码极致的简洁性，所以只需要像下面的方式定义struct就ok。
type S struct {
A string
B int
}但是在Java中你还是应该遵守规范为javabean定义get/set方法，因为你遵守规范才来享受规范为你带来的好处，比如你接入第3方库的时候，要使用reflect的方式来操作javabean时他们大多数都是采用get/set方法来实现的。如果你的javabean此时没有get/set方法那显然你是无法使用该库的。
以个人经验感受，代码的简洁性比代码的灵活性与可扩展性要重要。所以java中也出现了像lombok
リーリー
Java では、仕様に準拠し、javabean の get/set メソッドを定義する必要があります。これは、仕様に準拠して楽しむためです。たとえば、サードパーティのライブラリにアクセスし、reflect を使用して javabean を操作する場合、そのほとんどは get/set < を使用します。 /code> メソッドで実現します。現時点で javabean に get/set メソッドがない場合は、明らかにライブラリを使用できません。 🎜
<時間>
🎜個人的な経験からすると、コードの柔軟性やスケーラビリティよりもコードの単純さの方が重要です。したがって、lombok のようなツールキットも java に含まれており、コードを非常に簡素化できます。 🎜返事0
伊谢尔伦2017-04-18 10:37:44
上記の人たちはたくさん言いましたが、1 つの点が抜けています メソッドはポリモーフィックですが、属性はポリモーフィックではありません これをどう理解しますか?たとえば、Person は親クラス、Man はサブクラスで、親クラスとサブクラスの両方に Name 属性があり (これは非常にまれですが)、親クラスとサブクラスの名前は両方ともパブリックです。次のコードを参照してください:
リーリー答えが出力されます
person
null
迷茫2017-04-18 10:37:44
これは良い質問です！面倒なセッターやゲッターを使用する代わりに、このプライベート フィールドをパブリックにしたらどうでしょうか?理由はいくつかあります:
次のクラスを仮定しましょう:
リーリーこれに変更した方が良いでしょうか:
リーリー必要な速度が 0 ～ 40 の間であると仮定します。ゲッターとセッターがなければ、すべてのコードを書き直す必要があり、1 時間以内に完了することは不可能です。このセッターを使用すると、1 分以内に終了しない場合は、セッターのロジックを変更するだけで済みます。
リーリー
黄舟2017-04-18 10:37:44
私の理解では、「小さなプログラム」の場合、あなたと他のメンテナがパラメータ値の変更を明確に確認して制御できるため、短所はありません。プログラムの隅々まで、public甚至“利大于弊”，因为没有了setter&getter，减少了不少代码量。但当程序“大“到一定规模程度的时候，是不是应该要考虑程序的可维护性呢，比如a.money和a.getMoney()，突然有一天加入了一个a.action因子来影响money，如何保证每一个money的调用者都能知道因子影响规则，显然直接a.money就不那么可靠了。从写程序的角度来说，应该多写方法，这是我大学计算机程序课老师教我的，数据很枯燥，唯方法能让你形象地知道程序在干什么。从面向对象的角度来说，对象应该提供操作对象的方法，所以，还是方法，setter和getter就是体现了这一思想。从Java特性来说，setter和getter体现了封装特性的思想，就上面的例子，当另外一个money使用者需要调用money时，调用者本不需要知道还有一个action因子在那里，他只要getMoney()拿到正确的money だけで、変数はプライベートであり、変数を操作するためのパブリック メソッドが提供されています。この時点では、メリットがデメリットを上回ります。才能も知識もほとんどなく、同族の出身で、不適切な点があれば批判と修正を受け入れます。
さらに、setter&getter 内の論理の問題については、「できるかどうか」という問題ではなく、「そうすべきだ」という問題だと思います。前者については、長所と短所を比較検討する必要があります。プログラムのロジックとリスク管理が適切であれば、作成するのに便利です。それらの優れたフレームワークはこのように書かれているわけではなく、必ずメリットとデメリット（拡張など）を踏まえて論理処理層にロジックを置くのが一般的です。
PHP中文网2017-04-18 10:37:44
まず、メソッドの訳語はメソッドです。
それでは、あなたの混乱を理解させてください
でも、本当に将来のことをそんなに考えなくてはいけないのでしょうか
実際、これをやらない主な理由は、非常に面倒だからです。
しかし、実際には、読み取り専用フィールドなど、ゲッター セッターを使用する必要があるフィールド (フィールド、属性) があるため、コード全体の一貫性を保つために、すべてのゲッターとセッターを使用することをお勧めします。
2⃣️、ide の助けを借りれば、完了するのにそれほど労力はかかりません。
3⃣️、これは基本的に規範的なものであり、これを行う必要があるかどうかを考える必要はありません。
4⃣️、場合によっては、ゲッターとセッターは実際には必要ありません。ここでのデータが非常に単純であると確信できる場合は、データを直接公開してください。
別の質問について
プライベートフィールドがゲッターとセッターを提供する場合、それはパブリックとみなされますが、これは矛盾しているため、パブリックを使用する必要があります
目的は何ですか
まず第一に、プライベート フィールドにはゲッターとセッターのみが含まれますが、これは当然パブリックとは見なされません。セッターとゲッターの両方がある場合、それは思っているほど単純ではありません。自分で書いたゲッターセッターには処理ロジックがないのに、こんなこと考えてるんだから
リーリーこの例と同じニーズがある場合は、名前を保存するときに余分なスペースを削除する必要があります。 (ちなみに、上記のコードの構文が正しいかどうかは保証できません。私は長い間 Java を書いていませんでした。
オープンフィールドと呼んだほうがわかりやすいかという質問ですが、実は、あなたがおっしゃったPythonのオープンフィールドはオープンフィールドではありませんよね？実際の格納フィールドは _name で、getter と setter は name です。これは Java と構文が異なるだけで、本質は同じです。
ゲッターとセッターの利点を示すために、さらに 2 つのコードを追加します。
リーリー別の例
リーリー高洛峰2017-04-18 10:37:44
リーリー
ここにはカプセル化と制御の問題があります。ある日突然、プロパティ goodDog.size に直接アクセスすると、サイズごと、または特定のサイズごとに何かをフィルタリングする必要がある場合、どうすればよいでしょうか。次に、goodDog.size が表示されるすべての場所にフィルタリング メカニズムを追加する必要があります。 getSize() メソッドを使用する場合は、このメソッドでフィルタリングすれば問題ありません。 実際、全体的な考え方は、オブジェクト指向の観点から物事を行うことです。何か欲しいものがあれば、言ってください。家まで取りに行きますが、家に直接取りに行くことはできません。私の家に慣れていない場合はどうすればよいですか？
goodDog .size=12 が直接設定されている場合は安全ではありません。size の値が 10 未満の場合はどうなりますか?
これが起こらないようにするには、Java で統一された変更が必要ですか? set メソッド中に値を指定して範囲を制御できるため、将来ニーズが変わったときに、goodDog .size が使用されている場所を世界中で探す必要がなくなります
パラメータ付きメソッドとパラメータなしメソッドは、メソッドの特定の使用法に依存します。 set メソッドと get メソッドは、オブジェクト指向プログラミングのカプセル化の考え方を反映しており、メンバー変数をプライベートとして設定することは、特定のメソッドを通じてのみ変更およびアクセスできます。メソッドを使用して、プログラムのセキュリティを確保します。
Java Beans や Hibernate のように、属性を削除するときは、定義した属性サイズを取得するのではなく、getSize を取得し、get メソッドの小文字の S を削除してサイズを取得するという上記の答えもあります。
まだ理解できない場合は、次のことを思い出してください: 存在は合理的であるということは、ある日、特定のコードを書いているときに突然気づきます。
怪我咯2017-04-18 10:37:44
可視性を非表示にする場合、setter和getterメソッドは値に直接アクセスする必要はなく、いくつかの処理ロジックを追加することもできることを付け加えておきます。