eternity

Lead 레벨

바나나님 안녕하세요. 좋은 질문 해주셔서 감사합니다. 🙂&nbsp;질문에서 말씀하신 것과 유사하게 sealed interface는 인터페이스를 구현할 수 있는 종류를 제한하고 싶은 경우에 사용합니다.강의에서 만든 텍스트 어드벤처 예제에서는 사용자가 입력할 수 있는 명령어의 종류를 제한하기 위해 sealed interface를 사용하고 있습니다.&nbsp;예제 코드를 보시면 Command 타입의 종류로 Move, Unknown, Look, Help, Quit, Inventory, Take, Drop, Destroy, Throw로만 제한한다는 것을 확인할 수 있습니다.<pre><code class="language-java">public sealed interface Command {
 record Move(Direction direction) implements Command {}
 record Unknown() implements Command {}
 record Look() implements Command {}
 record Help() implements Command {}
 record Quit() implements Command {}
 record Inventory() implements Command {}
 record Take(String item) implements Command {}
 record Drop(String item) implements Command {}
 record Destroy(String item) implements Command {}
 record Throw(String item) implements Command {}
}</code></pre>현재는 인터페이스 안에 record 들을 정의하고 있지만 아래 코드처럼 permits를 사용한 선언문의 형태로 변경하면 종류를 제한하는 sealed interface의 용도를 좀 더 명확하게 이해할 수 있습니다.<pre><code class="language-java">public sealed interface Command permits Move, Unknown, Look, Help, Quit, Inventory, Take, Drop, Destroy, Throw {}

record Move(Direction direction) implements Command {}
record Unknown() implements Command {}
record Look() implements Command {}
record Help() implements Command {}
record Quit() implements Command {}
record Inventory() implements Command {}
record Take(String item) implements Command {}
record Drop(String item) implements Command {}
record Destroy(String item) implements Command {}
record Throw(String item) implements Command {}
</code></pre>&nbsp;sealed interface를 사용하면 인터페이스를 구현할 수 있는 모든 타입을 컴파일러가 알 수 있기 때문에 특정 케이스에 대한 처리를 누락하는 문제를 방지할 수 있습니다.Game 클래스의 executeCommand() 메서드를 보시면 switch 문에서 패턴 매칭(pattern matching)을 통해 Command의 종류를 누락하지 않고 저절히 처리하고 있는데 이 경우에 하나의 case문이라도 누락되면 컴파일 에러가 발생하게 됩니다.참고로 default 케이스 없이 모든 구문을 명시적으로 체크할 수 있는 switch 문을 스마트 스위치 표현식(smart switch expression)이라고 부릅니다.<pre><code class="language-java">private void executeCommand(Command command) {
 switch(command) {
 case Command.Move move -> world.tryMove(move.direction());
 case Command.Look() -> world.showRoom();
 case Command.Help() -> showHelp();
 case Command.Quit() -> quit();
 case Command.Unknown() -> showUnknownCommand();
 case Command.Inventory() -> world.showInventory();
 case Command.Take take -> world.takeItem(take.item());
 case Command.Drop drop -> world.dropItem(drop.item());
 case Command.Destroy destroy -> world.destroyItem(destroy.item());
 case Command.Throw aThrow -> world.throwItem(aThrow.item());
 }
}</code></pre>위 코드를 아래의 Move, Take, Drop, Destory, Throw에서 알 수 있는 것처럼 Command.Move(Direction direction)의 형태로 내부 요소를 분해해서 처리할 수도 있습니다.<pre><code class="language-java">private void executeCommand(Command command) {
 switch(command) {
 case Command.Move(Direction direction) -> world.tryMove(direction); 
 case Command.Look() -> world.showRoom();
 case Command.Help() -> showHelp();
 case Command.Quit() -> quit();
 case Command.Unknown() -> showUnknownCommand();
 case Command.Inventory() -> world.showInventory();
 case Command.Take(String item) -> world.takeItem(item);
 case Command.Drop(String item) -> world.dropItem(item);
 case Command.Destroy(String item) -> world.destroyItem(item);
 case Command.Throw(String item)-> world.throwItem(item);
 }
}</code></pre>&nbsp;참고로 sealed interface와 record는 Java에서 대수적 자료형(Algebraric Data Type)을 구현하기 위해 사용됩니다.대수적 자료형은 합 타입과 곱 타입을 조합해서 구현하며 자바의 경우 sealed interface는 OR로 조합할 수 있는 합 타입(Sum Type)을, record를 이용해서 다양한 상태를 조합할 수 있는 곱 타입(Product Type)을 사용해서 구현합니다.&nbsp;강의에서는 특별히 언급하지 않았지만 데이터와 로직을 하나의 단위로 묶는 객체지향과 달리, Command의 경우처럼 특정한 규칙에 따라 데이터와 로직을 나누는 패러다임을 데이터 지향 프로그래밍(DOP, Data-Oriented Programming)이라고 부릅니다.자바에서 데이터 지향 프로그래밍은 sealed interface와 불변 데이터를 구현하기 위한 record, 별도의 모듈에서 행동을 구현하기 위한 패턴 매칭을 조합해서 구현합니다.데이터는 sealed interface와 record를 이용해서 불변 데이터로 구현하며, 이 로직을 사용하는 로직은 executeCommand() 메서드와 같이 패턴 매칭을 이용해서 타입에 따라 적절한 처리를 수행합니다.객체지향이 객체의 행동에 초점을 맞추고 상태화 행동을 함께 묶어 행동을 통해 상태 변경을 캡슐화하는 방식이라면, 데이터 지향 프로그래밍은 데이터에 초점을 맞추는 대신 상태 변경으로 인한 부수효과를 억제하기 위해 불변 데이터를 사용하고 패턴 매칭을 통해 별도의 모듈에서 행동을 구현하는 방식이라고 보시면 될것 같아요.&nbsp;정리하면 예제 코드는 복잡한 게임 플레이 로직은 객체지향 프로그래밍 방식을 따르고, 명령 처리 로직은 데이터 지향 프로그래밍 방식을 따르고 있습니다.강의의 예제처럼 애플리케이션을 구현할 때는 하나의 패러다임만 적용하는게 아니라 여러 종류의 패러다임을 조합해서 애플리케이션을 구축하는 방식이 일반적입니다(따라서 자바는 멀티패러다임 언어라고 할 수 있습니다).&nbsp;답변이 되었는지 모르겠네요. 😊행복한 성탄절 보내시고 추가로 궁금한 부분이 있으면 질문 남겨주세요.

