オブジェクト指向の活用方法を教えて下さい

**デフォルトの名無しさん** · 2014/03/25(火) 21:44:07.66

お願いします。言語は問いません。
オブジェクト指向言語じゃなくても
オブジェクト指向の話であれば問題ありません。

**デフォルトの名無しさん** · 2014/04/11(金) 13:07:20.58

なんか面白いんだろうな...
俺には理解できないけど

**デフォルトの名無しさん** · 2014/04/12(土) 12:55:19.47

プログラマはソースのコピペを恐れないでください。誰でも最初は初心者で、
しかも誰もが成長するとは限らないのです。
成長を強いるオブジェクト指向が、万人の解決策になり得ないのは明らかです。
コピペこそが、初心者からベテランまで、万人の解決策となり得るのです。
第一、grepすらできないソースをメンテナンスできるはずありません。

コピペによるプログラミングは、複雑に絡まったバージョン依存問題を解決する
という、潜在的なポテンシャルがあります。

大体、オブジェクト指向を推進する人は、協調性がない人が多く、共同で作業す
るには向いていないのです。冗談のセンスすらありません。

**デフォルトの名無しさん** · 2014/04/12(土) 17:13:54.61

全部反対のことを言っていると見抜けば
>>248が言っていることに納得できるはずｗ

**デフォルトの名無しさん** · 2014/04/12(土) 17:19:09.23

なんか面白いんだろうな...
俺には理解できないけど

**デフォルトの名無しさん** · 2014/04/13(日) 10:45:23.58

ここで僕らは「良いソフト部品は、有名なのだけだ」という原則に立ち戻る必要があるだろうね。
誰も使ってない、メンテナンスもされない俺様オブジェクト部品を使うくらいなら、コピペの方がましな
んだよ。宣言型か関数型が使えるならその方がいいし、使えなければテストの自動化で乗り切る
しかないと、もう１０年も前からいわれて続けているわけだ。
research.microsoft.com/en-us/um/people/blampson/70-SoftwareComponents/70-SoftwareComponents.htm

**デフォルトの名無しさん** · 2014/04/13(日) 10:51:49.05

うん、まったくだ。
有名なソフトは良い。

有名じゃなくても良いソフトはまれにあるけど、
多くの、つまり何万、何十万とある無名なソフトはクソでしかない。

**デフォルトの名無しさん** · 2014/04/13(日) 11:22:22.91

ストラウストラップが「オブジェクト指向というのは継承と再利用なんだよ！」ってやったせいで
えらい風評被害やな。

単にクラスというCでの関数に代わる単位の取り回し方法だから
Objective-C辺りじゃ継承…めんどいから使わない
NSObjectってクラスの基本的ふるまいを持った基底クラスから
テキトーなクラス作って、その中に使えるクラスぶち込んで
メッセージ(メソッド)オーバーライドでふるまい変えて使う。
クラスとは単にレゴブロックみたいなパーツ扱い。

**デフォルトの名無しさん** · 2014/04/13(日) 11:38:57.62

＞NSObjectってクラスの基本的ふるまいを持った基底クラスからテキトーなクラス作って
継承してるじゃないの。

むしろC++の方が継承なしのパーツ扱いが多いんじゃないの。

**デフォルトの名無しさん** · 2014/04/13(日) 11:54:36.21

いわゆるObjectクラスが必要な理由って何かあるの？

**デフォルトの名無しさん** · 2014/04/13(日) 12:17:57.96

Objective-Cはとにかくクラスの実体ありきで
言語的にひな型からインスタンスを作るんじゃなくて
起動時に存在するファクトリクラスにallocとinitを送って
クラスに"自分のインスタンスを作らせる"から
すべてのクラスはallocやinit、retainカウント、deallocを受け付け管理する
NSObjectを継承していないとクラスとして存在しえないので…

**デフォルトの名無しさん** · 2014/04/13(日) 15:02:09.06

動的な言語だとだいたいObjectクラスが必須だよね

**デフォルトの名無しさん** · 2014/04/13(日) 15:38:34.94

>>256
別にObjectじゃなくても言語仕様でやればいいじゃんと思うんだけどそれじゃマズイことってあるのかな

