트리 구조에서 고민이 생겼다.
1.
다음과 같은 구조를 만들었다.
(1)
H 밑에 Is,
Is 밑에 J,
J 밑에 Ks,
Ks 밑에 K
복수 데이타를 담고있는 콜렉션 층이 없어지면 좋지 않을까 생각했다. 다음처럼 생각했다.
(2)
H 밑에 I,
I 밑에 J,
J 밑에 K
그러나 생각해보니 (2) 구조를 사용하면 다음과 같은 상황에서 불편해진다.
(3)
A 밑에 Ks
(1)을 사용하면 Ks를 바로 사용하면 된다.
(2)의 경우 어떻게든 하려면 J를 써야하는데 J와 Ks의 의미가 다르다.
(3)의 경우가 생기지 않는다면 (2)가 더 좋을지 의문이 생기긴 하다.
2.
자식의 메소드를 대신 실행하는 헬퍼 메소드가 복잡해 보인다는 생각이 들어 고민을 했는데 이는 위 상황때문에 생기는 문제가 아니다. (2)의 경우라도 헬퍼 메소드를 넣으려면 필요하다.
tree.H
.addI
(
I.createI().setID("1").setName("일")
)
.addI
(
I.createI().setID("1").setName("일")
)
헬퍼 메소드는 별 것은 아니고 hibernate의 DML-style operations을 참고삼아 만든 것이다. add, get, remove 형태의 콜렉션 메소드들은 데이타를 생성하고 추가할 때 자식 오브젝트를 생성하고 추가를 해야한다. 코드 상에서 생각하면 추가 작업(add method)의 등장이 자식의 생성보다 늦게 나타난다. 복잡한 부모-자식 구조라면 코드를 읽는 시간을 늘린다(고 생각하는데 아닐 수도 있겠지만 나는 그렇다). 그래서 사용한 방법은 마지막으로 넣은 object가 자신을 return 하여 점(.)을 찍고 추가 연산을 가능하게 하는 방법이다. 이렇게 하면 부모가 더 위에 나타나고 자식은 밑에 나타난다. 들여쓰기까지 사용하면 더 구조적으로 보인다. 더러 쓰이는 방법으로 알고있다. 예전에 JAVA nio 쓸때도 이런 메소드들이 많았던 것으로 기억한다.
아무튼 이 방법은 어떤 컨텍스트에서 작업을 했느냐가 중요하다. 깊이 있는 자식 object를 다루다가 부모 오브젝트 쪽에서 추가 작업을 하고싶으면 다시 부모로 올라가는 쉬운 방법이 없어 보인다. 그래서 헬퍼 메소드는 트리 구조의 상단에서 편하게 메소드를 호출하는 구조도 있지만, DML-style operations 처럼(이 말을 써도 되는지 아직 잘 모르겠음)메소드 체이닝처럼 데이터를 생성해낼 때 return 타입을 달리 할 수 있어 편리하다.
3.
결론적으로 각 클래스는 자신이 어떤 위치에 속해있는지를 모르게 설계하는 편이 좋을 수 있다는 것.
댓글 없음:
댓글 쓰기