자식클래스가 부모클래스 대체해도 문제없이 돌아가야 상속가능함

[익명(221.155)]

포함관계를 따지는게 아니라서

타원부모 원자식 클래스하면

e = r; 같은거하면 문제생김

소프트웨어공학 수업같은거 들으면

solid원칙에서 배우잖아

Liskov substitution principle라고

[익명(1.228)]

그럼 원이 부모가 되면?

[익명(221.155)]

원이 부모가 되면 무슨이득이 있는데? 다형성활용은 둘째치고 메소드도 다 따로짜야되는데?

[익명(39.7)]

그건 실제 구현의 문젠데 왜 문제가 생김

[익명(221.155)]

구현에서 문제가 생기니깐 원칙만들어놓은거지

[익명(39.7)]

만약 타원이 부모 원이 자식이라고 정했다면 저 법칙에 맞도록 구현하는게 과제인거지

[익명(39.7)]

구현의 난이도가 문제가 아니라 저 법칙은 뭐가 부모가 되야하냐의 근거가 안된다는 거임

[익명(175.119)]

그부분은 문제 없지 않을까 타원의 특수화된 종류가 원 아님? 초점 위치만 바뀌잖아

[17번(wjd918273)]

타원은 초점 두개와 거리로 정의되는데 원에 적용할경우 초점이 동일점이고 거리는 1/2하면 되지않나? - dc App

[17번(wjd918273)]

타원에 적용되는 모든 법칙들중 하나라도 원에 적용 안되는게 있나? 흠... - dc App

[익명(1.228)]

장반경 단반경 관련 메소드를 없애야 해서 그런듯

[17번(wjd918273)]

그냥 부모자식관계가 아니라 공통부모가 있는게 나을거같다 - dc App

[익명(211.109)]

안 없애도 됨 원도 타원의 특수한 형태라 둘다 가짐 값이 같을 뿐

[익명(175.119)]

장반경 = 단반경 = 반지름 없앨 필요는 없음

[17번(wjd918273)]

근데 낭비가 좀 있을듯 - dc App

[익명(211.109)]

이게 실제 사용할 때가 아니라 OOP 원리 따져보느라 그렇고 실제에서는 별개로 구현하는게 이득일 때가 많을 듯 둘다 그냥 Drawable의 구현으로 한다든지 Shape의 자식으로 한다든지

[17번(wjd918273)]

상충되는 이론 및 지향점들이 있기때문에 결국 상황에 따라 그걸 잘 조율하는게 중요할거같다는 결론을 얻었다 - dc App

[익명(39.7)]

이 쉑 타원의 정의를 모르는 듯