**デフォルトの名無しさん** · 2014/04/13(日) 15:55:24.32

動的な言語でも本来はObjectなんて要らない。
Smalltalk-80だってnilのサブクラスを作れたし。

**デフォルトの名無しさん** · 2014/04/13(日) 16:04:45.61

値の型が動的なのと
変数の型が動的なのとを
区別つけろよ。アホ。

Objectが必要なのは変数に型があって
値の型が動的な場合なだけだ。
変数に型があるが、そこで記述された型だけではなく
互換性がある型を入れられる。
そういう言語でどんな型にも互換性があるのがObject型だ。

変数に型がない言語ではどんな値でも入れられるから
Objectは要らない。変数にはどんな型でも入れられる
とはいうものもコードは互換性がある型を入れてないと
結局正しく動かないんだけどなｗ

**デフォルトの名無しさん** · 2014/04/13(日) 16:17:49.14

値の型が動的ってどういう事？
さっきまでStringだったけど今みたらIntに変わってたわ！みたいな？

**デフォルトの名無しさん** · 2014/04/13(日) 16:24:02.51

変数の型は固定なんだよ。
この変数は、Numeric型みたいに。

でもNumeric型って書いてあっても
その値は実はInt型だったりFloat型だったりと
Numeric型に互換性がある型に変わっていたりする。

変数の型は固定なのに値の型は違う。

それに対して、変数に型が決まってない言語があるの。
変数に型が書いてないなら変数aにどんな型でも入れられる。

**デフォルトの名無しさん** · 2014/04/13(日) 16:26:13.02

Objectって全部に共通の動作を定義するために使われてるよね普通は。
例えば、自分の型を返すとか。

**デフォルトの名無しさん** · 2014/04/13(日) 17:45:48.17

値が型情報持ってない言語は一応あるね、C言語とか
あれは変数側にしか型がない

**デフォルトの名無しさん** · 2014/04/13(日) 18:03:36.88

>>261
SmalltalkではさっきまでByteStringだったオブジェクトが今みたらWideStringだったぜとか普通

**デフォルトの名無しさん** · 2014/04/13(日) 18:07:49.11

>>263
それがルート(基底)クラスだな。
Objective-Cで言えばNSObjectで、全てのクラスのルート。

**デフォルトの名無しさん** · 2014/04/13(日) 18:54:15.96

全部に共通の動作なんてものが必要なうちはダメだな

**デフォルトの名無しさん** · 2014/04/13(日) 19:10:20.98

>>267
ダメな理由書いてみ

**デフォルトの名無しさん** · 2014/04/13(日) 19:31:38.05

>>265
それは参照してるオブジェクトが変わったんじゃないの？

**デフォルトの名無しさん** · 2014/04/13(日) 20:05:02.79

共通の動作がなければ、てんでばらばらって事じゃんw

**デフォルトの名無しさん** · 2014/04/13(日) 20:31:47.78

>>269
Smalltalkではbecome:というメソッドで
ポインタレベルでのオブジェクトの差し替えが可能なんで

| x y |
x := y := 'abc'
x become: 3.14.
y. "=> 3.14 "

これを応用してオブジェクトの型の変更も容易なんですよ

**デフォルトの名無しさん** · 2014/04/13(日) 20:36:46.47

>>259
よく知らないんですけどSmalltalkのnilとObjectって
お互い継承関係にあるんじゃないんですか？

**デフォルトの名無しさん** · 2014/04/13(日) 20:46:56.28

>>271
SmallTalk知らないんだけど、それってxというオブジェクトにbecome:という動作をさせてるの?
そうなら、become:という動作は全オブジェクトに共通だよね。

**デフォルトの名無しさん** · 2014/04/13(日) 20:50:21.03

>>271
Smalltalkよくしらないから適当言語だけど...
x = "x"; y = "y"; z = y;
の状態で
y become: x;
とやったら、
zの指してるオブジェクトは"x"になるって事？

**デフォルトの名無しさん** · 2014/04/13(日) 20:59:39.25

>>268
つ proxyパターン

>>272
nilはクラスではないところがポイント。

>>273
全オブジェクトに共通ではない。

