p.50 Q1. SimUDuck에 로켓 추가하기

[picaqwe104]

해당 문제에서는 "Fly"라는 동작을 인터페이스로 분리하고, 해당 인터페이스를 상속하는 또다른 Fly 인터페이스들을 작성하고 있음.
그 상태에서 Rocket을 통해 나는 방법도 새로 클래스를 만들면 된다고 나와있지만, 다음과 같은 경우는 어떻게 하는가 의문이 생겼기에 공유.

상상도는 다음과 같음

이를 p.50까지의 방법을 생각하면 다음과 같이 된다고 예상.

허나 오리로서도 날고 싶고 로켓으로도 날고 싶은 오리는 "fly()"가 충돌하지 않는가?

디스커션 기능을 익힐 겸, 첫 글도 적어볼 겸 작성.

[picaqwe104]

조금 더 구체화시켜서 생각하자면 다음과 같은 의문들이 있었음.

1. 애초에 문제점으로 인터페이스는 다중 상속이 가능하지만, 구현 클래스는 하나밖에 상속받지 못함.
   -> Rocket과 CuteDuck를 RocketCuteDuck가 같이 상속받을 수 없음.
2. 그렇다면 결과적으로 한 쪽만 상속을 받고, 나머지 fly기능은 따로 직접 구현해야 하는가?
3. 게임 개발 엔진등이라면 객체 자체를 따로 두고, 각각이 움직이도록 만들 수 있을텐데 자바에서 같은 식으로 구현하려면 어떻게 해야할까?

등등을 생각했지만 다음 페이지에 어느정도 정답이 나와주긴 함...

[gulddaggi]

일단 위의 다이어그램처럼 구현을 어떻게 할 수 있을지 생각하면서 아래 코드를 작성해봤습니다.

package test;

interface FlyBehavior {
	void fly();
}

interface RocketFlyBehavior extends FlyBehavior{
	public default void fly() {
		System.out.println("로켓으로 날기");
	}
}

interface NormalFlyBehavior extends FlyBehavior{
	
}

class Duck{
	String name;
	void swim() {
		
	}
}

class CuteDuck extends Duck implements NormalFlyBehavior{

	@Override
	public void fly() {
		System.out.println("귀여운 오리의 날기");
	}
	
}

class RocketDuck implements RocketFlyBehavior {

	@Override
	public void fly() {
		System.out.println("로켓으로 날기");
	}
	
}

class RocketCuteDuck extends CuteDuck implements RocketFlyBehavior {
	
}

public class test {
	public static void main(String[] args) {
		RocketCuteDuck rcd = new RocketCuteDuck();
		rcd.fly();
		
		// 출력 결과 : 귀여운 오리의 날기
	}
}

그리고 출력 결과로는 상속 클래스의 fly()가 호출되었습니다. 이와 관련해서 이해가 어렵다면 여기 를 참고해보시면 될 것 같아요. 요약하자면, 클래스가 인터페이스보다 상속의 우선순위가 높아 클래스의 메서드가 호출된다고 합니다.

결국 이렇게 구현하게 되면 2번의 우려하던 상황이 발생하게 되는데, 저는 여기서 문제를 해결하기 위해 두 가지 관점으로 접근해보았습니다.

1. RocketCuteDuck이 CuteDuck 과 is-a관계인가?
   두 객체를 연관이 없는 별개의 객체로 볼 것인가에 대한 접근입니다. 만약 공통되는 성질이 있어 RocketCuteDuck이 CuteDuck에 속하게 된다면, 즉 프로그래밍 관점에서 cute()와 같이 오버라이딩이 가능한 메서드가 존재한다면 is-a 관계로 구성이 가능할 수 있습니다. 하지만 그렇지 않다면 둘을 Duck을 슈퍼클래스로 갖고 각각의 Behavior 인터페이스를 보유한 클래스들로 구성하여 문제를 해결할 수 있을 것입니다.

2. Rocket은 Duck과 has-a관계인 클래스가 아닌가?
   Rocket을 Duck이 보유할 수 있는 클래스로 변경할 것인가에 대한 접근입니다. 바로 위 1에서 RocketCuteDuck과 CuteDuck이 is-a 관계를 가져 상속을 해야겠다면, Rocket을 클래스로 구현하고 Duck의 멤버로서 존재하도록 구성한다면 문제를 해결할 수 있을 것입니다. 단순하게는 boolean 타입 변수로 체크를 해주는 방법도 있겠지만, 확장성을 고려한다면 이러한 방식이 더욱 효과적일 수 있을 것이라 생각해요.

