객체지향 설계 :) 판매할 Database API UML 설계로로 알아본 객체지향 설계의 방법과 이해

 

 

 

goal

판매할 Database API의 UML을 보며 객체지향설계의 중요성에 대해서 생각해보자

 

 

글을 적는 이유

지금까지 객체지향 설계에 대해서 깊게 생각해본적이 없었다.

스터디를 시작하며 토비의 스프링의 책을 공부하게 되었는데 스프링을 공부하기 앞서서 저자는 책 초반부에 객체지향설계의 중요성을 강조함과 동시에 단계별로 Refactoring을 통해 객체지향 설계를 하는 방법을 나름 친절하게 설명하고 있다. 저자가 친절하게 설명해주고 있지만 생각보다 딱딱한 내용이고 직관적으로 이해가 되지 않는게 사실이다.

현재 포스팅하려는 부분은 Refactoring과정중에 있는 일부 단계이다. 비록 완성 단계는 아니지만, 객체지향 설계에 대해서 많은 것을 배울 수 있었고 현재 내가 이해한 것이 휘발될까봐 글을 적는다.

 

 

객체지향 설계를 왜 할까요?

지금 포스팅하려는 부분을 공부하지 않았더라면 기계적으로 나는 아래와 같이 답했을 것이다.

유지보수를 쉽게하려구요. 유지보수를 쉽게 한다는건 서비스 확장에 있어서 개발자가 고려해야할 사항을 적게 하고 생산성, 즉 개발 속도를 높이는 것을 의미합니다.
이렇게 된다면 유지보수에 드는 비용또한 매우 적어질 것이기 때문에 객체지향설계를 해야합니다

 

 

그러면, 객체지향 설계를 어떻게 해야하나요?

위의 답변이 100점짜리 답변인지는 모르겠다. 우선, 100점짜리 답변이고 아니고가 중요한게 아니라, 나는 나의 답변에 어떻게라는 고민을 해본적이 없다. 객체지향을 어떻게 해야하는가?의 초점을 두어 하나의 UML모델을 가져와 고민하고 생각해보자.

 

※ 소스코드 : my-github

GitHub - euncheol-kim/i-have-been-studying

1. Refactoring을 진행과정의 일부 단계, 판매할Database API 간략한 UML

---

[1] Database API 간략한 UML

---

※ Clinent 박스를 제외한 모든 네모는 하나의 java파일을 의미한다. (UserDaoTest박스로 보자)
하나의 파일이 어떤 기능을 하고 있는지는 아래에서 설명하겠지만
기능 중점으로 글을 보는 것보단 설계의 흐름을 중점으로 보면 더 좋은 글이 될 것이다.

※ 간략화 된 UML이다. UML을 작성하는 법이 궁금하다면 아래의 링크를 참고하자.

UML관련 : Java - 13. 클래스다이어그램, https://velog.io/@godkimchichi/Java-13-%ED%81%B4%EB%9E%98%EC%8A%A4%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8, godkimchichi

 

 

[2] UML을 표로 간략히 설명하기

---

• 하나의 java파일에는 클래스 하나만 존재하고 클래스 이름은 java파일명과 동일하다.
• 표의 내부 메소드(2열)은 클래스 안에 들어가 있는 메소드이다.
• 인스턴스 변수가 UserDao.java에서 한 번 사용되었고 다른 java파일에서는 전역변수가 없다.
• 접근제어자는 명시하지 않았다.
• ConnectionMaker.java는 인터페이스이다.

java파일명	내부 메소드 (메소드명 (매개변수) : 반환값)	java파일의 핵심 역할
UserDaoTest.java	main() : void	해당프로그램을 테스트하는 곳
DaoFactory.java	userDao() : UserDao	Factory역할 - UserDao에게 제공할 객체를 어떻게 생성하고 제공할지의 기능을 담음
UserDao.java	UserDao(Connection) add(User) : void get(String) : User	Database API의 핵심기능 - 추가와 검색
<<interface>> ConnetionMaker.java	makeConnection()	Database연결 기능
DConnection.java	makeConnection() : Connection	UserDao가 사용할 객체

 

 

 

