Solid

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

클래스나 모듈은 변경할 이유가 하나만 있어야 한다. 즉, 클래스는 하나의 책임 또는 작업만 가져야 하며, 클래스를 변경할 수 있는 다른 책임이 없어야 한다.

결과적으로 SRP원칙을 잘따른 클래스는 변경사항에 대한 파급 효과가 적으며 , 변화에 잘 대응할수 있다.

❗이때 무조건적으로 하나의 클래스에 하나의 기능만 있으란건아니고 해당클래스에 너무 위배되는 기능 (ex) 옷장이 옷을벗는다) 이 없으면 된다.

OCP(Open Closed Principle) 개방 폐쇄 원칙 (추상화, 다형성)

개방 폐쇄 원칙은 높은 응집도와 낮은 결합도 라는 원리로 설명할 수 있다.

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

이말은 새로운 변경사항은 유연하게 추가 또는 수정하되 객체에 존재하는 기존의 코드에는 변경이 일어나지 않도록 설계해야한다.

결론적으로 개방-폐쇄 원칙을 수용하는 코드는 컴파일타임 의존성을 수정하지 않고도 런타임 의존성을 쉽게 변경할수 있는 코드를 말한다. 위의 원칙을 준수하면 새로운 기능이 필요할때 기존의 코드를 변경하지 않고 기능을 추가할수 있다.

LSP(Liskov Substitution Principle) 리스코프 치환 원칙 (인터페이스)

객체 프로그램의 정확성을 깨지 않으면서 하위 타입의 인스턴스로 바꿀수 있어야 한다.

다형성을 지원하기 위한 원칙이다.

인터페이스의 메서드를 사용한다 할때, 어떤 구현체를 사용하든 호출부에서 기대하는 대로 동작되어야 한다.

상속을 통한 재사용은 기반 클래스와 서브 클래스 사이에 IS-A관계가 있을 경우로 제한해야하며 그외의 경우는 합성을 이용해 재사용을 해야 한다.

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

범용 인터페이스 하나보다는 특정 클라이언트를 위한 여러 개의 인터페이스 분리가 더 좋다.

이때 인터페이스가 구체화되면서 클라이언트에 변화를 일으키면 안된다.

예를들어 운전자가 자동차를 운전한다 라는 명제를 객체간 관계로 비교하면 자동차에 대한 인터페이스, 운전자에 대한 인터페이스를 각각 분리한다. 이렇게되면 운전자는 택시기사, 버스기사 등..이 될수있고 자동차는 택시,버스 ..등 이 될수있다. 즉 확장성이 커진다.

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

• 상위 수준의 모듈은 하위 수준의 모듈에 의존해서는 안된다.
• 추상화는 구체적인 사항에 의존해서는 안 된다. 구체적인 사항은 추상화에 의존해야 한다.

위 2가지 사항을 의존성 역전 원칙이라 한다. 이름이 의존성 역전 원칙인 이유는 절차형 프로그래밍(상위 모듈이 하위 모듈에 의존)과는 의존성의 방향이 반대방향이라 그렇다고 한다.

OOP 4원칙

캡슐화

데이터와 데이터를 활용하는 함수를 외부에 들어나지 않게 한다.

즉 데이터를 외부에서 접근하지 않고 함수를 통해서만 접근할수 있도록 한다.

캡슐화를 통해 객체의 상태가 실수로 수정되는 것을 방지하고 코드 유지보수성을 개선하는 도움을 준다.

상속화

상속은 클래스가 다른 클래스로부터 속성 및 메서드를 상속할 수 있는 메커니즘이다.

다른 클래스에서 상속하는 클래스를 서브클래스 또는 파생 클래스라고 하고, 상속하는 클래스를 수퍼클래스 또는 베이스 클래스라고 한다.

상속을 사용하면 코드를 재사용할 수 있으며 클래스를 관계에 따라 계층 구조로 구성하는 데 도움이 되며, 상속은 캡슐화를 유지 하는데도 도움을 준다.

추상화

인터페이스, 추상클래스, 추상 메소드를 통해 객체가 가진 특성중 필수적인 속성만 객체로 묘사하고 유사성만을 표현하며 세부적인 상세 사항은 객체에 따라 다르게 구현될수 있도록 한다.

다형성

하나의 메세지에 대해 각 객체가 가지고 있는 고유한 방법으로 응답할수 있는 능력

• 오버라이딩: 상위클래스가 가지고있는 메서드를 하위 클래스가 재정의 하여 사용
• 오버로딩: 서로다른 파라미터를 통해 이름이 같은 메서드 를 여러개 가진다.

equals,hashCode

