클래스 메소드와 클래스 필드에 대한 접근 방법으로 어느 것이 좋을까?

2013-04-03 10:41

next 자바 강의 교재로 자바 프로그래밍(Agile Java)를 활용할 계획이다. 강의 준비를 하다 다른 개발자들은 어떻게 개발하는지 궁금해서 질문 남겨 본다. 나도 그 동안 특별히 고민하지 않고 사용했던 부분이라 궁금하다.

자바에서는 클래스 메소드와 클래스 필드를 static을 활용해 다음과 같이 구현한다.

public class CourseSession {
	private static int count;
	
	private String department;
	private String number;
	private Date startDate;


	private ArrayList<Student> students = new ArrayList<Student>();


	private CourseSession(String department, String number, Date startDate) {
		this.department = department;
		this.number = number;
		this.startDate = startDate;
		CourseSession.count += 1;
	}
}

만약 위 코드를 리팩토링해서 count 증가하는 부분을 클래스 메소드로 추출할 수 있다.

public class CourseSession {
	private static int count;
	
	private String department;
	private String number;
	private Date startDate;


	private ArrayList<Student> students = new ArrayList<Student>();


	private CourseSession(String department, String number, Date startDate) {
		this.department = department;
		this.number = number;
		this.startDate = startDate;
		CourseSession.incrementCount();
	}


	private static void incrementCount() {
		count += 1;
	}
}

위와 같이 클래스 메소드를 활용하는 부분은 공감이 간다. 좋은 개발 습관이라고 본다. 이 책에서 저자는 클래스 메소드, 필드와 인스턴스 메소드, 필드를 구분하기 위해 위 예제 소스와 같이 클래스 메소드, 필드의 경우에는 클래스명을 앞에 추가하는 것이 좋겠다고 이야기하고 있다.

즉, CourseSession.count += 1;나 CourseSession.incrementCount();와 같이 구현하자는 것이다. 지금까지 클래스 메소드와 필드를 사용한 경우가 많지 않았지만 사용하는 경우 클래스명 없이 count, incrementCount()와 같이 구현했다. 다른 개발자들은 어떤 방식으로 구현하는지 궁금해 질문 남겨 본다. 설마 static은 아예 사용하지 않는 것이 아니겠지...

1개의 의견 from FB

13개의 의견 from SLiPP

2013-04-03 16:46

특별한 장점이나 단점이 없어보입니다. 클래스 변수나 메소드 사용을 명시적으로 드러냈는데 왜 그랬는지 모르겠네요. 메시지 리시버를 명시해서 클래스도 객체같이 보이게 하려고? 그러면 인스턴스 변수나 메서드를 쓸 때도 리시버인 this를 항상 명시해야 짝이 맞겠네요.

2013-04-03 18:41

agile java라는 책에는 어떤 내용이 있나요? 저는 코드가 agile하기 위해서는 충분히 가볍게 움직일 수 있는 상태여야 할 것 같아요. 그럴려면 불필요한 코드를 줄이고 한 클래스가 과하게 커지는 것을 방지해야 하고, 이런 관점에서 CourseSession 클래스를 본다면, 충분히 작게 유지되는 클래스의 static field를 메서드로 표현할 필요는 없을 것 같아요.

2013-04-03 18:46

그리고 너무 간단한 코드를 가지고 이것이 좋냐 나쁘냐를 따지는 것은 올바른 결정을 내리기도 쉽지 않은 것 같아요. 이미 문제가 너무 미미하니까요. 이럴 때 저는 대부분 단순한 쪽이 좋더라구요.

2013-04-03 19:09

@benghun 프로그래밍이라는 것이 정답이 있는 것은 아니잖아요? 그래서 위와 같이 소스 코드의 일부를 가지고 이런 논의를 하는 것이 쉽지 않은 듯 해요. 제가 이곳에서 논의하는 것은 한 가지 방법을 찾자는 것이 아니라 개발자들의 다양한 접근 방식을 보고 다른 개발자가 느끼고, 배우는 것이 있으리라 생각합니다. 그러므로 다양한 접근 방식의 이야기가 나오면 좋겠어요.

agile java 책에서는 제가 본문에서 공유한 소스처럼 안내하고 있습니다. 이 책에서도 그 방법이 맞다는 것이 아니라 static을 사용할 경우 이런 식으로 구현하는 것이 좋지 않겠느냐고 제안을 하는 형식입니다. static사용에 대한 위험성과 문제점을 이야기하면서 위와 같이 코드를 리팩토링하는 과정을 보여주고 있어요.

책이 접근하는 방식은 다양한 구현 방식을 보여주려는 것에 초점이 맞추어져 있다고 보면 됩니다. 제가 질문을 남긴 것은 위와 같이 static field에 대해서 제가 지금까지 구현하던 방식과 다른 방식으로 구현하고 있어서 다른 개발자들이 어떻게 구현하고 있는지 궁금해서였습니다.

