📌 SOLID 원칙

객체 지향적으로 설계하는데에 있어 기본이 되는 SOLID원칙에 대해서 알아보자.
SOLID는 각 원칙의 첫번째 글자를 따서 만든 것이다.

• 단일 책임 원칙 (Single responsibility principle; SRP)
• 개방-폐쇄 원칙 (Open-closed principle; OCP)
• 리스코프 치환 원칙 (Liskov substitution principle; LSP)
• 인터페이스 분리 원칙 (Interface segregation principle; ISP)
• 의존 역전 원칙 (Dependency inversion principle; DIP)

이 원칙들이 서로 다른 내용이라 하기에는 밀접하게 연관되어 있으므로 한꺼번에 같이 이해해야 할 것이다.

📌 단일 책임 원칙

객체 지향은 책임을 객체에게 할당하는데에 있다. 객체로 존재하게 하는 이유가 책임인데

이 원칙은 원칙 이름에서도 알 수 있듯 책임과 관련되어 있다.

📢 클래스는 단 한 개의 책임을 가져야 한다.

하나의 클래스가 여러 책임을 갖게되면 책임마다의 이유가 발생하기 때문에 클래스 변경이 잦아질 수 있다.

그래서 한개의 이유로만 클래스가 변경되려면 하나의 책임만을 가져야 한다.

지금 진행하고있는 TDD강좌를 들으면서 SOLID원칙 그리고 디자인 패턴에 대해 많이 학습하는것 같다.

1-2-3 과정으로 진행되는 과정이 예를 들어 있다고 한다면

public class Process {
    public void one() {
        /// 1...
        String test = two();
        three(test);
    }


    public void two() {
        /// 2...
    }

    public void three(String test) {
        /// 3...
    }
}

이렇게 작업을 하게되면, 연쇄적으로 코드 수정을 해야할 수 밖에 없다.

이것은 코드를 분리만했지 절차지향과 다를게 없다.

여기서 만약 String타입의 인자가 아니라 다른타입으로 오게되면 two와 three 모두 바꿔야한다.

극단적인 예시이지만, 같은 작업을 수행하는 것이라면 괜찮지만
데이터를 불러오고, 가공하고, 보여준다 라면 얘기는 다르다.

그러면 클래스마다 1개씩 잘라서 분리를 해주어야 한다.

그래서 최종적으로 동작하는 클래스에서 조립하는 느낌으로 구현을 한다고 생각하면 이해가 쉬울 듯 하다.

📌 개방-폐쇄 원칙

개방, 폐쇄 말만들으면 열고 닫는것.

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

말이 이렇게만 보면 어렵다.

기능을 변경하거나 확장은 할수 있되, 그 기능을 사용하는 코드는 수정을 하지 않아야 된다.

이부분은 추상화와 관련이 깊은것 같다. 사용하는 코드를 수정하지 않아야한다 라는 원칙이기 때문에

인터페이스 또는 추상클래스를 사용했을 시에 구현체에 따라 다르게 동작할 수 있게 만듬으로써

변경 확장이 용이하며, 코드 수정은 하지 않게된다.

개방 폐쇄 원칙이 깨질때의 증상 1 - 다운 캐스팅

이것은 다운 캐스팅을 할 경우에 그런데, instanceof 로 타입 다운을 시켜 검증을 하면

발생하는 것인데

내 경우에는 볼링게임 여기서 사용했었다.

객체마다 다르게 동작할 수 있는 무언가가 있다면 그 메소드를 추상화하여 동작하게 만들어야한다.

개방 폐쇄 원칙이 깨질때의 증상 2 - if-else

public void draw() {
    if (index == 1) {
        // 1조건
    }else if (index == 2) {
        // 2조건
    }
    ...
}

위 코드처럼 조건이 하나씩 늘게되면 else if로 늘려서 추가할 경우이다.

draw에서 그냥 메소드를 통일하고

Pattern이라는 인터페이스를 생성하고 방식에따라 다른 로직을 구현하고 메서드는 통일시키는 식으로

추가를 해주자.

개방 폐쇄 원칙은 유연함에 대한 것

이 원칙은 변화가 예상되는 것들을 추상화해서 유연함을 얻도록 해줬다.

그러니까 추상화를 하지 않거나 아직 개념이 부족해 못한다면

개방-폐쇄 원칙을 지킬 수 없게 되어 기능 변경이나 확장을 어렵게 만든다는 것이다.

내가 퇴사했던 회사에서 딱 이렇게 개발을 했었다. 오히려 이게 쉽다면서... 난 아니었는데 😥

각설하고, 코드의 변화 요구가 발생하면 이 구현부를 추상화해서 지금의 이 원칙에 맞게 수정할 수 있는지

항상 생각하면서 개발해야겠다.

📌 리스코프 치환 원칙

윗부분의 개방폐쇄에선 추상화 그리고 다형성을 이용하여 구현되었다.

이번에 알아보는 이 리스코프 치환 원칙은 개방 폐쇄를 조력해주는(?) 다형성에 관한 원칙이다.

상위 타입의 객체를 하위 타입의 객체로 치환하여도

상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다.

이거는 예제를 따로 개발자가 반드시 정복해야할 객체지향과 디자인 패턴에서 인용하였다.

부모 클래스와 자식 클래스가 있다고 가정. 특정한 메서드는 상위 타입인 부모클래스를 이용할 것이다.

public void someMethod(SuperClass sc) {
    sc.someMethod();
}

someMethod는 부모타입의 객체를 사용하고 있는데, 이 메소드에 하위타입 객체를 전달해도 someMethod 가