>>274
なる。xが"x"のままの流派と"y"になる流派とがある。

**デフォルトの名無しさん** · 2014/04/13(日) 21:09:17.21

よく知らない三連星ワロタ

>>275
なるほどそういう意図ですか
1. nillはUndefinedObjectのインスタンス
2. UndefinedObjectはObjectの継承している
3. Objectはnilを継承している
こうかな？
となると全てのクラスの共通となる祖先が存在してるんで
不要論として出すのはやっぱおかしくないですか？

**デフォルトの名無しさん** · 2014/04/13(日) 21:15:34.64

知れば知る程Smalltalkのウンコさが身にしみる

**デフォルトの名無しさん** · 2014/04/13(日) 21:40:50.80

proxyパターンと共通の動作にどういう関係があるのかわからん。

**デフォルトの名無しさん** · 2014/04/14(月) 01:52:57.81

>>258
＞別にObjectじゃなくても言語仕様でやればいいじゃんと思うんだけどそれじゃマズイことってあるのかな
いま、C++とかがそこに起因する泥沼に嵌ってるけど
オブジェクトクラスの側は言ってしまえば実装だしライブラリだから
将来に動作を変更されるうるし、実際に変更されるけど
言語仕様はもう一段上のルールだから変更が実に困難だという…

**デフォルトの名無しさん** · 2014/04/14(月) 01:57:18.83

>>259
要らないつうか、それだと基本的なオブジェクトとしてのふるまいを持ってないから
Objective-Cで生のC関数書いたりObjective-C++でC++のクラス扱ってる状態なだけじゃ…

**デフォルトの名無しさん** · 2014/04/14(月) 19:01:11.23

>>276
nilはクラスではないから共通の祖先となるクラスではないよ。
というか基底クラスが複数あるのはそんなに珍しいことではないが、
一体何がわからないのかわからない。

**デフォルトの名無しさん** · 2014/04/14(月) 20:50:15.58

>>281
nilを継承できる事と所謂Object型が不要になる事の繋がりが分からないんですよね
nillオブジェクトとObjectクラスは親子関係にあるのになんでだろう
って思って質問したんです

**デフォルトの名無しさん** · 2014/04/14(月) 21:32:49.46

> 3. Objectはnilを継承している
それが真であれば、Objectはnilの特徴を持っていないといけない。
Objectはnilではないので、これは間違い。

**デフォルトの名無しさん** · 2014/04/14(月) 21:40:20.78

>>280
要らないんじゃなくて、あった方がやり易いってことだよな。
別にObjective-CでもNSObject無視してクラス自作できるけど、まずそんな事しない。

**デフォルトの名無しさん** · 2014/04/14(月) 21:41:56.76

Rubyだと
・nil は Nilクラスの唯一のインスタンス
・NilクラスはObjectクラスから派生したサブクラス

$ irb2.0
irb(main):001:0> nil.class
=> NilClass
irb(main):002:0> NilClass.superclass
=> Object

Smalltalkは知らん

**デフォルトの名無しさん** · 2014/04/14(月) 22:20:14.96

>>283
あ、そうなんですか
Wikipediaに
> 基本的な派生元となるObjectやProtoObjectは、それらから派生したUndefinedObjectのインスタンスオブジェクトであるnilを継承しており再帰関係を持つ。
と書いてあったんでそういうものだと思ってました
あと
Object isKindOf: nill
が true を返すのはなんででしょう？

**デフォルトの名無しさん** · 2014/04/15(火) 04:06:44.72

>>285
つまりnilとNilは別々のオブジェクトであり、
NilがObjectのサブクラスであることとnilは何の関係もない、
ということだね。

>>286
つまりnilとUndefinedObjectは別々のオブジェクトであり、
UndefinedObjectがObjectのサブクラスであることとnilは何の関係もないし、
nilはクラスではないし
Squeak4.4ではObject isKindOf: nilはfalseだし、
Object new isKindOf: nilもfalseだし、
仮にtrueになる処理系があっても、nilはクラスではないからnilはObjectの基底クラスではない、
ということだね。

**デフォルトの名無しさん** · 2014/04/15(火) 18:46:18.65