5-4  Sealed Interface는 주로 모든 케이스 검증이 필요할 때 사용하나요?

ansxjrdptj94님 안녕하세요.캡슐화에 ppt 파일이 올라가 있었네요.파일을 수정해서 올릴 때 잘못 올린것 같아요.확인해 주셔서 감사합니다 🙂행복한 하루 보내세요.

이 강의만 자료가 ppt네요.

테디베어님 안녕하세요.설계원칙편에서 다시 만나뵈니 반갑네요. 🙂&nbsp;테디베어님이 주신 질문의 핵심은 화면에 출력할 문구를 구성하는 책임을 Player로 옮기는게 맞는가로 요약할 수 있습니다.예제 코드에서는 Game이 다음과 같이 Player로부터 정보를 얻은 후 문구를 구성하고 있습니다.<pre><code class="language-java">public class Game {
 private Player player;
 private CommandParser commandParser;
 private boolean running;
 
 private void showGreetings() {
 System.out.println("환영합니다!");
 }

 private void showHelp() {
 System.out.println("다음 명령어를 사용할 수 있습니다.");
 System.out.println("go {north|east|south|west} - 이동, look - 보기, help - 도움말, quit - 게임 종료");
 }

 private void farewell() {
 System.out.println("\\n게임을 종료합니다.");
 }
 
 public void showRoom() {
 System.out.println("당신은 [" + player.currentRoom().name() + "]에 있습니다.");
 System.out.println(player.currentRoom().description());
 }
 ...
}
</code></pre>코드를 보시면 화면에 출력할 문구를 구성하는 책임을 Game 클래스가 담당하고 있다는 사실을 알 수 있습니다.나머지 클래스들은 화면에 출력할 문구를 조합하는데 필요한 데이터를 제공하는 책임을 담당하고 있습니다.&nbsp;이렇게 두 가지 책임을 분리한 이유는 화면에 출력할 문구를 변경하는 것은 Player가 담당하는 로직과 상관없이 변경될 수 있기 때문입니다.즉, 변경의 이유가 다르기 때문입니다.&nbsp;이를 관심사의 분리라고도 부르는데 화면에 출력할 문구는 UI와 관련된 관심사에 해당하고, Player의 로직은 게임과 관련된 도메인 관심사에 해당하기 때문입니다.따라서 UI의 변경으로 화면에 출력될 문구를 변경하고 싶은 경우에는 Player나 다른 객체들은 수정하지 않고 Game 클래스만 수정할 수 있도록 변경의 범위를 제한한 것으로 생각해 주시면 됩니다.&nbsp;실무에서 어떤 객체를 데이터베이스에 저장하거나 조회하는 로직을 객체가 아니라 별도의 Repository나 DAO에 구현하는 경우와 유사하다고 생각하시면 될 것 같아요.예를 들어 Customer를 데이터베이스에 저장할 때 Customer의 필드를 이용해서 데이터베이스에 저장하지만 관심사 측면에서는 다르기 때문에 별도의 객체를 이용해서 객체의 데이터를 저장하는 방식을 떠올리시면 이해가 되실거에요.이렇게 객체 단위의 응집도를 낮추고 캡슐화를 약화시키는 대신 시스템 전체 관점에서 응집도를 높이는 기법이 자주 사용됩니다.&nbsp;답변이 되었는지 모르겠네요.감사합니다. 🙂