정상적으로 동작해야 한다. 이것이 바로 리스코프 치환 원칙이다.

중요❗❗❗ 이 원칙이 제대로 지켜지지 않는다면 개방-폐쇄역시 지켜지지 않는다.

개념적으로 상속 관계에 있는 두개의 클래스가 있더라도 막상 구현했을때는 상속 관계가 아닐 수도 있는 것들이 있다.

이럴 때는 상속이 아니라 각자 다른 타입으로 매칭을 시켜줘야한다.

📌 인터페이스 분리 원칙

인터페이스는 그 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다.

이 원칙또한 앞에서와 연관이 있는데 결국 용도에 맞게 인터페이스를 분리하는 것은

단일 책임 원칙과 연결이 된다. 하나의 타입에 여러 기능이 섞일 경우

한가지의 기능 변화로 인해 다른 기능이 영향을 받을 가능성이 높아진다.

그래서 인터페이스를 분리한다면 한 기능에 대한 변경의 리스크를 줄일 수 있게 된다.

그리고 인터페이스의 분리가 잘되어 있다면 즉, 단일 책임 원칙이 잘 지켜질때

구현클래스들의 재 사용성이 높아질 수 있기 때문에

결국 이 원칙은 인터페이스와 구현 클래스의 재사용성을 높인다는 효과를 가지게 된다.

원칙은 클라이언트에 대한 것

인터페이스 분리 원칙은 클라이언트 입장에서 인터페이스를 분리하란 원칙이다.

클라이언트가 사용하는 기능들을 중심으로 인터페이스를 분리하여 클라이언트에서 발생하는 인터페이스

변경의 여파가 다른 클라이언트에 미치는 것을 최소화 할 수가 있다.

📌 의존 역전 원칙

고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다.

저수준 모듈이 고수준 모듈에서 정의한 추상 타입에 의존해야 한다.

고수준 모듈은 저수준 모듈을 조합해서 한 모듈을 만들어 놓은 형태이고

저수준 모듈은 도메인단위로 분리했을 때 상세한 행동 하나하나를 정의한 것을 말한다.

고수준 모듈이 저수준 모듈에 의존할 떄의 문제

내가 생각하는 이 SOLID 원칙. 어떤 법칙을 읽던간에 무조건 인터페이스가 생각나는게 당연한걸까❓

이것도 내가 생각하기엔 추상화가 답인것 같다.

구현하는 비즈니스 클래스가 여러개가 있다고 한다면 개방폐쇄의 예시처럼 조건일때 다른 클래스 로직을 불러와

실행하는 것이 될것이다.

이런 방식이 프로그램을 변경하는데 너무 어렵게 만든다. 이 저수준 모듈이 변경됨에 따라

고수준은 변경이 되지 않게끔 하려면 나오는 원칙이 의존 역전 원칙이다.

그러니까 이 의존 역전 원칙이 리스코프나 개방-폐쇄를 따르는 설계를 만들어주는 밑바탕이 되는 것으로 볼 수 있다.

의존 역전

마땅한 코드 예시가 없어서 책에서 한번더 가져다 쓴다.

public class FlowController {
    public void process() {
        //소스 코드에서 FileDataReader에 대한 의존 발생
        FileDataReader reader = new FileDataReader();
    }
}

public class FileDataReader implements ByteSource {
    ...
}

이런 구조가 있다면

소스코드의 의존은 아래와 같다.

{: text-center}

그런데 런타임에서 본다면
FlowController -> FileDataReader 가 되는것이다.

왜냐면 컨트롤러가 시작점이고 거기서 하나씩 로드해서 참조하기 때문에

이런 구조가 나온다.

왜?

이유는 그냥 단순하다. 절차지향으로 생각해보면 저 Controller를 동작시켜야 아래가 동작하지 않는가?

정리

지금까지 SOLID 원칙에 대해 알아보았다. 결국 이 원칙이 말하는 바는

정말 원초적으로 생각하고 따지자면 유지보수하기 좋은 코드를 만드는 밑바탕이다.

왜냐면 요구사항이 변화하는것에 맞춰 유연하게 변경하니까 가 가장크다.

요즘 자바 공부에 재미를 붙였다.

이렇게 하나하나 습득해서 위로 올라가고 싶다.

나는 아직 자바가 고프다 ㅋㅋㅋㅋㅋㅋ

이번 포스팅 마치도록 하겠다.

준영속 상태의 지연로딩을 해결하는 방법

JPA에서 항상 생각을 해야되는 것이 바로 영속상태, 영속성 컨텍스트위에 있는가? 를 생각해야된다.

예를 들어 우리는 DAO층에서 실제 DB와 통신을 보편적으로 진행하는데, 이쪽은 영속성 컨텍스트에 의해 관리가 되어
영속 상태를 유지한다.

하지만, Controller, View 이런 계층에서는 준영속 상태가 된다. 그래서 영속상태와 다르게 변경감지, 지연로딩이 동작하지 않게 된다.

지연로딩이 동작하지 않기 때문에 이때 지연 로딩을 시도하면 문제가 발생하는게 당연하다.

하이버네이트가 구현체라면 org.hibernate.LazyInitializationException이 발생한다.

이것을 해결하는 문제는 두가지가 있다.

• 뷰가 필요한 엔티티를 미리 로딩
• OSIV를 사용해서 엔티티를 항상 영속 상태로 유지하는 방법

뷰가 필요한 엔티티를 미리 로딩

이름 그대로 영속성 컨텍스트가 살았을 때, 필요한 엔티티를 다 로딩하거나 초기화해서 반환하는 방법이다.