>>287
ありしゃす、Object isKindOf: nil の結果は実装依存なんですね
true になるのはGNU Smalltalkでした

**デフォルトの名無しさん** · 2014/04/15(火) 20:46:27.61

>>287
>つまりnilとNilは別々のオブジェクトであり、

nil はインスタンスでありNil はクラスだから、別々のオブジェクトってこと

>NilがObjectのサブクラスであることとnilは何の関係もない、

Nil と Object とは「サブクラス-スーパークラス」という継承関係であり、
Nil と nil とは「クラス-インスタンス」というインスタンス化関係であり、
二種類の関係をごっちゃにしてはいけない、ってこと

**デフォルトの名無しさん** · 2014/04/15(火) 21:07:45.24

>>286
>> 基本的な派生元となるObjectやProtoObjectは、
>>それらから派生したUndefinedObjectのインスタンスオブジェクトである
>>nilを継承しており再帰関係を持つ。

Rubyの場合
・ClassクラスのスーパークラスはModuleクラスである（継承関係）
・ModuleクラスのスーパークラスはObjectクラスである（継承関係）
・ObjectクラスはClassクラスをインスタンス化したオブジェクトである（インスタンス化関係）

$ irb2.0
irb(main):001:0> Class.superclass
=> Module
irb(main):002:0> Module.superclass
=> Object
irb(main):003:0> Object.kind_of?(Class)
=> true

結果として、各クラス間の関係は「循環的」に定義されることになる
ただしRubyコミュニティでは、それを(その循環関係)を「再帰的」と呼ぶ事はない

Smalltalkは知らんけど、おそらく、そのWikipediaの著者が
継承とインスタンス化をごっちゃに理解しているんじゃないかと思われ

**デフォルトの名無しさん** · 2014/04/15(火) 21:25:46.27

>>288
GNU Smalltalk は名前から受ける印象と違って
単なるファンお手製の勝手実装なうえに、
Smalltalk としてもかなりの変わり種なので
あれを元に Smalltalk がどういうものか学ぶのはちょっと問題が。
できれば VisualWorks 、悪くても Squeak/Pharo で
試すようにするのがよいと思います。
（これらの処理系はそれぞれ独自の進化を遂げてはいますが、
いちおう古典的 XEROX Smalltalk-80 からの直系の派生物で、
その名残を多く残しています）

**デフォルトの名無しさん** · 2014/04/15(火) 22:39:29.15

>>290
https://www.ogis-ri.co.jp/otc/hiroba/technical/Squeak4/S4-5-4_1.html
http://pharo.gforge.inria.fr/PBE1/PBE1ch14.html
を読んでみましたが

1. ObjectクラスはObject class(メタクラス)のインスタンス
2. Object class(メタクラス)はClassクラスを継承している
3. ClassクラスはClassDescriptionクラスを継承している
4. ClassDescriptionクラスはBehaviorクラスを継承している
5. BehaviorクラスはObjectクラスを継承している

って事で、Wikipediaの言う再帰関係は成り立ちますね
nilの存在は謎のままですが
間違ってたら教えて下さい

>>291
情報ありしゃす！
勉強はGNU以外でやります

**デフォルトの名無しさん** · 2014/04/15(火) 22:48:36.35

大量のベクトル演算をオブジェクト指向で行うのはいい考えではありませんでした。
パフォーマンスが話になりません。

あらためてオブジェクト指向の活用方法が知りたいです。

**デフォルトの名無しさん** · 2014/04/15(火) 22:56:10.29

あたりまえやないかw　インラインでやれ。

**デフォルトの名無しさん** · 2014/04/16(水) 05:01:31.46

>>292
それはmeta cyclicというのであってrecursionとは全く別だよ

**デフォルトの名無しさん** · 2014/04/16(水) 08:21:50.02

>>295
http://upload.wikimedia.org/wikipedia/commons/f/f9/Smalltalk_80_metaclasses.svg
を拝借するとrecursionはどの部分になりますか？(または当て嵌まらない、とか)
MetaclassとMetaclass classがrecursion？
と言うかmeta cyclicとrecursionは定義はどこを調べればいいんでしょうか
あー分かんなくなってきた

**デフォルトの名無しさん** · 2014/04/16(水) 17:33:35.89

