CoffeeMachine().setWaterAmount(100);これは少し長く見えますが、関数はより柔軟です。いま時点では必要ないとしても、この方法の場合、複数の引数を受け取ることができます。そのため、将来なにかをリファクタする必要がある場合に備えるなら、関数はより安全な選択肢です。これはトレードオフです。構文はより短くかけます。ここに厳密なルールはないので、決めるのはあなた次第です。アクセスするのを妨げるものは何もありません。フィールは当然のことながら継承可能です。polyfilling.プライベートなプロパティやメソッドに対する言語レベルのサポートを提供する、ほぼ標準的な完成したJavaScriptの提案があります。始める必要があります。それらはクラス内部からのみアクセス可能です。フィールドがプライベートであることを示す特別な記号です。その外側や継承したクラスからアクセスすることはできません。プライベートフィールドはパブリックなものと衝突しません。フィールド両方を同時にもつことができます。フィールドは言語レベルで強制されます。アクセスはできません。経由する必要があります。}}多くのシナリオにおいて、このような制限は厳しすぎます。拡張する際には、その内部にアクセスすべき正当な理由があるかもしれません。フィールドが使われています。フィールドは特別です。フィールドにアクセスできます。フィールドだとそれはできません。期待通り動作しません。あることを維持するための、構文上の制限になります。想像してください、コーヒーメーカーを使用している開発者のチームがあるとしましょう。会社で作られたもので、上手く動作します。ある時保護カバーが外され、内部インタフェースが公開された状態になっています。コーヒーメーカーの内部にいくらかの調整を行いました。それにより、2日後、コーヒーメーカーは失敗するようになりました。操作をさせた人の責任です。プログラミングでも同じです。外部からの変更を意図していないものが勝手に変更された場合、結果は予測不可能です。Supportableプログラミングにおける状況は、実際のコーヒーメーカーでの場合よりも複雑です。一度購入するだけではないからです。コードは絶えず開発と改良されます。内部インタフェースを厳密に区切ると、クラスの開発者は利用者へ通知しなくても内部のプロパティとメソッドを自由に変更することができます。特定のメソッド名を変更したり、パラメータを変更したり、あるいは削除したりすることができることが明らか(外部のコードはそれらに依存していないため)だと、開発は遥かに容易になります。利用者は、新しいバージョンが登場した際、全体的な見直しになる可能性はありますが、それでも外部インタフェースが同じであればアップグレードは簡単です。複雑さを隠す人々はシンプルなものを使うのを好みます。中身はそうでないかもしれませんが、少なくとも外から見たときは。プログラマも例外ではありません。実装の詳細が隠されていて、シンプルかつ良くドキュメント化された外部インタフェースが利用可能であることは常に便利です。プロパティを使用します。これはよく知られた慣習であり、言語レベルで強制されているものではありません。始まるフィールドにアクセスするべきです。クラス内からのみアクセスできます。前のレッスン次のレッスンシェアチュートリアルマップコメントコメントをする前に読んでください...自由に記事への追加や質問を投稿をしたり、それらに回答してください。タグを使ってください。codepen...)。記事の中で理解できないことがあれば、詳しく説明してください。Kantorプロジェクトについてコンタクト。