이미 다 로딩했기 떄문에, 지연 로딩이 발생할 걱정을 안해도 된다.

이 방법에서는 로딩해두는 방법에 따라 3가지로 나뉜다.

글로벌 페치 전략 수정

엔티티에서 fetch 타입을 변경하면 애플리케이션 전체에서 이 엔티티 객체를 로드할때 마다 해당 전략을 사용하므로 글로벌 페치 전략이라고 한다.

단점

사용하지 않는 엔티티까지 로딩
N + 1 문제 발생

JPQL을 사용할 때 문제가 발생하는데

Order와 Member가 다대일로 연결되어 있다고 가정한 후에
select o from Order o 를 사용해서 조회를 한다고 한다면
글로벌 페치 전략을 사용하지 않고 그냥 JPQL자체만 사용하기 때문에

1. 일단 Order를 조회
2. order 인스턴스들 생성
3. member 페치 전략이 즉시로딩이므로 order조회되면 member도 조회
4. 근데 영속성 컨텍스트에 없다? order엔티티 수만큼 계속 조회

이걸 해결하려고 나온것이 바로 아래 부분이다.

JPQL 페치 조인

여기선 join fetch를 사용하면 된다고 한다.

select o from Order o join fetch o.member

N + 1 자체의 문제를 해결해주는것은 좋다. 근데 이제 order만 조회하느냐, order에 연관된 member까지 조회하냐에 따라 메소드를 늘려야할 것이다. 이러면 내부적으로 논리적 의존관계 우려가 발생하기 때문에 잘 고려해서 사용해야 할 것이다.

강제 초기화

지연 로딩을 설정했을 때 연관된 엔티티는 프록시 객체이다.

이 가짜 객체는 실제 사용 시점에 초기화가 되는데 이것을 영속성이 살아있을 때 다 초기화를 하여 반환해준다면? 준영속에서도 사용이 가능하다.

Facade 계층 추가

뷰를 위한 프록시 초기화 담당 계층

서비스와 컨트롤러를 분리해서 그 계층 사이의 의존성을 한번 더 분리해주는 것이라고 생각하면 편하다.

Controller - Facade - Service 이렇게 말이다.

프록시를 초기화하려면 영속성 컨텍스트가 필요해서 Facade에서 트랜잭션을 시작해야 한다.

퍼사드 계층 역할 및 특징

• 프리젠테이션, 도메인 모델 계층 간의 논리적 의존성 분리
• 프리젠테이션 계층에서 필요로 하는 프록시 객체 초기화
• 서비스 계층 호출하여 비즈니스 로직 실행
• Repository 직접 호출해서 엔티티 탐색

이것도 근데 결국 프리젠테이션 계층에서의 준영속 상태 라는 것이 문제이기 때문에 고안해낸 것.

OSIV

OSIV(Open Session In View)는 영속성 컨텍스트를 뷰까지 열어준다는 뜻.

뷰에서도 지연로딩이 가능❗️

프리젠테이션 계층에서 엔티티를 수정못하게 막는 방법은

• 엔티티를 읽기 전용 인터페이스로 제공
• 엔티티 래핑
• DTO만 반환

들이 있다.

스프링 OSIV

True - 기본값

application.properties에 추가해주면 된다.

sping.jpa.open-in-view:true 

• 장점

  • 그림과 같이 커넥션을 유지해서 영속성 컨텍스트 범위가 넓어진다.
  • 그래서 연관관계 LAZY fetch 전략을 서비스를 벗어난 곳에서 사용 가능하다.

• 단점

  • 너무 오랜시간동안 DB 커넥션을 유지하여 리소스를 사용하기 때문에 실시간 트래픽이 중요한 애플리케이션에서 DB 커넥션이 모자랄 수 있음 (장애 발생)

False - 설정값

sping.jpa.open-in-view : false

DB 커넥션을 Transaction 내부까지만 유지
(트랜잭션은 Service에서 수행되니까 Service까지만 유지되는 것)

• 장점
  • DB 커넥션 리소스의 효율적인 사용
  • 트랜잭션을 종료할 때 영속성 컨텍스트를 닫으면서 DB 커넥션을 반환
• 단점
  • 모든 지연로딩을 트랜잭션 안에서 처리
  • 지연로딩에 관한 모든 로직을 Service / Repository 에서 해결해야 함

해결방안

• Command와 Query를 분리하는 방법 (김영한님 선호)
  • Controller에서 지연로딩을 처리해야 할 때 Query용 Service를 만드는 것
• OrderService
  • 핵심 비즈니스 로직
• OrderQueryService
  • 화면이나 API에 맞춘 서비스 (주로 읽기 전용 트랜잭션)

결론

결국 OSIV는 DB 커넥션 리소스에 대한 효율적인 사용과 관련된 전략이다.

OSIV 실무 TIP

실시간 API 고객 서비스를 해야한다면 OSIV false설정

ADMIN 처럼 커넥션이 많지 않은 곳 OSIV true 설정

삽질기

모든 코드는 깃허브에 있다.

일단 저번에 마이그레이션 1탄을 했었는데 의존성이 겹쳐서 다시 리팩토링 하려고 보니까 에러가 많았다.

의존성 겹침 에러

일단 의존성이 겹쳐서 생긴 에러가 조금 있다.

부분만 적은 gradle 일부이다.

plugins {
    id 'org.springframework.boot' version '2.5.3'
    id 'io.spring.dependency-management' version '1.0.11.RELEASE'
}