>>296
まず、
全てのクラスの基底となるクラスが存在するかどうかという>>255の話は継承関係の話で、
クラス-インスタンス関係で構成されるメタタワーの話である>>296の話とは
全く別々の話だということはOK？

**デフォルトの名無しさん** · 2014/04/16(水) 18:10:12.53

>>297
はいそれは分かってるつもりです
自分が疑問に思ったのは>>259なんで、
nilを継承できる事とObjectが不要である事の関連性を
説明して貰えるとありがたいんですが…

**デフォルトの名無しさん** · 2014/04/17(木) 03:03:07.59

isKindOf:等のクラス階層へのアクセスを使わない限りにおいて、
全てのクラスは基底クラスから継承したインスタンス変数やメソッド等を取り込むことで
nilからの継承による実装に置き換えることが出来るのはOK？

**デフォルトの名無しさん** · 2014/04/17(木) 06:51:39.99

>>299
はい、続けて下さい

**デフォルトの名無しさん** · 2014/04/17(木) 07:01:46.34

>>297と>>299を前提とすれば、
全てのクラスの基底クラスとしてのObjectは不必要であることは自明だというのはOK？

**デフォルトの名無しさん** · 2014/04/17(木) 07:48:37.17

>>301
いいえ、その飛躍が判りません
nilにObjectクラスと同じ能力があるからObjectクラスは不要だという事ですか？

**デフォルトの名無しさん** · 2014/04/17(木) 09:46:27.34

>>302
いいえ、nilにObjectと同じ能力があるなんて誰か言ってるのですか？

**デフォルトの名無しさん** · 2014/04/17(木) 19:48:33.36

>>303
じゃあ>>299の解釈が間違ってますね
うーん、Objectの代わりにnilから派生できるよ、としか汲み取れません
でもそれだとクラス階層のルートの必要性とは無関係の話だから違うんだろうな

自明の部分を取り違えないように省略せず説明して頂けませんか？

**デフォルトの名無しさん** · 2014/04/18(金) 02:02:31.47

今更な反応だけど
メソッドチェーンのデバッグどうのこうのは
パワーアサートである程度解決できるんじゃね

テストとデバッグを同一視すんなとか言われそうだけど
そこはなんやかんやで

**デフォルトの名無しさん** · 2014/04/19(土) 11:19:09.69

みんなモデリングツール使ってる？

**デフォルトの名無しさん** · 2014/04/19(土) 15:25:11.54

UMLは手書きのノートに万年筆で描いてるけど？

**デフォルトの名無しさん** · 2014/04/19(土) 15:25:52.03

ああ、もうすぐ司法試験なんだよなぁ・・・
今年も申し込みしてねーや。
仕事辞めたいわ

**デフォルトの名無しさん** · 2014/04/19(土) 15:28:51.08

ぜひ弁護士資格を取って人売り屋を訴えてやってください。

**デフォルトの名無しさん** · 2014/04/19(土) 15:32:20.57

弁護士より裁判官志望なんだけどな。
知財専門の裁判官やるわ。

**デフォルトの名無しさん** · 2014/05/02(金) 02:53:15.17

裁判官になるのはある意味、終身刑になるようなもの
仕事にやりがいはないし、趣味、嗜好、信仰の類は一切行えない
どうしてもやりたいというなら止めないが、いいもんじゃないぞ

**デフォルトの名無しさん** · 2014/07/11(金) 14:24:19.29

確かに日本語ネイティブじゃないと解り難い表現ではある

**デフォルトの名無しさん** · 2014/10/15(水) 02:03:28.04

急にスレが死んだ

**デフォルトの名無しさん** · 2014/10/16(木) 17:21:37.89

>>217
>ライナスは OO をぼろくそにけなしているね

Linusが批判したのはOOPじゃなくてC++だろ（Cとの比較で）。

**デフォルトの名無しさん** · 2014/10/18(土) 12:18:53.66

似たようなものさ‥Linus が GC の存在を受け入れるわけがない

**デフォルトの名無しさん** · 2014/10/18(土) 15:46:58.25

