Today's Dev Notes(2018-10-16)

안녕하세요. Brad입니다. '좌표계산기' 문제도 막바지에 이르렀네요. 그럼 오늘도 step을 진행하면서 생각하고 배운 것들을 정리해보겠습니다.

 

step6 에서 기존 step과 비교해서 별 요구사항이 없었습니다. 이미 인터페이스를 구현해놓은 상태라 요구사항을 이미 충족해 있었기 때문입니다. 그래서 기존 코드를 리팩토링할 좋은 기회라 생각했습니다.

• 팩토리 생성

  • 팩토리는 뭘까?

    • 팩토리는 의미 그대로 '공장'이라는 뜻입니다. 이때 만들어주는 것은 '객체'인데요. 팩터리 메서드는 객체를 생성하여 반환하는 메서드를 말합니다.
    • 여기에 '패턴'이 붙으면 하위 클래스에서 팩터리 메서드를 Override해서 객체를 반환하는 것을 말합니다. 예를들어 인터페이스를 하위 클래스에서 Override 하여 필요한 객체를 반환하는 것이 있습니다. 아래 예는 step6에서 FigureFactory 인터페이스를 받아 팩토리 클래스에서 해당 Figure에 대한 객체를 반환하는 소스코드입니다.

  public class SquareFactory implements FigureFactory {
  
      @Override
      public Figure create() {
          return new Square();
      }
  }
  

  • 어떻게 구성할까?

    • 기존에 Point개수에 따라 바로 그 도형의 객체를 생성했었습니다. 팩토리를 구성하게 되면 우선 FigureFactory 를 인터페이스로 하나 만들고, 이를 받는 하위 클래스에서 인터페이스에 있던 메서드를 Override하여 각 도형 객체를 반환합니다. 위의 소스코드 그대로 입니다.

  • 팩토리는 어느 패키지에 속할까? Domain? Controller?

    • Pobi에게 질의 결과 대부분의 팩토리 클래스는 Model로 보는게 일반적이라는 대답을 들었습니다.
    • 지난 '사다리게임' 미션에서 of메서드가 Domain에서 했던 역할, 그리고 팩토리 패턴이 Domain 내에서 수행한다는 점을 생각하면 Domain에 속한다는 것이 수긍이 가네요.

• List에서 배열로 어떻게 만드나?

  • 지난에 Arrays.asList()를 통해서 배열 형태를 List로 만들어 보았습니다. 이번에는 List을 배열로 형태로 만드는 것이 필요하였습니다.
  • 이 때 사용할 수 있는 메서드가 toArray()입니다. List형에다가 사용할 수 있고 매개변수로는 배열 자료형 그리고 그 size()를 선언하면 됩니다. 이번 코드에서 아래와 같이 사용하였습니다.

  Point[] p = getPoints().toArray(new Point[getPoints().size()]);
  

  • 여기서 배열 사이즈를 선언할 때 재미있는 부분이 있는데요. 우선 아래의 예시를 보겠습니다.¹

  List<String> stringList = new ArrayList<String>();
  stringList.add("A");
  stringList.add("B");
  stringList.add("C");
          
  String[] stringArray = stringList.toArray(new String[0]);
  

  위의 예에서 new String[0]으로 크기를 0으로 지정해도 정상적으로 배열이 생성됩니다. 왜냐하면 배열 사이즈가 List사이즈보다 크지 않을 때는 List사이즈대로 생성되기 때문입니다. 하지만 지정한 배열 사이즈가 List사이즈보다 클 때는 그 사이즈대로 배열이 생성됩니다. 따라서 만약 5로 지정해주고 한줄씩 값을 출력하면 아래와 같은 값들이 출력됩니다.

  

피드백

• create(points) 형태으로 고치기

• 기존에 도형의 넓이를 계산할 때 points 를 각 도형 클래스의 넓이 구하는 매서드의 매개변수로 전달하였습니다.

• 하지만 이번 피드백에서 이 방법보다는 Factory에서 도형을 만들 때 이 도형 클래스에 생성자로 points를 넘겨주는 것이 좋다는 것이었습니다.

• 처음엔 이 방법이 왜 좋을까 몰라서 우선 이 방법대로 구현해보면서 생각해 보기로 하였습니다. 구현 도중 발견한 좋은 점을 아래와 같습니다.

  • 도형의 생성자부터 points를 받아 이후에 points사용시 유용하게 사용될 수 있습니다. 도형에서 points는 꼭 필요한 정보이기 때문이죠!
  • 모든 도형 클래스에서 points는 꼭 필요하고, 즉 중복되는 코드이기 때문에 상속을 통해 한번에 처리 가능합니다.
  • 이 덕분에 어제 배웠던 자식 클래스가 추상 클래스를 받고 추상 클래스는 인터페이스를 받는 구조를 적용해 볼 수 있었습니다. 추상 클래스에서 중복되었던 points를 처리하는 생성자를 만들고 넓이를 구하는 매서드는 인터페이스에 선언해두구 자식 클래스에서 재정의하였습니다.

• 자식 클래스가 추상 클래스를 받고 추상 클래스는 인터페이스를 받는 구조를 사용하면서 '추상 클래스는 인터페이스에서 선언한 매서드를 구현할 필요가 없을까?' 라는 궁금증이 생겼습니다.

• 하지만 직접 구현해보니 추상클래스에서 인터페이스를 받아도 인터페이스에서 정의한 매서드를 반드시 구현할 필요는 없고(구현은 가능합니다) 자식 클래스에서만 강제된다는 것을 알 수 있었습니다.
• 주변 멤버에게 물어보니 추상 클래스 성격상 반드시 메서드가 구현될 필요가 없기 때문에 가능하다는 대답을 얻었는데요. 수긍이 가네요!

오늘 추가적으로 공부한 부분

• 2018/10/17 - [Algorithm] - Today's Algorithm(2018-10-16)

 

---

1 예시 및 내용을 이 블로그에서 참고하였습니다.↩