Game, Player, Room간의 관계에 대한 질문을 드려요

테디베어님 안녕하세요좋은 질문 남겨 주셔서 감사합니다. 🙂Movie의 calculateFee 메서드와 DiscountPolicy의 getDiscountAmount 메서드는 서로 다른 이유로 Screening 객체에 의존하고 있습니다.&nbsp;1. Movie 클래스가 Screening에 의존하는 이유말씀하신 것처럼 이 경우는 DiscountPolicy가 금액을 계산하기 위해 Screening의 데이터가 필요하기 때문에 이 데이터를 전달하기 위해 의존성이 필요합니다.만약 이 파라미터를 끊고 싶다면 아래와 같이 양방향 연관관계를 추가하는 방법이 있습니다.아래 코드를 보시면 DiscountPolicy에 Movie에 대한 참조를 추가해서DiscountPolicy가 직접 Movie를 통해 Screening에 접근하고 있습니다.<pre><code class="language-java">public class Screening {
 private Movie movie;
}

public class Movie {
 private Money fee;
 private DiscountPolicy discountPolicy;
 **private Screening screening;
 
 public void calculateDiscount() {
 fee.minus(discountPolicy.calculateDiscount());
 }** 
}

public class DiscountPolicy {
 private DiscountPolicy policy;
 **private Movie movie; // Movie 참조 추가**

 public Money calculateDiscount() {
 for (DiscountCondition each : conditions) {
 if (each.isSatisfiedBy(**movie.getScreening()**)) {
 return getDiscountAmount(**movie.getScreening()**);
 }
 }

 return Money.ZERO;
 }

 abstract protected Money getDiscountAmount(Screening screening);
}

</code></pre>이렇게 하면 Screening을 메서드의 파라미터로 전달할 필요가 없어지지만 아래 그림처럼 양방향 의존성이 추가되어 결합도가 높아집니다.&nbsp;<img src="https://cdn.inflearn.com/public/files/posts/ae3ed220-52d5-4f71-9dbd-6a8e07f90dbc/7b3df07c-56f8-401a-8264-11fac5361113.png" media-type="img" alt="image.png" title="image.png" width="643" height="39">&nbsp;이렇게 바꾸더라도 여전히 Movie는 인스턴스 변수로 Screening을 포함하기 때문에 Movie에서 Screening에 대한 의존성을 제거할 수도 없습니다.여기에서는 DiscountPolicy로 Screening을 전달해야하기 때문에 Movie에서 Screening으로의 의존성을 제거할 수는 없습니다.대신 가장 결합도가 낮은 방식인 메서드 파리미터로 Screening을 전달하는 방식을 선택한 것입니다.Screening 대신 값 객체를 전달해서 Screening에 대한 의존성을 완전히 제거하는 방법이 궁금하시면 아래 질문을 참조해 주시면 감사하겠습니다. 🙂<a target="_blank" rel="noopener noreferrer nofollow" href="https://inf.run/kqT92">https://inf.run/kqT92</a>&nbsp;2. DiscountPolicy의 getDiscountAmount 메서드가 Screening에 의존하는 이유getDiscountAmount 메서드는 자식 클래스들이 가격을 계산하기 위해 공통으로 의존하게 되는 메서드의 시그니처를 정의합니다.이 경우에는 상속 계층에 속한 모든 자식 클래스들이 동일한 메서드를 오버라이딩해야 하기 때문에 다른 자식 클래스에서 필요하지 않더라도 특정한 자식 클래스가 필요로 한다면 동일한 객체를 전달할 수 밖에 없습니다.이런 이유로 Screening을 전달한 것이죠.위에서 링크로 달아놓은 값 객체를 전달하는 예제의 경우에는 getDiscountAmount 메서드에 Screening 대신 값 객체를 전달할거에요.그런데 질문을 받고 코드를 보니 Screening대신 Movie를 전달하는게 결합도 측면에서 더 좋았을 것 같네요. 😂&nbsp;답변이 되었는지 모르겠네요.또 궁금한 부분 있으면 추가로 질문 남겨주시면 답변 드리겠습니다.

