Getter & Setter

beans에 대해…

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.”

Beans considered harmful

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 책을 참고를…

Similar Posts:

Comments 2

  1. 이희승 wrote:

    코드 생성이 정말 안좋은 냄새인가에 대해서는 조금 애매한 부분이 있습니다. 생성되는 코드를 가지고 우리가 개발을 하는 것이 아니라 우리가 개발한 코드를 통해 생성되기만 한다면 문제될 것이 없다고 봅니다. 자바 코드가 바이트 코드로 변환되는 것과 다를 것이 없지 않을까요?

    Posted 18 Nov 2004 at 6:36 pm
  2. 민구 wrote:

    아 이 홈피 갑자기 장사 쫌 되기 시작하네요.. ㅋㅋ
    일단 저는 se 나 아키텍처에 대해서는 잘 모름을
    말씀드리고 싶구요..

    음.. 코드 생성이 우리가 개발한 코드를 사용하여
    이루어진다는 것 자체는 좋지만 그것이 visible 한가
    그렇지 않은가도 생각할 거리가 되지 않나요?
    예를들어 c++의 템플릿은 넘겨준 타입에 따라
    클래스를 자동생성(즉 예를들어 List와 List
    은 별개의 클래스)해주지만 이것이 우리에게 직접
    보이는건 아니죠. 가령 List_int.cpp 와
    List_double.cpp가 생성되지는 않는다는거죠.
    그리고 자바의 경우는 erasure라는 개념을 사용하여
    역시 비 가시적으로 타입별 클래스에 대한 처리를 하고요..

    이렇게 볼때, 추상화가 잘 진행된 메타 정보 표현
    프레임웍이 우리에게 무언가를 가시적으로 계속 생성하게
    한다는 자체는 문제라고 생각해볼 수도 있지 않을까라고는
    생각해요.

    하지만 제 생각엔, getter/setter외에 다른 별다른 답안이
    있을거 같지는 않아요.

    Posted 19 Nov 2004 at 1:26 am

Post a Comment

Your email is never published nor shared.