[%] 클래스 설계 방법 같은건 어디서 봐야하냐

[익명(180.228)]

예를 들어,

인터페이스가 있고 그걸 구현한 클래스가 여러 개 있는데,

새로 구현할 놈이 인터페이스에 없는 기능을 필요로 해.

사용하려면 인터페이스 통해서 사용해야 하니까 인터페이스에 새로운 함수를 만드는데,

이러면 다른 클래스들은 사용하지 않을 함수를 하나 가지게 되는거잖아

이런건 어떻게 해결 해야 돼?

인터페이스를 새로 또 만드나? 그럼 인터페이스가 너무 많아지는거 아냐?

[익명(223.39)]

디자인 패턴

[익명(223.39)]

컴포지션 + 전략

[fender(mysticfall)]

이건 경우에 따라 다르다. 어쩌면 캐스팅을 하는 게 맞는 경우일 수도, 인터페이스를 쪼개는 것이 나을 수도, 혹은 설계 자체가 꼬여 있을 수 도 있는 문제 같다. 설계 문제는 항상 맥락이 중요하기 때문에, 어느 정도 구체적인 예시를 들어서 이야기하는 게 넛지 않나 싶다.

[익명(180.228)]

음, 머 구체적이랄 것도 없는데. 어떤 장비를 구동하는 프로그램이고, 이 장비에 들어가는 몇 가지 종류의 부품들이 있음. 각 종류마다 공통 동작을 인터페이스로 만들어서 부품이 바뀔 때 바뀌는 부분들을 구현해서 쓰고 있거든. 근데 그 인터페이스에서 엇나가는 애들이 나오는데, 이걸 어떻게 처리할까 하는거지. 빨리 빨리 해서 넘기려고 일단은 걍 인터페이스에 함수 만들고 구현 클래스에도 함수 만들고 사용하는 부분에도 함수 만들고 이러고 있어. 근데 다른 클래스에서는 안 쓸, 얘만을 위한 함수가 많아지는게 문제고, 그럴 때마다 여기저기 함수 만들어야 하는 것도 일이 많고.. 머 후자는 어떤 방법이라도 이것 저것 작성해야 하는 건 어쩔 수 없다면 상관없지만, 인터페이스가 지저분 해지는걸 해결하고 싶은데..

[fender(mysticfall)]

둘 중 하나일 것 같다. 애초에 구현체들이 같은 인터페이스로 묶이면 안될 것들이었던가, 아니면 인터페이스 분리가 필요하거나. 여전히 정확한 사례를 몰라서 막연하긴 한데, 후자의 경우라고 가정하면 특정 구현에 의미없는 동작을 정의하는 것보다는 그 동작을 별도 인터페이스로 분리하고 원 인터페이스를 상속하게 하거나, 아님 구현체 단위에서 둘 다 구현하는 쪽이 낫다고 본다. 그래서 쓰는 쪽에서 타입 체크해서 캐스팅을 하건, 아님 인터페이스로 구현체를 가져오는 팩토리 메서드를 만들건 그런 식으로 처리하는 게 일반적 해법일 것 같다.

[fender(mysticfall)]

케이스에 따라서 조금 다르게 풀 수도 있긴 한데, 예컨대 인터페이스 분리를 전제로, 해당 인터페이스의 구현체를 반환하는 메서드를 본래 인터페이스에 구현하는 것도 방법이다. 그래서 해당 기능을 구현안하면 널이나 옵션:None 같은 걸 반환하거나, NotImplemented 예외를 던지거나 하는 것도 방법이긴 하다. 이 것도 보다 구체적 케이스가 있어야 정확하게 말할 수 있긴 한데, 장점이라면 그냥 인터페이스 분리하는 경우 시그네쳐 상으로 확장 인터페이스가 드러나지 않는 불명확함이 해소된다는 점도 있고, 단점이라면 본래 인터페이스를 오염시키는 거라 비슷한 기능이 필요할 때마다 소스 수준에서 수정이 필요한다던지 그런 문제들이다.

[익명(211.36)]

일단 한 개의 인터페이스로 만든 건, 한 개 칩의 동작이라서 그렇게 한거 같음. 머 만들 땐 이런 동작을 하는 애가 없었겠지. 인터페이스 분리 쪽으로 말해준거 참고해서 좀 더 고민해봐여겠네. 감사감사