dependencies {
    implementation (
            'org.springframework.boot:spring-boot-starter-web', //이부분
            'org.springframework.boot:spring-boot-starter-test', //이부분
            'org.mybatis.spring.boot:mybatis-spring-boot-starter:2.2.0',
            'org.mariadb.jdbc:mariadb-java-client', //이부분
            'commons-io:commons-io:2.6',
            'commons-fileupload:commons-fileupload:1.3.3',
            'javax.servlet:jstl',
            'org.projectlombok:lombok',
    )
}

이렇게 주석처리한 부분들이 에러를 띄웠다.

각자의 버전마다 호응(?)이 되는 버전들이 맞아야 세팅이 완료가 되는데 서로 충돌해서 발생하는 에러였다.

그레이들에서

id 'org.springframework.boot' version '2.5.3'
id 'io.spring.dependency-management' version '1.0.11.RELEASE'

이 두가지의 부분이 중요한데,

org.springframework.boot는 부트 버전을 명시하여 boot starter 관련 된것들을 통일 시켜주고

dependency-management는 다른 라이브러리들의 의존성을 관리해주는 것인데 최적화된 버전들을 맞춰주는 역할을 한다.

그러면서 버전이 맞지않는게 생기면 에러를 띄워준다.

톰캣 오류

그리고 tomcat 오류였다.

부트와 jsp는 잘 맞지않는다.

그럼에도 일단 jsp가 너무 많아서 일단 jsp를 사용하려고 했기 때문에

의존성에는

implementation (
    'javax.servlet:jstl',
    'org.apache.tomcat.embed:tomcat-embed-jasper'
)

두가지를 일단 추가 해줬다. JSP를 사용하려면 embed-jasper가 존재해야 하는데

이건 기본으로 작성해줘서 문제가 아니었다. 😰

application.properties

spring.mvc.view.prefix=/WEB-INF/views/
spring.mvc.view.suffix=.jsp

여기는 둘다 잘 해주었는데.. 왜문제일까 약 2시간 고민했다 😡

근데 여기가 문제였다...

Working Directory에 저 설정을 안해주면 jsp 파일을 안찾는다. 그냥 반응이 없음..

@Controller @RequestMapping 이런건 문제가 아니었다.

Bean 주입

Bean을 예를 들어

public interface TestInter {
    void hello();
}

@Repository
public class TestImpl implements TestInter {
    @Override
    public void hello() {
        System.out.println("hello");
    }
}

@RequiredArgsConstructor
public class TestService {
    private final TestInter testInter;
}

스프링5 프로그래밍 입문

여기서 봤던건데 스터디원 한분이 알려줬다. 그러면서 책에있는게 기억이 나더라...

결론은 빈을 뭘 주입해야할지 모르는것이다.
@Qualifier를 통해 명시해줘서 하거나 이전 회사에서 하던 방식으로 어노테이션 뒤에 (빈 이름) 해서 매칭해주는 식으로 해야한다. 이게 좋지 않아서 다 삭제했다.

이랬던 구조들을

이렇게 바꾸었다. 클래스 이름들은 추후 안정화가 되면 바꿀 계획이다.

학원에서부터 벗어난지 꽤됐고, 그러면서 TDD강의까지 듣고있고 그동안 공부했던거를 생각하면서 코드를 보니까
더러운 부분이 참많다.

이제 시작이고 끝을 보겠다. 계속 리팩토링 하는 과정을 블로그 + 깃허브 에 업데이트 할 것이다.

연산자, 조건문 정리

• 산술 연산자
• 비트 연산자
• 관계 연산자
• 논리 연산자
• instanceof
• assignment(=) operator
• 화살표(->) 연산자
• 3항 연산자
• 연산자 우선 순위
• (optional) Java 13. switch 연산자

산술 연산자(Arithmetic Operator)

산술 연산자는 사칙연산을 다루는 연산자로, 가장 기본적이면서 가장 많이 사용되는 연산자 중의 하나.

산술 연산자는 모두 두 개의 피연산자를 가지는 이항 연산자이며, 결합 방향은 왼쪽에서 오른쪽이다.

int result = 1 + 2;
System.out.println(result);

String ss = "연습";
System.out.println(ss + " 입니다.");

int product = 5 * 4;
System.out.println(product);

System.out.println("정수형 나누기");
System.out.println(5 / 4);
System.out.println(5 % 4);

System.out.println("실수형 나누기");
System.out.println(5.0 / 4.0);
System.out.println(5.0 % 4.0);


System.out.println(5 / 0); // java.lang.ArithmeticException: / by zero

System.out.println(5.0 / 0.0); // Infinity

System.out.println(5.0 % 0.0); // NaN

System.out.println(-5.0 / 0.0); // -Infinity

System.out.println(-5.0 % 0.0); // NaN

정수형일때 조심해야 하는 점은 보는 것과 같이 나눗셈 연산을 수행할 때이다.
그냥 실행이 잘 되기 때문에 % 연산을 수행할 때에도 음수값으로 나눌때 값이 다르다.

실수형일때는 연산 과정에서는 오차가 발생할 수 있고 이것을 조심해야 한다.
0으로 나누거나 나머지 연산을 사용하면 Infinity, NaN 가 나온다.

단항 연산자

• + 를 붙이면 양수를 나타냄. (생략 가능)
• - 를 붙이면 음수 값을 나타낸다.

증감 연산자

++를 붙이면 값을 1씩 증가시킨다. 하지만 피연산자의 위치에 따라 계산이 살짝 달라진다.

앞쪽에 ++변수 의경우 식을 진행하기 전에 1을 증가시키고, 뒤쪽변수++에 위치하는 경우 식을 진행한 후에 1을 증가시킨다.

-- 도 이와 같다.

int result = 1;
for (int i = 0; i < 5; i++) {
    System.out.print(result++ + " ");
}

