행복한 아빠

여기서 말하는 "구조"는 데이터 구조를 이야기합니다. 우리의 소프트웨어는 크게 두 가지 부분으로 동작합니다. 하나는 우리가 사용하는 데이터(메모리, 변수, 배열 ...)와 그 데이터를 다루기 위한 명령의 집합인 알고리즘입니다. 동일한 기능을 제공하는 프로그램이라도 데이터의 구조와 알고리즘은 다를 수 있고 프로그램의 성격에 따라 데이터 구조가 복잡해질 수도 있고 알고리즘이 복잡해질 수도 있습니다. 알고리즘 보다는 구조 내가 학교에 다닐 때는 프로그램을 잘 하는 사람은 알고리즘을 잘 짜는 사람이라고 생각했습니다. 오랜 동안 이쪽에서 일하다보니 그 생각이 잘못되었다는 것을 알았습니다. 우리가 시스템이나 프로그램을 만들때 집중해야 할 것 중 하나는 풀어야 할 문제의 본질을 찾아 단순화하는 것입니다. 경험상 단순..

가끔 후배들에게 이런 질문을 합니다. 프로그래머가 뭐하는 직업이냐아무런 상황 설명 없이 하는 이런 류의 질문이 사람을 당황하게 하고 짜증나게 합니다. 물론 머뭇머뭇 거리다가 제대로 답하지 않는 경우가 대부분입니다. 꽤 오래 생각해 봐야 할 질문이죠. 특히 자신이 하는 직업일 경우는 더욱 그렇습니다. 프로그래머라는 직업을 가지고 이분야에서 일한지 십수년이 지났네요. 시간이 흐름에 따라 나이도 먹고 직급도 올라가고 거기에 따라 하는 일도 조금씩 달라지게 됩니다. 현재는 이클립스(프로그램 툴)보다 파워포인트가 화면에 떠있는 시간이 더 많아졌지만 나는 아직 "프로그래머"라는 직책을 버리지 않았습니다. 하는 일은 달라졌어도 여태껏 했던 일의 맥은 같다는 걸 알았습니다. (이미지출처) 코드와의 만남 처음 컴퓨터 프..

[무엇이 문제인가] [IoC&DI] [실전에서] Spring 프레임워크나 EJB3를 쓰다보면 Dependency Injection(이하 DI)에 대한 이야기가 많이 나오고 있다. 뿐만 아니라 근래에 나오는 프레임워크(Struts2, Hibernate, Grails, ...)들도 기본으로 D.I를 지원하는 추세이다. D.I의 정확한 의미를 알아보겠다. 무엇이 문제인가? Wiring 객체의 힘 - 추상화, 다형성 객체지향프로그램(OOP)의 위대함으로 추상화에 있다. 객체를 사용하는 클라이언트(Caller)를 실제 사용하는 객체가 뭔지 몰라도 객체의 인터페이스만 잡고 일을 시킬 수 있다. 여기에서 클라이언트가 잡고 있는 객체를 클라이언트 모르게 바꾸어도 그 코드는 잘 동작하고 동일한 인터페이스라도 실제 객체(..

설계를 하면서 클래스간의 관계에 대해 정확한 이해없이 설계하는 경우가 있다. 물론 문제 영역마다 그 관계의 종류가 명확하지 않을 수도 있고 aggregation이나 composition의 경우 미묘한 차이가 있어 너무 까탈스럽게 따지는 것도 그리 좋은 생각은 아니다. 동기 그러나 관계의 종류를 명확하게 하지 않을 경우 설계자의 의도와는 다른 결과물을 생성하는 경우를 종종 본다. 클래스 설계를 UML로 주로 하는데 여기서는 클래스간의 관계 중 dependecy, association, aggregation, composition 4가지를 정리해 보겠다. Generalization(클래스 상속)이나 Realization(인터페이스 구현,실현)은 그나마 명확하기에 제외하였다. Dependency 의존이란 제일..

[무엇이 문제인가] [IoC&DI] [실전에서] 실전에서 이러한 DI를 제공하는 몇 가지 컨테이너가 있다. 이제는 Spring 프레임워크가 대세인 것 같은데 여기서 이것을 포함하여 두 가지 예만 보겠다. PicoContainer (http://www.picocontainer.org/) PicoContainer는 DI를 제공하는 가벼운 컨테이너이다. 이것은 생성자의 아규먼트를 통해 의존성 주입을 이용하여 객체가 wiring을 한다. MovieLister class MovieLister... public MovieLister(MovieFinder finder) { this.finder = finder; } CSVMovieFinder class CSVMovieFinder... public CSVMovieFin..