지금 같은 경우 고유 ID 생성하여서 객체를 생성해야 하는 경우, 추가적인 초기화 작업을 팩토리 메소드 내부에서 처리할 수 있습니다.
그래서
복잡성을 관리할 수 있다. - 복잡한 코드를 클라이언트 코드에서 숨길 수 있음
확장성과 유지보수성 향상 - 객체의 구체적인 타입을 쉽게 바꿀 수 있다.
테스트가 용이하다.
1. Opacity 객체를 생성하여 1~10까지 검증되도록 하였습니다.
2. 컬러값도 초기화때 범위 안에드는지 검증을하도록 개선하였습니다.
3. 유니크 ID를 생성할 때 Set을 이용하여 검증하도록 개선하였습니다.
4. 유닛 테스트를 할 때
사각형 모델의 객체 속성들이 private로 되어있어서, 동등한지 비교하고 싶을 때 속성에 접근을 못하여서 속성을 꺼내는 함수를 만들까하는 고민과 테스트를 위해서 접근 제어자를 바꿀려고 하는 고민 2개가 떠올랐는데 전부 배보다 배꼽이 크다고 생각되었습니다. 그래서 디버그 빌드 환경에서만 컴파일 되도록 #if DEBUG지시어를 사용하여서 test용 속성을 쓸 수 있도록 하였습니다. 이런 의도가 지금 상황에서는 적합한 방법인지 궁금합니다.
팩토리 메소드와 생성자 init은 유사한데 왜 팩토리가 필요한가?
팩토리 메소드는 객체 생성 과정이 복잡하거나 추가적인 설정이 필요한 경우에 사용됩니다.
지금 같은 경우 고유 ID 생성하여서 객체를 생성해야 하는 경우, 추가적인 초기화 작업을 팩토리 메소드 내부에서 처리할 수 있습니다.
그래서
1. Opacity 객체를 생성하여 1~10까지 검증되도록 하였습니다.
2. 컬러값도 초기화때 범위 안에드는지 검증을하도록 개선하였습니다.
3. 유니크 ID를 생성할 때 Set을 이용하여 검증하도록 개선하였습니다.
4. 유닛 테스트를 할 때
사각형 모델의 객체 속성들이 private로 되어있어서, 동등한지 비교하고 싶을 때 속성에 접근을 못하여서 속성을 꺼내는 함수를 만들까하는 고민과 테스트를 위해서 접근 제어자를 바꿀려고 하는 고민 2개가 떠올랐는데 전부 배보다 배꼽이 크다고 생각되었습니다. 그래서 디버그 빌드 환경에서만 컴파일 되도록 #if DEBUG지시어를 사용하여서 test용 속성을 쓸 수 있도록 하였습니다. 이런 의도가 지금 상황에서는 적합한 방법인지 궁금합니다.