質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.51%

  • Java

    15311questions

    Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

  • Swift

    8406questions

    Swiftは、アップルのiOSおよびOS Xのためのプログラミング言語で、Objective-CやObjective-C++と共存することが意図されています

  • Android

    7097questions

    Androidは、Google社が開発したスマートフォンやタブレットなど携帯端末向けのプラットフォームです。 カーネル・ミドルウェア・ユーザーインターフェイス・ウェブブラウザ・電話帳などのアプリケーションやソフトウェアをひとつにまとめて構成。 カーネル・ライブラリ・ランタイムはほとんどがC言語/C++、アプリケーションなどはJavaSEのサブセットとAndroid環境で書かれています。

  • iOS

    4485questions

    iOSとは、Apple製のスマートフォンであるiPhoneやタブレット端末のiPadに搭載しているオペレーションシステム(OS)です。その他にもiPod touch・Apple TVにも搭載されています。

  • プログラミング言語

    730questions

    プログラミング言語はパソコン上で実行することができるソースコードを記述する為に扱う言語の総称です。

最近のプログラミング言語にgetter/setterがないのはなぜ?

解決済

回答 6

投稿

  • 評価
  • クリップ 18
  • VIEW 30K+

TetsuroMikami

score 35

プログラミング2年目で、Androidのアプリ開発から始め、Swiftで最近iOSもちょっとやってます。
SwiftやKotlinに若干触れた際の疑問です。

Javaでは、一般に、フィールド変数を直接参照するよりも、getter/setterメソッドを介して値をgetなりsetなりするのが良い、と最初の頃に読んだ本に書いてあり、実際それに沿った実装が多いと思います。

一方、SwiftやKotlinでは、フィールド変数はメソッド経由ではなく、直接参照したり、変更したりするような言語の設計になっていると理解しています。

そこで質問なのですが、なぜこれらの比較的新しい言語では、getter/setterを嫌って(?)このような設計となっているのでしょうか?
これによるメリットって、getter/setterを毎回書かなくて済むっていうことだと思うのですが、AndroidStudioだったら自動で書いてくれる機能がありますし、他のIDEでも、プラグインなどで同じ機能は簡単に実現できると思います。

むしろ、デメリットとして、次のような点があると思っています。

・参照したい時にとりあえずgetって打ってから予測変換で探すことができないからめんどい
・Swiftだと、ある変数の値を変えようとして代入すると、"この変数はReadOnlyだよ"とかいった警告が出てきて、だるい(それならgetterだけ実装してsetterを実装しなければいいのに)

そしてこのデメリットはメリットと比べて大きすぎるように自分は思うのですが、getter/setter排除による、僕が気づいていないメリットが他にあるのでしょうか?

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 6

checkベストアンサー

+39

なぜこれらの比較的新しい言語では、getter/setterを嫌って(?)このような設計となっているのでしょうか? 
getter/setter排除による、僕が気づいていないメリットが他にあるのでしょうか?

最大のメリットは、コードが簡潔になることだと思います。Java的なgetter/setter方式では冗長な記述が増えるため、プログラマにそのようなBoilerplateコードを書かせないための言語設計です。

一方、SwiftやKotlinでは、フィールド変数はメソッド経由ではなく、直接参照したり、変更したりするような言語の設計になっていると理解しています。 

上記解釈は、適切でないと思います。Kotlinには プロパティ(property) という仕組みがあり、これは改良されたgetter/setterと解釈できます。Swiftも同じく プロパティ という機能を持っています。

知っている限り、Java言語以降に登場したプログラミング言語ではgetter/setter方式よりも、property方式のほうが主流だと思います。

・Swiftだと、ある変数の値を変えようとして代入すると、"この変数はReadOnlyだよ"とかいった警告が出てきて、だるい(それならgetterだけ実装してsetterを実装しなければいいのに) 

値の取得のみを許す/設定は許可しないという設計に対して、誤ったコードにコンパイラが警告を出しているので、getterのみが提供される状態と同義です。(単に"慣れ"の問題と捉えました。)

