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

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

新規登録して質問してみよう
ただいま回答率
85.50%
Java

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

Android

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

iOS

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

プログラミング言語

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

Swift

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

Q&A

解決済

6回答

44809閲覧

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

TetsuroMikami

総合スコア43

Java

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

Android

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

iOS

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

プログラミング言語

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

Swift

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

14グッド

19クリップ

投稿2016/02/20 10:16

14

19

プログラミング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排除による、僕が気づいていないメリットが他にあるのでしょうか?

takotakot, stereo_code, tokoi, mhashi, naoyan, Snsk, DrqYuto, kozuchi, tatsuya6502, kitajima_rccm, 他4名👍を押しています

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

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

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

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答6

0

ベストアンサー

なぜこれらの比較的新しい言語では、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 10:59

編集2016/02/20 11:01
yohhoy

総合スコア6189

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Chironian

2016/02/20 11:08

> そもそもフィールドと1:1対応させたgetterを持たせることが、オブジェクト指向設計として適切なのかという議論が昔からあります。 ほんと、実はこれがポイントのように思います。たくさんのgetter/setterを定義するクラスって少ないですもんね。
TetsuroMikami

2016/02/20 11:17

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

2016/02/20 11:30

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

2016/02/21 02:18

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

2016/02/22 03:33 編集

Javaのgetter/setterはJavaBeans仕様が初出(という説が有力)なので、1996~1997年頃から歴史があるようですね。JavaBeansはフレームワークの規約ですから、言語本体の仕様拡張を嫌ったという側面が強いと思います。 プロパティ構文を導入した他プログラミング言語については、それより早い・遅いを調べるのは難しいですね…。軽く調べた感じだとD言語が2001年、C# v1.0が2002年、Objective-C 2.0が2006年ですから、いずれもJavaBeansよりは後発の様です。
Chironian

2016/02/23 05:33 編集

プロパティは現代の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年のようです。
yuba

2016/02/24 23:33

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

0

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

投稿2016/02/20 10:51

chitoku

総合スコア1610

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

TetsuroMikami

2016/02/20 11:08

SwiftのdidSetなどは知りませんでした。教科書的な記述をすっ飛ばして実装してしまっていたので、きちんと勉強しなければと思いました。 ご指摘ありがとうございます。 プロパティの一覧を補完機能から得るというのが、褒められたやり方でないというのは承知していますが、皆さんプロパティ名をど忘れたりとかってないのでしょうか?笑
chitoku

2016/02/20 11:15

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

0

こんにちは。

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

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

投稿2016/02/20 11:04

Chironian

総合スコア23272

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

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

投稿2016/02/23 09:18

_crane_

総合スコア15

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

SuehiroSaito

2016/09/20 14:07

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

0

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

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

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

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

投稿2016/02/23 04:14

poad1010

総合スコア30

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

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

投稿2016/02/23 04:02

編集2016/02/23 04:08
k_yosi

総合スコア16

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

fuzzball

2016/02/23 06:54

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

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

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

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問