System.out.println();
int result2 = 1;

for (int i = 0; i < 5; i++) {
    System.out.print(++result2 + " ");
}

두 증감 연산자에 대한 차이이다.

비트 연산자 (Bitwise Operator)

논리 연산자와 비슷하지만, 비트 단위로 논리 연산을 할 때 사용하는 연산자이다.

비트 단위로 왼쪽이나 오른쪽으로 전체 비트를 이동하거나 1의 보수를 만들 때도 사용된다.

관계 연산자

관계 연산자는 피연산자가 값이 어떤지 비교하는 연산자들이다.

• == : 같다.
• != : 다르다.
• > : 크다
• >= : 크거나 같다.
• < : 작다.
• <= : 작거나 같다.

문자열이 같은지를 보려면 equals()를 사용해야 한다.

==은 주소값을 비교하는 것이기 때문에 String 은 equals를 사용하자.

논리 연산자

피연산자 값으로 boolean을 받고 true/false를 판단할 경우에 사용한다.

• &&
  • AND 연산자이며, 좌우 값이 둘다 참일 경우에 true, 그렇지 않으면 false를 반환
• ||
  • OR 연산자로, 한쪽만 참이어도 참을 반환한다.
• !
  • NOT 연산자로 위의 두개와는 다르게 단항 연산자이며 조건이 거짓일때 true값을 반환해준다. 그러니까 기본이 거짓이면 true, 참이면 false를 반환한다.

instanceOf

객체 타입을 확인하는데 주로 사용하고, 나같은 경우에는 테스트 코드를 작성했을 때, 많이 사용한 메서드이다. 속성 자체는 연산자이고, 형 변환이 가능한지 여부를 true/false 로 가르쳐준다. 부모, 자식 객체인지 확인하는데 쓴다고 생각하면 된다.

class A {

}

class B extends A {

}

public class InstanceTest {
  public static void main(String[] args) {
    A a = new A();
    B b = new B();

    System.out.println(a instanceof A);
    System.out.println(b instanceof A);
    System.out.println(a instanceof B);
    System.out.println(b instanceof B);
  }
}

결과는 true, true, false, true 가 나온다.

b는 부모 클래스인 a를 상속받았기 때문에 A의 객체타입이 맞다.

그래서 true이고 A클래스는 반대로 B에 대한 부모 클래스이기 때문에 B의 객체 타입일 수는 없으므로 false를 출력하게 된다.

assignment(=) operator

할당 연산자는 연산자 기준 오른쪽값을 왼쪽의 피연산자에게 할당한다.

int x = 0; 에서 x라는 int형 변수에 0을 할당하는 것이다.

A a = new A(); 처럼 객체를 할당할 수도 있다.

복합 할당

public class Test {
  public static void main(String[] args) {
      int a = 0;
      a = a + 1;
      a += 1;
  }
}

a = a + 1 의 경우

a += 1 의 경우

서로 바이트 코드가 다르다!!!

아래의 경우가 속도가 조금 빠르지 않을까 생각한다.

화살표(->) 연산자

화살표 연산자는 Java8에서 람다 표현식으로 익명클래스를 대체한 것이다.

public interface Test {
    void test();
}

public class Main {
    public static void main(String[] args){
        Test test = new Test() {
            @Override
            public void test() {
                //로직 구현
            }
        };
    }
}

이런식으로 익명 클래스를 사용하여 구현을 해줬었다.

근데 이 화살표 연산자가 생긴뒤로는 이렇게 구현하지 않고 아래와 같이 구현한다.

@FunctionalInterface
public interface Test {
    void test();
}

Test test = () -> 로직;

이렇게 구현을 해준다.

@FunctionalInterface 를 인터페이스에 붙여주게 되면 interface에는 하나의 추상메서드만 정의가 가능하다.

람다를 다시 공부할때 포스팅 하도록 하겠다.

3항 연산자

삼항 연산자는 조건 ? 참일 경우 : 거짓일 경우 로 구현하는데 피연산자를 세개를 받으므로 삼항 연산자라고 불린다.

if-else문과 비슷한 역할을 수행하지만 한줄로 작성이 가능하다.

public class Ternary {
    public static void main(String[] args) {
        int n1 = 5;
        int n2 = 10;

        int max = (n1 > n2) ? n1 : n2;
        System.out.println("max : " + max);
    }
}

기본적으로 연산자에는 우선순위가 있으며, 괄호의 우선순위가 제일 높고,

산술 > 비교 > 논리 > 대입의 순서이며, 단항 > 이항 > 삼항의 순서다.

연산자의 연산 진행방향은 왼쪽에서 오른쪽으로 수행되며,

단항 연산자와 대입 연산자의 경우에는 오른쪽에서 왼쪽으로 수행된다.

switch 연산자

어떠한 값이 맞는다면 해당하는 식을 수행하게끔 만든 연산자이다.

단일 값으로 평가되는 하나의 표현식.

java 15 버전에서는 case를 case -> 로 표현한다고 한다.

public class Main {
    public static void main(String[] args) {
        String day = "월";

        switch (day) {
            case "월":
                System.out.println("월요일");
                break;
            case "화":
                System.out.println("화요일");
                break;
            case "수":
                System.out.println("수요일");
                break;
            case "목":
                System.out.println("목요일");
                break;
            case "금":
                System.out.println("금요일");
                break;
        }
    }
}

이것을

switch (day) {
    case "월" -> System.out.println("월요일");
    case "화" -> System.out.println("화요일");
    case "수" -> System.out.println("수요일");
    case "목" -> System.out.println("목요일");
    case "금" -> System.out.println("금요일");
    case "토", "일" -> System.out.println("주말");
}