hash 값을 사용하는 Collection에서 논리적으로 같은 객체인지 확인하는 과정은 위 그림과 같다. hashCode()에서 두 객체가 같다 판단한후 equals()메서드에서 두객체가 같다 판단한다면Collection은 동등객체라 판단한다.

HashSet<Point> points = new HashSet<>();
points.add(Point.of(1, 1));
points.add(Point.of(2, 2));
points.add(Point.of(3, 3));

Point pointToRemove = Point.of(1, 1);
points.remove(pointToRemove);

예를들어 위 코드에서 remove()메서드를 사용하더라도 points HashSet에 존재하는 첫번째 Point객체를 삭제할수없다. 그 이유는 우리가 Point클래스안에 equals() 와 hashCode()메서드를 재정의 하지않아 Object에 존재하는 equals,hashCode 메서드를 사용하며, Object에 존재하는 equals 메서드는 메모리주소가 동일한 객체를 같은객체로 판단한다.

하지만 points에 존재하는 Point.of(1,1)과 pointToRemove는 같은 메모리주소에할당된 객체 가아니기 때문에 위와같이 remove메서드를 통해 HashSet에서 좌표가 1,1 인 Point 객체를 삭제할수 없다.

따라서 위와같은 상황에서 우리가 원하는 결과값을 얻기위해선 equals 와 hashCode메서드를 재정의 해야한다.

class Point {
    private final int x;
    private final int y;
    ...
    @Override
    public boolean equals(Object o) {
        if (this == o) { //비교대상과 Remove할객체의 주소값이 같은가?
            return true;
        }
        if (o == null || getClass() != o.getClass()) { //Remove할 객체가 null이거나 비교대상과 Remove할 객체의 클래스가 다른가?
            return false;
        }
        Point point = (Point) o;
        return x == point.x && y == point.y;//비교대상과 Remove할 대상의 x,y 좌표값이 같은가?
    }

    @Override
    public int hashCode() {
        return Objects.hash(x, y);
    }
}

public void hashSet() {
        HashSet<Point> points = new HashSet<>();
        points.add(Point.of(1, 1));
        points.add(Point.of(2, 2));
        points.add(Point.of(3, 3));

        Point pointToRemove = Point.of(1, 1);
        for (Iterator<Point> iterator = points.iterator(); iterator.hasNext();) {
            Point point = iterator.next();
            if (point.equals(pointToRemove)) {
                iterator.remove();
            }
        }
}

Object 클래스에 존재하는 equals 메서드와 hashCode메서드를 override해 우리가 원하는 결과를 기대할수있게된다.

❗❗만약 위와같은 equals메서드만을 재정의 하고 hashCode()메서드를 재정의 하지 않는다면 어떻게 될까?

위와같은 상황에서 equals메서드만 재정의한다 가정하면 우리가 원하는 remove 동작을 기대할수있다. 왜냐하면 우린 위 코드에서 HashCode를 거치지 않고  point.equals(pointToRemove) 를 통해 우리가 삭제하고싶은 객체와 points안에 있는 객체중 같은 객체라 판단되는것을 삭제하기때문이다. 하지만points.add()를 하는상황에서 문제가 발생한다.

만약 hashCode()를 재정의 하지않고 points.add(Point.of(2,2))를 하게된다면 Collection이 동등한 객체를 판단하기위해 hashCode()를 호출후 equals()를 호출한다. 이때 재정의되지않은 hashCode()는 Object에 존재하는 hashCode()를 실행하게 된다. 즉 Object에 존재하는 hashCode()는 객체의 메모리주소값을 가지고 같은값인지 판단하지만 우리가 새롭게 추가할 Point.of(2,2)는 기존에 추가된 Point.of(2,2)와 메모리 주소값이 다르기때문에 equals() 메서드로 가기전에 이미 동등한 객체가 아니라는 결론이 나, set값에 같은 x,y좌표를 가진 Point객체가 2개 저장되게 된다.

따라서 equals()메서드를 override할땐 hashCode()메서드도 override 해주자 (hash 값을 사용하는 Collection이 아니라면 hashCode()를 재정의 하지 않아도 문제가 생기지 않을수 있지만 프로그래밍은 혼자하는게 아니므로 되도록 equals()와 hashCode()메서드를 같이 재정의 해주자)

When you add an object to a hash-based data structure like a HashSet, HashMap, or Hashtable, the data structure first computes the hash code of the object by calling its hashCode() method. The data structure then uses this hash code to determine the bucket location for the object.

Reference

• equals,hashcode

java.lang 패키지

class HelloWorld{
    public static void main(String[] args){
        System.out.println("Hello, World!");
    }
}

위와같은 class가 있다 가정해보자.

이때, 우린 아무런 package도 import하지 않았는데 System클래스에 존재하는 println메서드를 사용한다.