DiscountPolicy의 구현체에 관련 질문 드려요!

테디베어님 안녕하세요.강의 자료를 보니 말씀하신 것처럼 findDiscountCondition 메서드의 가시성은 public으로 수정하는게 맞습니다.장표를 만들면서 실수로 그 부분까지는 확인을 못하고 넘어간 것 같네요. 혹시 코드가 이상하다면 github에 올라가 있는 코드와 비교해 보시면 좋아요. 🙂 <a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/eternity-oop/object-basic-02-04/blob/main/src/main/java/org/eternity/reservation/domain/DiscountPolicy.java">https://github.com/eternity-oop/object-basic-02-04/blob/main/src/main/java/org/eternity/reservation/domain/DiscountPolicy.java</a> 동영상 부분이 수정하기 어려워서 고민인데 이렇게 질문 남겨 주시면 나중에라도 한번 모아서 오류 있는 부분을 수정하도록 하겠습니다.&nbsp;꼼꼼하게 봐주셔서 감사합니다!

강의 자료 관련 질문입니다! (2-4. 절차에서 객체로)

테디베어님 안녕하세요. 죄송하지만 질문 내용을 제가 정확하게 이해할 수 없어서 정확한 답변을 드리기 위해 몇 가지 질문을 드려야 할 것 같습니다.&nbsp;Q1. "영화 관람료"라는 객체를 추가하고 상영 객체가 의존한다고 하셨는데 구체적으로 영화 관람료가 맡은 책임은 무엇이고, 상영이 영화 관람료에 어떤 방식으로 의존(또는 협력)하는 것일까요? 이 부분을 이해해야만 답변을 드릴 수 있는데 의사 코드 수준으로라도 적어주시면 이해하는데 도움이 될 것 같아요.&nbsp;Q2. "영화 관람료"를 추가해서 상영이 할인 정책과 협력하면 지금 방식보다 어떤 점이 개선된다고 생각하시나요? 이 방식이 현실과 더 밀접하다고 하셨는데 어떤 점에서 그런지도 적어 주시면 좋겠습니다.&nbsp;위 내용을 적어주시면 적어주신 내용 기반으로 정확한 답변을 드릴 수 있을것 같아요! 🙂

도메인 관련 질문이 있습니다!

mint.inhrdev님 안녕하세요.&nbsp;다음 질문과 중복되어 답변 대신 링크로 대신합니다.<a target="_blank" rel="noopener noreferrer nofollow" href="https://inf.run/41yfx">https://inf.run/41yfx</a>&nbsp;답변 내용을 보시면 궁금하신 부분에 대해 명확하게 이해하실 수 있으실거에요. 🙂&nbsp;질문 남겨 주셔서 감사하고 해당 답변을 읽으신 후에도 궁금한 부분이 있으면 추가로 질문 남겨주세요.&nbsp;감사합니다!

6-2 보호 로직 중복 이슈

