Programing/Java & Spring

세무민의 코딩일기 : 개발자가 객체 설계시 염두해야 할 사항은?

세기루민 2021. 6. 20. 15:25
728x90

개발자가 객체를 설계하는 경우에 

회사에 로직이 존재한다면 큰 설계가 없이 기존 로직을 가져다 쓰는 경우가 대다수지만

때로는 개발을 해야하는 경우가 존재하다고 생각해서 작성해봅니다.



토비의 스프링이라는 E-book을 읽었을 때 생각하게 된 것입니다.


# 중복 코드의 메소드 추출 로직

// 결과값 체크 로직을 만든다고 가정
# VO 로직
public class UserVo{
	private String userName;
	private String userPhoneNumber;
	private String userSex;
	private Boolean userPhoneCheck;

	// getter와 setter가 존재한다고 가정
}

# SVC 로직
public String addUser(UserVo user){
	return checkUser(user);
}

private String checkUser(userVo user) {
	
	// 000-1111-2222
	int NumberSize = 13;
	
	// 010
	String frontCheck = 010;
	String frontCheckNumber = user.getUserPhonNumber().subString(0, 2);
	
	// '-' 여부 확인 - 추후 코드가 일치한다면 if에 넣어서 조건확인하면 됨 
	String textCheck = "-";
	String textCheckPoint = user.getUserPhonNumber().contains(textCheck);
	
	// userCheckDao이 존재한다고 가정
	String userCheck = userCheckDao.selectUserPhoneNumber(user);
		
	if(user.getUserPhonNumber().length() != NumberSize) {
		return checkingMsg("EM001");
	}
	else if(frontCheckNumber != frontCheck) {
		return checkingMsg("EM002");
	}
	else if(userCheck == null) {
		return checkingMsg("EM003");
	}
	else {
		int insertNum = userCheckDao.insertUserPhoneNumber(user);
		return  checkingMsg("EM100");
	}
	
}


private String checkingMsg(String msg){
	string phonNumberText = "";
	switch (msg){
		case EM001 :
			phonNumberText = "전화번호 길이가 맞지 않습니다.";
			break;
		case EM002 :
			phonNumberText = "-가 포함되어 있지 않습니다.";
			break;
		case EM003 :
			phonNumberText = "등록되지 않은 번호입니다.";
			break;
		case EM100 :
			phonNumberText = "확인되었습니다.";
			break;
	}

	return phonNumberText;
}

 

위에 코드는 사실 구현하지 않고 손코딩한건데 

급하게 생각나서 만들어봤다. 


위의 코드에서 설명하려는 내용은 만약 전화번호 데이터가 10000개쯤 된다고 생각해보자. 

 전화번호 체크에 대한 부분에서 변경이 일어났을 경우 위에서는 CheckUser 로직만 수정하면 된다. 

위에 add / check / msg로 로직을 분리했기 때문에 

check만 수정하면 되는 용이성이 있다.  

사실 이런 부분은 모두들 잘 알것이라고 생각하지만 

그래도 실무를 하다보면 하드코딩보다 공통함수를 이용하는 걸 추구하는 경우가 많다. 

사실 하드코딩은 누구나 싫어할텐데....

생각보다 옜날 코드들이 존재한다면 하드코딩으로 된 코드들이 엄청 많다 ^^;;;;;


틈틈히 디자인 패턴이라는 의미도 알아두면 좋을 것이다.

- 디자인 패턴은 소프트웨어 설계 시 특정 상황에서 

자주 만나는 문제를 해결하기 위한 사용할 수 있는 재가용 가능한 솔루션을 말한다.

생성패턴, 구조패턴, 행동패턴 등 다양한 패턴들이 존재하는데

그중에 알려진 패턴이 위에 패턴들이다. 

사실 디자인 패턴에 대해서는 나도 자세하게 몰라서 계속 공부해 나갈 것이다.


실제 업무에서 대단한 코드를 짜는 건 아니다.

대부분 기존 잘 만들어놓은 공통함수를 호출해서 자신의 방식으로 튜닝하듯이 사용하는 경우가 대부분이고

새로 솔루션을 만들거나 기능을 만들 경우 코딩을 하는게 대부분인거 같다.

비록 기업마다 다르겠지만 현재 인턴하는 곳에서는 공통함수를 쓰다보니..

뭔가 나 스스로 발전가능성은 아직 찾아보기 어려운거 같다. 


무튼 이번 포스팅의 결론은 

객체나 코딩을 할 때 하드코딩을 벗어나기 위해 설계가 중요하다.

또한 공통으로 사용가능하다면 매소드를 분리시키는게 가장 적합하다.

728x90