소웨공 6장

클래스 설계 원칙

단일 책임 원칙 Single-Responsibility Principle

클래스 변경 이유는 단 하나여야 한다.

개방 폐쇄 원칙 Open-Closed Principle

변경에는 닫혀 있어야 하고, 확장에는 열려 있어야 한다

계속해서 바뀌는 것들을 상속 구조로 만든다.

• 변경에 닫혀 있는 설계 : 파일 형식이 추가 되어도 Video_Player 클래스를 수정할 필요가 없다.
• 확장에 열려 있는 설계 : 파일 형식이 추가되어도 오른쪽 상속 구조로 추가하면 된다. (하위 클래스를 만든다)

리스코프 교체 원칙 Liskov Substitution Principle

상위 클래스의 객체는 언제나 자신의 하위 클래스의 객체로 교체할 수 있어야 한다.

LSP는 상속과 재정의의 중요성을 강조한다.
-> 재정의는 상위 클래스의 메서드가 추상 메서드일 경우만 사용한다.

• 피터 코드의 상속 규칙 : 하위 클래스는 상위 클래스의 책임을 무시하거나 재정의하지 않고 확장만 수행한다.

public abstract class Lecturer {
	public Lecturer() {
    	System.out.println("[리스코프 교체의 원칙]");
    }
    public String lecturer;
    public int charge = 70000;
    public void Lecturer(){}
}

/*LecturerNormal class*/
public class LecturerNomal extends Lecturer {
	public LecturerNomal(){
    	lecturer = "일반 강사";
    }
    public void Lecturer(){
    	System.out.println(lecturer);
        System.out.println("강사료 :" + charge + "원");
    }
}

의존 관계 역전 원칙 Dependency Inversion Principle

클라이언트는 구체 클래스가 아닌 추상 클래스에 의존해야 한다.

구체 클래스로 구현할 경우 선언~조건문까지 변경해야하기 때문에 구체 클래스에 의존하는 건 좋지 않다.
-> 추상 클래스에 의존하도록 만든다.
== 고수준 구성 요소가 저수준 구성 요소에 의존하면 안된다.

/*GameServer class*/
public class GameServer {
	public Games games;
    public void Game_Play(Games games){
    	games.Start();
    }
}

/*Games*/
public abstract class Games {
	public String title, version;
    
    public void Start() {
    	System.out.println("게임명" + title);
        System.out.println("버전 :" + version);
        System.out.println(title + "을 시작합니다.");
    }
}

/*LOL class*/
public class LOL extends Games {
	public LOL(){
    	title = returnTitle();
    	version = returnVersion();
    }
    
    public String returnTitle() { 
    	return "League of Legens";
    }
    
    public String returnVersion() {
    	return "v.2020";
    }
}

/*Racing class*/
public class Racing extends Games {
	public Racing() {
    	title = returnTitle();
        version = returnVersion();
    }
    
    public String returnTitle() {
    	return "Racing";
    }
    
    public String return Version() {
    	return "v2.3";
    }
}

/*SuperMario class*/
public class SuperMario extends Games {
	public SuperMario() {
    	title = return Title();
        version = reuturnVersion();
    }
    
    public String returnTitle() {
    	return "Super Mario";
    }
    
    public String returnVersion() {
    	return "v1.0";
    }
}

/*Tetris class*/
public class Tetris extends Games {
	public Tetris(){
    	title = returnTitle();
        version = returnVersion();
    }
    
    public String returnTitle() {
    	return "Tetris";
    }
    
    public String returnVersion() {
    	return "v1.3";
    }
}

/*Main class*/
public class Main {
	public static void main (String args[]) {
    	GameServer gameserver = new GameServer();
        gameserver.Game_Play(new SuperMario());
        gameserver.Game_Play(new Tetris());
        gameserver.Game_Play(new LOL());
        gameserver.Game_Play(new Racing());
    }
}

인터페이스 분리 원칙 Interface Segregation Principle

클라이언트는 자신이 사용하지 않는 메서드와 의존 관계를 맺으면 안된다.

vs 단일책임원칙
단일책임: 단일을 강조하고 클래스로 분리되어 메서드의 구현도 분리된다.
인터페이스분리: 인터페이스의 단일을 강조하여 인터페이스만 분리하고 구현 부분은 그대로 이다.

연습문제 (이해 안되는 문제)