そりゃ、カーネルやドライバレベルの開発でGC付きの言語環境は要らんわ。
OOPの話題でリーナス発言を引き合いに出すのは的外れすぎる。

**デフォルトの名無しさん** · 2014/11/05(水) 13:15:41.31

OOPって結局、こういう考え方すれば分かりやすくなりますよって例でしかないからな
その考え方を前提に置けば、こういう表現ができますよって利点はいろいろな実装があるけど

完全性や効率性を犠牲に、可読性を上げて保守性や再利用性、試験性なんかを上げましょうってそういうものだと思うんだけど

**デフォルトの名無しさん** · 2014/11/05(水) 20:29:01.97

OOPって結局、…でしかないからな

という奴って、OOP以外にも関数型言語でもアジャイルプロセスでも受託ビジネスでも
みーんな「結局、…でしかないからな」とわかったような気になるだけで
実際には何も身についてないんだよなw

**デフォルトの名無しさん** · 2014/11/05(水) 23:26:57.45

**デフォルトの名無しさん** · 2014/11/06(木) 08:17:55.90

>>31
「結局、ただの方法論でしかないからな」

方法を知っているかとそれをビジネスで生かせるかは全く別のスキルだしなー

**デフォルトの名無しさん** · 2014/12/15(月) 00:00:56.39

カプセル化ポリモーフィズム継承を理解して設計出来る人って実際、何人に一人ぐらいに感じる？

**デフォルトの名無しさん** · 2014/12/15(月) 09:52:17.25

ひとそれぞれ解釈違うからなんとも言えん

**デフォルトの名無しさん** · 2014/12/15(月) 11:05:06.23

ｶﾌﾟｾﾙ化＆オブジェクト化の行き先は関数型プログラミングじゃないの？

**デフォルトの名無しさん** · 2014/12/15(月) 12:54:30.82

絶対違う

**デフォルトの名無しさん** · 2014/12/15(月) 15:09:37.42

>>323
北極と南極の違いだろ。
OOPの落伍者のパラダイスが関数型なんだから。

**デフォルトの名無しさん** · 2014/12/17(水) 11:09:29.57

ポリモーフィズムは分かりやすいんだけどカプセル化がいまいちわからない
ゲッターセッター書いて何になるの？ってレベルの理解しかないから優しく教えて

**デフォルトの名無しさん** · 2014/12/17(水) 11:58:16.14

>>326
カプセル化はむしろ単純セッター書いたら負け
そのクラスの機能のみ提供して、内部実装を隠すのが要点

**デフォルトの名無しさん** · 2014/12/17(水) 13:49:16.52

カプセル内では、他のオブジェクトの定義を知らなくても済むように書く。
閉じたオブジェクトにすればいい。

**デフォルトの名無しさん** · 2014/12/17(水) 17:36:45.21

>>326
基本的にそのクラスのメンバーはそのクラス内でいじられることを保障するため。

**デフォルトの名無しさん** · 2014/12/17(水) 18:56:34.51

実装を隠す
→知らなくても使えるように設計する
→使い方さえ変えなければいい
→中は変え放題、新しい使い方も追加放題

>>329
よくあるサンプルみたいに全メンバアクセッサ実装してるようなクソクラスだと
その原則破るための効果の方が強くなってしまうからなぁ

クラスの中から≠クラスファイルの中から
クラスの中から＝クラス機能の中から

**デフォルトの名無しさん** · 2014/12/17(水) 19:24:20.07

327-330
いろいろありがとう
公開したいとこだけ公開すりゃいいのね

**デフォルトの名無しさん** · 2014/12/17(水) 19:38:57.10

極論を言えば「公開」したら負けなのがカプセル化

**デフォルトの名無しさん** · 2014/12/17(水) 21:14:17.50

>>326
getter-setter をかましておけば、なにかのときに簡単に監視やフックを追加できる

**デフォルトの名無しさん** · 2014/12/17(水) 22:00:02.25

>>333
ちょっとした用途ならリフレクションから呼べば良いじゃん
機能として提供する必要が出来たならそんな直接参照するような裏ワザ使わないで継承するなり追加するなりしようよ

影響が外に広がらないようにカプセル化して直接参照する手段を封じるんだから
直接参照できるセッターやゲッターつけたら保証できなくなるじゃん

