천천히, 꾸준히

[ORACLE] SQL SELECT 칼럼 가로로 합쳐서 조회

연결리스트 — Wed, 17 Aug 2022 09:02:51 +0900

SELECT SUM(C1)

, SUM(C2)

, TO_CHAR(ROUND((SUM(C2) / SUM(C1)) * 100, 2), 'FM00.00') || '%'

FROM (

SELECT COUNT(DINTINCT(ACNTNO) C1

, 0 C2

FROM TABLE1

WHERE DATE BETWEEN 'TO_DATE' AND 'FROM_DATE'

UNION ALL

SELECT 0 C1,

COUNT(DISTINCT(ACNTNO) C2

FROM TABLE2

WHERE DATE BETWEEN 'TO_DATE' AND 'FROM_DATE'

)

꿀팁

<JavaScript> invalid shorthand property initializer

연결리스트 — Mon, 11 Apr 2022 10:18:19 +0900

되게 단순한 오류...

변수 설정 시 '=' 가 아닌 ':' 을 사용해 주어야 하는데

잘못 매핑을 시키기 때문에 발생하는 오류

var params = {
reportToDate = reportToDate,
orgCode = UserInfo.getOrgCode(),
userId = UserInfo.getUserId(),
batchId = 'DM020TR052TR070DM072TR110' // 가치평가 배치 목록
}

아래와 같이 수정해주면 된다.

var params = {
reportToDate : reportToDate,
orgCode : UserInfo.getOrgCode(),
userId : UserInfo.getUserId(),
batchId : 'DM020TR052TR070DM072TR110' // 가치평가 배치 목록
}

프로그래머스 - SQL1

연결리스트 — Mon, 13 Dec 2021 17:42:24 +0900

ANIMAL_INS 테이블과 ANIMAL_OUTS 테이블을 비교해

ANIMAL_INS 테이블에는 없고 ANIMAL_OUTS 테이블에만 있는 컬럼 출력

select a.animal_id, a.name
from animal_outs a
left outer join animal_ins b
on a.animal_id = b.animal_id
where a.animal_id not in (
select animal_id
from animal_ins);

풀이 방법

- left outer join을 사용해 animal_outs와 animal_ins를 join (animal_outs에는 있지만 animal_ins에는 없는

칼럼까지 모두 출력)

- not in 조건을 사용해 출력한 칼럼들과 animal_ins 테이블을 비교해 animal_ins에는 없는 칼럼들만 출력

사용 개념

- LEFT OUTER JOIN

-> OUTER JOIN은 조인 조건에서 동일한 값이 없는 행도 반환할때 사용

-> LEFT, RIGHT OUTER JOIN은 기준이 되는 테이블이 조인 수행 시 드라이빙 테이블 된다

(적은 양의 데이터를 추출하는 테이블을 드라이빙 테이블로 설정하는것이 유리)

-> SELECT * FROM table1

LEFT OUTER JOIN table2

ON table1.key = table2.key;

- NOT IN

-> 일치하지 않는 컬럼들을 출력

-> SELECT *FROM table1

WHERE table1.key NOT IN (

SELECT table2.key

FROM table2);

-> 비교 대상에 NULL 값 포함 시 UNKNOWN 값 반환 (비교 X)

(NOT EXISTS는 NULL 비교 시 NULL 반환)

정보처리기사 - 실기

연결리스트 — Thu, 31 Dec 2020 10:19:08 +0900

한 번 떨어지고 두 번만에 붙었다 ㅠㅠ

Factory Method

연결리스트 — Wed, 18 Nov 2020 22:37:48 +0900

팩토리 메서드

- 객체 생성 처리를 서브 클래스로 분리해 처리하도록 캡슐화하는 패턴

- 객체 생성 코드를 별도의 클래스/메서드로 분리함으로써 객체 생성의 변화에 대비할 수 있다.

- 특정 기능의 구현은 개별 클래스를 통해 제공되는 것이 바람직하다.

- 기능의 변경이나 선택은 해당 객체를 생성하는 코드의 변경을 초래한다.

- 상황에 따라 적절한 객체를 생성하는 코드는 자주 중복될 수 있다.

- 객체 생성 방식의 변화는 해당되는 모든 코드 부분을 변경해야 하는 문제가 발생한다.

팩토리 메서드는 다음과 같은 상황에서 사용한다

- 어떤 클래스가 자신이 생성해야하는 객체의 클래스를 예츨할 수 없을때

- 생성하는 객체를 기술하는 책임을 자신의 서브클래스가 지정했으면 할 때

- 객체 생성의 책임을 몇 개의 보조 서브클래스 가운데 하나에게 위임하고, 어떤 서브클래스가 위임자인지에 대한

정보를 최소화하고 싶을 때

Product

- 팩토리 메서드로 생성될 객체의 공통 인터페이스

ConcreteProduct

- 구체적으로 객체가 생성되는 클래스

Creator

- 팩토리 메서드를 갖는 클래스

ConcreteCreator

- 팩토리 메서드를 구현하는 클래스로, ConcreateProduct 객체를 생성

팩토리 메서드의 개념과 적용 방법

- 객체 생성을 전담하는 별도의 Factory 클래스 이용

- Strategy 패턴과 Singleton 패턴을 이용

- 상속 이용 : 하위 클래스에서 적합한 클래스의 객체를 생성

- Strategy 패턴과 Singleton 패턴, 템플릿 메서드 패턴을 이용

예시

캔디 가게의 여러가지 캔디 관리하기

- 여러 개의 캔디를 보관한다.

- 캔디 통(CandyBarbin)에 있는 캔디가 특정 수 아래로 내려가 있는 경우는 재입고한다.

- 캔디 통에는 동일한 캔디만 보관한다.

CandyBarBin 클래스

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

public class CandyBarBin {
 
    private List<CandyBar> candies = new ArrayList<>();
    private static final int LowStockLevel = 3;
    private String cbType;
 
    public CandyBarBin(String cbType){
        this.cbType = cbType;
    }
     
    public void restock(){
        if(getAmountInStock() < LowStockLevel){
               if(cbType.equals("Snickers"))
                candies.add(new Snickers());
            else if(cbType.equals("Kitkat"))
                candies.add(new Kitkat());
            else if(cbType.equals("ThreeMusketeers"))
                candies.add(new ThreeMusketeers());
        }
    }
 
    private int getAmountInStock() {
        return candies.size();
    }
}
 
Colored by Color Scripter

cs

- 캔디의 종류를 문자열로 받아온다.

- restock 메서드에서는 캔디가 특정 수 이하가 되면 받은 문자열과 일치하는 캔디의 객체를 생성한다.

- 만약 새로운 캔디 종류가 추가되거나 변경 사항이 생길 경우 restock 메서드는 영향을 받게 된다는 문제점이 생긴다.

- 즉, 위의 코드는 OCP 원칙을 만족하지 못하는 설계인 것이다.

해결 방안

CandyBar 클래스

1
2
3
4
5
6

public abstract class CandyBar {
 
    // 팩토리 메서드: 하위클래스에서 구체적인 내용을 정의
    public abstract CandyBar createCandyBar();
}
 
Colored by Color Scripter

cs

Candy 클래스들

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

public class ThreeMusketeers extends CandyBar {
    
    @Override
    public CandyBar createCandyBar() {
        System.out.println("Creating ThreeMusketeers");
        return new ThreeMusketeers();
    }
}
public class Snickers extends CandyBar {
 
    @Override
    public CandyBar createCandyBar() {
        System.out.println("Creating Snickers");
        return new Snickers();
    }
}
public class Kitkat extends CandyBar {
   
    @Override
    public CandyBar createCandyBar() {
        System.out.println("Creating Kitkat");
        return new Kitkat();
    }
}
Colored by Color Scripter

cs

CandyBarBin 클래스

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

public class CandyBarBin {
 
    private List<CandyBar> candies = new ArrayList<>();
    private static final int LowStockLevel = 3;
    private CandyBar candyBar;
 
    // 보관통을 만들 때 어떤 캔디를 담을 보관통일지 정의
    public CandyBarBin(CandyBar candyBar) {
        this.candyBar = candyBar;
    }
 
    public void restock(){
        if(getAmountInStock() < LowStockLevel){
            // 정의된 캔디의 인스턴스를 받아와 리스트에 추가
            candies.add(candyBar.createCandyBar());
        }
    }
 
    private int getAmountInStock() {
        return candies.size();
    }
}
 
Colored by Color Scripter

cs

 

CandyStore 클래스

1
2
3
4
5
6
7
8
9

public class CandyStore {
 
    private List<CandyBarBin> bins = new ArrayList<>();
    
    public void add(CandyBarBin bin){
        bins.add(bin);
    }
}
 
Colored by Color Scripter

cs

Main 클래스

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class Main {
    public static void main(String[] args) {
        CandyStore mystore = new CandyStore();
 
        CandyBarBin bin1 = new CandyBarBin(new Kitkat());
        mystore.add(bin1);
        bin1.restock();
 
        CandyBarBin bin2 = new CandyBarBin(new Snickers());
        mystore.add(bin2);
        bin2.restock();
    }
}
 
Colored by Color Scripter

cs

- 추상 클래스 CandyBar의 하위 클래스에서 어떤 객체를 생성할지 정의하게 한다.

- CandyBarBin 클래스의 restock 메서드에서는 특정 수 이하가 된 캔디들을 각 캔디 종류 클래스들에 정의되어 있는

createCandtBar 메서드를 이용해 객체를 생성한다.

- CandyBar 클래스를 팩토리 메서드로 만들어 캔디 종류의 변화에 기존 코드가 영향을 받지 않도록 설계하였다.

- 새로 추가하거나 변경하고 싶은 캔디가 있으면 CandyBarBin 클래스에 영향을 끼치지 않고 CandyBar 클래스를 상속

받는 클래스를 추가하거나 변경시켜주면 되는것이다.

- 위와 같이 상속을 이용하는 팩토리 메서드는 스트래티지 패턴, 싱글턴 패턴, 템플릿 메서드 패턴과 함께 사용된다.

- 공통기능을 제공하는 템플릿 메서드와 하위 기능의 객체를 생성해주는 팩토리 메서드는 같이 사용되는 경우가

많지만 해당 설계에서는 팩토리 메서드만이 사용됐다.

Gof Factory Method

상위 클래스에서 어떤 객체를 생성할 것인지 정하지 않고 하위 클래스에서 정의하는 것

참고

www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788968480911&orderClick=JAj&OV_REFFER=click.linkprice.com/

템플릿 메서드 패턴

연결리스트 — Thu, 12 Nov 2020 22:56:11 +0900

템플릿 메서드 패턴

- 어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화해 전체 기능을 수행하는 구조는 바꾸지 않으면서 특정 단계

에서 수행하는 내역을 바꾸는 패턴

- 전체적으로는 동일하면서 부분적으로는 다른 구문으로 구성된 메서드의 코드 중복을 최소화할때 유용하다.

- 동일한 기능을 상위 클래스에서 정의하면서 확장 / 변화가 필요한 부분만 서브 클래스에서 구현할 수 있도록 한다.

- 예를 들어, 전체적인 알고리즘은 상위 클래스에서 구현하면서 다른 부분은 하위 클래스에서 구현할 수 있도록 함으로

써 전체적인 알고리즘 코드를 재사용하는데 유용하도록 한다.

AbstractClass

- 템플릿 메서드를 정의하는 클래스

- 하위 클래스에 공통 알고리즘을 정의하고 하위 클래스에서 구현될 기능을 primitive, hook 메서드로 정의하는 클래스

ConcreteClass

- 물려받은 primitive, hook 메서드를 구현하는 클래스

- 상위 클래스에 구현된 템플릿 메서드의 일반적인 알고리즘에서 하위 클래스에 적합하게 primitive, hook 메서드를

오버라이드하는 클래스

예시

엘리베이터에 여러 회사의 모터 적용하기

엘리베이터 제어 시스템에서 모터를 구동시키는 기능

- 현대 모터를 이용하는 엘리베이터라면 HyundaiMotor 클래스에 move 메서드를 정의할 수 있다. - HyundaiMotor 클래스 --> Door 클래스 - move 메서드를 실행할 때 안전을 위해 Door가 닫혀있는지를 확인하기 위해 연관 관계를 정의 해준다.

- Enumeration Interface

- 모터의 상태 (MOVING, STOPPED)

- 문의 상태 (OPENED, CLOSED)

- 이동 방향 (UP, DOWN)

Enum Interface

1
2
3
4
5
6

public enum DoorStatus { CLOSED, OPENED }
public enum MotorStatus { MOVING, STOPPED }
public enum Direction { UP, DOWN }


 
Door 클래스


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public class Door {
    private DoorStatus doorStatus;
    
    // doorStatus 생성자 기본 값으로 closed 상태를 가짐
    public Door(){
        doorStatus = DoorStatus.CLOSED;
    }
    public DoorStatus getDoorStatus(){
        return doorStatus;
    }
    public void open(){
        doorStatus = DoorStatus.OPENED;
    }
    public void close(){
        doorStatus = DoorStatus.CLOSED;
    }
}
Colored by Color Scripter

cs

 
HyundaiMotor 클래스

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

public class HyundaiMotor {
  private Door door;
  private MotorStatus motorStatus;
 
  public HyundaiMotor() {
    this.door = door;
    motorStatus = MotorStatus.STOPPED; // 초기: 멈춘 상태
  }
  private void moveHyundaiMotor(Direction direction) {
    // Hyundai Motor를 구동시킴
  }
  public MotorStatus getMotorStatus() { return motorStatus; }
  private void setMotorStatus() { this.motorStatus = motorStatus; }
 
  /* 엘리베이터 제어 */
  public void move(Direction direction) {
    MotorStatus motorStatus = getMotorStatus();
    // 이미 이동 중이면 아무 작업을 하지 않음
    if (motorStatus == MotorStatus.MOVING) return;
 
    DoorStatus doorStatus = door.getDoorStatus();
    // 만약 문이 열려 있으면 우선 문을 닫음
    if (doorStatus == DoorStatus.OPENED) door.close();
 
    // Hyundai 모터를 주어진 방향으로 이동시킴
    moveHyundaiMotor(direction);
    // 모터 상태를 이동 중으로 변경함
    setMotorStatus(MotorStatus.MOVING);
  }
}
 
Colored by Color Scripter

cs

 
Main 클래스

1
2
3
4
5
6
7
8

public class Client {
  public static void main(String[] args) {
    Door door = new Door();
    HyundaiMotor hyundaiMotor = new HyundaiMotor(door);
    hyundaiMotor.move(Direction.UP); // 위로 올라가도록 엘리베이터 제어
  }
}
 
Colored by Color Scripter

cs

- HyundaiMotor 클래스의 move 메서드는 우선 getMotorStatus 메서드를 호출해 모터의 상태를 조회한다.

- 모터의 상태가 동작 중이면 move 메서드의 실행을 종료

- Door 클래스의 getDoorStatus 메서드를 호출해 문의 상태를 조회한다.

- 문이 열려있는 상태면 Door 클래스의 close 메서드를 호출해 문을 닫음

- 그리고 moveHyundaiMotor 메서드를 호출해 모터를 구동시킨다

- setMotorStatus를 호출해 모터의 상태를 MOVING으로 기록한다.

문제점

- 다른 회사의 모터를 제어해야 하는 경우 OCP를 위반한다.

- 각 회사마다 모터를 제어하는 코드를 작성한 경우 모터를 제어하는 각 클래스들은 많은 중복 코드를 갖게된다.

중복 코드는 유지보수성을 악화시키므로 바람직한 구조가 아니다.

- 2개 이상의 클래스가 유사한 기능을 제공하면서 중복된 코드가 있는 경우 상속을 이용해 코드 중복을 해결할 수 있다.

- 중복되는 기능을 Motor 클래스에 정의한 뒤 상속을 통해 해결할 수 있다.

- Door 클래스와의 연관 관계, motorStatus, setMotorStatus, getMotorStatus 메서드의 중복이 해결가능하다.

- 하지만 HyundaiMotor와 LGMotor 클래스의 move 메서드는 여전히 대부분 비슷하다는 문제가 있다. 즉, move 메서드

여전히 코드 중복 문제가 있는 것이다.

- move 메서드에서 각 회사의 모터를 호출하는 부분을 제외하고 모든 부분이 동일하고, 기능면에서도 동일하기

때문에 move 메서드를 상위 클래스인 Motor 클래스로 이동시키고 각 회사의 모터를 호출하는 부분을 하위 클래스

에서 오버라이드하는 방식으로 해결할 수 있다.

Template Method 예시

Motor 클래스

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

/* HyundaiMotor와 LGMotor의 공통적인 기능을 구현하는 클래스 */
public abstract class Motor {
 
    protected Door door;
    private MotorStatus motorStatus; // 공통2 motorStatus 필드
 
    // 공통1 Door 클래스와의 연관 관계
    public Motor(Door door){
        this.door = door;
        motorStatus = MotorStatus.STOPPED;
    }
 
    // 공통3 getMotorStatus, setMotorStatus 메서드
    protected MotorStatus getMotorStatus() {
        return motorStatus;
    }
    protected void setMotorStatus(MotorStatus motorStatus) {
        this.motorStatus = motorStatus;
    }
 
    // 템플릿 메서드
    public void move(Direction direction){
 
        MotorStatus motorStatus = getMotorStatus();
 
        // 이미 이동 중이면 아무 작업도 하지 않음 
        if(motorStatus == MotorStatus.MOVING)
            return;
 
        DoorStatus doorStatus = door.getDoorStatus();
 
        // 만약 문이 열려있으면 우선 문을 닫음
        if(doorStatus == DoorStatus.OPENED)
            door.close();
 
        // 모터를 주어진 방향으로 이동시킴 
        moveMotor(direction);
        // 모터 상태를 이동중으로 변경함
        setMotorStatus(MotorStatus.MOVING);
    }
 
    // 중복된 기능을 자식 클래스에서 사용할 수 있도록 추상화
    protected abstract void moveMotor(Direction direction);
}
 
Colored by Color Scripter

cs

HyundaiMotor 클래스

1
2
3
4
5
6
7
8
9
10
11

/* Motor를 상속받아 HyundaiMotor 클래스를 구현 */
public class HyundaiMotor extends Motor{
  public HyundaiMotor(Door door) { 
        super(door); 
  }
  protected void moveMotor(Direction direction) {
    // Hyundai Motor를 구동시킴
    System.out.println("HyundaiMotor Initiated");
  }
}
 
Colored by Color Scripter

cs

LGMotor 클래스

1
2
3
4
5
6
7
8
9
10
11

/* Motor를 상속받아 LGMotor 클래스를 구현 */
public class LGMotor extends Motor{
  public LGMotor(Door door) { 
    super(door); 
  }
  protected void moveMotor(Direction direction) {
    // LG Motor를 구동시킴
    System.out.println("LGMotor Initiated");
  }
}
 
Colored by Color Scripter

cs

- Motor 클래스에서 move 메서드는 HyundaiMotor와 LGMotor에서 동일한 기능을 구현하면서 각 하위

클래스에서 구체적으로 정의할 필요가 있는 moveMotor 메서드 부분만 각 하위 클래스에서 오버라이드

되도록 한다.

- 이와 같이 Template Method 패턴을 이용하면 전체적으로 동일하면서 부분적으로는 다른 알고리즘으로 구성된

메서드의 코드 중복을 최소화할 수 있다.

Template Method

- Abstract Class : Motor 클래스

- Concrete Class : HyundaiMotor, LGMotor

- Template Method : Motor 클래스의 move 메서드

- primitive or hook Method : move 메서드에서 호출되면서 하위 클래스에서 오버라이드될 필요가 있는

moveMotor 메서드

Decorator 패턴

연결리스트 — Mon, 9 Nov 2020 19:19:33 +0900

Decorator 패턴

- 객체의 결합을 통해 기능을 동적으로 유연하게 확장할 수 있도록 해주는 패턴이다.

- 기본 기능에 추가할 수 있는 기능의 종류가 많은 경우에 각 추가 기능을 Decorator 클래스로 정의한 후 필요한

Decorator 객체를 조합함으로써 추가 기능의 조합을 설계하는 방식이다.

- 기본 기능에 추가할 수 있는 많은 종류의 부가 기능에서 파생되는 다양한 조합을 동적으로 구현할 수 있는 패턴이다.

Component

- 기본 기능을 뜻하는 ConcreteComponent와 추가 기능을 뜻하는 Decorator의 공통 기능을 정의한다.

- 클라이언트는 Component를 통해 실제 객체를 사용한다.

ConcreteComponent

- 기본 기능을 구현하는 클래스

Decorator

- 많은 수가 존재하는 구체적인 Decorator의 공통 기능을 제공한다.

ConcreteDecorator

- Decorator의 하위 클래스로 기본 기능에 추가되는 개별적인 기능을 뜻한다.

- ConcreteDecorator 클래스는 ConcreteComponent 객체에 대한 참조가 필요한데, 이는 Decorator 클래스에서

Component 클래스로의 합성(composition) 관계를 통해 표현된다.

합성관계

- 생성자에서 필드에 대한 객체를 생성하는 경우

- 전체 객체의 라이프타임과 부분 객체의 라이프 타임은 의존적이다.

- 전체 객체가 없어지면 부분 객체도 없어진다.

예시

도로 표시 방법 조합하기

도로를 간단한 선으로 표시하는 기능 (기본 기능)

도로의 차선을 표시하는 기능 (추가 기능)

1
2
3
4
5

// 기본 도로 표시 클래스
public class RoadDisplay {
    public void draw() { System.out.println("기본 도로 표시"); }
}
 
Colored by Color Scripter

cs

 


1
2
3
4
5
6
7
8
9

// 기본 도로 표시 + 차선 표시 클래스
public class RoadDisplayWithLane extends RoadDisplay {
  public void draw() {
      super.draw(); // RoadDisplay 클래스(상위 클래스) 의 draw 메서드를 호출해서 기본 도로 표시
      drawLane(); // 추가 기능인 차선 표시
  }
  private void drawLane() { System.out.println("차선 표시"); }
}
 
Colored by Color Scripter

cs

 


1
2
3
4
5
6
7
8
9
10

public class Client {
  public static void main(String[] args) {
      RoadDisplay road = new RoadDisplay();
      road.draw(); // 기본 도로만 표시
 
      RoadDisplay roadWithLane = new RoadDisplayWithLane();
      roadWithLane.draw(); // 기본 도로 표시 + 차선 표시
  }
}
 
Colored by Color Scripter

cs

- RoadDisplay 클래스에는 기본 도로 표시 기능을 실행하기 위한 draw 메서드를 구현한다.

- RoadDisplayWithLane 클래스에는 차선 표시 기능을 추가하기 위해 상속받은 draw 메서드를 오버라이드한다.

- 기본 도로 표시 기능 : 상위 클래스(RoadDisplay)의 draw 메서드 호출

- 차선 표시 기능 : 자신의 drawLane 메서드 호출

위와 같은 방식은 또 다른 도로 표시 기능을 추가로 구현하는 경우, 여러 가지 추가 기능을 조합해야 하는 경우 상속을 통한 기능의 확장은 각 기능별로 클래스를 추가해주어야 한다는 문제점이 발생할 수 있다.

-> 위 문제를 해결하기 위해서는 각 추가 기능별로 개별적인 클래스를 설계하고 기능을 조합할 때 각 클래스의 객체

조합을 이용하면 된다.

- 도로를 표시하는 기본 기능만 필요한 경우 RoadDisplay 객체를 이용한다.

- 차선을 표시하는 추가 기능도 필요한 경우 RoadDisplay 객체와 LaneDecorator 객체를 이용한다.

- LaneDecorator 클래스에서는 차선 표시 기능만을 직접 제공한다. ( drawLane() )

- 기본 도로 표시 기능은 RoadDisplay 클래스의 draw 메서드를 호출한다. ( super.draw() )

(DisplayDecorator 클래스에서 Display 클래스로의 합성관계를 통해 RoadDisplay 객체에 대한 참조)

Display 클래스

1
2
3
4
5

public abstract class Display { 
    public abstract void draw(); 
}
 
 
Colored by Color Scripter

cs

RoadDisplay 클래스

1
2
3
4
5
6

/* 기본 도로 표시 클래스 */
public class RoadDisplay extends Display {
  @Override
  public void draw() { System.out.println("기본 도로 표시"); }
}
 
Colored by Color Scripter

cs

DisplayDecorator 클래스

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

/* 다양한 추가 기능에 대한 공통 클래스 */
public abstract class DisplayDecorator extends Display {
  private Display decoratedDisplay;
 
  // '합성(composition) 관계'를 통해 RoadDisplay 객체에 대한 참조
  public DisplayDecorator(Display decoratedDisplay) {
      this.decoratedDisplay = decoratedDisplay;
  }
 
  @Override
  public void draw() { 
    decoratedDisplay.draw(); 
    }
}
 
Colored by Color Scripter

cs

LaneDecorator, TrafficDecorator 클래스

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

/* 차선 표시를 추가하는 클래스 */
public class LaneDecorator extends DisplayDecorator {
 
  // 기존 표시 클래스의 설정
  public LaneDecorator(Display decoratedDisplay) { 
         super(decoratedDisplay); 
  }
  @Override
  public void draw() {
      super.draw(); // 설정된 기존 표시 기능을 수행
      drawLane(); // 추가적으로 차선을 표시
  }
  // 차선 표시 기능만 직접 제공
  private void drawLane() { 
      System.out.println("\t차선 표시"); 
  }
}
 
/* 교통량 표시를 추가하는 클래스 */
public class TrafficDecorator extends DisplayDecorator {
 
  // 기존 표시 클래스의 설정
  public TrafficDecorator(Display decoratedDisplay) { 
      super(decoratedDisplay); 
  }
  @Override
  public void draw() {
      super.draw(); // 설정된 기존 표시 기능을 수행
      drawTraffic(); // 추가적으로 교통량을 표시
  }
  // 교통량 표시 기능만 직접 제공
  private void drawTraffic() { 
      System.out.println("\t교통량 표시"); 
  }
}
 
Colored by Color Scripter

cs

Main 클래스

1
2
3
4
5
6
7
8
9
10
11

public class Client {
  public static void main(String[] args) {
      Display road = new RoadDisplay();
      road.draw(); // 기본 도로 표시
      Display roadWithLane = new LaneDecorator(new RoadDisplay());
      roadWithLane.draw(); // 기본 도로 표시 + 차선 표시
      Display roadWithTraffic = new TrafficDecorator(new RoadDisplay());
      roadWithTraffic.draw(); // 기본 도로 표시 + 교통량 표시
  }
}
 
Colored by Color Scripter

cs

- 각 road, roadWithLane, roadWithTraffic 객체의 접근이 모두 Display 클래스를 통해 이루어진다.

- 어떤 기능을 추가하느냐에 관계없이 Client 클래스는 동일한 Display 클래스만을 통해 일관성 있는 방식으로

도로 정보를 표시할 수 있다.

- 위와 같이 Decorator 패턴을 이용하면 추가 기능 조합별로 별도의 클래스를 구현하는 대신 각 추가 기능에 해당하는

클래스의 객체를 조합해 추가 기능의 조합을 구현할 수 있다.

- 추가 기능의 수가 많을수록 효과가 큰 설계 패턴이다.

추가 예시

기본 도로 표시 + 차선 표시 + 교통량 표시

1
2
3
4
5
6
7
8
9
10
11

public class Client {
  public static void main(String[] args) {
  // 기본 도로 표시 + 차선 표시 + 교통량 표시
    Display roadWithLaneAndTraffic =
      new TrafficDecorator(
      new LaneDecorator(
      new RoadDisplay()));
    roadWithLaneAndTraffic.draw();
  }
}
 
Colored by Color Scripter

cs

- 가장 먼저 생성된 RoadDisplay 객체의 draw 메서드 실행

- 첫 번째 추가 기능인 LaneDecorator 클래스의 drawLane 메서드 실행

- 두 번째 추가 기능인 TrafficDecorator 클래스의 drawTraffic 메서드 실행

참고

gmlwjd9405.github.io/2018/07/09/decorator-pattern.html

[Design Pattern] 데코레이터 패턴이란 - Heee's Development Blog

Step by step goes a long way.

gmlwjd9405.github.io

www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788968480911&orderClick=JAj&OV_REFFER=click.linkprice.com/

JAVA 객체지향 디자인 패턴 - 교보문고

『JAVA 객체지향 디자인 패턴』은 자바와 UML을 중심으로 객체지향 이론이 무엇인지를 배운 다음 GoF에서 소개하는 디자인 패턴의 핵심 10가지를 알기 쉽게 소개한다. 실제 디자인 패턴을 익히고

www.kyobobook.co.kr

Strategy 패턴

연결리스트 — Tue, 6 Oct 2020 16:55:59 +0900

- Strategy 패턴이란 전략을 쉽게 바꿀 수 있도록 해주는 디자인 패턴이다.

- 같은 문제를 해결하는 여러 알고리즘이 클래스별로 캡슐화되어 있고 이들이 필요할떄 교체할 수 있게 함으로써 동일

한 문제를 다른 알고리즘으로 해결할 수 있게 하는 디자인 패턴이다.

- Strategy : 인터페이스나 추상 클래스로 외부에서 동일한 방식으로 알고리즘을 호출하는 방법을 명시

- ConcreteStrategy1,2,3 : Strategy 패턴에서 명시한 알고리즘을 실제로 구현한 클래스

- Context : Strategy 패턴을 이용하는 역할을 수행, 필요에 따라 동적으로 구체적인 전략을 바꿀 수 있도록 setter 메서

드를 제공

Strategy 패턴 예시

- 위의 클래스 설계는 작업시간과 초과시간을 기반으로 임금계산을 해주는 기능을 제공한다.

- 해당 클래스는 한 클래스에서 임금계산 기능만을 수행하므로 SRP는 만족한다.

- 하지만 임금 계산 로직이 바뀌거나 새로운 로직이 추가될 경우 코드가 변경되고, 다른 로직에 영향을 미칠 수 있다는

문제점 때문에 OCP는 만족하지 못한다.

- 위와 같은 경우 로직의 변경, 새로운 로직의 추가에도 기존의 코드들이 아무런 영향을 받지 않도록 하기 위해 Strategy

패턴을 적용한 설계가 필요한 것이다.

- 이 때 변화하는 변화의 단위는 임금을 계산하는 로직이므로 로직을 클래스로 만들어 주어야 한다.

- 위의 클래스 설계는 Strategy 패턴을 적용하여 로직의 변경, 새로운 로직의 추가에도 기존의 코드들은 영향을 받지 않

도록 설계한 것이다.

- Employee 클래스가 Context 역할을 수행하고 Pay Manager 인터페이스는 구체적 클래스로 구현된 임금 계산 로직들

을 캡슐화 해준다.

- Pay Manager 인터페이스가 로직 변화에 대한 방화벽 역할을 수행 해주어 로직의 변경, 새로운 로직 추가 등의 변화에

도 Employee 클래스의 변경을 차단해준다.

Employee 클래스

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

public class Employee {
 
    private String id;
    private String name;
    private int workHours;
    private int overTimeHours;
 
    private PayManager payManager;
 
    public void setPayManager(PayManager payManager) {
        this.payManager = payManager;
    }
 
    public int pay() {
        return payManager.pay(workHours, overTimeHours);
    }
 
    public String getId() {
        return id;
    }
 
    public String getName() {
        return name;
    }
 
    public int getWorkHours() {
        return workHours;
    }
 
    public int getOverTimeHours() {
        return overTimeHours;
    }
 
    // id, name은 생성자에서 참조
    public Employee(String id, String name) {
        this.id = id;
        this.name = name;
    }
 
    public void setWorkHours(int workHours) {
        this.workHours = workHours;
    }
 
    public void setOverTimeHours(int overTimeHours) {
        this.overTimeHours = overTimeHours;
    }
 
}
 
Colored by Color Scripter

cs

 
PayManager 인터페이스


1
2
3
4
5

public interface PayManager {
 
    public int pay(int workHours, int overTimeHours);
}
 
Colored by Color Scripter

cs

 
ClassicalPayment 클래스 

1
2
3
4
5
6
7
8
9

public class ClassicalPayment implements PayManager {
 
    // 작업시간, 초과시간을 인자로 받아 임금을 계산해주는 로직 클래스
    @Override
    public int pay(int workHours, int overTimeHours) {
        return 10000*workHours+15000*overTimeHours;
    }
}
 
Colored by Color Scripter

cs

NewPayment 클래스

1
2
3
4
5
6
7
8
9
10
11

public class NewPayment implements PayManager {
 
    @Override
    public int pay(int workHours, int overTimeHours) {
        if (overTimeHours>10)
            return 20000*workHours+30000*overTimeHours;
        else
            return 10000*workHours+20000*overTimeHours;
    }
}
 
Colored by Color Scripter

cs

Main

1
2
3
4
5
6
7
8
9
10
11

public class Main {
    public static void main(String[] args) {
        Employee emp1 = new Employee("1234", "insang1");
        emp1.setWorkHours(40);
        emp1.setOverTimeHours(10);
        //emp1.setPayManager(new ClassicalPayment());
        emp1.setPayManager(new NewPayment());
        System.out.println(emp1.pay());
    }
}
 
Colored by Color Scripter

cs

빌더 패턴 (Builder Pattern)

연결리스트 — Tue, 6 Oct 2020 14:53:42 +0900

- 객체 생성 패턴

- 생성자의 인자가 많은 경우, 생성자의 인자들 중에 필수적 인자와 선택적 인자가 혼합되어 있는 경우 사용

- 또한 immutable 객체 (변경, 수정할 수 없는 객체)를 생성하고 싶은 경우에도 사용

- 점층적 생성자 패턴의 경우 인자가 많을수록 생성자 개수도 많아진다.

생성자의 개수가 많기때문에 인자가 어떤 의미인지 파악하기 힘들고 가독성이 떨어진다는 문제점이 있다.

- JavaBeans 패턴의 경우 setter 메서드로 각 속성의 값을 설정하는 경우, 가독성은 향상되나

immutable object를 만들 수 없다는 문제점이 있다.

- Builder 패턴

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

public class Book {
        private Long id; //필수
        private String isbn; //필수
        private String title;
        private String author;
        private int pages;
        private String category;
 
 
        public static class BookBuilder {
            private Long id; //필수
            private String isbn; //필수
            private String title;
            private String author;
            private int pages;
            private String category;
 
            public BookBuilder(Long id, String isbn) {
                this.id = id;
                this.isbn = isbn;
            }
 
            public BookBuilder title(String title) {
                this.title = title; return this;
            }
            public BookBuilder author(String author) {
                this.author = author; return this;
            }
            public BookBuilder pages(int pages) {
                this.pages = pages; return this;
            }
            public BookBuilder category(String category) {
                this.category = category; return this;
            }
 
            public Book build() {
                Book book = new Book();
                book.id = this.id;
                book.isbn = this.isbn;
                book.author = this.author;
                book.title = this.title;
                book.pages = this.pages;
                book.category = this.category;
                return book;
            }
 
            public Long getId() {
                return id;
            }
 
            public String getIsbn() {
                return isbn;
            }
 
            public String getTitle() {
                return title;
            }
 
            public String getAuthor() {
                return author;
            }
 
            public int getPages() {
                return pages;
            }
 
            public String getCategory() {
                return category;
            }
        }
}
 
Colored by Color Scripter

cs

 
 - method chaining을 위해 BookBuilder의 this로 반환해주며, Builder의 setter 타입은 void형이 아닌 Builder 형이다.
 - Build 메서드는 인스턴스를 생성한뒤 설정받은 속성값을 전달해주고 인스턴스를 반환해준다. 
 - Build 메서드에서 최종적인 완결작업을 하는 것이다. 
 - Builder 패턴을 통해 가독성 개선, 메서드 체이닝, immutable 생성이 가능해진다. 
 
Lombok @Builder Annotation 사용
 - Lombok @Builder 어노테이션을 사용하면 코드를 직접 작성할 필요없이 구현이 가능하다. 
 - lombok.Builder을 import하고 @Builder 어노테이션을 붙여주면 된다.
 - 필수적 인자인 경우 인자 위에 @nunNull 어노테이션을 붙여주면 된다.

SOLID 원칙

연결리스트 — Mon, 5 Oct 2020 21:30:34 +0900

SRP (Single Responsibility Principle), 단일 책임 원칙

- SRP에서 책임의 기본 단위는 객체를 지칭

- 책임이란 해야 하는것, 할 수 있는 것으로 간주할 수 있다

- 즉 객체는 단 하나의 책임만을 가져야 한다는 것이다

- 객체에 책임을 할당할 때는 어떤 객체보다도 작업을 잘 할 수 있는 객체에 책임을 할당해야 한다

- 또한 객체는 책임에 수반되는 모든 일을 자신만이 수행할 수 있어야 한다

- 좋은 설계란 시스템에 새로운 요구사항이나 변경이 있을 때 가능한 한 영향 받는 부분을 줄이는 것이다.

한 객체가 많은 책임을 지고 있다면 클래스 내부에서 다른 역할을 수행하는 코드들간의 결합도가 높아지게 된다.

이는 클래스에 변경이 있을때마다 영향을 받는 부분이 많다는것이며 또한 변경 후 기존의 기능에 영향을 주는지를

평가하는 회귀 테스트 비용도 늘어난다는 것을 의미하기 때문에 좋은 설계라고 할 수 없다.

- 위와 같은 문제를 해결하기 위해서는 한 클래스에 너무 많은 책임을 부여하지 말고 단 하나의 책임만을 수행하도록 해

변경 사유가 될 수 있는것을 하나로 만들어주어야 하며 이를 책임 분리라고 한다.

한 클래스에 너무 많은 책임이 부여되어 있다. Student 클래스에서 굳이 수행할 필요가 없는 print 메서드들을 분리하여 설계해 주어야 한다.

Student 클래스에 대해 책임 분리를 해주어 개선한 디자인이다.

OCP (Open-Closed-Principle), 개방-폐쇄 원칙

- 개방-폐쇄 원칙이란 기존의 코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계해야 한다는 것이다

- 가장 중요한 점은 무엇이 변하는 것인지, 무엇이 변하지 않는 것인지를 구분하는 것이다 이를 통해 변해야 하는 것은 쉽게 변하

게, 변하지 않는 것은 변하는 것에 영향을 받지 않게 해야한다.

- 변화의 단위 = 클래스

- OCP를 만족하는 어떤 학생이 오더라도 프린트할 수 있게 해주도록 설계한 디자인 - 변해야 하는 Student 클래스는 쉽게 변하도록 하였고, 변하지 않아야할 print 클래스들은 Student 클래스에 영향을 받지 않도 록 개별적인 클래스를 처리하지 않고, 인터페이스에서 구체적인 print 클래스를 캡슐화해 처리하도록 하였다. - 위와 비슷하게 상속을 통한 다형성으로도 OCP를 만족하는 설계가 가능하다.

LSP (Liskov Substitution Principle), 리스코프 치환 원칙

- 일반화 관계를 적절히 사용했는지를 점검하는 원칙

- 부모 클래스와 자식 클래스 사이의 행위가 일관성이 있어야 한다.

- 부모 클래스의 인스턴스를 자식 클래스의 인스턴스로 대신하여도 의미는 변화되지 않도록 설계하는 것이다.

- 행위 일관성 = pre -> pre' (선조건 pre가 만족된다면 pre'가 만족되어야 한다)

post' -> post (후조건 post'가 만족된다면 post가 만족되어야 한다)

