Q&A
> プロパティ。上より打つのが手間。
質問者さんとしてはそれだけが理由なのですか？
7.25 追記--
現在、質問に対し以下の回答をいただきました。
・プログラムの抽象構造を追う際に困る。
・会社のルールとか名前付け規則とかに引っかかる。
もしこれらや質問文のリンクにあるもの以外に、フィールドにすると困る点がありましたら、よろしくお願い致します。
※私はチームへ参加したばかりの立場です。
既存メンバーから以下のようなの反論の可能性を考慮しています。
「構造を追うのに困ってない」
「規約があれば従うが、このPjでそういった規約はない」
「バイナリ互換は要件に入っていないので、意識しなくてよい」
もし反論の余地がないような、フィールド使用によるデメリットがあればよろしくお願いいたします。
--ここまで追記
get; set; ともに public で、bind しない場合、基本的にフィールドでも問題ありませんか？
// フィールド
public int A = 0;
// プロパティ。上より打つのが手間。
public int A { get; set; } = 0;
// 古い c# だと初期化を一緒にかけないので、もっと手間なコードになる。
↓を読んだところ、CAS や バイナリ互換 等を意識すようなケースを除いて、読書公開の場合はフィールドでもデメリットはないという認識は合ってますでしょうか。
https://ladybug.hatenadiary.org/entry/20070328/p2
よろしくお願いします。
はい。
1か所だけなら大した手間ではありませんが、
1クラスに数十か所 x 数十クラス となると、それなりに手間になってきますので。
入力の手間だけならスニペットを作ればいいと思います。または私ならマクロかスクリプトを使って自動生成します。
それより一つの新規クラスに数十の何もしない公開プロパティというところから、設計に失敗してそうな臭いがプンプンします。クラスが肥大化しすぎかつクラス同士の結合が密なのではないでしょうか。
> それなりに手間になってきますので
手間がかかるからという理由は、はっきり言わせていただければ、そもそもが議論できるレベルの話ではないと思います。
> 質問者が1時間前に「まだ回答を求めています」と言っています。
会話できないところを見てそっと閉じる人は多いです。会話ができないなら、聞かれなくても自分が何を求めているか十分説明できる表現力が必要でしょう。
スニペットなどの情報ありがとうございます。
質問としては当初1行目に書いていた「...フィールドでも問題ありませんか？」になりますので、フィールドにした場合の問題点 としては引き続き募集させていただいております。
tamoto さんの回答を理解する土壌のない職場なら、オブジェクト指向プログラミングにも興味なさそうなので、好きにしたらいいと思います。
というより、状況から判断するかぎり設計者がスパゲッティをゆでる方法しか知らないので、それ以上言っても場を混乱させるだけかもしれません。自身もそれほど詳しいわけではない新人が余計なことを言って混乱させるより、先輩に相談して言う通りにするのが一番平和だと思います。時間を捻出してオブジェクト指向の勉強会を開くのも一案です。
十分な回答は付いてると思うけど、「タイプが面倒ならフィールドでも問題ありませんよ！」という回答が返ってくるまで納得しないタイプの人なんだろうか。
逆です。昨日追記済みの個所にある反論を許さないような、フィールドにすることで致命的に困るような内容を知りたいのです。
最初の話は、
> // プロパティ。上より打つのが手間。
と書いてあったので、質問者さん自身がそう思っていると理解していました (会社の仕事で面倒だからやらない何て話が通るのか疑問ではありましたが)。
しかし、7.25追記を見ると、組織の中で回りが面倒だからプロパティを使いたくない派で、質問者さんはプロパティ推進派のように見えます。
話が違ってきていませんか？
C# を作っている会社の公式の見解です。
https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/classes-and-structs/fields
> 通常、フィールドは、プライベートまたは保護されたアクセシビリティを持つ変数に対してのみ使用します。 クラスからクライアント コードに公開するデータは、メソッド、プロパティ、およびインデクサーを使用して提供する必要があります。
つまりフィールドの公開は「非推奨事項」です。
それを無理やり公開するのであれば、「公開するに足るだけの理由」が逆に必要です。
なぜ非推奨なのかを一言で言えば、「それがオブジェクト指向だから」になります。
「隠蔽なにそれおいしいの」とばかり、状態を全部無制限に公開したのではカプセル化も何もありません。
ただし、あなたの会社のコードの作り方は元々間違っているので、フィールドの公開非公開だけでどうこうなるものではありません。職場を破壊しないよう口を慎み、十分な経験を積んで技術力と発言力を手に入れるまで先輩に従ってください。
Java の話ではありますが、次の記事が参考になるのではないかと思います。
https://blog1.mammb.com/entry/2019/12/06/090000
Java にプロパティは無いので、プロパティのようなものを実装するには、フィールドを直接公開するか、それともそのフィールドにアクセスするゲッター・セッターと呼ばれるメソッドを作らなければいけません。
オブジェクト指向に慣れていない人はあなたと同じように考えました。「フィールドを公開すればいいだけなのに、わざわざゲッター・セッターを使う必要はないんじゃないか」と。そして、ゲッター・セッターを使うべきと考える人たちと論争を繰り広げました。
今挙げた記事は、その論争をする両者の主張がどちらも的外れなものであることを指摘しています。
> 話が違ってきていませんか？
私のget setとも公開の自動プロパティに対するスタンスは、
質問時点で
自分が最初から書くなら使わない、
既存のコードがあるならそれに合わせるというものです。
回答を得た7.25時点で、
今後は最初から書く時もプロパティにしてみようかな、
でも「バイナリ互換」「抽象構造を追える」は一定のメリットだけど
人に説明する際には反論される余地があるな、といったところです。
質問としては一貫して、
get setともに公開の自動プロパティの意義
なので、特に触れませんでしたが
MSのリンクを拝見しましたが、
～無効な値が入力されることを防止できます。
とあります。
これは分かっています。
今も以前もチェックが必要ならプロパティにします。
今回の質問は、"get setとも公開の"自動プロパティに限定したものです。
public int A { get; set; }
つまり何のチェックもしないsetが公開されているケースです。
フィールドで実用上問題ないような何もしないプロパティを新人が新たに数十個並べるのがおかしいという話です。
しかしそれが必要なことであれば、インターフェースやオーバーロードを考えると、最初からプロパティでいいでしょう。
ただしそれを決めるのは新人ではなく責任上位者にしておくのが後々不幸を最小限に減らせます。説得や実力行使ではなく、相談すべきでしょう。
では私の意見は最初のレス（下記に再掲）のとおりです。（あなたの組織の製品の品質の問題でロケットが落ちたり、インフラが止まったり、個人情報が漏洩したりしないことを願いながら）自分は撤退します。
> それなりに手間になってきますので
手間がかかるからという理由は、はっきり言わせていただければ、そもそもが議論できるレベルの話ではないと思います。
そもそもオブジェクト分析・設計のフェーズで各クラスのインターフェースは基本的に確定しており、そのインターフェースと内部データを分離しておくことでそのクラス内に閉じた将来的な機能追加や修正（既にある回答のようなロギング等）の影響を「他のクラスへ及ぼさない事を論理的に保証する」のがカプセル化なんだから、「フィールドで公開しておいて必要になったら後で直せばいい」って発想をする事自体がオブジェクト指向の否定になってるんで、その上で「プロパティに意味があるのか」という質問はピントが合ってないし、議論する意味がない。
OOPやる気があるならその基本思想に従ってプロパティにするし、それを否定したいんならオレオレパラダイムでやっていく、という事なんだから、話が噛み合うはずがないし、質問者を含めていまその現場にいる人たちはそれで良いかも知れないけど、将来入るメンバーは「ちゃんとOOPやってる」という前提に立てなくなるからかなり困るだろうね。
恐れ入りますが「他のクラスへ及ぼさない事を論理的に保証する」は分かりませんでした。
下記ともにAが変更されればAを読むクラスには影響があるかと。
//フィールド
public int A;
//プロパティ
public int A { get; set; }
それは設計と実装を混同してるから理解できてないだけ。
クラス設計の段階で「プロパティの取り得る値」は確定しており、それが他のクラスから見た「インターフェース」であり、「仕様」そのもの。
そのクラスの「仕様」に変更がないのであれば、その「クラス内部の処理」をどのように（プロパティのセッターでロギングを追加したりだとかの）変更しようが「論理的に＝設計段階で」別クラスに対して影響（修正が必要となるような懸念）が発生しない。これは「設計」フェーズで保証されている話。クラスの「公開仕様」そのものに変更がないんだから当然。
それに対して、あなたがやろうとしているように、実装の都合に引きずられてフィールドをプロパティに変更するような事をすると、それは「設計の変更」を同時に引き起こすことにもなる。
つまり、実装の前段階の「設計」というフェーズで、最低限仕様書は書き直す必要もあり、「仕様変更があった」ということは「論理的に」そのクラスの仕様を元に作成された別クラスにも影響が出ていることになる。これは実際のコードがどうこう、という以前の話。だからコード出して話す時点で理解できてない。
実装の都合で設計フェーズに手戻りを発生させるのを良しとする方がおかしい。プロジェクト管理上もありえない。それならオブジェクト指向的に「プロパティ」となるべきものは最初からプロパティとして実装されているべき。
たぶんロクな仕様書も起こさず、コードだけを見て適当に考えてるだけだから「概念的に違うもの」に変更する事を意味がわかってないんだと思う。
なるほど、プロパティを設計書に全部記述すると想定されていたのですね。
合点がいきました。
長々詳しくありがとうございましたm(__)m
> なるほど、プロパティを設計書に全部記述すると想定されていたのですね。
普通そうします。
今までのコメントを見て思うのは、質問者が作っているのは会社の仕事ではなく Unity の同人ゲームじゃないかということです。
もう一点。フィールド反対派のふりをしていますが、実は逆で、どうしてもフィールドでやりたいようにしか見えません。
公開した作りかけの同人ゲームで公開フィールドを多用していたのを笑われ、それに反論しようとしているというのが一番ありそうに思えます。
> なるほど、プロパティを設計書に全部記述すると想定されていたのですね。
そこじゃない。
想定云々じゃなく、率直に言えばあなたが「考える順序」を間違っているという話。
例えばフィールドとプロパティが本当に差がないと思うなら、じゃあクラス分割してプログラミングするメリットって説明できますか？処理を共通化したいだけならサブルーチンを書けば実現できます。
もっと言えば、なんでC#使ってるんですか？C#なんか使わずにアセンブリ言語を使った方が実行速度もよっぽど速いものが書けるのに。移植性とかの事情なら、C言語の方が優れてます。
C#はOOP型の言語なんで、その特徴を活かすには、OOPのメリットをちゃんと理解している必要があり、それは「人間が理解しやすくなる」からに他ならない、というが出発点じゃないですか。
個々のクラスに問題領域を分割して考えられるのがオブジェクト指向のメリットで、分割して小さな単位で考えるから効率的に仕様を作れる。
その上でカプセル化によって「データを取得・設定するための操作は公開するが、内部データは非公開にする」事で分割した問題領域間の依存関係を緩くし、クラスの公開仕様に影響がない修正を行いやすくしよう、という発想が元になってプロパティが利用されるようになった。
こういう「思想」が先にあって、その元で設計され、設計の成果物として仕様書が作成され、コードはあくまでその工程を経た上での最終的なアウトプットです。
にも関わらず、その出来た「コード」だけに着目して、フィールドとプロパティの違いがわからないとか、メリットがどうこうとか議論すること自体、そもそも話の順序が違う。
それよりもまず、特にチーム開発においてなぜオブジェクト指向が採用されているのか、をちゃんと理解するところから始めた方が良いです。（ここはZuishinさんが指摘しているのとほぼ同じ）
補足すると「想定云々じゃない」というのは、例えどんな回答を書こうが「それはこちらの想定とは違う」と言われたら無意味になるんで、そんな事が言いたいのではない、という意味。
その論法使うとあなたの懸念しているように
> 既存メンバーから以下のようなの反論の可能性を考慮しています。
>「構造を追うのに困ってない」
>「規約があれば従うが、このPjでそういった規約はない」
>「バイナリ互換は要件に入っていないので、意識しなくてよい」
とまぁ話すだけ無駄な反論が無限にできるんで、まったく意味がない。
そうやって自己完結するならお好きにどうぞ、と思うんで、そこだけしか捉えられないならこれ以上意見を述べる意思はないです。
既にいただいている複数の回答とコメントの内容に比して、質問者さんが求めているのが要はご自分の言い訳に使える意見と補完だけ？と言う印象があります。回答の落としどころが分かりませんね。異議があればご指摘願います。
>gentaroさん
再び長々ありがとうございます。
オブジェクト指向の「思想」的にフィールドがクラス外から直接アクセスできるのはおかしい。
ということで合っていますか？ 違っていたらすみません。
>dodox86さん
他者への説明用であり、自分の納得用でもありますね。
getのみ公開の自動プロパティや
get or set時に何かを行うのプロパティであれば
プロパティの必要性は明らかですが、
get setともに公開の自動プロパティについては
状況限定のメリット程度に考えていましたので。
> 他者への説明用であり、自分の納得用でもありますね。
そうではありませんね。あなた自身の結論がすでにあって、それを主張しているだけにしか見えません。
> ↓を読んだところ、CAS や バイナリ互換 等を意識すようなケースを除いて、読書公開の場合はフィールドでもデメリットはないという認識は合ってますでしょうか。
に代表されるように、どのコメントに関しても自分の読みたいところしか読まず、真逆の結論を多々出しているところから明らかです。
> という認識は合ってますでしょうか。
合ってるわけないじゃないですか。
> オブジェクト指向の「思想」的にフィールドがクラス外から直接アクセスできるのはおかしい。
> ということで合っていますか？ 違っていたらすみません。
それはあなたも元々知っているんじゃないですか。
ものすごく局所的な解釈しかしてない（あるいはする気がない）ように見えます。
カプセル化のメリットについてはここまでで十分な説明がされており、目の前のひとつのプロジェクトのコードを見て「この場合はXXという事情があるからフィールドでも良い」とかそういう低レベルな話をしたいのであれば、基本的にそれはOOPをやる上での前提から間違ってるだろ、という話にしかなりません。
また、そのプロジェクトの全てのコードが本当にプロパティとすべきものをフィールドとしていしまっていないか、どうやって担保するんでしょうか？ひとつひとつちゃんとチェックしているんですか？余計手間が増えてますが。
「必要になったら後で修正すればいい」というのは論外で、「後で修正する必要のないようにプロパティにする」という考え方と真っ向から対立しており、話が噛み合うはずがありません。
そもそもそのプロダクトのコードについて、将来起こり得る変更を全て想定するのは不可能である、というのが一般的な前提条件です。だから「書き捨てコードなら好きにすれば良い」という趣旨の回答も付いてます。
そこに「ｘｘは必要ない」「ｘｘはやらない」「ｘｘは要件にない」「ｘｘの場合はそこだけ修正すればいい」等の通常あり得ない前提条件を持ち出して「基本的にフィールドでも問題ありませんか？」という質問自体が意味を成していないんで、もはや他人に判断を委ねる問題じゃなくなってます。
Zuishinさんやdodox86さんの指摘にある通り、なんとか正当化する理由探しをしているようにしか見えません。それは議論のための議論でしかなく、何ら生産性のあるものではありません。
>gentaroさん
すみませんが、私が直前にまとめた以上のことは理解に及びませんでした。
長々書いていただきましたが、力不足で申し訳ありません。
質問者さんの認識に対するコメントですが、そういうレベルの話をするなら、
「フィールドを公開しても良いか？」について一言で答えると「ダメです。絶対に公開してはいけません。」
理由は「言語の設計思想に反するから」で終わりです。これは設計を行う際の「前提」です。反論の余地は一ミリもありません。
例えば、for 文の代わりに if 文と goto 文を使ってコードを書いていても、結果が変わらなければ良いと思いますか？
ローカル変数の代わりに、全てグローバルな変数を使ってプログラムが書かれていても、正しく動くなら良いと思いますか？
わざわざクラスやメソッドを使わなくても、Main メソッドに全部書けば良くないですか？
高級言語の機能は、一切使わないでもプログラムは書けます。なんなら機械語を書いてもいいんです。
では、高級言語が何のためにあるのか？それは、「他者との間の暗黙的な合意」を用いて認知のコストを下げるためにあるのです。
同じ言葉を話すことで対話を円滑にする、というものはプログラミングに限らない「言語」の存在意義です。
フィールドを公開することは、決して許されない罪です。そのように認識しておいてください。
>tamotoさん
分かりやすいまとめ と 例をありがとうございます。
完全な納得至れましたので、これにて質問を閉じさせていただきます。
ああ、「オブジェクト指向」という言葉がわからなかったわけですか。そこからとは。
tamotoさんと言ってることは全然変わらない（むしろ詳しく説明してた）んだけど、ちょっと難しかったのかな。
回答4件
0
ベストアンサー
こんにちは。
自分でしか使わないコードなら好きにすれば良いと思いますが、自分はフィールドを private 以外に設定しているコードは全部リジェクト対象だと考えます。
フィールドはオブジェクト指向の文脈上には表れない存在なので、外に公開されたフィールドは、プログラムの抽象構造を追う際に困ります。
例えば、interface はオブジェクトの性質を定義するものですが、プロパティは持てますがフィールドは持てません。
単純に一言で、private ならフィールド、それ以外のアクセシビリティならプロパティ、という使い分けでいいです。
公開フィールドを定義するのと公開自動実装プロパティを定義するのでは手間がそんなに変わるっていうわけでもないと思いますが、どうしてもフィールドにこだわるなら、自分専用なら、好きにフィールドを使えばいいと思います。
ところで、実のところを言うと、bind 用途でないクラスに public な auto-property 作ったこと一度もないです。可能なものは積極的に immutable にしてしまうからですね。
投稿2020/07/22 17:12
総合スコア4119
ご回答ありがとうございます。
社の既存コードに公開プロパティと公開フィールドが混在してまして、自分が編集・追加(大量)する部分をどちらに合わせるか、悩んでおりました(;^_^A
そういう話ならプロパティ一択ですね。
本来なら公開フィールドは全てプロパティであるべきなので、これ以上負債を増やす意味はないです。
そうですね。
とりあえず新規クラスについてはプロパティで統一しようと思います。
既存クラスについては以下みたいになると、統一性について突っ込まれそうなので、既存部に合わせてお茶を濁します
//既存部
public int a = 0;
public int b = 0;
public int c = 0;
//私が追加する箇所
public int d{get;set;} = 0;
public int e{get;set;} = 0;
すでに抽象構造を追えない状態ですし(;^_^A
[質問へのコメントに移動する為削除しました]
0
自動実装プロパティで済むような何かを大量に書くという前提？が既に謎めいていて状況がよくわからない感じですが…
そのような世界においても，
「呼び出し元」を探すとか，ブレークポイントを貼るとか，そういう部分での利便性の面で，プロパティの方がメリットがあるんじゃないでしょうか．
投稿2020/07/26 04:12
総合スコア11663
そうですね、私も作り方に対して疑問はありますが、そっちの構造の改修に関心がないのでそこは置いてます笑
自動プロパティにブレークは貼れない認識でしたが、今調べると貼る方法がありました。
ありがとうございます^^
あと，設計だとか動作だとかとは関係ない事柄ですが，
なんというか，「単一のクラスにpublicフィールドと自動プロパティの両者が混在しているという状況」って，心理的にキモくないですか？
（例えるならば，インデントが行ごとにタブだったりスペースだったりするような…）
で，「フィールドで書いておいて必要が生じたやつだけを都度プロパティに書き換える」ようなやり方だと…… なんということでしょう！ 結果として上記のキモい混在が生まれ得るじゃないですか．こんなの許されることじゃありませんよ！
ゆえに，「プロパティに書き換えることが考えられる」ならば，publicフィールドを書くという方向性はあり得ませぬな．
最初から全てプロパティ側に統一しておけば，カオスなコードに「F●ck！」とか声を上げることもないので，プロパティで書くことは必然となりましょうな．
逆に言えば，「プロパティに書き換えることなど考えらない」ブツであれば，「publicフィールドで統一」もあり得るということ．
Cで言うところの構造体のような，値を保持することだけが役目であって値自体に責任を負わないようなしょぼくれた型であればpublicフィールドを並べるので十分だと考えます．
キモイ、だと他の人への説得としては不足なんですよね(;^_^A
(報酬÷時間 の最大化も考えると)
キモいの自体はその通りだと思います。
ろくな設計書もなく設計も複数のプログラマーが実装しながら同時に行い、コードのみからプログラマーの意図を汲み取らなければならないことを強いるようなプロジェクトで「キモい」のは感情だけの話ではなく、時間の大きなロスに繋がる話です。
それと繰り返しますが、あなたが先輩を説得する必要はありません。それは経験も知識も浅い新人が思い込みや付け焼き刃の知識ですることではありません。まずはみんなで OOP を勉強するところからスタートです。
今のプロジェクトは何とか泥縄でコミケに間に合わせ、次から頑張ってください。
私ごとき雑魚がちょっと真面目な方向で考えるとしたら…
あるクラスにpublicフィールドを書いたならば，「その型のその名前のフィールドが常に存在すること」がそのクラスのインタフェース（と呼ぶのが妥当かどうかわからんけども，外部との約束事）となる，と言えるのではないですかな？
外部は，その約束を信じて，フィールドに対してできることは何でもやってよいわけですな．
対して，プロパティというのは，そのフィールド相当のオブジェクトが存在することすら担保しなくてよい代物ですな．
具体性というか約束の強さというかが両者の間では違うのですな．
しなくてもよい約束はしないでおいた方が，後々面倒が起きませんでしょうな．
「フィールド側のデメリットとは何か？」といわれれば，「その型のその名前のフィールドが常に存在することが後々までの縛りとなる」ということと言えましょうか．
フィールドをプロパティに難なく置き換えられたとしたら，それは「たまたま運が良かっただけ」と言えるかもしれません．
置き換えられるかどうかは，そのクラスではなく，クラスを使用している外側に依存するのですから．
追加説明ありがとうございます。
確かに そのフィールドを消す際、使用側のクラスをいじれない時はメリットになりますね。
詳しくありがとうございました。
0
自動プロパティなら特殊な処理入ってないしフィールドでも別にいいじゃん、と思うかもしれませんが、プロパティは実質メソッドなので、後からロギング処理を組み込んだり、StackFrameで呼び出し元を追跡したりする事も可能です。
また、継承先でオーバーライドして返させる値を変える事も可能です。
テスト用に使う簡易的なクラスなら好きにすればよいかと思いますが、複数人が使用する事が想定されるクラスで、publicフィールドを入れるのはちょっと有りえないです。自分がコードレビュー担当なら、即直させます。
投稿2020/07/25 14:11
編集2020/07/25 14:31退会済みユーザー
総合スコア0
ご回答ありがとうございます。
その理由ですと、ロギングやオーバーライド等が必要になった部分だけプロパティ化しては良いのでは。
プロパティにするメリットの方が大きいので、僅かなタイプを惜しんでわざわざ後からプロパティにするより、最初からプロパティでいいと思います。また、上で挙がっているようにバイナリ互換が無くなるという問題もあるので、クラスライブラリで提供する際に困ります。
まあ、その僅かなタイプ量を絶大なデメリットと考えるのであればお好きにどうぞとしか。
"後からプロパティにする"のも、"僅かなタイプ量"かと存じます。
また、ロギングのために最初からプロパティ化するなら、非公開フィールドも非公開プロパティにすることになってしまうかと。
バイナリ互換についてはすでに承知済みです。
ご回答ありがとうございました。
> "後からプロパティにする"のも、"僅かなタイプ量"かと存じます。
そんなわきゃないでしょ。プロジェクト全体を見直さなきゃならなくなるのに。
ん？
ロギングとかする個所限定の話では。
どっちにしろ自動プロパティで書いていたものなら書き直しが必要になるのは同じですし。
それだけ大量の無駄フィールドがあるならリフレクションで取得・設定する可能性も高いし、参照渡しを使う可能性も高いし、他にもフィールドとプロパティには違いがありますが、フィールドをプロパティに変更するということは、それらの見直しとテストと再実装をプロジェクト全体でやり直さなくてはならなくなるということです。リフレクションなどは特に実行時エラーしか出ないので、場合によってはテストを新たに作成する必要すら出てくるかもしれません。
あなたの作った部分だけの書き直しだけで済む話ならいいですけど、フィールド→プロパティは使用している関連個所全部コンパイルし直しになりますけど。
> バイナリ互換についてはすでに承知済みです。
これを軽く捉えていそうで、本当に理解してるとは思えないんですよね。
ものすごく小規模な開発しか経験した事ないのでは？
0
個人で作っているものなら問題ないと思いますよ。
会社とか売り物ならその会社のルールとかバイナリ互換とか名前付け規則とかに引っかかってきます。
投稿2020/07/22 16:32
総合スコア5275
ご回答ありがとうございます。
社の既存コードに公開プロパティと公開フィールドが混在してまして、自分が編集・追加(大量)する部分をどちらに合わせるか、悩んでおりました(;^_^A
それはその辺のことを統括する責任を負っている人と相談するといいと思います。自分だったら長く使うマジメに作らなければいけないものに public field は使いませんが、単なる動作確認など捨ててしまうコードをさっと書きたいだけの時は public field を使います。
いまから弄る箇所だけプロパティかしてもバイナリ互換性はすでにないと思いますが、一応相談だけして、自分の責任は果たしたと思うことにします(笑)
ありがとうございました。
あなたの回答
tips
プレビュー