이렇게 표현이 가능하다.

if-else문은 원하는 조건이 나올때까지 순서대로 모든 경우를 비교하고

switch문은 jump-table을 사용해서 한번에 원하는 곳에 이동한다.

그래서 if문은 조건문의 개수만큼 O(n)의 시간복잡도를 갖게 되어 성능에 단점이 있고,

switch문은 case의 개수만큼 jump-table을 차지하므로 메모리에 단점이 있다.

때문에 성능면으로 보면 switch문이 더 빨라서

조건이 3개 이상일 경우에는 switch를 사용하는 것이 더 좋다고 한다.

그렇지만 사실 그 차이는 컴파일러의 처리 속도에 따라 차이가 생기는 것이고

요즘 컴파일러들이 워낙 우수하기 때문에 차이가 미비하다고 하다.

if-else 를 쓰든 switch 를 쓰든 (특별히 성능과 메모리의 이슈를 갖고 있지 않은 이상) 각자의 취향이 아닐까.

가독성을 높이는 쪽으로 선택해서 사용하면 될 것 같고

나는 되도록이면 Early Return을 하려고 한다.

String string;

if (조건) {
    string = "참";
} else {
    string = "거짓";
}

이런게 있다고 하면 조건에 부합하는 문자열만 보내주면 된다.

그래서

String string = getString();

public String getString() {
    if (조건) {
        return "참";
    }

    return "거짓";
}

이렇게 분리하는 방법이 좋은것 같다.

이걸 더 분리한다고 치면 이제 공부했던 State패턴을 사용하면 되겠다.

이거는 다시 정리하는것이기 때문에 나중에 객체지향 개념을 들어가게 되면 구체적으로 정리를 해보도록 하겠다.

2주차

주차마다 원래 관리를 해주어야 하는 스터디 이지만 이미 끝났으므로 공부하면 바로 포스팅을 할 계획이다.

• 프리미티브 타입 종류와 값의 범위 그리고 기본 값
• 프리미티브 타입과 레퍼런스 타입
• 리터럴
• 변수 선언 및 초기화하는 방법
• 변수의 스코프와 라이프타임
• 타입 변환, 캐스팅 그리고 타입 프로모션
• 1차 및 2차 배열 선언하기
• 타입 추론, var

primitive 타입 종류와 값의 범위 그리고 기본 값

자바의 변수 타입에는 primitive와 reference 타입 두가지가 있다.
프리미티브 타입의 경우 정수, 실수, 그리고 논리값 으로 이루어져있다.

이 변수의 타입들의 범위는 조금만 생각해보면 왜 저렇게 정해져있는지 알 수 있다.
연관성은 바로 이진수의 제곱 의 범위 이다.

1bit 당 가질수 있는 경우의 수는 2개이다. 0, 1 이렇게 말이다.
그러니까 비트가 늘어날 때마다 자연스럽게 제곱범위로 늘어나는 것이다.
근데 이것을 반으로 갈라서 음수부분, 양수 이렇게 나누기 때문에
범위는 아래 표와 같다. 근데 반이면 반이지 절대값으로 봤을때 1이 차이가 나는데
그 이유는 0 때문에 그렇다.

프리미티브 타입과 레퍼런스 타입

프리미티브 타입은 stack에 적재가 된다.

반대로 레퍼런스 타입은 Heap내에 저장이 된다.

그래서 참조 타입 변수의 주소값에는 직접적인 값이 아니라 Heap 영역에 할당된 주소가 저장이 된다.

참조형 타입에는 클래스(Class) 안에 문자열(String) 포함, 배열(Array), 열거형(Enumeration), interface 가 있다.

int a = 10;
double b = 19.2;
Car c = new Car("제네시스", "gv80");

{: .text-center}

이렇게 저장이 된다고 보면 된다.

참조형 타입에는 빈 객체를 의미하는 null이 존재한다.
예를 들어 객체나 배열을 Null 값으로 받으면 NullPointException이 발생하므로 변수값을 넣어야 한다.

Literal

리터럴은 변수나 상수에 저장되는 값 그 자체이다.

위에서 보면 10이나 19.2가 그에 해당한다.

고정된 값을 표현하는 리터럴은 정수, 실수, 문자, boolean, 문자열 을 표현하는 리터럴 등이 있다.

정수형 리터럴

정수를 표현하는 리터럴은 이렇게 구성되어 있다.

int a = 10;       //10진수 리터럴
int a = 012;      //8진수 리터럴
int a = 0x1a;     //16진수 리터럴
int a = 0b110101; //2진수 리터럴

실수 리터럴

실수 타입의 리터럴은 기본적으로 double 타입이고, float 타입으로 표현하려면 f를 명시적으로 붙여야한다.

double b = 1.1;
double b = 1E-1;
float b = 1.1f; 

문자 리터럴

문자 리터럴은 작은 따옴표 안에 할당할 수 있다.

char a = 'A';

이스케이프 문자열

그리고 이스케이프 문자열을 사용할 수 있다.

{: .text-center}

참조타입인데도 불구하고 리터럴을 지원하는 문자열이다.

문자열 타입은 리터럴 을 지원하는데, 리터럴 방식으로 String 에 값을 주면 Heap 영역에서 String constant pool 이라는 특수한 영역에 값이 저장된다.

동일한 값을 쓰는 경우에 다른 일반적인 레퍼런스타입 처럼 Heap 에 또 올라가지 않고, String constant pool 에 존재하는 값을 참조하는 방식으로 작동한다.

