[Java] OOP

in Devlog on Java, Devlog, Oop


객체지향 개발 5대 원칙 (SOLID)

  • SRP (단일 책임의 원칙, Single Responsibility Principle)
  • OCP (개방폐쇄의 원칙, Open Close Principle)
  • LSP (리스코브 치환의 원칙, The Liskov Substitution Principle)
  • ISP (인터페이스 분리의 원칙, Interface Segregation Principle)
  • DIP (의존성 역전의 원칙, Dependency Inversion Principle)

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

클래스는 한가지 기능만 가지며 한가지 책임을 수행하는데 집중되어야 한다.

장점

단일 책임의 원칙을 따르면 클래스를 여러가지로 분할하여 유연하게 설계할 수 있다.

다른 행동, 책임이 격리되어 있어 연쇄적인 사이드 이펙트가 발생할 여지가 줄어든다. -> 수정될 코드 또한 적어진다.

주의사항

책임이 여러군데로 파편화 되어있는 경우, 다시 응집력을 높여주는 작업이 필요할 수 있음.

OCP (개방폐쇄의 원칙, Open Close Principle)

소프트웨어의 구성요소는 확장에는 열려있고, 변경에는 닫혀있어야 한다.

LSP (리스코브 치환의 원칙, The Liskov Substitution Principle)

서브 타입은 언제나 기반 타입으로 교체할 수 있어야 한다.

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

한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다.

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

고수준 모듈은 저수준 모듈에 의존해서는 안된다. 둘 다 추상화에 의존해야 한다.

추상화는 세부 사항에 의존해서는 안된다. 세부 사항은 추상화에 따라 달라진다.

일급 컬렉션 (First Class Collection)

콜렉션을 포함한 클래스는 반드시 다른 멤버 변수가 없어야 한다.

각 콜렉션은 그 자체로 포장돼 있으므로 이제 콜렉션과 관련된 동작은 근거지가 마련된 셈이다.

필터가 이 새 클래스의 일부가 됨을 알 수 있다.

example

Map<String, String> map = new HashMap<>();
map.put('1', "A");
map.put('2', "B");
map.put('3', "C");

public class GameRanking {
    private Map<String, String> ranks;

    public GameRanking(Map<String, String> ranks) {
        this.ranks = ranks;
    }
}

Collection을 Wrapping 하면서, 그 외 다른 멤버 변수가 없는 상태를 일급 컬렉션이라 함.

Wrapping함으로써 다음과 같은 이점을 가지게됨.

  1. 비즈니스에 종속적인 자료구조
  2. 불변성을 보장
  3. 상태와 행위를 한 곳에서 관리
  4. 이름이 있는 컬렉션

2. 불변

Java의 final은 정확히는 불변을 만들어주는 것은 아니며, 재할당만 금지 합니다.

    @Test
    public void final도_값변경이_가능하다() {
        //given
        final Map<String, Boolean> collection = new HashMap<>();

        //when
        collection.put("1", true);
        collection.put("2", true);
        collection.put("3", true);
    0    collection.put("4", true);

        //then
        assertThat(collection.size()).isEqualTo(4);
    }

3. 상태와 행위를 한곳에서 관리

값과 로직이 함께 존재

Enum의 장점과 일맥상통.

Enum

장점

  • 문자열과 비교해, IDE의 적극적인 지원을 받을 수 있다. (자동완성, 오타검증, 텍스트 리팩토링 등)

  • 허용 가능한 값들을 제한할 수 있다.

  • 리팩토링시 변경 범위가 최소화 된다. (내용의 추가가 필요하더라도, Enum 코드외 수정할 필요가 없다.)

34*+

참고 자료

https://woowabros.github.io/tools/2017/07/10/java-enum-uses.html

https://jojoldu.tistory.com/412

https://velog.io/@lsb156/%EA%B0%9D%EC%B2%B4%EC%A7%80%ED%96%A5-%EA%B0%9C%EB%B0%9C-5%EB%8C%80-%EC%9B%90%EC%B9%99-SOLID