왜 OnClickListener가 모든 뷰에서 쓰임에도 불구하고 따로 정의하지 않은채 View의 안쪽에서 정의되어있을까요?
클래스의 상속 구조를 잘 정의하면 따로 빼서 구현하는 인터페이스의 필요성은 상당히 줄어들게 됩니다.
zgundam님께서 말씀하신 내용은 예를들면
MySmile1과 MySmile2가 있는데 둘다 동일한 OnSmileListener가 필요함에도
MySmile1에만 OnSmileListener를 정의하고 사용하는 경우에 해당하는 이야기 입니다.
아니면 불필요하게 둘다 따로, 내용은 똑같은 OnSmileListener를 정의해서 사용하거나....
만약 MySmile에 OnSmileListener를 정의하고
MySmile1과 MySmile2가 MySmile을 상속 받는다면 크게 문제될게 없는 내용입니다.
"만약 interface가 MySmile뿐만 아니라 기타 다른 클래스에서도 사용되어야 할 경우
interface가 MySmile 클래스에 종속적으로 설계되어 있기때문에 interface에 기능을 추가하기 위해
불필요하게 MySmile 클래스를 수정하는 부분이 생기는 거죠."
이부분은 좀 이해가 안되는데요... interface가 따로 나온다고 해서 이부분을 해결할수 있는건가요?
interface에 기능 (결국은 메소드가 될건데...)이 추가되거나 변경되면
이넘과 의존성을 맺고 있는넘은 어떤형태로든 바뀌어야 하지 않나요?
불필요한게 아니고 일단 의존성이 생긴이상 저건 그냥 어쩔수 없는겁니다.
그리고 그 의존성은 "어디에서 정의되었느냐"가 아닌 "객체의 생성/소멸, 사용"에서 나오는 의존성입니다.
의존생이 생긴 이상 어쩔수 없다..식으로 넘어가서는 안되죵^^..저 부분을 풀어야 하는거니까요..
그냥가자..님의 얘기는 현재의 설정에서 생긴 의존성은 어쩔수 없다 하시지만 저 부분은 풀어갈수 있는 부분입니다..
지금이야 현재 정의에서는 저런 의존성을 설정해도 문제가 없지만..요구사항..이란건 계속 끊임없이 변하는 것입니다..
그리고 그것에 대해 관련된 것들 끼리만 변화시키면 그거야 말고 금상 첨화인거죠..
그럼 그걸 해결하는 내용을 알려드리죵..
어떤 용도의 click 이벤트와 관련된 Listener가 있는 interface를 만들고(a.class) 이 인터페이스를 상속받는 넥서스원용 클래스와 갤럭시S용 클래스를 만든다 하죵..(Nexsus.class, Galaxys.class)
그리고 MySmile에서 이걸 사용한다 하면
class MySmile{
private a aval;
public void setAval(a aval){
}
// 여기서부터 사용자 함수들이 기술
// 사용자 함수들은 a 인터페이스에 정의된 함수들(onclick 이벤트) 사용이 가능
}
그리고 이 사용자 함수를 생성할때 다음과 같이 합니다
MySmile smile = new MySmile();
smile.setAval(new Nexus()); // 갤럭시 S라면 new Galaxy()로 하면 되겠죠..
이러면 됩니다..
이걸로 무슨 차이가 있냐..하시겠지만 분명한 차이가 있습니다..
예를 들어 앱을 운영하는 과정에 있어서..
인터페이스 a.class 의 onclick 이벤트에서 갤럭시 S쪽에 변경사항이 있다고 가정을 하죠..
기존 스타일처럼 만약 MySmile에서 Listener 인터페이스를 상속받아서 구현을 했다면..
MySmile 클래스 자체를 수정해야 하는 상황이 발생합니다..
즉 갤럭시 S에서 변경상황이 발생했는데..
그것을 이용하는 부분인 MySmile을 건드리는 상황이 되는거죠..
그리고 그걸 건드리는 과정에서 넥서스원에서도 돌게끔 일종의 분기개념 코드도 넣어야 합니다..
하지만..지금과 같이 갤럭시 S 전용 클래스를 만들고
거기서 수정하게 한다면
넥서스원이나 MySmile 에서는 코드 수정이 일절 없는 거죠
즉 변경관점이 있는 클래스에서만 수정하면 되는겁니다..
불필요하게 변경 관점과는 관련이 없는 부분을 건드릴 필요가 없는거죠..
안드로이드와 하드웨어가 업그레이드될수록..
개발자들의 수정사항은 그만큼 많아지는 법입니다..
구조를 설계할때 서로의 의존성을 최대한 줄여놓으면..
변경 사항이 발생했을때 변경되는 관점에서만 수정을 하면 되는 것이지요..
지금의 상황에서 의존성이 이렇게 맺어졌으니 어쩔수 없다..라는 식의 생각은..
조금만 고민해보면 풀수 있습니다..
그래서 요즘 디자인 패턴쪽을 공부하고 있네요..이런 내용이 디자인 패턴에 있어서..
뭔가 제가 말하려는 논점의 이해가 잘못되었다는 생각이 드는데요...
저는 의존성이 어쩔수 없다가 아니라, 밖으로 빼나 안에 넣으나 의존성은 같다라고 말하고 있는겁니다.
물론 public일 경우이죠...
밖으로 빼도 건담님의 말씀과 같은 문제는 나오게 되어있습니다.
그리고 그건 실제로 애초에 상위 클래스 리스너 정의시 하위에 대한 고려가 부족했기 때문인거죠...
안에서 정의한것과 밖에서 정의한 차이는 절대로 아닙니다.
클래스마다 리스너가 따로 정의되어있다고 하면 어차피 그것도 효율을 위해 적당한 상속 관계를 쓸거고...
정말 안쓰고 개개마다 다 리스너를 정의한다고 해도,
그게 클래스 안쪽에 정의한것과 그렇지 않은것의 차이는 없을겁니다.
a.onclicklistener냐 onclicklistener냐의 차이만 있을뿐입니다.
제가 말씀드리는 의존성..은 클래스와 클래스의 관계로만 한정지은게 아닙니다.
디자인 패턴 관점에서 보자는 거에요..
변경사항이 발생했을때 변경해야 하는 부분을 관련된 내용만 변경하도록 가장 최소한의 연결관계만 갖도록 하는 겁니다..
분명 제가 말한 방법대로 해도 의존성 자체가 아주 없어지는 것도 아닙니다..
어차피 상속이든 구현이든 그런 부분이 생기면 의존성은 당연 생기죠..
그 관점에서만 놓고 보면 그냥가자님이 말한 내용은 맞습니다..
하지만 그건 코드관점에서의 의존성이지..
실제 변경사항을 고려했을때 내가 코드를 어디까지 변경해야 하는 부분에 대한 고려를 하자는 것이지요..
폰에 대한 변경사항이 발생했을때..
업무로직이 구현된 클래스를 그때그때 마다 변경하느냐..
아니면 폰에 대한 전용 클래스를 만들어 거기에 업무로직을 구현한뒤..
거기를 변경하느냐..하는 것은 분명 차이가 있습니다..
유지보수 관점에서도 폰에 대한 전용 클래스에 업무로직을 구현해서 그것을 수정하는것이 훨씬 이득입니다..
물론 초기제작 비용은 많이 들어갑니다..
모든 폰에서 똑같이 수행하는 기능 클래스를 만들고 특화된 것만 개개 폰클래스를 만들어서 제작하니..
클래스 갯수도 많아지겠죠..
하지만 유지보수나 추가사항이 발생하여 수정을 할때..
점점 코드가 지저분해지는 상황을 지켜보면..
분명 폰별로 클래스를 빼서 하는 부분이 훨씬 좋다고 생각합니다..