**デフォルトの名無しさん** · 2014/12/17(水) 22:40:02.99

>>334
リフレクションは悪、コンパイル時に検出できるエラーがリフレクションにすると検出できなくなってしまう‥
まあ何でもかんでもsetter-getter で公開してしまうのはどうかと思うが（ましてやプロパティを公開してしまうのは最悪）

**デフォルトの名無しさん** · 2014/12/18(木) 15:10:59.93

おいおいインスタンスにアクセサなかったら、
そいつの状態を変えたりモニターしたりどうやるんだよ。

**デフォルトの名無しさん** · 2014/12/18(木) 15:18:48.22

>>336
状態をモニタするのは「モニタする」メソッドでやるべきじゃね？
状態を変えるなら、状態を変えるメソッドを通すべきだと思うし

もちろん、カプセル化の観点から見たら、の話ね
何か目的があってカプセル化を崩すなら、それはそれだろうし

**デフォルトの名無しさん** · 2014/12/18(木) 15:31:32.87

いやそのためのメソッドがsetter/getterだろうと。

**デフォルトの名無しさん** · 2014/12/18(木) 16:01:52.60

>>335
> ましてやプロパティを公開してしまうのは最悪
.NETのクラスは山ほどプロパティを公開してるけど、これも最悪なの？

**デフォルトの名無しさん** · 2014/12/18(木) 22:10:35.29

>>339
>>335 はプロパティをフィールドと混同している気がする。
フィールドを公開するのが最悪、なら納得できるもん。

>>338
setter/getterはあくまで、結果としてそうなるだけのものだよ。

あくまで例えばの話だけど setLeft(), setRight(), setWidth() という3つのsetterがあったとして、
内部データは「left,right」でもいいし「left,width」でも「center,width」でも
「center,half_width」でもいい、もっと言えば「width,right」でも構わない。
まあよほど処理上の都合がないかぎり最後のを選ぶ人は少数だと思うけど、
どれが単純なsetter/getterになるのか、どれが違うのかは外からは分からない。
そして、それは分からなくていいものだと思うよ。

状態が最初にあって、それを見たり弄ろうと思うとsetter/getterになっちゃうけど
まずそのオブジェクトで何をしたいのかを考えて、それを実現するための内部構造と考えると
自然とカプセル化されてくもんじゃないかな。

**デフォルトの名無しさん** · 2014/12/18(木) 22:32:07.68

>>340
いやだからアクセサでオブジェクトの状態を変える・モニターするのは別に普通だろと言ってるの。

**デフォルトの名無しさん** · 2014/12/18(木) 22:55:00.66

Entityにgetsetつけてるのって何も考えてないとしか思えない

**デフォルトの名無しさん** · 2014/12/18(木) 23:22:15.68

状態変更やモニタするメソッドの名前をgetやsetにするのは自由だけど・・・命名規則的にそれってどうなの？
それに当然モニタリング機能を提供すべき責任を負ってるクラスだけだからな

状態を変更するメソッドならバリデーションや整合性チェック、状態変化に伴う動作まで含めて一つの完結した機能として定義すべきかな
状態変化監視するならオブザーバパターンで、JavaならpropeatyChangeListenerとか
実装して受け取るべきだと思う
もしくは監視用ステータスオブジェクトを返す感じとかか？

**デフォルトの名無しさん** · 2014/12/18(木) 23:28:53.90

ああ、俺が言ってるのは単純にプロパティの事だよ。

**デフォルトの名無しさん** · 2014/12/19(金) 00:08:44.41

こういう説明はどうだろう？
NG:状態変数を取得するために状態変数取得メソッドを作った
OK:状態取得メソッドを作ったので保管場所として状態変数を作った

少なくとも設計段階でデザインするべき物かな
そうやってデザインの結果として一部にクラスに、
結果的に単純プロパティのような形の実装になった物が出来るの悪いことではないと思う

**デフォルトの名無しさん** · 2014/12/19(金) 00:25:25.61

始めからプロパティとして定義するものもあれば、
プライベート変数を後からプロパティに変更する事もあれば、
プロパティだったものをプライベート変数に変更する事もあるよ。