mint.inhrdev님 안녕하세요.좋은 질문 남겨주셔서 감사합니다.&nbsp;먼저 SRP라는 용어는 메서드가 아니라 클래스 또는 모듈 단위에서 사용하는 용어입니다.메서드 수준에서는 단순히 응집도라는 개념을 사용하고 SRP라는 용어를 사용하지 않습니다.기본적으로 SRP에서 말하는 개념과도 상관이 없고 강의에서도 조합 메서드 패턴이라고 표현하고 SRP라는 용어는 사용하지 않고 있습니다.&nbsp;조합 메서드로 리팩터링할 때 변경을 고민하기도 하지만 변경만이 메서드를 나누는 절대적인 기준은 아닙니다.강의에서도 설명드렸던 것처럼 조합 메서드의 목적은 추상화를 동일한 수준으로 맞춰서 읽고 이해하기 쉽도록 만드는 것이기 때문에 주된 목적은 가독성을 향상시키는 것입나다.따라서 질문을 SRP vs 가독성이라는 표현 대신 가독성을 향상시키기 위해 메서드를 얼마나 작게 나누는게 적절한가로 바꿔서 표현하는게 좋겠습니다.&nbsp;먼저 질문에서 말씀하신 아래 코드는 “입력 파싱”이 아니라 공백을 기준으로 “토큰을 분리”하는 작업이라는 점을 짚고 넘어가야 할 것 같아요.<pre><code class="language-java">input().toLowerCase().trim().split("\\\\s+");
</code></pre>실제로 입력을 파싱하는 로직은 parseCommand() 메서드에서 처리하고 있습니다.<pre><code class="language-java">private void parseCommand(String input) {
 String[] commands = input.toLowerCase().trim().split("\\\\s+");
 switch (commands[0]) {
 case "go" -> {
 switch (commands[1]) {
 case "north" -> moveNorth();
 case "south" -> moveSouth();
 case "east" -> moveEast();
 case "west" -> moveWest();
 default -> showUnknownCommand();
 }
 }
 case "look" -> showRoom();
 case "help" -> showHelp();
 case "quit" -> stop();
 default -> showUnknownCommand();
 }
}
</code></pre>이제 질문은 위 코드를 아래처럼 변경하는게 parseCommand() 메서드 내부의 추상화 수준을 일관성 있게 만드는데 도움이 되느냐가 될겁니다.<pre><code class="language-java">private void parseCommand(String input) {
 String[] commands = tokenize(input);
 switch (commands[0]) {
 case "go" -> {
 switch (commands[1]) {
 case "north" -> moveNorth();
 case "south" -> moveSouth();
 case "east" -> moveEast();
 case "west" -> moveWest();
 default -> showUnknownCommand();
 }
 }
 case "look" -> showRoom();
 case "help" -> showHelp();
 case "quit" -> stop();
 default -> showUnknownCommand();
 }
}

private String[] tokenize(String input) {
 return input.toLowerCase().trim().split("\\\\s+");
}
</code></pre>아래 메서드가 전체적인 추상화 수준에서 일관성이 있어서 코드를 이해하기 쉽게 만든다고 판단된다면 두번째 코드처럼 분리하고, 해당 로직이 분리할 정도로 복잡하지 않거나 분리할 정도로 중요한 부분이 아니라면 그대로 두면 됩니다.제 개인적으로는 배열을 공백으로 분리하는 작업이 별도의 메서드로 분리할 정도로 중요하지 않고 parseCommand 자체가 switch 문을 이용해서 배열을 파싱하는 전체적으로 추상화 수준이 낮은 코드이기 때문에 메서드 전체의 추상화 수준에서는 이 상태로 둬도 괜찮다고 판단했습니다.만약 이 메서드를 동일한 추상화 수준으로 맞춘다면 아래 코드처럼 변경하는게 좋을겁니다.<pre><code class="language-java">private void parseCommand(String input) {
 parseTokens(tokenize(input));
}

private String[] tokenize(String input) {
 return input.toLowerCase().trim().split("\\\\s+");
}