[3] UML이해하기

---

UserDao.java

---

UserDao.java의 UserDao클래스는 Database의 핵심기능만을 책임지게 설계한다.

즉, Database연결 부분의 객체만 받아서 해당 파일의 핵심 기능인 검색과 추가만 수행하도록 한다.

조금 더 풀어서 설명하자면, UserDao클래스는 자신이 어떤 객체를 받던 신경쓰지 않는다. ConnectionMaker객체이기만하면 된다. 이런 설계를 함으로써 해당 클래스는 Database의 핵심기능만 수행하게 함으로써 추후, 확장될 서비스(예를 들자면 Database의 데이터 삭제)에 자유로우며 다른 기능을 수행하는 부분이 수정이 일어나더라도 신경을 쓰지 않아도 된다. 확장에만 영향이 있는게 아니다. 독립적인 설계가 됨으로써 다른 파일에서 기능이 추가될 때 해당 클래스는 테스트를 진행할 필요가 없다.

 

 

<<interface>> ConnectionMaker.java

---

Database와 연결과 관련하여 명세한다 (interface는 명세만한다. 메소드의 구현부는 작성하지 않는다.)

interface로 구현한 이유는, DConnection.java(구매할 회사)파일과 같이 구매할 회사가 많아진다면 공통적으로 작업이 수행되어야할 부분이기 때문이다. 우리가 Database API를 판매할 때 소스코드로 판매하지는 않을 것이다. 영업기밀이기에 바이너리 파일로 팔지... 만약 interface로 구현하지 않는다면 바이너리 파일로 구매한 회사 입장에는 내부적으로 Database 서비스가 바뀌게 될 때 수정이 불가능할 것이다. (수정해서 쓰라고할려면 소스코드를 넘겨버려야한다. 지속적인 수입이 약속되는 프로그램이 일시불로 넘겨짐으로써 그 이상의 물질적 가치는 얻지 못하게 된다. 또한, 서비스 확장과 수정에 있어서도 큰 문제를 가져올 수 있다. (독립적인 기능만 수행하는 것이 아니기 때문에)) 구매회사(DConnectionMaker와 같은)에게 interface를 상속하게하여 회사마다 독자적인 내부 구성으로 Database연결을 하도록한다.

 

 

DConnectionMaker.java

---

DConnectionMaker.java는 우리의 Database API를 구매할 회사고 ConnectionMaker 인터페이스를 상속시킴으로써 Database연결과 관련한 구현부를 설계하게 한다. 구현된 DConnection의 객체는 UserDao.java에서 사용된다. (독립적 기능 수행)

 

 

DaoFactory.java

---

DaoFactory는 객체의 생성방법을 결정하고 만들어진 객체를 돌려준다.

객체를 생성하는 쪽과 생성된 객체를 사용하는 쪽의 역할과 책임을 분리하려는 목적으로 설계되었다.

만약 UserDaoTest에 생성과 사용이 같이 있게 된다면 두 가지의 책임을 갖게 되는거고 이는 객체지향 설계에 위배된다. 객체지향 설계에 위배됨으로써 나중에 확장과 수정에 있어서 유지보수가 매우 힘들어질 수 있다.

 

 

UserDaoTest.java

---

우리가 작성한 UserDao.java가 잘 동작하는지 확인하는 파일이다. (사용목적)

해당 파일의 main()메소드에서는 UserDao타입을 가진 참조변수를 선언하고 구매한 회사의 객체를 DaoFactory에서 받아옴으로써(객체 생성 방법의 결정) UserDao의 핵심기능들을 테스트한다.

 

 

 

글을 쓰며 느낀점

 글을 작성하면서도 제대로 이해하고 있다는 느낌을 받지 못하고 있다.

객체지향설계를 제대로 이해하기 위해서 디자인패턴과 SOLID원칙 그리고 직접 적용하며 경험치를 축적시켜야겠다.