- 행위 일관성을 지키기 위해서는 부모 클래스의 행위를 더 명확하게 정의할 수 있어야 한다.

- 왼쪽의 Bag 클래스는 가격을 설정하고 반환해주는 기능을 한다.

- 오른쪽의 DiscountedBag 클래스는 할인율을 설정해 할인된 가격을 계산해주는 기능을 한다.

- DiscountedBag 클래스는 Bag 클래스의 가격을 설정하고 반환해주는 기능을 변경없이 상속받았다.

- 자식 클래스에서 부모 클래스의 기능을 재정의하지 않았으므로 부모 클래스와 자식 클래스의 행위는 일관성이 있다.

- 따라서 위의 클래스들의 상속관계는 LSP를 위반하지 않는다.

ISP (Interface Segregation Principle), 인터페이스 분리 원칙

- 인터페이스를 클라이언트에 특화되도록 분리시키라는 원칙

- 클라이언트 관점에서 클라이언트 자신이 이용하지 않는 기능에는 영향을 받지 않아야 한다.

- 비대한 인터페이스 -> 작고 특화된 인터페이스

- 여러가지 메서드(기능)을 포함하는 비대한 클래스는 클라이언트와 무관하게 발생한 변화임에도 클라이언트에게 영향

을 끼칠 우려가 있다.

