Code Generation Isa Design Smell
Code Generation Isa Design Smell
“It’s such a great product,” says the PointyHairedBoss, “just look at all the AutomatedCodeGeneration it does for you!”
“Dude!” I say, “you just don’t understand: The need to do lots of AutomatedCodeGeneration is a flaw, not a feature.”
JeffBay thinks Java Beans suck. He has eventually explained why in this forum. Read on!
Everybody knows what a bean is, but why does everybody put up with code like this:
private String foo;
public void setFoo(Object foo) { this.foo = foo; }
public Object getFoo() { return foo; }private String bar;
public void setBar(Object bar) { this.bar = bar; }
public Object getBar() { return bar; }or this:
private String bar;
private String foo;public Object getBar() { return bar; }
public Object getFoo() { return foo; }public void setBar(Object bar) { this.bar = bar; }
public void setFoo(Object foo) { this.foo = foo; }Either way, when you have bar, foo, baz, biff, blag, blarg, and bloog, it seems a bit ugly to me. How about:
public class something implements FOO
private Map fields;
public Object get(Name name) { return fields.get(name); }
public void set(Name name, Object value) { fields.put(name, value); }public List names() {
Object[] names = { FOO.bar, FOO.foo, FOO.baz, FOO.biff, FOO.blag, FOO.blarg, FOO.bloog };
return Arrays.asList(names);
}or
public List names() {
Object[] names = { “bar”, “foo”, “baz”, “biff”, “blag”, “blarg”, “bloog” };
return Arrays.asList(names);
}
자바가 제일 귀찮은 것이 이 getter와 setter이죠.
자바를 시작하면 누구나 만나는 getName()/setName()류의 메소드들.
.NET의 경우에는 property를 사용하므로 get어쩌구라고 쓸 필요없이
NAME=”abc”; 라고하면 NAME 프로퍼티에 자동으로 값을 부여하고,
이때 사전에 정의한 validation 을 할 수 있죠..
어쨌거나 크게 정리하자면, getter와 setter를 사용하면 validation을
위한 단계를 둘 수 있다는 것이 가장 기본적인 시발점이죠. 그리고 여기서
나아간 형태가 .NET의 프로퍼티입니다.(타이핑이 덜 귀찮고 가독성이 높음.)
하지만 .NET의 경우도 public field와 프로퍼티를 구분하기가 애매한
단점이 있죠… 물론 client 입장에서 알 필요가 있냐고하면 할말 없고,
외부의 인터페이스는 유지하며 이를 프로퍼티로 전환하는 것도 용의한 점에는
한표이지만.
다음 문제는 과연 이 getter/setter를 사용하여 자바 빈즈 답게 쓰는
코드를 개발자가 얼마나 생산하는가 하는 문제입니다… 실제로 자바빈즈는
다양한 validation, notification 프레임웍을 갖추고 있죠. 그러므로
그러한 프레임웍을 잘 맞춰주면 그림그리듯이 프로그램을 짤 수 있다라는 건데
실제로 우리가 그렇게 짜고 있지는 못하죠…
그러나 요즘은 덜 귀찮아진게 이클립스에서 간단하게 getter/setter를 만들어주고,
JBuilder 등은 말할 필요도 없이 잘 만들어주죠.. 심지어 그림그리듯이 프로퍼티를
지정할 수 있음.
그럼 또 다시 나오는 문제가 이런 자동 코드 생성이 ‘좋은 기능’인가 혹은
언어의 ‘메타 정보 표현 능력’에 대한 땜빵인가 하는 문제인가 보네요..
제일 위의 링크는 자바서비스넷의 링크이고, 아직 얘기가 안끝난거 같으니
퍼오지는 않았습니다.
개인적인 의견으로는, 저는 뭐 버릇같이 getter/setter를 만들고 있으며
코드 자동생성의 덕을 톡톡히 보고 있으나 VO에 대해서는 public을 애용합니다.
저야 규모가 작은 코딩만 하니까 아직까지는 그렇게 살아요..
VO(Value Object)에 대해서는 Sun Java Center J2EETM Patterns- Value Object와 Refactoring 책을 참고를…