String s1 = "java";
String s2 = "java";

이렇게 하면 둘의 주소는 같다.

그래서 위와같이 주소값은 같아지게 된다.

변수 선언 및 초기화 방법

저번 포스팅에서 봤듯이 클래스의 필드에선 자동으로 선언만 해줘도 초기화가 기본값으로 진행이 된다.

선언을 하는 순간 이 변수를 저장할거야 저장공간을 할당해줘 라고 해석된다.

메소드 내에서는 선언만하고 초기화를 안해준다면

java: variable a might not have been initialized

에러가 발생한다.

그래서 선언만 해주고 진행을 해 나가다가 무조건적으로 결국엔 값을 할당해서 초기화를 시켜주어야 한다는 것이다.

선언과 초기화

선언과 초기화를 같이 진행할 수도 있다.

String s;
s = "java";

String s = "java";

두개 다 사용이 가능한 방법

변수의 스코프와 라이프타입

scope

변수의 스코프는 해당 변수를 사용할 수 있는 영역 범위를 뜻한다.
변수의 경우 scope 에 따라 Instance 변수, class 변수, Local 변수 로 나눌 수 있다.

lifetime

해당 변수가 메모리에 언제까지 살아있는지를 의미한다.

인스턴스 변수

인스턴스 변수는 클래스안에서 생성된 변수이며 필드라고 부른다.

• scope: static 메서드를 제외한 전체
• lifetime: 해당 클래스를 인스턴스화 한 객체가 메모리에서 제거될 때까지

클래스 변수

class 변수는 클래스 내에 필드에 생성이 되지만 static 키워드가 붙어있는 변수

• scope: 클래스 전체
• lifetime: 프로그램 종료시

로컬 변수

Local 변수는 지역변수라고도 부르며 위의 두 변수를 제외한 모든 변수가 이것에 해당된다.

• scope: 변수가 선언된 메서드 내부
• lifetime: 프로그램이 해당 메서드를 제어하는 동안

타입 변환, 캐스팅 그리고 타입 프로모션

타입 변환

자료형이 자기 자신보다 큰 자료형에 넣게되면 그건 타입 변환이 필요없고 자동 캐스팅으로 변환이 된다.

하지만 큰 자료형이 작은 자료형으로 가려면 타입 변환이 필요하다.

int a = 1;
byte b = (byte)a; //변형이 오지 않음

만약 작은 자료형의 데이터 범위를 넘어선 변수가 타입 변환을 한다면?
데이터의 손실이나 변형이 올 수 있다.

int a = 10000;
byte b = (byte)a; //byte 최대 범위를 넘었기 때문에 변형이 생긴다.

타입 프로모션

타입 캐스팅과 반대로 크기가 더 작은 자료형을 더 큰 자료형에 대입하는 것을 의미한다. 예를 들어, byte타입의 데이터를 int타입에 대입하는 경우이다.

이 경우에는 데이터 손실이나, 변형이 오지 않음으로 캐스팅할 때 처럼 명시적으로 적지 않아도 자동으로 변환이 가능하다.

그냥 캐스팅과 프로모션은 같이 생각해야 안 헷갈릴 것 같다 구분하는 필요를 안둬도 될것 같은? 느낌

이 타입 변환들은 primitive 타입에서만 사용되는게 아니라 참조 타입에서도 가능하다.
부모클래스로의 타입변환은 자동적으로 가능하지만 자식클래스로의 타입변환은 타입캐스팅이 필요하다. 하위 클래스는 상위 클래스의 필드나 메소드를 물려받음으로 하위 타입의 객체를 상위 타입으로 바꾼다고 해서 데이터의 손실이나 변형이 일어나진 않으니까 말이다.

1차 및 2차 배열 선언하기

배열은 하나의 동일 타입을 여러개 담을 수 있다.

[]로 감싸진 0으로 부터 시작하는 index가 배열의 길이나 순서를 나타낸다.

배열도 type에 따라 기본 값(default value)로 채워진다. (명시적으로 값을 넣어주지 않는다면)

참조 타입의 경우 Null

1차원 배열

int[] a = new int[5]; //[0,0,0,0,0] 로 초기화
int[] b = {1,2,3,4,5}; // 명시적으로 값을 넣어주면 이대로 초기화가 된다.

int[] c = new int[5];
//값 넣기 이렇게도 가능하다.
c[0] = 1;
c[1] = 2;
c[2] = 3;
c[3] = 4;
c[4] = 5;

1차원 배열은 이렇게 선언하면 된다.

2차원 배열

2차원 배열은 행렬(matrix)를 생각하면 된다.

int[행][렬] = new int[행][렬]

가령 3행 3열의 행렬이 이렇게 있다고 가정하면

1 2 3
4 5 6
7 8 9

자바로 표현되는 선언식은 아래와 같다.

int[][] arr = { {1,2,3}, {4,5,6}, {7,8,9} };

지정된 값 말고 동적으로 추가하는 느낌이라면

int[][] arr = new int[3][3];

for(int i = 0; i < 3; i++) {
    for(int j = 0; j < 3; j++) {
        arr[i][j] = 넣을 변수값
    }
}

하면된다.

타입추론, var

타입 추론이란 데이터 타입을 코드에 명시하지 않아도, 컴파일 단계에서 컴파일러가 타입을 유추해 정해주는 것을 뜻한다. 1.5버전 부터 추가된 Generic 이나 자바 8에서 추가된 람다에서 타입추론이 사용된다. 그리고 자바10 에서는 이러한 타입추론을 사용하는 var 이라는 Local Variable Type-Inference 가 추가되었다.

아직 많이 사용할지는 잘 모르겠다.