・参照したい時にとりあえずgetって打ってから予測変換で探すことができないからめんどい

これについては、たしかに一定のメリットがあります。ただし、そもそもフィールドと1:1対応させたgetterを持たせることが、オブジェクト指向設計として適切なのかという議論が昔からあります。

古くは2003年頃の"Why getter and setter methods are evil"まで遡れるようです。他にも"getter setter"で検索すると様々な意見があるかと思います。本回答では断定的な表現はさけますが、全体の論調としては反対派が優勢ですし、現にモダンな言語ではgetter/setterを避ける機構が用意されています。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/02/20 20:08

    > そもそもフィールドと1:1対応させたgetterを持たせることが、オブジェクト指向設計として適切なのかという議論が昔からあります。

    ほんと、実はこれがポイントのように思います。たくさんのgetter/setterを定義するクラスって少ないですもんね。

    キャンセル

  • 2016/02/20 20:17

    回答ありがとうございます。
    どうもSwiftやKotlinについての僕の理解が足りていないようですね。
    勉強します。

    キャンセル

  • 2016/02/20 20:30

    Javaであってもsetterはあまり定義しないほうが楽ですね。
    setterがあると、「この不正状態を作った奴は誰だぁ!」をしないといけないので。

    キャンセル

  • 2016/02/21 11:18

    yohhoyさんのお答えの通りかと思いますが、歴史的経緯としては「Javaのgetter/setter方式がよろしくないからプロパティ方式が広まった」というよりは、「プロパティ方式を取り込もうとしたJava陣営が、文法ルール拡張を避けるためにgetter/setterのメソッド名ルールという規約でプロパティを表現することにした」の方がより実体に近いと思います。

    キャンセル

  • 2016/02/22 09:43 編集

    Javaのgetter/setterはJavaBeans仕様が初出(という説が有力)なので、1996~1997年頃から歴史があるようですね。JavaBeansはフレームワークの規約ですから、言語本体の仕様拡張を嫌ったという側面が強いと思います。

    プロパティ構文を導入した他プログラミング言語については、それより早い・遅いを調べるのは難しいですね…。軽く調べた感じだとD言語が2001年、C# v1.0が2002年、Objective-C 2.0が2006年ですから、いずれもJavaBeansよりは後発の様です。

    キャンセル

  • 2016/02/23 13:21 編集

    プロパティは現代のRAD的なGUI設計スタイルに起点があると思います。
    RADスタイルでGUIを設計するのはVisual Basicが最初ではないかと思います。VBの初版は1991年みたいです。
    それがDelphiに取り込まれ、C++Builderへ展開され、その開発メンバの一部がマイクロソフトに引きぬかれてC#へ引き継がれたと理解してます。

    ただ、RADの3大要素のプロパティ、メソッド、イベントの内どれか一つはVBにはなかった記憶が有ります。どれだったのかもう記憶に残ってません。
    でも、1995年のDelphiでは3つ揃っていました。私はDelphi 1.0を展開したC++Builder 1.0にて初めてプロバティを扱って感動した記憶があります。

    【追記】
    探したら、VB 2.0の情報がありました。
    http://www.ipentec.com/document/document.aspx?page=software-visual-basic-20-install
    プロパティ・ウィンドウにはC++Builderもよく似た項目が並んでました。VB 6.0とC++Builderのプロパティは同じ働きでした。VB 2.0を触ったことはないですが議論の対象になっているプロパティと同じと思いますよ。VB 2.0は1992年のようです。

    キャンセル

  • 2016/02/25 08:33

    ありがとうございます。VBのことは知らなかったのですが、念頭にあったのはDelphiでした。

    キャンセル

+11

