우연히 S/W 프레임워크 수업을 수강하고 있다.
프레임워크라는 단어에 반가워서 수강신청했는데
수업내용이 전자정부 프레임워크였다. ;;;
학점관리상 굉장한 이득을 볼 수 있었지만 수업내용은 군대에서 공부한 토비 스프링
내용보다 원리 중심적이지는 않고 실무 지향적인? 내용으로 수업이 흘러갔다.
솔직히 스프링 프레임워크를 JDBC도 잘 모르는 학부생들을 상대로
가르치려고 노력 하시는 강사님이 대단하게 느껴진다.
학생들이 안타까워... 저걸 어케 이해함...
수업 초기에 작년에 강의평가에서 혹평을 받았다고 하셨는데
경영학과 학부생 상대로 스프링 프레임워크 강좌가 열린다는 것 자체가
이상한일....
컴공애들 상대로 강의를 해도 스프링의 철학같은것을 이해하기 힘들텐데
프로그래밍에 관심도가 덜한 경영 학부생들이면 말 다했다..
서문이 길었다.
수업 듣다보니 단골 질문이 나왔다.
Class 와 Interface의 차이를 서술하시오
간단한 내용이지만 정리를 해볼까 한다.
1. Interface는 선언부 Class는 구현부이다.
자바는 철저한 OOP 를 기반으로 하고있다.
객체지향 프로그래밍의 핵심은 추상화(Abstraction) 이다.
추상화를 함으로서 중복된 소스코드를 없앨수도 있고
느슨한 결합도 (loose Coupling)를 유지 할수도 있다.
추상화하는방식(상속과 인터페이스의 차이도 나중에 작성해야 겠다. )
인터페이스는 객체지향적인 소스코드를 생산할수 있도록 도와준다.
.
Don't re-invent the wheel(바퀴를 다시 만들지 말라)
객체지향 프로그래밍의 궁극적 목표인 위 모토를 만족하기 위해서 객체지향 5대 원칙(SOLID)을 세우고
캡슐화 추상화와 같은 이론들을 정립했다
Interface는 이러한 정립된 이론들을 구현하는 최전선에 서있는 개체이다.
Interface는 프로그래밍에 입문 하는 사람들에게는 그 편리함을 체감하기 힘든 기능이다.
Interface는 식당의 메뉴판 같은 역할을 한다.
“메뉴판을 보는 손님들이 원하는 정보는 어떤 음식을 먹을까?”이지 그 이상의 복잡한 정보를 원하지 않는다.
스테이크요리를 만들기 위해서는 불에 얼마나 굽고 어떤 소스를 만들고 숙성을 얼마나 하는지 같은 복잡한 내용이 적힌 두꺼운 요리책이 필요하다.
그러나 그러한 두꺼운 요리책을 손님 메뉴판으로 제공하지 않는다.
Class 가 두껍고 복잡한 내용이 담긴 요리책이라면 Interface는 1~2장으로 이루어진 가벼운 메뉴판이다.
우리는 손님에게(사용자) 가벼운 메뉴판을 제공하지 두껍고 무거운 요리책을 주지 않는다.
손님은 소고기 스테이크가 불위에서 어떤방식으로 구워지는지 몇분 구워지는지 같은 세세한 정보를 알고 싶지 않다.
그저 맛있는 스테이크를 먹고싶어서 간단히 적힌 메뉴판을 보고
"소고기 스테이크 1인분 주세요~" 라고 주문할 뿐이다.
소프트웨어에서도 마찬가지다.
어떠한 라이브러리,API를 사용하는 사용자는 그 API가 얼마나 멋진 추상화가 적용되었고 다양한 기법들이 사용됬는지 알고싶지 않다.
그저 그 API또는 라이브러리를 통해 내가 구현하고자하는 기능에 편하게 쓰고싶을 뿐이다.
그렇기 때문에 우리는 메뉴판을 제공하듯이 인터페이스를 제공한다.
스테이크의 조리법이 수정되었다고
메뉴판에서 무엇인가 수정되지 않듯이
구현체가 바뀌었다고
인터페이스가 수정되지 않는다.
JDK로 알아보는 Interface 사용 예제
List<String> list=new ArrayList<String>();
list.add("HI");
list.add("assignment");
list.add("yea~!");
다음 예제를 보자 위 예제는 ArrayList에 3개의 문자열을 넣는 소스코드이다
여기서 봐야할 점은 객체 list 의 선언을 왜 ArrayList<String> 로 하지 않고
List<String> 으로 선언했는가? 이다.
ArrayList<String> list=new ArrayList<String>();
list.add("HI");
list.add("assignment");
list.add("yea~!");
이렇게 ArrayList로 선언 해도 돌아가는데 아무런 문제가 없지만
좋은 프로그래머라면 전자방식을 선호하며
반드시 그래야만 한다.
자바언어를 창시한 제임스 고슬링은 리스트라는 자료구조를 설계할 때 리스트의 구현 방식이
리스트를 선언하는데 영향을 주고 싶지 않았을 것이다.(진짜설계는 다른 사람이 했겠지만 편의상..)
그래서 List<>를 interface로 선언했다.
List<>를 Interface 선언 함으로서 우리는 소스코드 변경이 가능하다
이것은 Strategy Pattern (전략패턴) 이라 부르는 디자인 패턴이다.
하나의 기능을 구현하는 여러가지 전략(알고리즘)이 있으면 이것을
인터페이스로 선언부를 작성하고 여러가지 구현부를 클래스로 작성하여
교체하기 편리하게 하는 것이다.
인터페이스를 사용함으로서 이러한 설계상 이점을 가질수 있다.
사실 인터페이스는 아무런 의미가 없는 껍떼기에 불과하다 느낄 때가 있다.
실제로도 구현상 인터페이스는 그저 매개체 정도의 역할만 하고 실질적인 내용에는 아무런 기여를 하지 않는다.
인터페이스는 설계상 이득을 얻기위해 선언하는것이다.
인터페이스는 기능들을 묶는 논리적인 하나의 단위를 띄고 있다.
인터페이스는 비용(Cost)이다. 그러나 모든 코드 또한 비용이다.
비용을 들인 만큼 얻는 가치가 있다면 투자하면 되고 없다면 투자해서는안될것이다
프로그래밍에서 간접화와 추상화에 관련된 코드를 비용으로 따진다면 간접비에 해당한다.
추상화를 하면 할수록 SW은 오히려 복잡도가 더 올라갈수 있고
소프트웨어 공학에서도 과도한 추상화와 디자인패턴 남발은 피하도록 노력해야 한다고 주의하고있다.
그러나 복잡도가 올라갈수 있는 위험이 있다고 인터페이스를 사용하지 않는다면
구더기 무서워서 장 못담군다는 말이 가장 어울리는 표현일 것이다.
“그렇다고 모든 클래스에는 인터페이스를 만든다” 라는 과격하고 경직된 방식의 프로그래밍은
인터페이스가 좋다 하더라도 너무 극단적인 방식 이다.
인터페이스의 사용여부는 결국 개발자 또는 아키텍트 당사자의 판단에 맡길 수 밖에 없다.
인터페이스를 사용해야만 하는 상황을 그때그때 적절히 판단하여
사용하는 것이 결국 정답일 것이다.
