OOPのInterface型
OOP言語で、classにimplementsする為に明示的に定義する
Interface 型のことを指している他の例はInterface等を参照
Interfaceの使われ方
2種類あると思う
型として利用する
property定義、関数の引数、変数宣言など
implements するInterfaceに、propertyを定義できないのはなぜなのか #??
OOP言語なので、それができてしまうと弊害が起きるから制限されているのだと思うが、その理由がわからない
振る舞い駆動だから？
そもそもこの制限はOOPの共通見解なのか #??
PHPが特殊なだけなのかどうか
例えばKotlinやTSはできる
Javaにはあるっぽいな
ただしfinal
PHPもconstなら定義できる
なんで定数 #??
型縛りでいいじゃん、と思うのだが
propertyはデータの特定の実装を表す
propertyを公開するとカプセル化が壊れる
propertyじゃなくてgetterを使え、という感じになるのか
propertyが定義できない理由、たぶんこれだろう
>実際、真にオブジェクト指向のデザインでは挙動 以外のもの を持つべきではありません。 データはプライベートにしておき、メソッド経由でのみアクセスできるようになっているべきです。ref
OOPが本来振る舞い駆動なので、data(property)を隠蔽するほうが良い、という思想がある
やりとりする相手がどういうデータ構造なのか、を意識してはいけない
こういうことをやりたいときに、どうやるのが正解なのかを知りたい #??
上述の「型として利用する」の方の特に、property定義のもの
Hoge classは IPiyo のような2つのpropertyと1つのmethodを持ったデータ構造であることを明示したいtsclass Hoge {
private piyo: IPiyo;
private defPiyo: IPiyo;
}
interface IPiyo {
id: number;
name: string;
getName(): string;
}このIPiyoを抽象クラスで代替するのは明らかにおかしい
継承できないもん
IPiyoを普通のclassにすればいいのか
OO的にはこれはclassで表すべき、ってことか?
Interfaceはあくまでも振る舞い明示の為に使えってことかな
PHPのtraitでも良いかも知れない
この辺むずかしすぎる
今のの仮説
OOPは振る舞い駆動なので、他classとやり取りするときにpropertyに依存すべきでない
全てはOOPのmessageなので、そこだけでやり取りすべき
もし仮にHoge内で
piyo.name のような情報が必要になるのであれば、propertyに直接アクセスするのではなく、getterを使用すべき故に
IPiyo の内部は name:string ではなく getName(): string のようにすべきpropertyに依存すると、データ構造に依存することになる
functional-orientedなら寧ろこっちの方が自然と捉えている
抽象クラスとの差異
Interfaceの設計レベル
型は仕様
これはかなり大前提のはなしであると思う
その上で利用しやすい、身動きの取れやすいインターフェースを提供することが必要になる