이 글도 제 블로그에 있는 내용을 바탕으로 기억나는대로 적어봅니다.
자바나, C#과 같은 중간계 언어의 장점중 하나는 OS에 독립적이라는 것입니다.
이 의미는 어떤 OS에서라도 같은 소스로 프로그램이 작동한다는 뜻이지요.
이러한 것을 가능케 한 것은 Virtual machine이라는 녀석이 컴파일된 소스를
동작중인 OS에 맞게 다시한번 해석해줍니다.
그 결과 어떤 OS에서든지 움직이는 막강한 언어가 된 것이지요.
여기까지의 내용은 솔찍히 자바나 C#과 같은 언어 책을 보게 되면,
보게되는 내용입니다.
하지만, 이와 같은 장점을 더욱더 살리기 위해서는 오브젝트를 이용해서
프로그래밍을 해야합니다.
제가 경험했던 예를 들자면,
Zip압축 프로그램을 작성할때, 압축된 파일을 디스크상에 작성해놓고,
그 압축된 파일을 목적에 맞게 다루는 식으로 작성하였습니다.
윈도우상에서는 아무런 문제도 없었고, JUnit에서의 테스트도 별 문제없어서,
svn서버에 업데이트를 했습니다.
문제는 svn서버 OS가 리눅스였는데, 리눅스상에서의 테스트에서 번번히
실패로 돌아가 원인이 무엇일까 조사하던중, 알게 된 사실이
압축 파일을 다루는 메소드에 문제가 있다는 것입니다.
논리적으로는 크게 문제가 될 것 없이 움직이는 소스였지만,
저는 File오브젝트가 아닌, String으로서 경로의 탐색 및 비교를
하고 있었기때문입니다.
단순히 글로만 설명하면 이해가 잘 안되리라 생각되기때문에 간단히
소스로 비교해보면 다음과 같습니다.
src. 1)
new File("xxx").getParent().equals("test\\java") ;
src.2)
File parent = new File("test");
String child = "java";
new File("xxx").getParentFile().equlas(new File(parent, child));
src.1과 src.2는 파일의 디렉토리부분을 비교하는 부분입니다.
new File("xxx"). getParentFile() <-파일의 디렉토리 정보를 얻어오는 부분입니다.
그러므로, 위 소스는 xxx라는 파일이 저장된 디렉토리 값과 equlas()안의 내용을
비교해서 같은가를 검사하는 내용입니다. ^^;
소스 설명이 빠져서 추가합니다. ^^;
src.1은 파일 오브젝트를 사용하고는 있습니다만, 비교하고자 하는 검사식(붉은색 부분)이 String입니다.
반면 src.2는 파일 오브젝트를 사용하고 검사식(붉은색 부분)또한 파일 오브젝트를 이용한 비교문입니다.
String을 이용한 비교문을 보면, 간단하게 작성할 수 있는 장점이 있습니다.
그리고, 메모리 취급면에 있어서도 오브젝트를 생성후 취급해야하는 방식에 비해 속도가
빠를 수 있다는 가능성도 있습니다.
하지만, 오브젝트 언어 프로그래머들은 신뢰성이 낮은 방식을 꺼려합니다.
표준 라이브러리로서 제공되는 클래스들은 전 세계에서 사용되고 있고, 신뢰성 또한 인증받은 클래스입니다.
그에 반해 자신의 스타일대로 작성한 클래스들은 자기만이 인증한 클래스입니다.
이와같은 신뢰성이 낮은 클래스로 작성된 프로그램은 사후관리적 차원에서도 문제가 되지만,
다른 프로그래머가 이 소스를 봤을때 느끼는 인상은, 초보구나 하는 것일 겁니다...ㅠ.ㅠ;;
이야기를 다시 돌려서, 위 src.1소스는 윈도우상에서는 문제 없이 움직입니다.
하지만, 리눅스상에서는 동작하지 않습니다.
이유는 리눅스 상에서는 /를 디렉토리 구분자로 사용하기 때문입니다.
src.2의 경우는 파일 오브젝트가 실행될 OS 환경에 맞게 변경해주기때문에,
아무 문제없이 작동합니다.
이상으로 오브젝트를 사용해야하는 이유를 간단히(?) 적어보았습니다.
그래도 의문이 나시는 분은 각자 조사해주시기 바랍니다. ^^;;