まず現状として Java が getter や setter に言語レベルで対応していないのでわざわざメソッドを作らなければならなくなっています。
Swift はプロパティーに対して didSet や willSet を設定できるためそもそもメソッドを作る必要がありません。読み取り専用プロパティーは getter だけ実装すれば良いというのはその通りで、Swift でもそのようにプロパティーを定義することで readonly になります。
わたしは C# という自動実装プロパティーという機構を持つ言語(Swift に似ています)を使っていますが get と打ってプロパティの一覧を得るようなことはしませんし、むしろ短く表記できるのでこの方が便利だと感じます。慣れの問題ではないでしょうか…。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/02/20 20:08

    SwiftのdidSetなどは知りませんでした。教科書的な記述をすっ飛ばして実装してしまっていたので、きちんと勉強しなければと思いました。
    ご指摘ありがとうございます。

    プロパティの一覧を補完機能から得るというのが、褒められたやり方でないというのは承知していますが、皆さんプロパティ名をど忘れたりとかってないのでしょうか?笑

    キャンセル

  • 2016/02/20 20:15

    もちろんプロパティーに対して補完機能は使いますが、別に get で始まっていなくても補完されますよね…?

    キャンセル

+10

こんにちは。

「getter/setterが無い」のではなく、「プロパティがある」のではないでしょうか?
フィールドに対して参照/設定をするのと同じ構文で、getter/setterを呼び出せる機能がプロパティと呼ばれています。そのような言語でもgetter/setterを定義することは可能な筈です。
ですので、他のプロジェクト・メンバーと話して合意が得られれば、プロパティを使わないで旧来のgetter/setterを使えばよいのではないでしょうか?

getter/setterをいちいち定義しなくて済むことが嬉しい人はプロパティを使えば良いし、予測変換でメソッドが出てこないことが嬉しいし人はgetter/setterを定義すれば良いように思います。
両方取りたい人は命名規則を決めて、メソッド、リードライト可能なメンバ変数、リードオンリなメンバ変数のプリフィックスを被らないように定めることも可能かと。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+2

ご存知かもしれませんが、SwiftにはComputed Propertyというものがあります。使う側からはプロパティに見えますが、実態はメソッドというものです。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/09/20 23:07

    これが,一番いいでしょうね。

    キャンセル

0

無意味な回答ですので削除します(回答の削除方法がわからない・・・)

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/02/23 15:54

    ページ右下から運営さんにお願いすると削除してもらえます。

    キャンセル

0

実用面でのお話については、殆どの理由が挙がっているので、オブジェクト指向としての考え方に則した面での論点をば。

「オブジェクトは、単なるデータホルダーではない」
が尤もな理由のように感じます。

http://tbd.kaitoy.xyz/2015/07/22/getters-setters-evil/

Javaには、他の言語いうプロパティ相当の昨日はありませんが、メソッドで代用するにしても、すべてにおいてset〜とか、get〜とするのはよくないと思います。
あとは、Javaでありがちなbooleanを返すis〜というメソッド。
wasでもhaveでもneedでも、その時々の最適な命名が存在するはずです。
不変オブジェクトであれば、getterメソッドも不要で、そのままpublic finalなフィールドへアクセスさせてもいいと思います。(モジュール結合強度上がってしまうし、Mock化してテストし辛いので、実用面では避けたほうがいいですが)

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

同じタグがついた質問を見る

  • Java

    15311questions

    Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

  • Swift

    8406questions

    Swiftは、アップルのiOSおよびOS Xのためのプログラミング言語で、Objective-CやObjective-C++と共存することが意図されています

  • Android

    7097questions

    Androidは、Google社が開発したスマートフォンやタブレットなど携帯端末向けのプラットフォームです。 カーネル・ミドルウェア・ユーザーインターフェイス・ウェブブラウザ・電話帳などのアプリケーションやソフトウェアをひとつにまとめて構成。 カーネル・ライブラリ・ランタイムはほとんどがC言語/C++、アプリケーションなどはJavaSEのサブセットとAndroid環境で書かれています。

  • iOS

    4485questions

    iOSとは、Apple製のスマートフォンであるiPhoneやタブレット端末のiPadに搭載しているオペレーションシステム(OS)です。その他にもiPod touch・Apple TVにも搭載されています。

  • プログラミング言語

    730questions

    プログラミング言語はパソコン上で実行することができるソースコードを記述する為に扱う言語の総称です。