또한 저한테 아주 중요한 사고를 깨우쳐준 개념 또한 있는데,
10챕터에 가면 Mix-In 이라는 개념을 소개하면서
C# 8.0 부터 도입된 Interface에 대한 기본 구현에 대한 내용입니다.
밑 부분은 원래 10, 11 챕터에 가면 해야 할 내용이지만 업데이트 하다가 또 생각이 안 날수도 있고 구현에 대한 이슈업에 된 이상 지금 하는 게 맞을 것 같습니다.
저는 이 기능이 업데이트 되었을 떄 전통 OOP 개념을 해친다고 생각했습니다.
Interface는 메시지이고, 책임을 나타내는데 책임에 대한 기본구현이 생기므로써 책임이 책임이 아니게 되었다고 생각하면서 믹스인 개념을 싫어했고, 호불호에 관련된 내용이라고 생각했습니다.
이 기능이 처음 추가된 것은 Java의 기본구현이라고 생각했으며 이 Interface의 기본 구현이 등장하게 된 이유 중 찾을 수 있었던 것은
Interface에 대해 다중 Layer로 추상화를 해놨더니, 유지보수를 할 때 같은 Interface 를 구현하는 클래스들 끼리 공통 구현에 대한 소스코드 가 중복되는 것이 많아졌다. 전통 인터페이스 개념을 살려서 이런 경우 중복 소스코드 방지를 없에기 위해 클래스를 사용해서 중복소스코드를 줄였더니, OOP는 상속계층이 단일 방향이기에 다중상속이 안되어서 Layer를 오히려 복잡하게 만들었다. 이 경우 Interface에 기본 구현을 사용했더니 이런 부분들이 해결되었다. 다만, 이 경우 Interface에 대한 다이아몬드 상속 이 될 수 있어서 호불호가 발생할 수 있다.
위 글은 제가 언젠가 인터페이스 기본구현에 대해 찾아보면서 읽었던 글을 기억을 되살려서 적었습니다. 그때는 믹스인 이라는 개념을 모를 때 였고, 위 글을 봐쓸 때 공감했고 저는 호불호 중 불호였습니다.
이유는 다이아몬드 상속이 OOP를 해친다고 생각했기 때문이고 다이아몬드 상속은 C++ 때부터 이슈업되었던 것이고 그로 인해 C++는 다중상속이 가능한 만큼, 단일 상속구조로 가져가기 위해 클래스 지향 설계 라는 용어가 따로 언급이 되었을 정도로 C++를 OOP 적으로 사용하려고 했던 시도와 운동이 있던 것으로 알고 있습니다.
하지만 오브젝트 10챕터의 믹스인 개념은 이것을 깨줬고, 저자는 스칼라(Scala)의 Trait 개념을 소개하면서 믹스인을 언급하고 있었습니다.
이 스칼라의 Trait는 Trait에 기본 구현을 정의하여 여러 개의 Trait을 하나의 클래스에 Plug-in 처럼 붙혀서 Class 기능을 확장할 수 있는 개념이었습니다.
여기까지만 보면 스칼라 Trait은 정말 훌륭한 개념이었고 C#에는 이런 개념이 없나? 하고 찾아봤는데 함께 10챕터 독서회를 진행해주셨던 @eundini93 님께서 위 MSDN의 C# 믹스인을 찾아주셨습니다.
여기까지 보고나니 갑자기 없었던 벽이 생성되면서 “아 뭐야, Trait이 결국 기본구현 Interface였어?” 하면서 모르고 볼 때는 아름답게 보이다가 실체를 알고 보니 추하게 보였습니다. 없던 선입견이 불러와서 생긴 것이지요.
하지만 좀 더 생각을 해보니까 Class가 아니라 Interface로서 기본 구현을 가졌기 때문에 시사하는 바가 다른 것처럼 느껴졌습니다.
-
첫번째로 우선은 저는 OOP를 쓰는 이유가 첫째도 둘째도 셋째도 N째도 유지보수 때문에 사용하는 것인데 믹스인을 사용하면 유지보수가 더욱 뛰어나질텐데 내가 생각하는 OOP와 달라졌다고 무작정 싫어할 이유도 없었다는 것을 깨달았습니다.
제가 어디가서 패턴을 위한 패턴을 하지 말고 유지보수를 위한 적절한 트레이드 오프를 섞으라고 말하고 다니면서도 스스로 OOP를 위한 OOP를 하려고 했다는 사실을 깨달았습니다. -
두번째로 그것이 class가 아니라 Interface라서 용납이 되었습니다. 저자는 끊임없이 Interface는 메시지이고 책임이며 상속이 아니라 구현이라고 말하고 있습니다. OOP의 원형 자바에서도 extends가 아니라 implements이라고 하는 것처럼요. 즉 믹스인이라고, 기본 구현이 있다고 해서 그것이 상속이 되는 것은 아니라는 것을 깨달았습니다. 인터페이스에 기본 구현이 추가되었다고 해도, 인터페이스는 여전히 메시지이고, 책임이었습니다.
구현에 초점을 맞추는 것이 아니라 우리가 공부하는 OOP가 추상적인 개념을 공부하듯 그 본래 의미를 안다면 구현은 더 이상 중요해지지 않다는 것을 깨달았습니다.
11챕터에 쓸 독후감을 미리 쓴 듯 한데, 더 추가할 수도 있겠지만 이것으로 개인 독후감은 링크로 끝낼거같네요…ㅎ