private void parseTokens(String[] command) {
 switch (commands[0]) {
 case "go" -> {
 switch (commands[1]) {
 case "north" -> moveNorth();
 case "south" -> moveSouth();
 case "east" -> moveEast();
 case "west" -> moveWest();
 default -> showUnknownCommand();
 }
 }
 case "look" -> showRoom();
 case "help" -> showHelp();
 case "quit" -> stop();
 default -> showUnknownCommand();
 }
}
</code></pre>결과적으로 paerseCommand() 메서드를 두 개의 작은 메서드를 호출하는 메서드로 나눌 것인가, 아니면 현재의 코드를 그대로 둘 것인가의 결정인데, 저 같은 경우에는 위 코드가 이전 코드보다 그렇게 개선된 것으로 보이지 않고 오히려 너무 세분화돼 보여서 파싱 흐름을 이해하기 어렵게 만들기 때문에 그대로 뒀다고 보시면 됩니다.만약 원칙에 따라 두 개의 작은 메서드로 나누는게 코드를 이해하기에 더 좋다고 판단된다면 나누셔도 좋습니다.&nbsp;두번째로 언급하신 isRunning 메서드는 장표에 오류가 있고 코드에서는 누락되었네요.아래와 같이 isRunning() 메서드로 추출하는게 맞습니다.&nbsp;<pre><code class="language-java">private boolean isRunning() {
 return running == true;
}</code></pre>&nbsp;&nbsp;너무 많은 장표를 만들다보니 확인하지 못한 부분이 많은데 확인해 주셔서 감사합니다.이 부분은 수정해서 커밋해 놓을게요. 🙂

3-2 메서드를 얼마나 작게 나누는게 적절한가요?

동관님 안녕하세요.좋은 질문 남겨 주셔서 감사합니다. 🙂 먼저 영화와 예매는 N:M 관계가 아니라 1:N 관계입니다.어떤 관계에서 다중성(multiplicity)은 하나의 객체에 대해 연결될 수 있는 다른 객체의 개수를 나타냅니다.하나의 영화에는 여러 개의 예매가 만드어질 수 있는데 반해 예매는 하나의 영화에 대해서만 생성될 수 있기 때문에 영화:예매는 1:N 관계에 해당됩니다. 상영은 그 자체로 도메인에 존재하는 중요한 개념입니다.아래 그림에서 영화는 "어쩔수가없다"이고 아래에 예매 가능한 4개의 박스가 상영에 해당됩니다.<img src="https://cdn.inflearn.com/public/files/posts/27e2bc02-22fc-4d86-a6ce-2370312a0801/a5a2d73f-1171-402f-bd54-a724033afd4c.webp" media-type="img" alt="스크린샷 2025-10-26 오전 11.43.23.png.webp" title="스크린샷 2025-10-26 오전 11.43.23.png.webp" width="422" height="272">&nbsp;참고로 다대다 관계를 해소하기 위해 중간 테이블을 추가하는 개념은 데이터베이스 모델링의 영역에 한정되는 기법입니다.객체 관계에서는 다대다 관계가 가능하기 때문에 다대다 관계를 해소하기 위해 중간 객체를 추가할 필요가 없고 협력 관점에서 특정한 동작을 수행할 객체가 필요하거나 도메인 관점에서 명시적으로 드러내야 하는 경우에 적절한 객체를 추가하게 됩니다.&nbsp;답변이 되었는지 모르겠네요. 🙂감사합니다.

영화, 상영, 예매 도메인 관계에 대한 질문