2013-04-03 19:22

@benghun 앗 그런 의도로 쓴 댓글은 아닙니다. 단지, agile java에 있는 내용을 궁금해서 하셔서 쓴 글입니다. 온라인으로, 글로 소통한다는 것이 참 어렵죠? 제가 @benghun 님의 생각이 짧다고 적은 답변은 아니니 오해는 없으시기 바랍니다.

제가 이 커뮤니티를 통해 느꼈으면 하는 것이 다양한 관점과 소통을 통해 무엇인가 배웠으면 하는 것입니다. 앞으로도 좋은 의견 많이 남겨주세요. 저 또한 많이 배우고 있습니다.

2013-04-03 21:07

@fupfin 이번 기회에 한권 사시죠. 팀원들과 같이 스터디를 해보는 것도 좋은 방법일 듯 합니다. 스터디하고 후기를 남겨주심 교재 선정할 때 다시 함 고려해 보도록 할께요. ㅋㅋ

2013-04-03 21:08

암튼... 흥미로운 제안이네요. 전 필드와 로컬 변수를 구분하려고 this.fieldName 형태로 쓰는 편입니다. 하지만 클래스 메서드나 필드에 대해서는 생각을 안 해 봤네요. 일단 제 의견은, 클래스 메서드와 인스턴스 메서드가 구분이 안 될 정도로 클래스가 커진다면 그게 문제이고 구분해서 얻는 이익보다 구분하느라고 들이는 수고가 더 커 보인다...입니다. 저 예에서는 클래스 이름이 짧지만 늘 그런 것도 아니고요.

2013-04-04 23:16

제가 agile java로 스터디 하고 있는데... 개인적으로 포지셔닝이 애매한 책 같습니다. 자바를 처음 배우는 사람이 보기에는 기본적인 설명이 너무 부족하고... 어느 정도 경험있는 사람이 보기에는 자바 언어를 깊이 있게 알아가기 위한 책이라기 보다는 TDD와 리팩터링에 대해 치우친 면이 있고... TDD나 리팩터링을 위한 책이라고 보기에는 포지셔닝이 또한 애매하고...

번역이나 용어 선택에 있어서 어색한 표현이 많고... 제가 느낀 점은 그렇습니다.

포지셔닝이 애매한...

2013-04-05 10:12

@ezblog 내가 agile java를 선택한 이유는 TDD와 리팩토링에 대한 내용도 있지만 일련의 스토리를 가지고 수업을 진행할 수 있겠다는 생각 때문이다. 사실 프로젝트를 하나를 선정해 스토리를 만들면서 커리큘럼을 설계하는 것이 상당히 힘든 일이거든. 이번 학기에서는 책의 도움을 받아서 스토리를 만들어 가면서 수업을 진행하려고 한다. 물론 반응이 괜찮으면 앞으로도 계속 사용할 계획이다.

스토리 기반으로 진행하려는 이유는 자바를 자연스럽게 배우게 하기 위함이고, 거기에 TDD와 리팩토링까지 녹여낼 수 있다면 더 좋다. 번역이나 용어 선택은 마음에 들지 않아서 내가 많기 수정해서 강의 진행하려고 해. 나는 오히려 한 가지 분야에 너무 깊이 있게 다루지 않고 애매한 포지셔닝을 취하고 있어서 다양한 관점을 배워야하는 학생들에게 적합하지 않을까라는 생각도 한다. 내가 교재를 선정한 것에 대한 합리화라고 할까. ㅋㅋ

2013-04-08 10:35

프로그래밍을 어떻게 한다가 적절한지는 좀 더 다른 주제로 얘기하면 좋겠지만..^^

아마 코드 레벨을 맞추려는 의도 같습니다. ^^ 즉, 해당 생성자에서 연산 관련 부분은 extract하여 다른 상위의 할당하는 과정과 code level을 맞춰서 가독성을 일관성 있게 맞추려는 의도로 보입니다.

코드는 작자에 따라 다양한 표현으로 작성이 됩니다. 그 수준에 따라 코드는 코드가 아닌 story를 가진 글이 되는냐 정말 code가 되는냐가 달라집니다. 위에 표현은 그 작자가 그런 의미에서 code level을 맞추어 타 개발자로 하여금 가독성을 높이기 위해서 작성되었다고 보입니다.

또한, 이 부분은 그런 부분을 의도해서 집필된 영역이라 생각됩니다. 이런 부분을 선생님(박형~)이 학생들에게 잘 설명 해주셔야 할 듯 합니다.~ ^^

라고 저는 이해~ ^^ ㅋㅋ

의견 추가하기

연관태그

← 목록으로