• foreach
  • 그냥 우리가 리스트 열거할 때 쓰던 for문, for(Person person : personList) 문에서 변수 선언할 때 var로 쓰면 편하다. 이클립스나 인텔리제이나 for문 쓸때, 타입 추론하기엔 열거 타입을 정의할 때까지 타입을 직접 작성하거나, 템플릿을 작성해야 해서 난감할 때를 많이 겪어봤을 것이다. 이를 var 키워드가 순식간에 해결해준다.

List<Person> people = new ArrayList<>();
people.add(new Person("a"));
people.add(new Person("b"));
people.add(new Person("c"));

for (var person : people) {
    //....
}

이렇게 작성하면 IDE 에서는 var 키워드를 Person 클래스로 인식할 수 있는 기회가 주어지게 되고, 컴파일할 때도 var 키워드를 Person 으로 변환하게 될 것이다. 타이핑이 정말 간결해진다. Object 타입으로 미리 단정지을 필요도 없다.

정리하는 겸 유튜브 백기선님 자바 스터디를 보며 다시 상기시키는 공부를 진행한다.

이미 정식 스터디는 끝났지만 늦게 시작하여 블로그에 따로 기록하려고 한다.

📢 1주차

• JVM이란 무엇인가
• 컴파일 하는 방법
• 실행하는 방법
• 바이트코드란 무엇인가
• JIT 컴파일러란 무엇이며 어떻게 동작하는지
• JVM 구성 요소
• JDK와 JRE의 차이

📌 JVM이란?

JVM이란 Java Virtual Machine(자바 가상 머신) 의 줄임말

일반적인 프로그램은 OS위에서 실행되는데 자바 프로그램 같은 경우에는
OS위의 JVM에서 실행이 된다.

JVM위에서 실행 시키는 이유는 OS에 상관없이 실행시키기 위해서이다.

각기 다른 운영체제에서 실행시키는 이점은 정말 좋다.

📌 JVM의 역할

• 자바 애플리케이션을 클래스 로더를 통해 읽어 들여 자바 API와 함께 실행하는 것이다.
• JVM은 자바와 OS사이에서 중개자 역할을 수행하여 OS에 독립적인 플랫폼을 갖게 해준다.
  • OS의 메모리 영역에 직접 접근하지 않고 JVM을 통해 간접적으로 접근한다.
• JVM은 프로그램 메모리 관리를 알아서 해준다. (GC 자동)

📌 자바 실행과정

1. 프로그램이 실행되면 JVM은 OS로부터 이 프로그램이 필요로 하는 메모리를 할당받는다. 이 메모리를 할당받고 용도에 맞게 여러 영역으로 나누어 관리한다.
2. 자바 컴파일러(javac)가 자바 소스코드(.java)를 읽어들여 자바 바이트코드(.class)로 변환시킨다.
3. 클래스 로더를 통해 class파일들을 JVM으로 로딩한다.
4. 로딩된 class 파일들은 Execution engine을 통해 해석된다.
5. 해석된 바이트코드(.class)는 Runtime Data Areas에 배치되고 수행이 이뤄지게 되는데 여기서 가비지 컬렉터 같은 관리 작업도 수행한다.

{: .text-center}

📌 자바 바이트코드

자바 바이트코드(.class)란 JVM이 이해할 수 있는 언어로 변환된 자바 소스 코드를 의미한다.

자바 컴파일러(javac)에 의해 변환되는 코드의 명령어 크기가 1바이트라서 자바 바이트코드라고 불리고 있다.

📌 JIT 컴파일러란?

JIT(Just-In-Time) 컴파일러는 바이트코드를 CPU로 직접 보낼 수 있는 명령어로 바꾸는 프로그램이다.

일반적으로 컴파일러는 개발자와 최종 사용자를 위한 애플리케이션의 속도를 결정하는데 있어 핵심이다.

JIT 컴파일러는 성능 최적화를 위해 애플리케이션 런타임을 향상시킬 수 있다.

다른 컴파일러와는 다르게 JIT 컴파일러의 특성은 프로그램이 시작되고 코드를 컴파일 한 후에 JIT컴파일러가 실행된다.

📌 JVM 구성요소

• 인터프리터
  • 바이트코드(.class)를 해당 하드웨어의 환경에 맞게 변환을 하여 운영체제에 종속적이지 않은 상태를 만들어줌.
• 클래스 로더
  • 컴파일러가 SSD 내부에 만든 바이트코드 파일을 읽는다.
• 실행엔진(JIT 컴파일러 포함)
  • 로더에 존재하는 클래스를 읽으면서 static이 붙은것을 판단한다.
  • static이 붙은 클래스가 없다면 그대로 종료
• GC(Garbage Collector)
  • 더 이상 사용하지 않는 메모리를 자동으로 회수

📌 JRE, JDK 차이

JRE(Java Runtime Environment) : 컴파일된 자바 프로그램을 실행시킬 수 있는 자바 환경

• JRE는 JVM이 자바 프로그램을 동작시킬 때 필요한 라이브러리 파일들과 기타 파일들을 가지고 있다.
• JRE는 JVM의 실행환경을 구현했다고 할 수 있다.
• 자바 프로그램을 실행 시키기 위해선 JRE를 반드시 설치해야 한다.
• 자바 프로그래밍 을 하기 위해선 JDK가 필요하다.

JDK(Java Development Kit) : 자바 프로그래밍에 필요한 컴파일러 등등 포함

• 개발을 위해 필요한 도구들을 포함한다.
• JDK를 설치하면 JRE도 같이 설치가 된다.
• JDK = JRE + @