결국 책의 뒷부분에 나오는 것처럼 오리의 나는 행동을 동적으로 관리할 수 있게 된다면, 그냥 난다 or 로켓으로 난다 처럼 여러 동작 중 하나를 선택하는 구현이 가능하게 되니 제일 나은 정답이라고 생각합니다 ㅋㅋ... 하지만 그걸 배재하고 고민한다면 저는 위의 두가지 접근을 시도하지 않을까 싶어요!

[picaqwe104]

시험 코드와 링크 감사합니다. 글을 읽으며 슈퍼 클래스와 인터페이스 간의 우선순위가 있는 것에 대해서는 이렇게 이해할 수도 있지 않을까 생각했습니다.
클래스는 객체를 구성할 수 있는 요소, 뿌리같은 느낌이고 인터페이스는 어디까지나 기능이라는 느낌입니다.
즉, 귀여운 로켓을 단 오리를 설명할 때, "오리다!" 라고 하는 것과 "로켓달고 날 수 있는 것이다!" 라고 하는 것 중 어느쪽이 근본에 가깝냐하면, 오리다! 라고 하는 쪽이겠죠.

더불어, 게임적인 관점에서 생각하면 객체와 객체는 일반적으로 합체가 아닌, 별도로 존재하는 장비 느낌이라고 생각하면 될 것 같네요.

막상 구현 시도해보려고 하니까 쉽지 않네요.
ex) Duck는 Flyable을 상속받지 않고, CuteDuck이 날 수 있는 기능을 상속받았더니 Duck cuteDuck = new CuteDuck(); 로 만든 오리가 날 수 없는 상황이 발생...!!! 이러면 다형성을 유지할 수 없게 된다...

생각보다 간단한 부분부터 막히니 머리가 어질어질.

[mini9922g]

오리로서도 날고 싶고, 로켓으로도 날고 싶은 오리.

하지만 자바는 다중 상속을 지원하지 않기 때문에, 두 클래스를 동시에 상속받을 수는 없었다.
하나를 상속받고, 다른 하나를 인터페이스로 구현하는 방식에 대해서는 재성이가 이미 잘 설명해주었기 때문에 여기서는 생략한다.

그렇다면 둘 다 인터페이스로 구현하면 어떨까?
FlyBehavior를 상속받은 DuckFly 인터페이스와 RocketFly 인터페이스를 만들어 사용한다고 하면, 결국 두 인터페이스 모두 fly()라는 동일한 시그니처의 메서드를 가지게 된다.
[Java] 자바의 다중상속 (feat. 인터페이스와 추상클래스) 글을 참고하면, 인터페이스가 동일한 메서드를 가지고 있을 때 구현 클래스에서 이를 한 번만 오버라이딩해도 충돌 없이 정상적으로 동작함을 확인할 수 있다.

그런데 이렇게 되면 결국 한 시점에 하나의 fly() 동작만 가질 수 있게 된다.
즉, 로켓으로 날거나, 오리로서 날거나, 혹은 오리로켓으로서 날거나 중에서 하나만 선택할 수 있는 구조가 된다.

그래서 이 상황을 어떻게 해결할 수 있을까 고민해봤는데, 크게 두 가지 방식이 있다고 생각했다.
1. DuckFly, RocketFly의 공통 조상인 FlyBehavior를 타입으로 가지는 필드를 하나 두고, 메서드를 통해 비행 전략을 변경하는 방식
이 방식은 전략 패턴에 기반한 것으로, 예를 들어 duck.setFlyBehavior(new RocketFly())처럼 동적으로 비행 방식을 바꿀 수 있다.
하지만 이 방식의 한계는 결국 한 시점에 하나의 상태만 유지할 수 있다는 점이다.
즉, 오리는 로켓으로 날 수도 있고, 오리로서 날 수도 있지만 동시에 두 상태를 함께 가지는 것은 불가능하다.
2. DuckFly와 RocketFly를 각각 필드로 두는 방식
이 경우 오리가 두 개의 비행 전략을 동시에 가질 수 있게 된다.
하지만 비행 방식이 추가될 때마다 새로운 필드를 추가해야 하므로 유지보수나 확장성 측면에서 불리하다.
이를 해결하기 위해 리스트나 배열 등의 컬렉션으로 비행 전략을 관리할 수도 있지만, 이 경우 인덱스나 키를 통해 접근해야 하므로 직관성이 떨어질 수 있다는 문제점이 있다.