Chanuk님 안녕하세요. 😊좋은 질문 남겨 주셔서 감사합니다.제가 아침부터 계속 강의를 하느라 이제서야 답글을 남기네요.답변이 늦어져서 죄송합니다.&nbsp;<ol><li>현실적으로 DB 스키마가 이미 정해져 있거나, 기존 데이터를 마이그레이션해야 해서 새롭게 설계하기 어려운 경우, 또는 DBA가 별도로 관리하는 환경에서는 책임주도 설계를 적용하기가 쉽지 않을 것 같습니다. 이런 상황에서도 객체지향적인 설계를 현실적으로 적용할 수 있는 방법이 있을까요? (DAO를 중간 계층으로 두면 어느 정도 해결될까요? 아니면 도메인 레이어와 퍼시스턴스 레이어는 분리된 영역이니 크게 상관없을까요? 반대로, 두 레이어가 지나치게 달라지면 오히려 유지보수가 더 어려워지지는 않을까 하는 걱정도 듭니다.) 근본적으로 DB 설계와 객체지향 설계는 접근방식과 목적이 다르기 때문에 신규 프로젝트라고 하더라도 두 구조 사이에 차이가 발생할 수 밖에 없습니다.이런 차이를 임피던스 불일치(impedance mismatch) 문제라고 부르는데 DB는 데이터 관점에서 중복을 최소화하는 방향으로 설계해야 하고 객체지향 설계는 강의에서 설명드렸던 것처럼 행동 관점에서 안정적인 구조를 만드는 것을 목적으로 하기 때문입니다. 임피던스 불일치 문제를 해결할 목적으로 만들어진 도구를 ORM(Object Relational Mapping)이라고 부릅니다. Java 진영의 JPA 표준과 Hibernate 구현체가 ORM의 대표적인 예라고 할 수 있습니다. ORM을 사용하면 직접 쿼리를 작성할 필요 없이 어느 정도 DB와 클래스 사이의 차이점을 상쇄시킬 수 있습니다. 물론 ORM은 만능이 아니기 때문에 모든 이슈를 다 해결해 주지는 못합니다. 따라서 실용적인 관점에서 완전한 객체지향 설계를 하려고 하시기 보다는 질문에서 언급하신 것처럼 매핑이 좀 더 수월한 방식으로 객체 구조를 선택하실 필요가 있습니다. ORM을 사용하는 경우에도 해결하기가 수월하지 않은 경우가 있는데 말씀하신 것처럼 레거시 테이블이 정규화가 안된 상태로 장기간 유지된 경우가 여기에 해당합니다. 이렇게 극단적으로 매핑이 어렵지만 객체지향 설계 방식을 선태하시는게 장점이 크다고 판단되시면 테이블과 1:1로 매핑되는 데이터 용 클래스를 만들어서 데이터베이스에서는 이 데이터용 클래스를 이용해서 데이터를 조회하신 후 객체 구조로 다시 매핑하는 방법도 있습니다. 이 방식은 테이블 스키마에 얽매이지 않고 객체지향 설계를 자유롭게 할 수 있다는 장점이 있지만 데이터용 클래스와 객체를 위한 클래스를 함께 유지해야 한다는 단점도 존재합니다. 문제의 복잡도와 유지보수 관점에서의 장단점을 기반으로 적합한 방법을 선택하시면 될 것 같아요. &nbsp;</li><li>그리고, 책임주도 설계가 이론적으로는 유지보수에 강하다고 하지만, 실제로는 아직 구조가 다소 복잡하게 느껴져서 오히려 유지보수성을 해칠 수도 있지 않을까 합니다. 이런 복잡함은 설계 패턴에 익숙해지면 자연스럽게 해소될까요? 말씀하신 것처럼 객체지향 설계에 대해 아직 익숙하지 않다보니 복잡하고 어렵게 느끼시는게 아닐까 싶어요. 절차적인 설계에서 객체지향 설계로 이동하는 상황을 패러다임 전환(paradigm shift)라고 부를 정도로 절차적인 사고방식을 객체지향적인 사고방식으로 바꾸는 일은 매우 어렵고 힘든 일이기는 합니다(저도 겪었던 문제구요). 절차적인 방식은 새로운 코드를 작성하거나 코드를 읽을 때는 객체지향보다 쉽게 느껴집니다. 반면에 객체지향은 기존 코드에서 수정할 부분을 찾거나 코드를 수정할 때 절차적인 방식보다 더 쉽게 느껴집니다. 다시 말해서 절차적인 방식은 새로운 코드를 작성할 때는 유리하지만 유지보수의 측면에서는 좋지 않고, 객체지향은 새로운 코드를 작성할 때는 불리하지만 유지보수 측면에서는 유리하다고 볼 수 있습니다. 제 생각에 객체지향이 복잡하다고 느끼시는 이유는 처음 코드를 작성할 때 들어가는 노력이 절차적인 방식보다 더 크기 때문이 아닐까 싶어요. 유지보수 단계에서의 장점을 이해하기 위해서는 실제로 변경이 일어날 때 코드를 수정해본 경험이 필요하기 때문에 객체지향에 익숙해지시고 요구사항 변경이 빈번하게 발생하는 상황에서 코드를 수정하는 경험이 쌓이면 유지보수 측면에서 객체지향이 유리한 이유를 이해하시게 될거라고 생각합니다.</li></ol> 답변이 되었는지 모르겠네요. 🙂행복한 주말 보내세요!

eternity

投稿