이러한 이유는 JAVA에서 필요한 클래스들이 모여있는 패키지인 java.lang package는 import문이 따로 없어도 자동적으로 프로그램에 포함이 되기 때문이다.

java.lang에 존재하는 클래스

• Object: The root class of the Java class hierarchy.
• String: A class that represents a sequence of characters.
• System: A class that provides access to the standard input, output, and error streams of the program.
• Math: A class that provides methods for performing basic mathematical operations.
• Integer, Long, Float, Double, Short, Byte: Wrapper classes for primitive types.
• Exception, RuntimeException, Error: Classes for handling exceptions and errors.

In addition to these, the java.lang package also contains other classes such as Thread, ClassLoader, Process, and ProcessBuilder, among others.

위 클래스들말고도 수많은 클래스가 존재한다. 아무튼 결론은 우리가 따로 import하지않아도 사용할수 있는 클래스들은 java.lang package에 존재한다고 보면된다.

Assertions를 통해 오류를 던지는지 확인하기

org.junit.Assert 와 org.assertj.Assertions의 차이점

org.junit.Assert: 가장 널리 사용되는 Java 테스트 프레임워크 중 하나인 JUnit 테스트 프레임워크의 일부이다. JUnit은 예상 결과를 실제 결과와 비교하여 확인할 수 있는 어설션 메서드 세트를 제공한다. 예를 들어 assertEquals(expected, actual)를 사용하여 두 개체가 동일한지 확인할 수 있다.

org.assertj.Assertions: 반면에 org.assertj.Assertions는 비교적 최신 Java 테스트 프레임워크인 AssertJ 테스트 프레임워크의 일부이다. AssertJ도 어설션 메서드 세트를 제공하지만, 어설션 작성을 위한 보다 유창하고 직관적인 API를 제공하는 것을 목표로 한다. 예를 들어, assertThat(actual).isEqualTo(expected)를 사용하여 두 객체가 동일한지 확인할 수 있다.

그럼 둘중 무엇을 사용해야할까?

org.junit.Assert와 org.assertj.Assertions는 모두 코드 테스트를 위한 어설션 메서드를 제공하지만, AssertJ의 더 전문화된 API가 일부 테스트 시나리오에 더 나은 선택이 될 수 있다. 궁극적으로 두 프레임워크 중 하나를 선택하는 것은 개인의 선호도와 테스트 프로젝트의 특정 요구 사항에 따라 달라진다.

따라서 나는 아직 초보다 보니 org.junit.Assert 와 org.assertj.Assertions 방법 모두 사용했다.

@Test
@DisplayName("사람이 10000명일때 pointsValidate 성공 테스트")
void pointsValidateSuccessTest() {
    LadderLine line = new LadderLine(10000);
    line.createLine();

    //1. org.junit.jupiter.api.Assertions 로 테스트

    //람다식을 사용한 형태
    org.junit.jupiter.api.Assertions.assertDoesNotThrow(() -> line.pointsValidate());

    //람다식을 사용하지 않은 형태
    org.junit.jupiter.api.Assertions.assertDoesNotThrow(new Executable() {
        @Override
        public void execute() throws Throwable {
            line.pointsValidate();
        }
    });


    //2. org.assertj.core.api.Assertions 으로 테스트

    //람다식을 사용한 형태
    org.assertj.core.api.Assertions.assertThatCode(() -> line.pointsValidate()).doesNotThrowAnyException();

    //람다식을 사용하지 않은 형태
    org.assertj.core.api.Assertions.assertThatCode(new ThrowableAssert.ThrowingCallable() {
        @Override
        public void call() throws Throwable {
            line.pointsValidate();
        }
    }).doesNotThrowAnyException();

}

테스트한 method에 대해 설명을 하자면 pointsValidate메서드는 LadderLine객체에 존재하는 ArrayList points에 연속된 true가 저장되어있다면 IllegalArgumentException을 발생시킨다.

위 테스트는 성공 테스트이기때문에 org.junit.Assertions에서는 asseretDoesNotThrow를

org.assertj.Assertions에서는 doesNotThrowsAnyException을 사용했다. (즉 예외가 발생하면 안된다)

Excutable, ThrowableAssert를 사용한 이유

" assertDoesNotThrow(new Executable().. " 여기서 Excutable을 사용한이유는 위 사진처럼 assertDoesNotThrow는 파라미터를 Executable로 받기 때문이다.

"assertThatCode(new ThrowableAssert.ThrowingCallable... " 인 이유도 위와 동일하다. 이때 ThrowableAssert가 붙는이유는 ThrowingCallable 인터페이스를 가지고있는 클래스가 ThrowableAssert이기 때문이다.