- 비대한 클래스에 ISP 원칙을 적용하여 인터페이스를 클라이언트에 특화되도록 적용하였다.

- 위와 같이 설계하면 인터페이스가 일종의 방화벽 역할을 수행해 클라이언트는 자신이 사용하지 않는 메서드(기능)에

생긴 변화로 인한 영향을 받지 않게 된다.

DIP (Dependency Inversion Principle), 의존 역전 원칙

- 의존 관계를 맺을 때 변화하기 쉬운 것보다는 변화하기 어려운 것에 의존하라는 원칙

- 구체적인 것 -> 변화하기 쉬운 것, 추상적인 것 -> 변화하기 어려운 것

- DIP를 만족하기 위해서는 구체적인 클래스보다는 인터페이스나 추상 클래스와 의존 관계를 맺도록 설계해야 한다

- 인터페이스 -> 변하지 않는 것, 구체 클래스 -> 변하기 쉬운 것

- DIP를 만족하면 의존성 주입을 통해 변화를 쉽게 수용하는 코드를 작성할 수 있다

- 상위 모듈은 하위 모듈에 의존하면 안된다. 이 두 모듈 모두 다른 추상화된 것에 의존해야 한다.

- 추상화된 것은 구체적인 것에 의존하면 안된다. 구체적인 것이 추상화된 것에 의존해야 한다.

- DIP의 위반은 OCP의 위반을 초래한다.

- 변하기 쉬운 구체 클래스들을 추상 클래스와 의존관계를 맺도록 설계한다.