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