コーディング規約 第3条

>>946
ビジネスロジックの「心底ウザい条件チェック」と「心底ウザい条件変更の多発」を経験してると、何だってsetter/getter経由にしたくなる

いまさら噛み付いてる奴も結構どっか問題ある連中なんだなと思う。

完全に話が終わって次の話題に移りかけてる所で蒸し返す奴も以下無限ループ

結局スレチな話題で半分埋まっちまったなぁ

何ヶ月もレスが無かったスレが言える台詞じゃないわな

と思ったが3年の歴史のあるスレがこの終り方はちょっと可哀想だわｗｗｗ

ごめんなさいw

このスレ2007年からなのか・・・
インデントはタブかスペースかなんてなんか長閑な話題でスタートしてたんだな。

終わりよければ全て良し。

>>951
無駄なたらい回し、ってことじゃないの？本人じゃないから真意はわからんけど。

これだからオブジェクト指向って役に立たないよな。

馬鹿の助けにはならないよね

>>951
コードが読みづらくなる。
つか、お前全部アクセッサ経由にしてるのか？

プロパティと言うステッキーな機構があるからぜんぜん読み辛くならんし

どちらも想定している言語の明示と、>934からの流れの確認をしないと
齟齬が生じると思うのだけど。

個人的にはプロパティのある言語（LLやC#）ならともかく、
C++やJava（6.x系まで）では微妙な気がする。

C++ならお得意のマクロでも使えば

プロパティなら30秒もあればアクセッサ経由に書換え可能だから、どうでもいい問題だな

コーディングの話ではなく設計の話だが、
設計から導かれる setter/getter は 良い setter/getter。
実装から導かれる setter/getter は 悪い setter/getter。

ちょっと意味が分からん

悪い、C++での話ね。

俺的にはいいも悪いも評価保留中だけど、それってどうなの的な話題ふり。
この議論は『Smalltalk Best Practice Patterns』が初出らしいんだけど、Smalltalk固有の
何かが関係しているのかどうかは不明。

ただ、俺が読んだ話（何で読んだかは忘れた）では、C++でprivateメンバ変数を
必ずアクセッサ経由で呼ぶという流派があって、その理由の一つは継承先で
getterを遅延評価に変えたりする可能性があるかららしい。

俺としては、そういう流派の人がもしいたら理由を聞きたい的なレベル。

つまり、コーディング規約で、privateメンバ変数にアクセスするときは、必ずアクセッサ経由にすること、
みたいな規約だったらどう思う？的なこと。

どうでもいい

的的うるせーよ

いいんじゃないの？
今時のコンパイラなら空のアクセサを直接アクセスへのコード展開ぐらいしてくれるだろうし。

アクセッサなら良くて>>541なら駄目というのはこれいかに。

アクセッサというからには、少なくともprotectedだろ。そこが>>541とは違う。

>>970
> その理由の一つは継承先で 
> getterを遅延評価に変えたりする可能性があるかららしい。 

サブクラスがスーパークラスの getter に変更を加えるってピンと来ないな
privateメンバの getter でしょ、protectedメンバじゃなくて

> サブクラスがスーパークラスの getter に変更を加えるってピンと来ないな

フツーにオーバーライドでは？

> privateメンバの getter でしょ、protectedメンバじゃなくて

えっ？

>>977
privateのsetter/getterって誰がアクセスするの？

はてしなく、どうでもいい話題。
アホを釣り上げて叩こうって意図？

public メンバ変数は必ず private のバッキングストア作ってアクセサ作れ
そしてクラス内でバッキングストアにアクセスするときもアクセサ使え、
って主張とちゃうの？是非はともかく。

1)
class Person {
public int age; // アクセサなんぞいらんわ
void aging() { age++; }
}

2)
class Person {
private int age;
public int getAge() { return age; }
public void setAge(int age){ this.age = age; }
public aging() { age++; } // private にアクセサ使うとか・・・
}

3)
class Person {
private int age;
public int getAge() { return age; }
public void setAge(int age){ this.age = age; }
public aging() { setAge(getAge() + 1); } // 継承対策っすよ
}

>>981
全てのprivateメンバ変数に対するアクセスもsetter/getterを経由しろってのは、
Personの例でいえばこんな感じ。

class Person {
public:
void setName(const char* name) {
　if (ミドルネームが存在したら) {
　　// isMiddleNameExist = true; こうはせずに
　　setIsMiddleNameExist(true);　// こうしろ
　}
}
protected:
virtual void setIsMiddleNameExist(bool b) {
　isMiddleNameExist = b;
}
private:
bool isMiddleNameExist;
}

>>981の3)に付け加えて、publicで公開しないものも含めてって意味。

継承先で書き換えを期待してるかしてないか、または
クラス内でもフィールドの仕様が安定してないとかで変わるんじゃないの？

virtual 付けてたり、final みたいなオーバーライド禁止付けたりしないんであれば
アクセサ経由じゃないとオーバーライドの内容次第じゃおかしなことになるんじゃない？

お客様が仕様ですの中で暮らしているか
仕様は仕様の中で暮らしているかの違い

ひょっとして、みんなprivateメンバまできっちり設計とかしてんの？

↑しても意味が無いから変更に強いコーディングスタイルにしたいんだろ
それはもう手間の面でしか判断できん

>>984
virtual付けないとオーバーライドできないけど？

前スレ二個も、いったい何を議論してんだろうか。
次スレいるのか？

要らないかな

3年間続いたこのスレに黙祷

終焉記念パピコ

>>988
だから、「virtual 付けてたり」「finalみたいなオーバライド禁止尽けたりしないん」であれば
オーバーライドの内容次第でおかしくなるだろってこと。

virtual付けてなければオーバーライド出来ないんだからおかしくならないのでは？

>>994
だから、「virtual”付けてたり”」「finalみたいなオーバライド禁止尽けたりしないん」であれば
オーバーライドの内容次第でおかしくなるだろってこと。

オーバーライドの内容次第でおかしくなるか？
privateメンバだぞ？

protected、public なアクセサの話だぞ？
>>981>>982 みれ

何ぞこのアホな幕引きは・・・

> アクセサ経由じゃないとオーバーライドの内容次第じゃおかしなことになるんじゃない？

要するに何が言いたいんだろう？
オーバーライドしようがしまいが、アクセッサ経由でしかアクセスできないだろ。

>>997
privateメンバ変数の話だぞ？>>934見ろ馬鹿。

最後は激烈馬鹿で終了。

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。