'자바'에 해당되는 글 2건

  1. 2012.06.15 프로그래밍의 등가교환(java, c의 간단한 비교) 1
  2. 2010.01.21 인터페이스(interface)


요즘 자바 대신 C계열 언어를 익히고 있는데 배우면서 드는 생각은
프로그래밍에서도 등가교환의 법칙이 있구나 하는 생각입니다.

 

자바는 가비지컬렉션이라는 넘이 있습니다. 개발자를 편하게 해주는 거죠~
그 반면에 C계열에는 가비지컬렉션이 없습니다.

 

프로그램을 돌리기 위해서는 메모리에 올리고 지우고 올리고 지우고 올리고 지우고를 반복하면서

 실행되게끔합니다. 모바일에서 지우지 않고 계속 올리기만 하면 강제종료됩니다. 올리고 지우고..

이게 말이 쉽지 "도대체 언제 지워서 없애야지 하는지"라는 고민을 하게 됩니다. 프로그래밍에서

고민이 하나 늘어난다는 것은 그 고민이 다른 고민들과 엮이게 되어서 고민들이 더더더 커질 수도

있습니다. 때에 따라서 멘붕도 찾아옵니다.
---여기서 포인트는 프로그래머의 고민증가

 

그럼 가비지컬렉션이 멀까요. 말 그대로 쓰레기를 수집하는 넘입니다. 내가 메모리에 올리고 지우지

않아도 지울때 되면 알아서 버려줍니다. 오토인거죠. 완전 편합니다. 메모리 지우는 걸 까먹고 있어도

 쓰레기 수집가가 수집해가서 앞에서 말한 강제종료를 어느정도 막아줍니다. 하지만 쓰레기 수집가도

하나의 큰 작업입니다. 쓰레기를 수집하기 위해서는 그게 쓰레기인지 아닌지 cpu가 체크를 계속 해줘야합니다.
---여기서 포인트는 가비지컬렉션는 또하나의 큰 작업임~

 

말을 종합해보면 자바는 개발자를 편하게 해주지만 퍼포먼스는 C계열보다 못합니다.(기기가 월등해야지 비슷함)
하지만 자바는 개발자의 고민을 덜어주죠..

반대로 C계열은 퍼포먼스는 좋지만 가끔 개발자를 힘들게 합니다.

 

여기서 내가 얻는 그 가치에 맞게 다른 것(대가)을 교환하는 등가교환이 생깁니다.

편하고 쉬울 것을 선택하면 그만큼 불이익이 생길 수도 있는 거죠.

 

간단한 예를 하나 더 들자면 자동차를 볼 수 있습니다. 수동과 오토, 앞에서 말한 가비지컬렉션의 유무와 비슷한 조건입니다.

수동은 배우기 어렵고 힘들지만 연비효율이 좋아집니다.

오토는 배우기 쉽고 다루기 쉽지만 그만큼 연비효율은 떨어집니다.

 

말이 너무 길었네요. 제가 하고 싶은 말은 배우는 게 힘든 만큼 그 만큼의 플러스 등가교환이 일어난다는 것입니다.

Posted by Finebe
,



인터페이스는 다중상속을 구현하기 위한 꼼수 입니다.
그렇다면 다중상속이 필요한 이유가 무엇이냐?

예를 들자면 이렇습니다.
한 회사의 부서들을 클래스로 나타내고 각 직원들을 각각의 부서에 할당했다고 하죠.
일단
1. 영업부 class
2. 기술부 class

정도로 크게 나눴다고 하고 영업부를 더 자세하게 나눈다고 치죠.

1-1 해외영업부class
1-2 국내영업부class

그리고 기술부 역시

2-1 시스템개발부 class
2-2 소프트웨어개발부 class

정도로 나눴다고 치고 모든 직원을 아래의 4개의 클래스에 속한다고 칩시다..(사실 클래스의 개념에 좀 안맞기는 하지만 예를 들기 위해서..^^;;;)
그런데 문제가 생겼습니다... 영업부 직원 중에 운전을 할줄 아는 사람과 할줄 모르는 사람이 있어서 이것을 구분해야 하는 거죠... 그렇다면 어떻게 해야 할까요....

이때 인터페이스라는 개념이 필요한 것입니다.

운전을 하고 못하고는 위의 네개의 클래스 구분과는 무관하겠죠. 다시 말하면 국내영업부 직원이나 소프트웨어개발부 직원이나 모두 운전을 할 수 있습니다.
이것은 다시 말하면 전혀 다른 방식으로 전 직원들을 구분할 필요가 있다는 것을 나타냅니다. 하지만 자바에서는 다중 상속이 불가능하죠. 왜 다중상속이 안되느냐 하면 만일 한 클래스가 두개의 클래스를 상속받을 경우에 그 클래스를 정의하는 두개의 방식이 존재해서 혼란이 일어납니다. 간단하게 이놈이 김씨 아들인지 박씨 아들인지 알수가 없어진다는 정도로 이해하면 되겠습니다. ^^;;

여기서 Drivable 이라는 인터페이스를 구현하고 운전을 할줄 아는 직원들에 대해서 이 인터페이스를 implements 하도록 하면 직책에 따른 직원의 구분 이외에 운전 여부에 대해서 다시 직원들을 구분할 수가 있을 겁니다.

어떤 직원이
extends 시스템개발부class implements Drivable
가 되었다면 이 직원은 시스템개발부에 속하면서 운전을 할줄 아는 직원이 되는 거죠.

여기에 부가적으로 일어를 할 수 있는 직원과 영어를 할 수 있는 직원 그리고 중국어를 할 수 있는 직원을 더 구분하고 싶다면 JPSpeakable, ENGSpeakable, CHNSpeakable 이라는 인터페이스를 정의하고 각각의 직원이 구사할 수 있는 외국어에 대해서 위의 인터페이스를 implements 해주면 될겁니다.


그러면 일괄적으로 일본어를 할 수 있는 직원을 부서에 관계없이 참조할 수 있겠죠.

중요한 것은 여기서 직원들에 대한 구분을 해당 부서가 가장 중요한 분류 기준이고 부가적으로 운전을 할 수 있는지로 다르게 분류하고 있다는 겁니다.
운전을 할 수 있는지가 더 중요한 기준이 된다면
Drivable 을 implements 하지 않고 extends 해서 처리하겠죠.. extends와 implements는 이런 차이입니다.

ps. 개인적으로 구현이든 상속이든 별 차이 없다고 생각합니다. 언어 차원에서 깊게 파고 들어가면 그 차이가 보이겠지만 프로그래밍을 하는 입장에서는 문법의 문제라기보다는 개념의 문제인것 같습니다.

http://kin.naver.com/qna/detail.nhn?d1id=1&dirId=1040201&docId=65288998

'Application Programming > Java' 카테고리의 다른 글

입력된 문자열 뒤에 공백 추가해주는거  (0) 2008.11.10
Posted by Finebe
,