[SOLID원칙] 문제 만들기

Q1. 옳은 말을 한 학생을 고르시오.

남규: 합성 대신에 상속 방식을 사용하자. 서로 연결되니 수정을 하거나 틀린 것을 찾기 쉬울거야.

나경: 응집도는 낮추고 결합도를 높이는 것이 SOLID 원칙의 목적이랬어.

채빈: 필요한 객체를 해당 클래스에서 직접 만들어 사용하는 것이 DI/IOC 원칙의 핵심이야.

윤하: 너희들은 모두 틀렸어.

 

A1.

답: 윤하

해설: 친구들의 말 옳게 고치기

• 남규: 상속(IS-A) 방식 대신 합성(HAS-A) 방식을 사용해야 한다. 상속 방식은 자식 클래스가 부모 클래스의 변수와 메소드를 물려받게 되어 강한 결합을 유발한다. 만약 상위 클래스가 수정되면 하위 클래스에게도 영향이 가기 때문에 잘못된 부분을 찾기 어렵고 수정이 어려워진다. 반면에 합성 방식은 계층적으로 연결되는 대신(상속 방식 대신) 다른 클래스의 객체를 자신의 변수로 포함하는 방식으로, "A는 B를 가지고 있다, 사용한다"라고 표현한다. 약한 결합이므로 서로 미치는 영향이 적어 수정에도 용이하다. 
• 나경: SOLID 원칙은 응집도는 높이고 결합도를 낮추는 것을 목표로 한다. 여기서 응집도란, 동일 종류만을 모아놓는 특성을 말하고, 결합도란 클래스들 간 분리가 어려운 정도를 말한다. 따라서 단일 책임 원칙과 인터페이스 분리 원칙으로 응집도를 높이고, 상속 방식 대신 합성 방식의 "객체 외부 주입"을 권장하는 DI/IoC 원칙을 준수하도록 해서 결합도를 낮추는 것이 SOLID 원칙의 핵심이다.
• 채빈: DI/IoC 원칙이란 객체의 생성을 외부에 맡겨서 주입받는 것을 말한다. HAS-A, 주입, 사용하는 방식을 쓰는 것이다. 

//상속방식
public class MyWin extends JFrame{
	//...
   	public MyWin(){
    	this.setSize(500, 300);
        this.add(b1);
   	//...

-extends JFrame했다. JFrame에 문제가 생길 경우 MyWin까지 영향을 받는다.

-this. 만으로 상위의 메소드를 불러올 수 있다는 간편함은 있지만 하위클래스가 너무 영향을 많이 받게 된다.

//합성 방식
public class MyWin{//extends가 아니다.
	private JFrame view; //JFrame 객체를 외부로부터 전달받고
    //...
    public MyWin(JFrame frame){//생성자로 "주입"받아서 사용하기만 한다.
    	this.view = frame;
        //...

-객체를 외부로부터 전달받아 생성자로 주입받는다.

-주입 받은 걸 사용하기만 하므로 결합도가 낮아진다.

 

 

 

---

 

 

Q2. 아래의 방식이 SOLID 원칙을 만족한다고 보는가? 만약 그렇다면 어떤 원칙을 만족하는지 설명하고, 그렇지 않다면 코드를 바꿔보고 어떤 원칙에 맞춘 것인지를 설명하시오.

public class DepartmentManagement {
	
	public void manage(String departmentType) {
		if("ComputerEngineering".equals(departmentType)) {
			
		}
		else if("CyberSecurity".equals(departmentType)){
			
		}
	}
}

 

A2.

위 코드는 SOLID 원칙을 만족하지 않았다. 특히 Open-Closed 원칙(개방-폐쇄 원칙)을 준수하지 않은 코드이다. 이 원칙은 확장에 대해 개방적이어야 하고, 수정에는 폐쇄적인 원칙이다. 하지만 현재의 코드는 새로운 학과가 추가될 때마다, 기존의 DepartmentManagement 클래스의 if-else 블록을 수정해야 한다. 고로 확장에 폐쇄적이면서, 수정을 적극적으로 해야하는 식이 되어버렸다. 이는 개방-폐쇄 원칙에 아예 반대된다. 새로운 학과가 추가될 때마다 기존의 코드를 수정해야 한다. 따라서 아래의 클래스 다이어그램처럼 고쳐야한다.

 

public interface DepartmentManagement {
	void manage();
}
---------------------------------------------
public class ComputerScience implements DepartmentManagement {
	public void manage(){
    	System.out.println("컴퓨터 공학과의 커리큘럼 관리");
        }
}
---------------------------------------------
public class CyberSecurity implements DepartmentManagement {
	public void manage(){
    	System.out.println("사이버 보안과의 커리큘럼 관리");
        }
}

이렇게 인터페이스를 implements하게 되면 학과를 새로 추가할 때마다 DepartmentManagement 인터페이스를 물려받는 클래스를 새롭게 추가하면 되므로 기존 코드를 해치지 않고 추가할 수 있게 된다.

 

 

---

 

 

Q3. 다음 문장이 SOLID 원칙을 만족하면 O, 아니면 X를 고르시오.

 

커피메이커 코드에서 가격을 출력하는 기능을 추가하고 싶다. Coffee 인터페이스의 하위클래스들 각각에 가격이 매겨져야 하므로 공통의 상위 역할인 Coffee 인터페이스에 getPrice() 메소드를 추가하면 된다. 

 

 

A3.

X이다. Interface-Segregation 인터페이스 분리 원칙에 따라 인터페이스에는 하나의 기능만 있는 것이 좋다. 또한 Single Responsibility 단일 책임 원칙 측면에서도 옳지 않다. 음료를 준비하는 prepare() 제조 책임과 가격을 나타내는 getPrice() 가격 책임이 한 인터페이스 안에 있으면 가격이 변경될 때에도 레시피가 들어 있는 Latte 클래스를 수정해야 한다. 그러니 GetPrice 인터페이스를 추가하여 가격을 따로 관리하는 것이 좋다.