결국 여러 개의 상태를 동시에 가지고 날 수 있어야 한다면, 가장 간단하게는 필드를 계속 추가하는 방식이 있고,
또 다른 방법으로는 “로켓으로 날다”라는 행위를 아예 로켓 클래스로 분리하고, 오리가 그 로켓을 “가지고 있는” 방식으로 구성하는 것도 있다.
이렇게 하면 로켓과 오리의 책임이 분리되며, “날다”라는 행위 자체의 책임도 명확히 분리된다.
확장성과 유연성을 고려하면, 이처럼 행위의 책임을 적절히 나누는 방식이 더 나은 선택이 될 수 있다고 생각했다.

반면, 하나의 상태만 가지면 충분한 경우라면, FlyBehavior를 타입으로 하는 필드를 하나 두고, setFlyBehavior()를 통해 전략을 교체하는 방식이 가장 단순하고 효과적인 접근이라고 생각한다.

제 생각을 적었던걸 GPT쌤으로 흐름만 잡았습니다!

[picaqwe104]

실제 게임이라고 생각했을 때를 기준으로 생각해도 비슷한 접근법이 가능하다고 생각합니다.
게임에서는 행동을 취하기 위해서는 그에 따른 조작이 필요하고, 일반적으로 "난다" 라는 행위는 스페이스바를 빠르게 두 번 입력하는 등의 조작을 받습니다.
여기서 로켓을 "가지고 있는" 방식으로 구현하여, 로켓이 날도록 한다면 로켓에는 다른 조작 (f키를 누르면 로켓이 작동하여 날라간다 등)을 연결시켜 두거나, 로켓을 장착하는 방식으로 하는(이는 스터디 모임때 나왔던 얘기기도 합니다) 방법이 있다고 생각합니다. 결과적으로 책임은 분리되어 있을 것입니다.

여기까지 생각하게 되면 시스템으로의 효율성이냐, 유저 인터페이스의 최적화냐 까지 연결될 것 같긴 하네요...
개발의 모든 것은 유기적으로 연결되어 있다?!?!?!?

[Hyochang098]

1. 앞에서 배운 전략패턴의 유연성에 대해 생각한다면 자연스러운 상태의 코드라고 생각합니다.
   전략패턴은 코드의 재사용성을 보장해주는 상속과 인터페이스의 아쉬운 부분이였던 유연성을 보완하고 기존 설계 원칙인 OCP를 지키게 해주는 패턴입니다.
   앞 페이지에서 나오던 set메서드 사용해 필요한 순간에 적절하게 바꾸어준다면 전략패턴이 매우 잘 적용된 구조라고 생각한다.
   그러나, 1번의 경우에는 인터페이스의 기능을 제대로하지 못할 수 있다는 요소가 생기게됩니다(=인터페이스자체가 무엇을 하려는지 알 수 없음). 설계원칙인 LSP를 위반하게 될 수 있다

2. 로켓이라는 다른 객체를 만들고 그 로켓을 포함하고 있는 클래스를 하나 만드는 것입니다.
   전략패턴의 유연성에 대해 얘기하는 부분에서는 거리가 멀어지지만, 확실하게 로켓오리라는 존재가 명확하게 생성되기 때문에 더 명확한 객체(=나는 방식이 다른 오리가 아닌 특수오리)가 된다고 생각합니다.
   아까 위에서 언급한 코드를 보고 어떤 기능을 하는지 모르는 문제를 극복할 수 있다(명확하게 어떤 날기를 할지 알 수 있음)

1번이나 2번 중 옳은 방법이 있다고 생각하기 보다는 1번은 유연한 상황, 2번은 특수개체가 중요한 상황에서 사용되는 것이 적절하다고 생각됩니다.

[ChoMinGi]

1번의 경우에는 인터페이스의 기능을 제대로하지 못할 수 있다는 요소가 생기게됩니다(=인터페이스자체가 무엇을 하려는지 알 수 없음). 설계원칙인 LSP를 위반하게 될 수 있다

좀더 첨언하자면

LSP는 클라이언트가 부모 타입만 보고도, 하위 타입이 동일하게 작동할 것이라는 신뢰를 전제로 한다고 합니다.
따라서 전략 패턴에서 다양한 구현체가 같은 메서드를 제공할때, 그 메서드 명에 맞는 올바른 행위를 제공하지 않을때 (우리의 예시로는 fly()를 하지만 날지 않는 경우) 신뢰가 깨지기 때문에 이를 고려하는 내용이라고 봐도 좋을것 같습니다.