구찌의 나도한번 해블로그

서버 이중화의 종류는 무엇이 있을까?

KOOCCI — Sun, 21 Aug 2022 12:45:32 +0900

목표 : 서버 이중화 종류에 대해 설명할 수 있다.

VM 환경에서는 상용 서버에 대해 이중화 이상을 적용하는 것이 바람직하다.

하나의 서버가 죽더라도 다른 서버가 적절히 실행되어 서비스가 중단이 없어야 하기 때문이다.

그 종류는 사실 다양하다.

API 서버의 경우, 부하 분산 등을 생각해 Active-Active 구조로 설정될 수 있지만, Active-standby나, master-slave 구조를 가지는 것도 많다.

그럼 이런 종류들에 대해 정리해 보도록하자.

Active-Active 구조

Active 서버의 기준은 현재 정상 동작하고 있는가? 이다.

부하를 분산시켜 줄 수 있는 L4 스위치 등 LoadBalancer가 있고, Active 서버에 요청을 적절히 분배한다.

따라서 부하에 따라, Active 서버의 갯수를 늘리며, Scale-Out을 시킬 수도 있다.

2대 이상으로 구성된 Active-Active 구조에서는 한 서버가 장애가 나더라도, 지속 운영이 가능하고 Down되는 시간이 없다.

매우 좋아보이지만, 특정 상황에서는 쉽지 않은 경우도 있다.

예를 들면, DB 서버의 경우, 지원하는 DBMS도 적고, Active-Active 상황이다 보니, 그만큼 스토리지에 대해서 병목 현상이 발생할 수 있다

Active-Standby 구조

Standby 서버의 기준은 Active 서버를 대신할 수 있는가? 이다.

Active 중이던 서버가 장애가 발생하는 등, 어떤 이벤트가 발생했을 때 Active 서버 대신해서 Request를 받아 낸다.

보통, Application의 HeartBeat를 측정하는 솔루션이 있어서, 이벤트 발생 시, Active서버를 전환시키거나 수동으로 처리하는 경우가 많다.

예를 들면 DB 서버가 있다고 하자.

사용하고자 하는 DBMS가 Active-Active를 지원하지 않아서, Storage를 공유하는 2대의 DB 서버는 Active-Standby로 구성되었다.

그럼 특정 솔루션에서는 Active 서버의 상태를 확인하다가 장애가 났을 때(failover), Standby 서버로 전환해준다. (수초에서 수분 소요될 수 있음)

전환되는 시간이 소요되어, 그 시간동안은 이슈인 상황이지만 그래도 에러 상황을 빠르게 복구시킬 수 있다.

또한 standby 서버에는 실제로 요청이 들어오는 경우가 거의 없으므로, Active 서버만 동작하기 때문에 동기화에 큰 무리가 따르지 않는다.

Master-Slave 구조

이번엔 조금 다른 개념으로 넘어왔다.

Master 서버의 기준은 CUD가 가능하다는 것이다. 그에 비해, Slave 서버는 Read가 가능하다.

역할이 달라지는 것이며, 그에 따라 트래픽이 분산될 수 있다.

Master는 데이터 동시성이 아주 높은 트랜잭션을 담당하고, Slave는 데이터 동시성이 꼭 필요없는 경우에 읽기 전용으로 데이터를 가져온다.

Master가 Slave에게 데이터를 알려주는 구조는 다음과 같다.

Master DB에 Data가 변경될 시, Master DB에 반영
변경 이력을 Binary Log로 저장
Slave DB에게 이벤트 전송
Slave IO Thread에서 이벤트를 받고, Binary Log를 Slave DB 각각의 Relay Log에 저장
Slave SQL Thread에서 Relay Log를 읽어 Slave DB 업데이트
읽기 처리 시, Slave DB를 사용

다만, 데이터가 들어오는 양이 많아진다면, Master가 Slave에게 알려주기 전에 SELECT 요청이 들어올 수 있다.

이를 복제 지연이라고 하며, 이럴 때는 임시로 Master에게도 Select Query가 가능하도록 만들어 주기도 한다.

Wrap Up

결국 서버의 역할을 용어를 통해 분리한 것이였다.

위 개념을 잘알아두고, 서버 세팅 시에 잘 이해할 수 있도록 하자.

@Transactional은 어떻게 쓰는것일까?

KOOCCI — Sun, 21 Aug 2022 00:02:42 +0900

목표 : @Transactional의 사용법을 설명할 수 있다.

Transaction을 유지하는 방법 정도로 알고 있는 Annotation에서 벗어나서, 조금 더 자세히 알아보도록 하자.

그동안은 어떻게 써왔는가?

일단 로직이 길 수 밖에 없는 상황에 써왔다. 다시 말해 쓸 수 밖에 없었다.

Transactional을 통해 묶어주어야, 2개 이상의 쿼리에 대해 DB Commit 과 Rolback이 가능하도록 관리된다고 알고 있었고, 연동 구간이 길 수 밖에 없는 로직, 예를 들면 기기제어, 각종 로그인, UI를 통한 컨텐츠 변경 등의 작업이 필요할 때마다 Service에서 사용하는 Method에 @Transactional를 설정하여 처리했다.

과연 난 잘 써왔을까?

Transaction

Transaction을 모르고 사용하는 사람은 없을 것이다.

그러니 한번 정도는 정리하고 가보자.

우선 Transaction은 상호작용의 단위이다.

데이터베이스 관리 시스팀 혹은 그와 유사한 시스템에서 사용하는 상호작용의 단위라고 할 수 있다.

ACID라고 하는 특징을 가진 변화에 있어서의 한 단위로 다시 말할 수 있다.

Transaction이라는 한 묶음은 ACID(Atomic, Consistency, Isolation, Durability)를 보장한다.

다시 말해, Transaction이라는 단위는 독립적이고, 원자성을 가지며, 일관성있게 영구적인 상태를 가지게 된다.

데이터는 변화에 민감해야 하며, 서로에게 영향을 행사할 수 없는 독립성(Isolation)을 가진다.

또한, 중간에 흐트러지지 않는, 어줍잖게 되고 있는 그 중간같은 값이 없이, 되거나 안되거나, 0 or 1 영역의 원자성(Atomic)을 가져야 한다.

이런 행위 전후에는 데이터베이스가 가지고 있는 제약이나 규칙에 위배되지 않고 일관성(Consistency)을 지켜야 한다.

마지막으로, 성공적인 수행 이후에는 계속 유지되는 지속성(Durability)이 있어야 한다.

Spring에서의 Transaction 설명

그럼 내부를 살펴보기 전에, Spring에서는 어떻게 설명하고 있는지 확인해보자.

Transaction Management

먼저, Spring에서의 Transaction 관리의 이점은 다음과 같다.

A consistent programming model across different transaction APIs, such as Java Transaction API (JTA), JDBC, Hibernate, and the Java Persistence API (JPA).

JTA(Java Transaction API), JDBC, Hibernate 및 JPA(Java Persistence API)와 같은 다양한 트랜잭션 API에서 일관된 프로그래밍 모델.

Support for declarative transaction management.

선언적 트랜잭션 관리를 지원

A simpler API for programmatic transaction management than complex transaction APIs, such as JTA.

JTA와 같은 복잡한 트랜잭션 API보다 프로그래밍 방식의 트랜잭션 관리를 위한 더 간단한 API

Excellent integration with Spring’s data access abstractions.

Spring의 데이터 접근 추상화와의 탁월한 통합.

Advantages of the Spring Framework’s Transaction Support Model

java EE 개발자는 Global Transaction이나 Local Transaction을 활용해 Transcation을 관리했다. 그러나, 둘 다 한계가 있다.

Local Transaction
쉽게 표현하면, 하나의 DB와의 연결이다. JDBC Connection 등 전용 리소스를 사용한다.
단점은, 여러 Transaction Resource인 상황에선 유효하지 못하다. Global Transaction 에서는 실행할 수 없다는 것이다.

Global Transaction
여러 개의 DB 작업을 하나의 트랜잭션으로 묶는다. Java는 이를 위해 JTA(Java Transaction API)를 제공한다.

Local Transaction이냐, Global Transaction이냐에 따라 코드도 다르고, 어떤 DB에 접근하냐에 따라 사용하는 트랜잭션 코드가 달라진다. 즉, Data Access 기술에 종속이 되어 버린다.

그리고 스프링은 트랜잭션 기술의 공통점을 모아, 추상화를 제공한다.

Spring Framework’s Consistent Programming Model

스프링은 일관성 있는 프로그래밍 모델을 지원한다. 즉, Global Transaction과 Local Transaction의 단점들을 해소해준다.

결과적으로 각기 다른 환경에서 다른 트랜잭션 관리 전략을 쓰더라도, 코드는 한 번만 작성하면 된다.

스프링에서는 Declarative & programmatic transaction management를 둘다 지원한다.

보통, Declarative transaction management를 선호하며 권장한다.

이렇게 추상화된 상태라면, 트랜잭션 관리와 관련된 코드를 아예 작성하지 않거나 매우 조금만 참여하며, 어플리케이션 개발에 집중할 수 있다.

Understanding the Spring Framework Transaction Abstraction

그럼 스프링에서 어떻게 추상화 했는지 알아보자.

스프링에서는 the notion of a transaction strategy, 트랜잭션 전략이라는 개념이 들어간다.

트랜잭션 전략은 TransactionManager, 그 중에서도 imperative(명령형) TransactionManager인 PlatformTransactionManager 와 reactive(반응형) transaction management인 ReactiveTransactionManager가 있다.

public interface PlatformTransactionManager {
   TransactionStatus getTransaction(@Nullable TransactionDefinition definition) throws TransactionException;
   void commit(TransactionStatus status) throws TransactionException;
   void rollback(TransactionStatus status) throws TransactionException;
}

여기서 TransactionException은 모두 Unchecked Exception (RuntimeException을 상속)한 것이다.

트랜잭션 인프라의 장애는 거의 예외없이 치명적이고, 드물게 트랜잭션 실패를 App에서 복구한다면, TransactionException을 잡아서 처리할수도 있다. 즉, 개발자가 예외를 처리하도록 강요하지 않는다.

다시 말해, Spring에서는 Checked Exception에 대해서는 Rollback이 되지 않도록 Default로 설정되었다. (rollbackFor로 수정할 수 있다)

Checked Exception은 복구가 가능하다는 매커니즘을 갖고 있기 때문이다.

예를 들면, 파일이 없을 때는 Default이미지를 catch에서 선택하는 등의 복구전략이 있다는 것이 전재이므로, Rollback을 처리하지 않는게 Default이다.

getTransaction() 메서드는 TransactionDefinition 파라미터에 따라, TransactionStatus를 반환한다.

TransactionDefinition

public interface TransactionDefinition {
   int PROPAGATION_REQUIRED = 0;
   int PROPAGATION_SUPPORTS = 1;
   int PROPAGATION_MANDATORY = 2;
   int PROPAGATION_REQUIRES_NEW = 3;
   int PROPAGATION_NOT_SUPPORTED = 4;
   int PROPAGATION_NEVER = 5;
   int PROPAGATION_NESTED = 6;
   int ISOLATION_DEFAULT = -1;
   int ISOLATION_READ_UNCOMMITTED = Connection.TRANSACTION_READ_UNCOMMITTED;
   int ISOLATION_READ_COMMITTED = Connection.TRANSACTION_READ_COMMITTED;
   int ISOLATION_REPEATABLE_READ = Connection.TRANSACTION_REPEATABLE_READ;
   int ISOLATION_SERIALIZABLE = Connection.TRANSACTION_SERIALIZABLE;
   int TIMEOUT_DEFAULT = -1;
   int getPropagationBehavior();
   int getIsolationLevel();
   int getTimeout();
   boolean isReadOnly();
   @Nullable
   String getName();
}

많은 사항들이 있고, 주석으로 설명이 있지만, 간략하게 특수한 용어들만 먼저 정리해보자

Propagation(전파) : 동작 도중 다른 트랜잭션을 호출할 때, 어떻게 할 것인지를 지정
기본적으로 트랜잭션 범위 내에 있는 모든 코드는 해당 트랜잭션에서 실행된다. 단, 트랜잭션 컨텍스트가 이미 있는 상태에서 트랜잭션 메소드를 실행하는 경우엔 동작 방식을 지정할 수 있다. 예를 들어 기존 트랜잭션에서 코드를 계속 실행하거나 (일반적), 기존 트랜잭션을 일시 중단하고 새 트랜잭션을 만들 수 있다.

Isolation(고립) : 이 트랜잭션 작업과 얼마나 격리할 것인지를 나타내는 척도, 일관성없는 데이터 허용 수준 (격리 수준)
예를 들어, 현재 트랜잭션은 다른 트랜잭션에서 커밋하지 않는 쓰기를 볼 수 있는가?

TimeOut(타임 아웃) : 트랜 잭션의 실행 시간으로, 타임 아웃 시, Rollback

Read-Only(읽기 전용) : 데이터를 수정하지 않고, 읽기만 하는 상태

TransactionStatus

public interface TransactionStatus extends TransactionExecution, SavepointManager, Flushable {
    @Override
    boolean isNewTransaction(); // 새로운 트랜잭션 존재 여부
    boolean hasSavepoint(); // 현재 일치하는 트랜잭션이 존재하는가
    @Override
    void setRollbackOnly(); // rolbakc이 가능한가?
    @Override
    boolean isRollbackOnly(); //rollback이 되었는가?
    void flush(); // 실제 DB에 동기화
    @Override
    boolean isCompleted(); // 트랜잭션 완료 여부
}

TransactionStatus를 통해, 간단한 코드로 트랜잭션 실행을 제어하고, 상태를 확인할 수 있다.

Declarative Transaction Management

스프링 프레임워크 사용자 대부분이 Declarative Transaction Management(선언적 트랜잭션 관리)를 선택한다.

Application 코드에 미치는 영향이 가장 적기 때문에, 이상에 알맞다.

스프링에서 Declarative Transaction management는 AOP덕분에 가능한 방법이다.

트랜잭션 지원은 AOP Proxy를 통해 활성화되며, 트랜잭션 advice는 메타데이터(XML 혹은 Annotation)로 구동된다는 점이다. 트랜잭션 메타데이터를 가지고 만든 AOP Proxy는 TransactionInterceptor와 적당한 TransactionManager 구현체를 사용해 메소드 호출을 둘러싸고 트랜잭션을 실행한다.

Transactional Proxy

Using @Transactional

// the service class that we want to make transactional
@Transactional
public class DefaultFooService implements FooService {

    Foo getFoo(String fooName) {
        // ...
    }

    Foo getFoo(String fooName, String barName) {
        // ...
    }

    void insertFoo(Foo foo) {
        // ...
    }

    void updateFoo(Foo foo) {
        // ...
    }
}

클래스 레벨에 사용하는 Annotation은, 선언하는 클래스(하위 클래스도)의 모든 메소드에 적용할 기본값을 나타낸다.

물론 메소드마다 개별로 Annotation을 달아도 된다. 다만, 클래스 계층 구조 상 위에 있는 클래스엔 적용되지 않으며, 상속된 메서드는 subclass 레벨의 Anntation에도 포함되려면 재정의(redeclared)되어야 한다.

이제 큰 2가지 사항에 대해 확인해볼 것이다.

public 메서드에만 적용해야 한다.
같은 객체에 있는 다른 Method를 호출하면, 트랜잭션이 적용이 되지 않는다.

Transactional Proxy를 사용할 때는 public 메서드에만 적용해야 한다.

protected, private에 선언해도 에러는 아니지만, 정상적인 동작을 하지 않는다. (내부 메서드 호출과 동일한 이유)

만약 필요하다면, AspectJ를 사용하는 것이 좋다.

@Transactional Annotation은 인터페이스 정의나 인터페이스의 메서드, 클래스 정의, 클래스 public 메서드에 적용할 수 있다.

다만, 인터페이스 대신 구체적인 클래스(구체적인 클래스의 메서드)에 선언하기를 권장한다.

인터페이스에 적용할 경우, Interface-based Proxy를 사용할 때만 의도대로 동작한다.

만약, class-based Proxy를 사용하거나 weaving-based aspect를 사용한다면, 트랜잭션 세팅은 proxy와 weaving infrastructure에게 인지되지 않고, 객체는 transactional proxy에 감싸지지 않을 것이다.

위 설명을 다시 정리해보면, Spring AOP는 Proxy 기반으로 만들어져, Target Method가 호출되는 시점에 부가기능을 추가할 메소드를 자체적으로 판단하여, 부가기능을 주입한다. 즉, Runtime에 Weaving한다고 하여, Runtime Weaving이라고 한다.

이 Runtime Weaving 기능을 Spring 에서는 CGLib Proxy와 JDK Proxy를 상황에 따라 번갈아가며 사용한다.

SPring AOP Proxy

JDK Dynamic Proxy는 인터페이스를 구현하여 Proxy를 생성해주고, CGLib(Code Generator Library) Proxy는 클래스를 상속받아 Proxy를 생성한다.

그리고, Spring은 CGLib Proxy 를 기본으로 권장하는 것이다.

또 다른 한가지, 같은 객체에 있는 다른 Method를 호출하면, 트랜잭션이 적용이 되지 않는다.

이는 Proxy의 특징으로, Transaction에 의한 AOP Proxy를 예로 들면, Target Object 메서드 호출 전에, Transaction이 시작하고 호출 후에 commit or rollback된다.

즉, Proxy는 Client가 Target Object를 호출하는 과정에만 동작한다.

그 말은, Target Object에서, 자신의 다른 Method를 호출하면 프록시는 정상적으로 동작하지 않는다.

프록시를 통하지 않고 다른 Method가 호출이 되며, @Transactional Annotation이 있더라도 동작하지 않는다.

다음 예시를 보자.

출처: https://springsource.tistory.com/135 [Rednics Blog:티스토리]

@Transactional
public class MemberService {
  
  @Transactional(propagation=Propagation.REQUIRES_NEW)
  public void add(Member m) {...}
  
  public void complex() {
    ...
    this.add(new Member(...));
  }
  ...
}

클래스 전체에 Transactional이 걸려있고, 내부에 method에도 걸려있다.

이 때, Client로부터 complex()라는 게 호출된다면, 그전에 Proxy를 먼저 타게 될 것이고, Class에 적용된 Annotation에 따라 Proxy에서 트랜잭션이 시작된다.

문제는, 그 안에 있는 this.add 메서드의 실행이다.

이미 Proxy를 통과해서 들어온 상황이라, add 메서드는 트랜잭션 속성이 반영되지 못한다.

즉, add 메서드는 호출이 되었지만, 새로운 트랜잭션이 생성되는 것이 아니고, complex() 에서 시작된 트랜잭션에 그냥 참여될 뿐이다.

이에 대한 해결방법은 모드를 Proxy가 아닌 AspectJ 모드를 사용하는 방법이 있다. 이 방법은 프록시 없이 Weaving을 통해(바이트 코드를 수정해서) @Transactional 을 Target Class에 있는 모든 메소드의 런타임 동작으로 전환한다.

@Transactional Settings

Property	Type	Description
value	String	사용할 트랜잭션을 지정하는 생략 가능한 한정자 (qualifier)
transactionManager	String	value의 Alias
label		Transaction에 표현적인 설명을 추가하기 위한 문자열 라벨의 배열
propagation	enum: Propagation	생략 가능한 전파 설정
isolation	enum: Isolation	생략 가능한 고립 수준. propagation이 REQUIRED나 REQUIRES_NEW일 때만 적용할 것.
timeout	int (in seconds of granularity)	생략 가능한 트랜잭션 타임 아웃. propagation이 REQUIRED나 REQUIRES_NEW일 때만 적용할 것.
timeoutString	String (in seconds of granularity)	타임 아웃을 String 값(EX> placeholder)으로 대신 사용할 수 있음.
readOnly	boolean	읽기/쓰기 versus 읽기 전용 트랜잭션. propagation이 REQUIRED나 REQUIRES_NEW일 때만 적용할 것.
rollbackFor	Array of Class objects, which must be derived from Throwable.	롤백을 유발해야 하는 exception 클래스 배열. 생략 가능
rollbackForClassName	Array of exception name patterns.	롤백을 유발해야 하는 exception 클래스 이름의 배열. 생략 가능
noRollbackFor	Array of Class objects, which must be derived from Throwable.	롤백을 유발하지 않을 exception 클래스 배열. 생략 가능
noRollbackForClassName	Array of exception name patterns.	롤백을 유발하지 않을 exception 클래스 이름의 배열. 생략 가능

propagation

앞서, Propagation(전파)은 동작 도중 다른 트랜잭션을 호출할 때, 어떻게 할 것인지를 지정이라고 정리했다.

그 설정값들을 정리해보자.

REQUIRED : default 값. 현재 활성화된 트랜잭션이 존재하면, 해당 트랜잭션에 비즈니스 로직을 Append, 없다면 새로운 트랜잭션 생성

SUPPORTS : 활성화된 트랜잭션이 있으면 해당 트랜잭션을 사용, 없다면 트랜잭션 없이 실행

MANDATORY : 활성화된 트랜잭션이 있으면 해당 트랜잭션을 사용, 없다면 예외 발생

NEVER : 활성화된 트랜잭션이 존재하면 예외 발생, 없다면 트랜잭션을 사용하지 않음.

NOT_SUPPORTED : 활성화된 트랜잭션이 존재하면 보류, 비즈니스 로직을 트랜잭션 없이 실행.

REQUIRES_NEW : 항상 새로운 트랜잭션을 시작. 이미 진행중인 트랜잭션이 존재하면, 해당 트랜잭션을 잠시 보류.

NESTED : 활성화된 트랜잭션이 존재하면, 해당 트랜잭션의 세이브 포인트를 기록. 중첩 트랜잭션을 만들어 진행하는데, 비즈니스 로직에 예외가 발생하면 세이브 포인트로 롤백.

isolation

isolation(고립)은 ACID의 한 요소로, 이 트랜잭션 작업과 얼마나 격리할 것인지를 나타내는 척도, 일관성없는 데이터 허용 수준 (격리 수준)이라고 정리했다.

이 때, 그 정도에 따라 발생할 수 있는 동시성의(concurrency) side effects로, 3가지가 존재한다.

Dirty Read

A 트랜잭션에서 완전히 반영되지 않은 데이터를 B 트랜잭션이 읽을 수 있다.

만약, A 트랜잭션이 롤백되면, 데이터 불일치가 나온다.

Non-repeatable Read

A 트랜잭션이 조회중인 정보를 트랜잭션 B에서 수정하고 커밋하면, A 트랜잭션 내에서 재조회했을 때, 수정된 데이터가 조회된다 (이전 데이터는 다시 조회할 수 없다). 즉, 반복해서 같은 데이터를 읽을 수 없는 경우 (트랜잭션 내에서 결과가 일관성을 가지지 못한다)

Phantom Read

외부에서 수행되는 삽입/삭제로 인해, 트랜잭션 내에서의 동일한 쿼리가 다른 값을 반환

위 Side Effect로 인해, 격리 수준을 4단계로 제공하고, 그 설정값이 다음과 같다.

DEFAULT : 기본 격리 수준 (DB 설정에 종속한다.)

READ_UNCOMMITED(Level 0) : 커밋되지 않는 데이터에 대한 읽기를 허용한다.

- Dirty Read가 발생할 수 있다.

READ_COMMITED(Level 1) : 커밋된 데이터에 대해서만 읽기 허용한다. (데이터 변경 중에는 접근 불가)

- Dirty Read 방지

REPEATEABLE_READ(Level 2) : 동일 필드에 대해 다중 접근 시 모두 동일한 결과를 보장

- 트랜잭션이 완료될 때까지 SELECT 문장이 사용하는 모든 데이터에 Shared Lock이 걸리므로 다른 사용자는 그 영역에 해당하는 데이터에 대한 수정이 불가

- 선행 트랜잭션이 읽은 데이터는 트랜잭션이 종료될 때까지 후행 트랜잭션이 갱신하거나 삭제가 불가능하기 때문에 같은 데이터를 두번 쿼리했을 때, 일관성을 가진다.

- Non-Repeatable Read 방지

SERIALIZABLE(Level 3) : 가장 높은 격리, 성능 저하의 우려가 있음

- 데이터의 일관성 및 동시성을 위해 MVCC(Multi Version Concurrency Control)을 사용하지 않음.

- 트랜잭션이 완료될 때까지 SELECT 문장이 사용하는 모든 데이터에 shared lock이 걸리므로 다른 사용자는 그 영역에 해당되는 데이터에 대한 수정 및 입력이 불가능

- Phantom Read 방지

MVCC : 다중 사용자 데이터베이스 성능을 위한 기술로 데이터 조회 시, LOCK을 사용하지 않고 데이터의 버전을 관리해 데이터의 일관성 및 동시성을 높이는 기술)

따라서, 격리 수준에 따라 문제점 발생 도표는 다음과 같다.

Isolation Level	Dirty Read	Non-Repeabtable Read	Phantom Read
Read Uncommitted	O	O	O
Read Committed	-	O	O
Repeatable Read	-	-	O
Serializable	-	-	-

이제 Annotation을 보자.

@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface Transactional {

   @AliasFor("transactionManager")
   String value() default "";

   @AliasFor("value")
   String transactionManager() default "";

   Propagation propagation() default Propagation.REQUIRED;

   Isolation isolation() default Isolation.DEFAULT;

   int timeout() default TransactionDefinition.TIMEOUT_DEFAULT;

   boolean readOnly() default false;

   Class<? extends Throwable>[] rollbackFor() default {};

   String[] rollbackForClassName() default {};

   Class<? extends Throwable>[] noRollbackFor() default {};

   String[] noRollbackForClassName() default {};

}

대부분의 설정값을 이해할 수 있을 것이며, 이제 최종적으로 정리해보자.

Wrap Up

아주 길게 Transactional에 대해 정리해보았다.

생각보다 양이 굉장히 많아서 놀랬다.

우선 하나씩 다시 정리해보자.

Transaction은 상호작용의 단위이며, ACID를 보장하는 한 변화의 단위이다.

ACID는 Atomic, Consistency, Isolation, Durability 이며, 원자성, 일관성, 격리, 지속성을 말한다.

Spring에서 Transaction은 추상화를 통해, Global Transaction과 Local Transaction으로 나누어 처리하던 로직을 간소화하였다.

선언적 Transaction Management에서 PlatformTransactionManager 이라는 인터페이스를 Transaction 전략으로 사용하였다.

이 때, getTransaction, commit, rollback 3개의 메서드를 가지고 있으며, Exception은 TransactionException으로 unchecked Exception을 관리한다.

getTransaction() 메서드는 트랜잭션을 시작하는 것과 동일하고, TransactionDefinition 파라미터에 따라, 간단한 코드로 트랜잭션 실행을 제어하고, 상태를 확인할 수 있도록 TransactionStatus를 반환한다.

Spring에서 Declarative Transaction management는 AOP Proxy로 관리된다. Proxy 패턴으로 Target 전에 Transaction이 실행된다.

@Transactional Annotation은 클래스나 인터페이스 혹은 그 메서드에 선언될 수 있으나, 인터페이스보다는 클래스나 그 메서드에 선언되는 것을 권장한다.

JDK Dynamic Proxy의 경우, Interface 기반의 Transaction 설정으로 되었을 때 동작하지만, 클래스나 그 메서드에 선언되어 있을 때는 동작하지 않는다.

따라서, CGLib Proxy를 통해, Runtime Weaving 될 때, 바이트 코드를 만들어 버리는 형태로 진행해야 클래스나 그 메서드에서 정상적으로 동작할 수 있다.

@Transactional는 public 메서드에만 적용해야 하며, 같은 객체에 있는 다른 Method를 호출하면, 트랜잭션이 적용이 되지 않는다.

Proxy로 적용되는 흐름 상, 내부 메서드 호출은 Proxy를 타지 않기 때문이며, 외부 노출이 안되면 실행이 안되기 떄문이다.

@Transactional에는 여러 설정이 있고, propagation, Isolation, timeout, RollbackFor 등이 있다.

propagation은 한 트랜잭션에서 다른 트랜잭션이 실행될 때, 어떻게 전파되는지를 설정한다.

Default로 REQUIRED 이며 이미 진행되는 트랜잭션이 있으면, 해당 트랜잭션에 소속되며 아니면 새롭게 생성된다.

isolation은 ACID에도 포함되는 격리성이다.

격리 레벨에 따라 Side Effect로 3가지, Dirty Read, Non-repeatable Read, phantom Read 가 나올 수 있다.

격리 레벨은 총 4개 (default 포함 5개)로 구분되며 각각 Side Effect가 나올 수 있는지 여부가 판단된다.

DEFAULT, READ_UNCOMMITED, READ_COMMITED, REPEATABLE_READ, SEARIALIZABLE 이다.

그럼 나는 @Transactional을 잘 쓰고 있었을까?

용도는 맞았을 지도 모르겠다. 그러나 그냥 남들 쓰는 걸 보고 썼다.

@Transactional(value="transactionManager", propagation = Propagation.REQUIRED, rollbackFor = Exception.class)

거의 대부분의 코드에 쓰인 내용이다.

rollbackFor 정도를 제외하면 설정이 없어도 될 정도다.

rollbackFor에 Exception.class를 적용한 이유는 아마, 반드시 처리되어야 할 Checked Exception이 발생했을 때, 이를 unChecked Exception으로 바꾸어 던지기보다, 간편했기 때문일 것이다.

쉽지 않은 작업이지만, 구체적으로 Throw를 날릴 수 있도록 연습해야할 것이다.

[Spring] @SpringBootApplication은 무엇이 다를까?

KOOCCI — Fri, 19 Aug 2022 03:12:04 +0900

목표 : @SpringBootApplication의 Annotation에 대해 설명할 수 있다.

앞서, Spring 자체가 EJB로 서버개발이 너무 어려워, 그에 대한 대체/보완으로 나온 프레임워크라는 것을 배웠다.

그럼에도 점차 발전한 Spring은 SpringBoot를 내놓으며, 더 간소화된 내용으로 제공하고 있다.

그리고, SpringBoot에는 @SpringBootApplication이 main 실행의 Annotation으로 존재하며, SpringBoot와 Spring을 비교했을 때, 그 차이점에 포함된다.

그럼 무엇이 다른지 알아보자.

@SpringBootApplication은 어떻게 생겼을까?

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
      @Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication {

   @AliasFor(annotation = EnableAutoConfiguration.class)
   Class<?>[] exclude() default {};

   @AliasFor(annotation = EnableAutoConfiguration.class)
   String[] excludeName() default {};

   @AliasFor(annotation = ComponentScan.class, attribute = "basePackages")
   String[] scanBasePackages() default {};

   @AliasFor(annotation = ComponentScan.class, attribute = "basePackageClasses")
   Class<?>[] scanBasePackageClasses() default {};

   @AliasFor(annotation = ComponentScan.class, attribute = "nameGenerator")
   Class<? extends BeanNameGenerator> nameGenerator() default BeanNameGenerator.class;

   @AliasFor(annotation = Configuration.class)
   boolean proxyBeanMethods() default true;
}

Indicates a configuration class that declares one or more @Bean methods and also triggers auto-configuration and component scanning. This is a convenience annotation that is equivalent to declaring @Configuration, @EnableAutoConfiguration and @ComponentScan

하나 이상의 @Bean 메서드를 선언하고 AutoConfiguration 및 ComponentScan을 트리거하는 구성 클래스를 나타냅니다. @Configuration, @EnableAutoConfiguration 및 @ComponentScan을 선언하는 것과 동일한 편리한 주석입니다.

@SpringBootApplication 의 주석을 지운 소스코드와 제일 상단에 있는 주석 내용이다.

Annotation들을 하나씩 파헤쳐 보면서, 그 의미를 찾아보자.

@Target(ElementType.TYPE)

@Target은 어디에 이 Annotation을 어디에 쓸 수 있는가? 에 대한 내용이다.

TYPE : Class, interface (including annotation type), or enum declaration

Enum인 ElementType으로 정의되어 있으며, TYPE의 경우, Class, Interface, Enum에 사용할 수 있다는 뜻이다.

Wiki에 따르면, Built-in Annotation 중, Meta-Annotation 중 하나로, 다른 Annotation에 적용된 Annotation이다.

TYPE 외에도 FIELD (Bean이 ANNOTATION_TYPE과 함께 대표적인 FIELD가 적용되는 Annotation이다.), METHOD(@Autowired에는 FIELD, CONSTRUCTOR, PARAMETER, METHOD, ANNOTATION_TYPE이 들어간다) 등 다양하니 다음 링크를 보면 그 리스트를 알 수 있다.

@Retention(RetentionPolicy.RUNTIME)

다음은 @Retention 이라는 Annotation이며 언제까지 살아있는가?(LifeCycle) 를 의미한다.

@SpringBootApplication 의 경우, RUNTIME시에 유지된다는 것을 알 수 있다. (@Retention도 @Retention이 걸려있는 걸 보면 재미있는 요소다(재귀?))

RetentionPolicy의 경우, 3개로 구성되어 있는데, 다음과 같다.

SOURCE
CLASS
RUNTIME

SOURCE의 경우, 이 Annotation은 .java 파일(소스코드 파일) 까지만 남아있게 된다. (컴파일시 사라짐)

Lombok의 @Getter를 보자.

@Target({ElementType.FIELD, ElementType.TYPE})
@Retention(RetentionPolicy.SOURCE)
public @interface Getter {

SOURCE로 선언이 되어 있다. 즉, 컴파일 시, 사라진다.

그 이유는 Lombok에서 바이트 코드를 생성해서 넣어주기 때문에, 컴파일 시 사라져도 상관없기 때문이다.

그래서, Lombok을 Gradle에 Dependency로 넣어줄 때, 컴파일 때만 적용해두면 되기 때문에 아래처럼 CompileOnly로 적용한다.

compileOnly 'org.projectlombok:lombok'

RUNTIME의 경우, 실행되어 메모리에 올라왔을 때도, 남아있게 된다.

즉, 실행중인 도중에도, 어노테이션 정보가 필요한 상황에 사용한다. (Controller, Service 모두 실행중에 ComponentScan이 가능해야 한다)

CLASS의 경우, .class 파일(컴파일 후 생성코드)까지 남아있게 된다.

이에 대해서는 잘 모르던 부분인데, 다음 글의 댓글에 적혀있어 남겨둔다.

.java 뿐 아니라 .class로 만들어진 파일(라이브러리 등)에 대해서도 어노테이션 정보를 가지고 와서 보여주기 위함이다. (IDE에서 자주 사용한다)

@Documented

@Documented는 JavaDoc 생성 시, Anntation에 대한 정보도 보여줄 수 있도록 설정하는 것이다.

@Inherited

Annotation이 상속되도록 설정하는 것이다.

@SpringBootConfiguration

Indicates that a class provides Spring Boot application @Configuration. Can be used as an alternative to the Spring's standard @Configuration annotation so that configuration can be found automatically (for example in tests).
Application should only ever include one @SpringBootConfiguration and most idiomatic Spring Boot applications will inherit it from @SpringBootApplication.

클래스가 Spring Boot 애플리케이션 @Configuration을 제공함을 나타냅니다. 구성을 자동으로 찾을 수 있도록(예: 테스트에서) Spring의 표준 @Configuration 주석에 대한 대안으로 사용할 수 있습니다. 애플리케이션에는 @SpringBootConfiguration이 하나만 포함되어야 하며 대부분의 관용적인 Spring Boot 애플리케이션은 @SpringBootApplication에서 이를 상속합니다.

위 설명에 따르면, @Configuration과 동일한 기능을 하지만, 단 한 개만 쓸 수 있는 Annotation이라고 한다.

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Configuration
@Indexed
public @interface SpringBootConfiguration {

그리고, 내부적으로 @Configuration을 가지고 있다는 것을 알 수 있다.

또한, SpringBootTest 시, 그 정보를 자동으로 찾을 수 있다는 장점이 있다.

@EnableAutoConfiguration

사실 기존 Spring에서 Spring Boot로 바뀔 때, 가장 간편해지는 요소 중 하나가 Configuration의 자동화다.

@EnableAutoConfiguration은 spring.factories에 있는 자동 설정들을 실행 시에 적용시키는 것이다.

다음과 같은 설정 파일들이 있고, 이를 별도의 작업없이 자동으로 적용할 수 있다.

해당 클래스패스에 Configuration관련 사항이 존재할 때만 실행되며, 만약 쓰고 싶지 않다면 exclude도 가능하다.

@ComponentScan

@ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
      @Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })

전체를 다 긁어보면 위와 같다.

앞서 말했지만, @ComponentScan은 @Configuration과 @Bean 및 @Component의 하위 어노테이션(@Repository, @Service, @Controller, @RestController, @ControllerAdvice, @RestControllerAdvice)이 있는 클래스 및 메소드를 찾아, Spring Container에 등록한다.

그런데 옆이 @Filter를 포함해 많은 내용이 있다.

한번 보도록 하자.

먼저 excludeFilters를 통해, 자동 등록에 포함시키지 않을 내용을 적용하고 있다.

그 내용은 TypeExcludeFilter와 AutoConfigurationExcludeFilter를 제외하고 자동 등록을 하겠다는 것이다.

여러 FilterType 중, CUSTOM으로 만들어진 두 Filter를 사용한다는 것이며, TypeExcludeFilter 는 SpringApplicationTest에서 사용하는 부분이라 제외를 하며(Hashcode, Equals 구현관련), AutoConfigurationExcludeFilter는 Auto-configuration 부분을 제외하는 것이다.

WrapUp

SpringBoot가 달라진점은 보통 다음을 꼽는다.

Dependency 간소화 (spring-boot-starter-*)
Configuration 간소화 (application.yml 설정)
Auto-Configuration
Embedded-timcat

그 중 Auto-Configuration 설정이 어디에 들어간 것인지, 확인해 볼 수 있었다.

[Spring] Filter와 Intercepter의 차이는 무엇일까?

KOOCCI — Fri, 19 Aug 2022 00:19:48 +0900

목표 : 스프링의 Filter와 Intercepter의 차이를 설명할 수 있다.

아마 가장 많은 비교와 사용에 대한 질문을 받는 영역 중 하나일 것이다.

Filter와 Interceptor는 대체 무엇이길래 이렇게 헤깔리게 하는것일까?

Filter & Interceptor

나는 어디에 써보았나?

Filter의 경우, 전체 Req/Res 로그를 남기길 원할 때, XSS 를 막을 때, 사용하였고, Interceptor의 경우는 AccessToken에 대한 확인을 요할 때나, 권한에 따라 다른 Menu 정보를 가져오고 싶을 때 사용하였다.

과연 나는 적절한 방법으로 설정하였을까? AOP를 사용해야 하진 않았을까?

하나씩 개념부터 정리하며, 적절했는지를 알아보자.

Filter

개념부터 정리

Web Application에서 관리되는 영역으로써 Spring Boot Framework 에서 Client로 부터 오는 요청/응답에 대해서 최초/최종 단계에 존재하며, 이를 통해 요청/응답의 정보를 변경하거나, Spring에 의해서 데이터가 변환되기 전의 순수한 Client의 요청/응답 값을 확인할 수 있다.

정리하면 다음과 같다.

Web Application에서 관리되는 영역
Client로부터 오는 요청/응답에 대해, 최초/최종 단계에 존재 (DispatcherServlet 외부)
요청/응답의 정보를 변경하거나 Client의 요청/응답 값을 확인
유일하게 ServletRequest, ServletResponse의 객체를 변환할 수 있음

Web Application 영역

먼저 Web Application에서 관리되는 영역이라고 하였다. 이게 무슨 의미일까?

모든 요청을 처리하는 DispatcherServlet의 앞단에서 실행된다는 것이다.

DistpatcherServlet도 하나의 Servlet이고 Servlet Container가 관리한다.

즉, Servlet Container에 의해 관리되는 영역이라는 뜻이다.

필터의 실행

한가지 의문인 것은 Filter도 @Component 로 등록해서 사용했다는 것이다.

이건 새롭게 알게된 부분인데, 아무렇지 않게 Filter를 적용하여 썼으나 사실 이전에는 서블릿 컨테이너가 관리하는 영역이다 보니, Bean으로 등록이나 주입이 불가능했다.

다만, DelegatingFilterProxy라는 것을 지원하기 시작하면서부터, 스프링에서 관리가 가능해졌다.

DelegatingFilterProxy는 Servlet Filter와 Spring Bean Filter를 서로 연결해주는 매개체 역할을 하는 proxy다.

Client로부터 오는 요청/응답에 대해, 최초/최종 단계에 존재

앞서 설명했지만, DispatcherServlet의 앞에 존재한다는 내용으로 보면 될 것이다.

요청/응답의 정보를 변경하거나 Client의 요청/응답 값을 확인

Pure한 Client의 요청/응답(객체로 매핑되지 않은 상태)을 알 수 있고, 그에 따라 요청/응답의 정보를 임의로 변경할 수도 있다.

그러니, XSS나 CORS, Encoding, Logging 혹은 인증과 관련된 로직을 한번에 처리하는 역할을 할 수 있다.

유일하게 ServletRequest, ServletResponse의 객체를 변환할 수 있음

아래, 실습으로 확인하겠지만, ServletRequest와 ServletResponse의 객체를 변환할 수 있는 유일한 곳이다.

Filter 실습

@Data
@NoArgsConstructor
@AllArgsConstructor
public class User {
  private String name;
  private int age;
}

@Slf4j
@RestController
@RequestMapping("/api")
public class ApiController {

  @PostMapping("")
  public User user(@RequestBody User user) {
    log.info("User : {}, {}", user, user); // {} 안에 toString 값 들어감
    return user;
  }
}

@Slf4j
@Component
public class GlobalFilter implements Filter {
  @Override
  public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
    // 전처리

    // 형변환 -> Filter에서는 형변환이 가능하고, HttpServletRequest는 ServletRequest를 상속받기 때문에 가능
    HttpServletRequest httpServletRequest = (HttpServletRequest) request;
    HttpServletResponse httpServletResponse = (HttpServletResponse) response;

    String url = httpServletRequest.getRequestURI();

    BufferedReader br = httpServletRequest.getReader();

    br.lines().forEach(line -> {
      log.info("url : {}, line : {}", url, line);
    });

    chain.doFilter(httpServletRequest, httpServletResponse);

    // 후처리
    
  }
}

위 Filter에 사용하는 Override된 method들은 다음 문서를 참고하자.

위 내용은 에러(Cannot call getInputStream(), getReader() already called)가 나온다.

2022-08-18 23:32:04.906  INFO 20120 --- [  XNIO-1 task-1] TestFilter                               : url : /api, line : {
2022-08-18 23:32:04.908  INFO 20120 --- [  XNIO-1 task-1] TestFilter                               : url : /api, line :     "name": "name",
2022-08-18 23:32:04.908  INFO 20120 --- [  XNIO-1 task-1] TestFilter                               : url : /api, line :     "age": 1
2022-08-18 23:32:04.908  INFO 20120 --- [  XNIO-1 task-1] TestFilter                               : url : /api, line : }
2022-08-18 23:32:04.960 ERROR 20120 --- [  XNIO-1 task-1] io.undertow.request                      : UT005023: Exception handling request to /api

org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.IllegalStateException: UT010003: Cannot call getInputStream(), getReader() already called
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1014) ~[spring-webmvc-5.3.22.jar:5.3.22]
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:909) ~[spring-webmvc-5.3.22.jar:5.3.22]

주석에 나온 것처럼, BufferdReader는 Stream으로 데이터를 처리하고 소비하는 역할이지, 저장하지 못한다.

이를 해결하기 위해, SpringBoot에서는 ContentCachingRequestWrapper, ContentCachingResponseWrapper 를 제공한다.

@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
        throws IOException, ServletException {
    LOG.debug("doFilter");
    // 전처리

    ContentCachingRequestWrapper httpServletRequest = new ContentCachingRequestWrapper((HttpServletRequest) request);
    ContentCachingResponseWrapper httpServletResponse = new ContentCachingResponseWrapper((HttpServletResponse) response);

    String url = httpServletRequest.getRequestURI();

    BufferedReader br = httpServletRequest.getReader();

    br.lines().forEach(line -> {
        log.info("url : {}, line : {}", url, line);
    });

    chain.doFilter(httpServletRequest, httpServletResponse);
    // 후처리
}

그러나 또다른 에러(Required request body is missing)가 나온다.

2022-08-18 23:30:12.314  INFO 15352 --- [  XNIO-1 task-2] TestFilter                               : url : /api, line : {
2022-08-18 23:30:12.314  INFO 15352 --- [  XNIO-1 task-2] TestFilter                               : url : /api, line :     "name": "name",
2022-08-18 23:30:12.314  INFO 15352 --- [  XNIO-1 task-2] TestFilter                               : url : /api, line :     "age": 1
2022-08-18 23:30:12.314  INFO 15352 --- [  XNIO-1 task-2] TestFilter                               : url : /api, line : }
2022-08-18 23:30:12.314  WARN 15352 --- [  XNIO-1 task-2] .w.s.m.s.DefaultHandlerExceptionResolver : Resolved [org.springframework.http.converter.HttpMessageNotReadableException: Required request body is missing: public com.example.demo.cli.dto.User com.example.demo.cli.Controller.ApiController.user(com.example.demo.cli.dto.User)]

그 생성자를 한번 보자.

public ContentCachingRequestWrapper(HttpServletRequest request) {
   super(request);
   int contentLength = request.getContentLength();
   this.cachedContent = new ByteArrayOutputStream(contentLength >= 0 ? contentLength : 1024);
   this.contentCacheLimit = null;
}

request의 길이를 저장해두고, 실제로 내용은 나중에 넣어준다.

즉, 후처리 때 적용된다는 것이다.

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {
        LOG.debug("doFilter");
        // 전처리
        ContentCachingRequestWrapper httpServletRequest = new ContentCachingRequestWrapper((HttpServletRequest) request);
        ContentCachingResponseWrapper httpServletResponse = new ContentCachingResponseWrapper((HttpServletResponse) response);

        chain.doFilter(httpServletRequest, httpServletResponse);
        // 후처리
        String url = httpServletRequest.getRequestURI();
        String reqContent = new String(httpServletRequest.getContentAsByteArray());
        LOG.info("request url : {}, request body : {}", url, reqContent);

        String resContent = new String(httpServletResponse.getContentAsByteArray());
        int httpStatus = httpServletResponse.getStatus();

        LOG.info("response status : {}, response body : {}", httpStatus, resContent);
    }
}

로그는 잘 찍혔는데, 정작 응답값은 비정상으로 나오는 것이 확인될 것이다.

getContentAsByteArray 역시, Stream이기 때문이다.

@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
        throws IOException, ServletException {
    // 전처리
    ContentCachingRequestWrapper httpServletRequest = new ContentCachingRequestWrapper((HttpServletRequest) request);
    ContentCachingResponseWrapper httpServletResponse = new ContentCachingResponseWrapper((HttpServletResponse) response);


    chain.doFilter(httpServletRequest, httpServletResponse);
    // 후처리
    String url = httpServletRequest.getRequestURI();
    // req
    String reqContent = new String(httpServletRequest.getContentAsByteArray());
    LOG.info("request url : {}, request body : {}", url, reqContent);

    String resContent = new String(httpServletResponse.getContentAsByteArray());
    int httpStatus = httpServletResponse.getStatus();

    httpServletResponse.copyBodyToResponse();
    LOG.info("response status : {}, response body : {}", httpStatus, resContent);
}

이제 정상적으로 적용되는 것을 볼 수 있다.

위와 같이, Logging 처리에 사용할 수 있고, Session 확인 후 Response를 바로 내버리는(401, 403 등) 역할이 가능하다.

다만, 인증은 Interceptor에서 구현을 많이 하는 편이니 참고하자.

또한, @WebFilter를 사용하면, 특정 URL에 대해서만 적용할 수도 있다.

@Slf4j
@WebFilter(urlPatterns = "/api/user/*") // 특정 URL 지정
public class GlobalFilter implements Filter {

  @Override
  public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
    // 전처리
    ContentCachingRequestWrapper httpServletRequest = new ContentCachingRequestWrapper((HttpServletRequest) request);
    ContentCachingResponseWrapper httpServletResponse = new ContentCachingResponseWrapper((HttpServletResponse) response);


    chain.doFilter(httpServletRequest, httpServletResponse);
    // 후처리
    String url = httpServletRequest.getRequestURI();
    // req
    String reqContent = new String(httpServletRequest.getContentAsByteArray());
    log.info("request url : {}, request body : {}", url, reqContent);

    String resContent = new String(httpServletResponse.getContentAsByteArray());
    int httpStatus = httpServletResponse.getStatus();

    httpServletResponse.copyBodyToResponse();
    log.info("response status : {}, response body : {}", httpStatus, resContent);
  }

}

Interceptor

이제 Interceptor로 가보자.

앞서, Filter랑 비교해서 보는 것도 좋다.

Spring Context에서 관리
어떤 메서드를 사용하는지 알 수 있다.
AOP와 유사하게 사용할 수 있다.

Spring Context에서 관리

이미 앞에서 보았지만, Interceptor는 DispatcherServlet 뒤에 존재한다.

즉, Spring Context에 등록된다.

어떤 메서드를 사용하는지 알 수 있다.

이미 Controller 매핑까지 끝난 상태로 전달받기 때문에, 어떤 메서드를 사용하는지도 알 수 있다.

또한, 선/후처리로 Service Business Logic과 분리하여 사용할 수 있다.

AOP와 유사하게 사용할 수 있다.

하단의 예시와 이전 AOP 예시를 비교해보자.

Interceptor 실습

@Documented // javadoc2으로 api 문서를 만들 때 어노테이션에 대한 설명도 포함하도록 지정해주는 것
@Retention(RetentionPolicy.RUNTIME) // 어노테이션의 유지 정책을 설정
@Target({ElementType.TYPE, ElementType.METHOD}) // 어노테이션을 적용할 수 있는 위치
public @interface Auth {
}

@Auth
@Slf4j
@RestController
@RequestMapping("/api/private")
public class PrivateController {
    private final Logger LOG = LoggerFactory.getLogger(this.getClass().getSimpleName());

    @PostMapping("hello")
    public String user() {
        return "PRIVATE HELLO";
    }
}

@Slf4j
@RestController
@RequestMapping("/api/public")
public class PublicController {
    private final Logger LOG = LoggerFactory.getLogger(this.getClass().getSimpleName());

    @PostMapping("hello")
    public String user() {
        return "PUBLIC HELLO";
    }
}

@Slf4j
@Component
public class AuthInterceptor implements HandlerInterceptor {

  @Override
  public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
    String url = request.getRequestURI();
    URI uri = UriComponentsBuilder.fromUriString(request.getRequestURI())
        .query(request.getQueryString()) // Query 가져오기
        .build()
        .toUri();
    log.info("request URL : {}", url);
    // 권한 체크할 예정
    boolean hasAnnotation = checkAnnotation(handler, Auth.class);
    log.info("hasAnnotation : {}", hasAnnotation);

    // 조건 : 모두 Public으로 동작하지만, Auth 권한을 가진 요청에 대해서는 세션/쿠키/RequestParam 등을 체크하겠다.
    if(hasAnnotation) {
      // 권한 체크
      String query = uri.getQuery();
      log.info("query : {}", query);
      if(query.equals("name=steve")) {
        return true;
      }
      return false;
    }
    return true;
  }

  private boolean checkAnnotation(Object handler, Class clazz) {
    // resource는 통과 시켜야 함
    if(handler instanceof ResourceHttpRequestHandler){
      return true;
    }

    // Annotation 체크
    HandlerMethod handlerMethod = (HandlerMethod) handler;
    // 해당 클래스에 Annotation이 있는지 확인
    if(null != handlerMethod.getMethodAnnotation(clazz) || null != handlerMethod.getBeanType().getAnnotation(clazz)) {
      // Auth annotation이 있는 경우 True
      return true;
    }

    return false;
  }
}

@Configuration
@RequiredArgsConstructor
public class MvcConfig implements WebMvcConfigurer {

    private final AuthInterceptor authInterceptor;

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(authInterceptor);
    }
}

마지막으로 AuthException을 적용해주면서, 최종적으로 확인해보자.

public class AuthException extends RuntimeException{
}

@RestControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(AuthException.class)
    public ResponseEntity authException() {
        return ResponseEntity.status(HttpStatus.UNAUTHORIZED).build();
    }
}

@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
    String url = request.getRequestURI();
    URI uri = UriComponentsBuilder.fromUriString(request.getRequestURI())
            .query(request.getQueryString()) // Query 가져오기
            .build()
            .toUri();
    log.info("request URL : {}", url);
    // 권한 체크할 예정
    boolean hasAnnotation = checkAnnotation(handler, Auth.class);
    log.info("hasAnnotation : {}", hasAnnotation);

    if(hasAnnotation) {
        // 권한 체크
        String query = uri.getQuery();
        log.info("query : {}", query);
        if(query.equals("name=steve")) {
            return true;
        }
        throw new AuthException();
    }
    return true;
}

Wrap Up

그럼 전체적으로 정리해보자.

Filter는 Web Application 관리 영역으로, ServletRequest/ServletResponse를 변환할 수 있는 유일한 구간이자, Client의 Pure한 요청을 보고, Request/Response의 양 종단간의 데이터를 확인할 수 있다. (DispatcherServlet 외부)

보통, Logging, XSS, CORS, Encoding 등에 사용한다.

Interceptor는 Spring Context 영역으로, 빈으로 관리되어, 메서드 단위까지 확인이 가능하며, AOP기능과 유사하게 사용할 수 있다.

보통, 인증이나 Logging에 사용한다.

그럼 내가 사용한 방법은 적절했을까?

전체 Req/Res 로그를 남기길 원할 때, XSS 를 막을 때에 대해 적절히 Filter를 썼으며, Auth와 관련한 로직은 Interceptor로 쓰며, 메뉴 관리까지 하였다.

앞으로는 더 다양한 방법을 사용해 볼 수 있도록 하자.

[Spring] DispatcherServlet이 뭘까?

KOOCCI — Tue, 16 Aug 2022 22:34:26 +0900

목표 : DispatcherServlet에 대해 설명할 수 있다.

SpringMVC에 대해 처음 설명하는 사항이 DispatcherServlet이다.

대체 무엇이길래 제일 처음부터 설명하는 것일까?

DispatcherServlet

SpringMVC는 Spring Framework에 최초부터 들어있던 Servlet API 기반의 웹 프레임워크다.

우선 한번 복습해보자.

Servlet

Servlet : 정적인 HTML의 한계를 극복하고 자바를 사용하여 웹페이지를 동적으로 생성하는 서버측 프로그램 혹은 그 사양

Servlet Container : Servlet Interface의 구현체로서, Servlet의 LifeCycle(Init, Destroy, Service)을 구현하고 있으며 구동 환경을 제공하여 Servlet을 관리. (Apache Tomcat, Jeus 등)

Servlet Container 구동 순서

Servlet Container가 시작 시, 모든 Servlet을 가지고 있는다.
Client로부터 요청이 들어왔을 때, Request(HttpServletRequest)와 Response(HttpServletResponse) Instance 를 생성한다.
요청 URL을 분석하여, 어떤 Servlet이 담당인지 찾고, 해당 Servlet의 쓰레드에 Request와 Response 객체를 전달한다.
1. Servlet의 Service() 메서드를 호출해, Request와 Response를 전달하고 메소드에 따라 doGet, doPost등을 호출한다.
2. 해당 메서드에서response에 응답내용을 넣는다.
Servlet Container는 Response를 Client에게 전달하고, Request와 Response를 소멸시킨다.
Servlet Instance 자체는 사라지지 않고, Servlet Container가 멈추기 전까지 요청에 대한 처리를 수행한다.

Servlet 상속관계

DispatcherServlet

이제 Servlet이 무엇인지 알고 있으니, DispatcherServlet이 어떻게 다른지 알아볼 차례다.

공식 문서에서는 다음과 같이 표현하고 있다.

Spring MVC, as many other web frameworks, is designed around the front controller pattern where a central Servlet, the DispatcherServlet, provides a shared algorithm for request processing, while actual work is performed by configurable delegate components. This model is flexible and supports diverse workflows.

DispatcherServlet은 중앙 서블릿이며,요청 처리를 위한 공유 알고리즘을 제공하는 반면 실제 작업은 구성 가능한 대리자 구성 요소에 의해 수행되는 Front Controller 패턴으로 설계되었다.

너무 번역투이니 조금 정리해보면,

Front Controller 패턴으로 설계되어, 모든 요청처리를 가장 먼저 받고, 실질적으로 일하는 적합한 Component(Controller)에게 위임하는 역할이다.

DispatcherServlet은 다른 Servlet과 마찬가지로, web.xml이나 java configuration으로 선언된다.

다음과 같이 설정하면, Servlet Container에서 자동으로 찾아서 설정하게 된다.

(SpringBootServletInitializer의 경우, 내부적으로 WebApplicationInitializer를 구현하고 있는 Abstract Class다.)

public class MyWebApplicationInitializer implements WebApplicationInitializer {

    @Override
    public void onStartup(ServletContext servletContext) {

        // Load Spring web application configuration
        AnnotationConfigWebApplicationContext context = new AnnotationConfigWebApplicationContext();
        context.register(AppConfig.class);

        // Create and register the DispatcherServlet
        DispatcherServlet servlet = new DispatcherServlet(context);
        ServletRegistration.Dynamic registration = servletContext.addServlet("app", servlet);
        registration.setLoadOnStartup(1);
        registration.addMapping("/app/*");
    }
}

혹은 Web.xml로 설정하는 방법도 제공한다.

<web-app>

    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>

    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/app-context.xml</param-value>
    </context-param>

    <servlet>
        <servlet-name>app</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value></param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>app</servlet-name>
        <url-pattern>/app/*</url-pattern>
    </servlet-mapping>

</web-app>

왜 DispatcherServlet이 사용되었을까?

Web.xml에서 Servlet 매핑을 줄여주었다.

각 Servlet에 대해 요청URL과 매핑해주어야 했던 이전과 달리, DispatcherServlet이 Front Controller를 해주므로, Controller를 수현해두기만 하면, DispatcherServlet이 알아서 위임해주게 되었다.

공통된 처리를 할 수 있다.

인코딩, 에러 처리, 공지 등에 대한 처리를 한번에 해결할 수 있다.

DispatcherServlet의 흐름

그럼 전체 흐름을 한번 그려보자.

서블릿 컨테이너는 시작 시, 모든 Servlet을 가지고 있다.
Client의 요청이 들어오면, 제일 먼저 DispatcherServlet이 요청을 받는다.
공통적인 작업을 먼저 DispatcherServlet이 처리한다.
URL을 분석해 알맞는 Controller(Servlet)를 찾는다.
요청을 컨트롤러로 위임할 Handler mapping을 찾아서 전달한다. (Controller로 전달하려면 어떤 Mapping을 가져올지 확인)
Handler Adapter를 통해 요청을 위임한다. (Mapping된 Adapter로 위임)
Service 로직(Business 로직) 실행
응답 반환 (Controller -> Adapter -> DispatcherServlet)
Client로 반환

Wrap up

조금 더 자세한 내용들이 많다.

파고들면 파고들수록 까다로운 Spring이다.

Heap 메모리 구조와 GC는 어떻게 될까?

KOOCCI — Tue, 16 Aug 2022 01:06:41 +0900

목표 : Heap 메모리와 GC에 대해 설명할 수 있다.

앞선 포스팅으로 JVM 내부 메모리 구조를 알아보았다.

그 중, Heap 메모리에 대한 상세한 설명을 추가하고자 한다.

Garbage Collection

Heap을 설명한다 했지만, GC부터 알아보려고 한다.

Heap과 자연스럽게 연결될 것이며, 일단 용어를 좀 정리해야 설명하기 편할 것 같아서다.

JVM은 자동으로 메모리를 관리해준다.

GC는 더이상 사용되지 않는 인스턴스(Referrer가 없는 Object)를 찾아 메모리 할당을 삭제하는 행위이다.

이 말은 JVM에서는 GC가 자동으로 일어난다는 것이고, 성능에 중요한 역할을 한다.

GC 혹은 메모리 설정이 잘못되면 금방 OOM(Out of Memory) Error가 발생할 것이다.

이 때 말하는 메모리가 Heap이며, Heap의 구조로 넘어가보도록 하자.

Heap 메모리 구조

우선 그림으로 복습하면, JVM 내의 메모리 구조는 다음과 같다.

JVM 메모리 구조

그 중, Heap 영역을 잘게 쪼개어 보도록 하자.

Heap Memory

우선 Java8부터 달라진 부분 부터 보자.

Native Memory

Native Memory는 JVM에서 사용하는 메모리다.

기존, Perm 부분(PermGen)은 Class 메타 정보나, Method의 메타 정보, static 변수와 상수 정보들이 저장되는 공간으로 흔히 메타데이터 저장 영역이었다.

정의가 뭔가 중복되는 걸 알아야 하며, Method Area에 저장되는 정보와 유사하다는 것이다.

공부하면서 궁금하여, 한번 찾아보았더니 유사한 내용을 궁금해한 사람이 많았다.

그 중, 다음 블로그에서 가장 얻고 싶은 정보를 얻을 수 있었는데, 결국 결론은

JVM 벤더마다 다양하게 구현할 수 있지만 HotSpot JVM 기준으로, Method Area = PermGen으로 할 수 있으며, Non-Heap 영역이라는 것이다.

하여튼, 현재는 Perm 영역은 없어지고, Metaspace라는 영역으로 바뀌었으며, Native Memory로 포함되었다.

Young Generation (Eden + Survivor)

그럼 Heap 영역으로 넘어와서, 먼저 Young Generation에 대해 알아볼 차례다.

Young Generation은 쉽게 말해 짧게 살아남은 메모리들이 존재하는 공간이다.

오래 살아남은 친구들에 비해, 작은 공간에 존재하며, 그만큼 메모리 상의 객체를 빨리 찾을 수 있다.

따라서, Young Generation에서 이루어지는 GC는 Minor GC라고 한다.

Young Generation은 Eden 영역과 Survivor 영역으로 나누어진다.

Young Generation GC

new로 생성된 객체가 있다고 하자.

모든 객체는 처음에 이 Young Generation의 Eden 영역에 생성된다.
Eden 영역이 Full이 되었을 때, 메모리 복사가 일어난다.
Minor GC가 일어나게 되며, Eden 내의 객체를 검사해, 사용되지 않는(레퍼런스가 없는)객체를 해제한다.
살아남은 객체들은 From Space (Survivor 영역)으로 이동된다.
Eden이 또다시 Full이 되었을 때, From Space에서 살아남은 친구들은 To Space로 이동한다.
특정 횟수 (-XX:MaxTenuringThreshold=32) 를 반복하고도 살아남으면, Old Generation으로 이동된다.

Old Generation

Young Generation에서 살아남은 객체들은 아주 큰 공간인 Old Generation으로 이동된다.

크기가 큰 만큼, GC는 적개 발생되며, 이 영역에서 발생하는 GC를 Major GC라고 한다.

GC 알고리즘

GC에서는 크게 2가지가 발생한다.

Stop The World(STW)
Mark & Sweep

Stop The World (STW)

STW(Stop The World)는 JVM이 Application의 실행을 멈추는 것을 말한다. 즉, GC가 실행될 때는 GC에 대한 쓰레드를 제외하고 모든 쓰레드들의 작업이 중단된다.

GC 튜닝이 STW를 줄이는 것에 목표가 있다는 것을 알면, 아주 큰 일이 발생한다고 볼 수 있다.

Mark & Sweep (& Compact)

STW는 Thread가 멈추고 Mark & Sweep 작업이 필요하다.

Mark : 객체가 현재 사용 중인지, 확인한다.
Sweep : Mark 처리가 된 객체를 메모리 주소 매핑을 삭제한다. (실제로 삭제한다기 보다, 정보만 지운다)
*Compact : 디스크 조각모음 하듯이, 메모리 공간을 단편화시킨다. 알고리즘에 따라, 하지 않는 경우도 있다.

GC 알고리즘 종류

Serial GC (-XX:+UseSerialGC)

가장 단순한 GC로, 싱글 쓰레드로 동작한다.
STW 시간이 그만큼 길다.
Mark & Sweep & Compact 알고리즘을 사용한다.
실무에선 거의 사용되지 않는다 (CPU 코어가 1개인 경우 사용)

Serial GC

Parallel GC (-XX:+UseParallelGC)

java 8의 기본 GC
Young 영역의 GC를 Serial GC와 같지만, 멀티 쓰레드로 진행한다.
STW는 상대적으로 Serial GC보다 짧다.

Parallel GC

Parallel Old GC (-XX:+UseParallelOldGC / -XX:+ParallelGCThreads=n)

Old 영역에도 멀티쓰레드 방식을 적용

CMS GC(Concurrent Mark Sweep GC)

Concurrent Mark Sweep GC

STW를 최소한으로 하기위해 만들어진 GC
Reference가 있는 객체를 여러번에 나누어 찾는다.
- Initial Mark : GC Root가 참조하는 객체만 마킹 (stop-the-world 발생)
- Concurrent Mark: 참조하는 객체를 따라가며, 지속적으로 마킹. (stop-the-world 없이 이루어짐)
- Remark : concurrent mark 과정에서 변경된 사항이 없는지 다시 한번 마킹하며 확정하는 과정. (stop-the-world 발생)
- Concurrent Sweep : 접근할 수 없는 객체를 제거하는 과정 (stop-the-world 없이 이루어짐)

G1 GC (Garbage Frist GC) (-XX:+UseG1GC)

java 9+의 default GC
현재 GC 중 stop-the-world의 시간이 제일 짧음
CMS GC 를 개선하여 만든 GC로 위에서 살펴본 GC와는 다른 구조를 가진다.
Heap을 Region이라는 일정한 부분으로 나눠서 메모리를 관리한다.
전체 Heap에 대해서 탐색하지 않고 부분적으로 Region 단위로 탐색하여, 각각의 Region에만 GC가 발생

G1 GC

Wrap Up

JVM의 Heap 구조를 공부하고, GC에 대해서까지 알아보았다.

GC자체를 프로젝트하면서 건들여본 적이 없기 때문에, 직접적으로 바로 알 수는 없었지만, 최소한의 개념을 알아두도록 하자.

JVM의 메모리 구조는 어떻게 될까?

KOOCCI — Mon, 15 Aug 2022 21:42:25 +0900

목표 : JVM 메모리 구조를 설명할 수 있다.

JVM이 java Virtual Machine 이라는 것은 잘 알고 있다.

다만, 이 구조에 대해 설명을 하려고 하면, 쉽지 않은 부분이 있어 정리하고자 한다.

JVM,JRE,JDK

왜 자바가 많이 사용되었을까?

근본적인 질문일 수 있다.

JVM을 설명하기 전에, Java의 특징 중 하나인 OS에 종속적이지 않다는 점을 설명하기 위한 질문이다.

그럼, OS에 어떻게 종속받지 않은 환경을 만들었을까?

어디에서든 Java가 돌아갈 수 있게 감쌀 무언가가 필요했고, 그게 바로 Java Virtual Machine 이라고 하는 JVM이다.

Java는 컴파일 언어다.

Java의 특징 중 또 다른 하나는 컴파일 언어라는 것이다.

컴파일 언어라 함은, 기계어로 번역하는 과정이 필요하며, 이에 따라 빌드 시간이 다소 소요되지만, 미리 컴파일 에러를 잡아낼 수 있고, 런타임 상황에서 빠른 실행이 가능하다.

Java는 컴파일 언어로서, 기계어로 번역하는 과정이 필요하다.

우리가 처음 만든 .java 파일을 Bytecode로 변경하는 작업이 필요한 것이다.

즉, java compiler가 (JDK(Java Development Kit) 의 javac) .java 파일을 .class라는 파일로 변환하게 된다.

Java Bytecode to Binary Code

.java 파일이 컴파일러에 의해 .class파일로 변경되며, Java Bytecode가 된다는 사실을 알게 되었다.

Java Bytecode는 JVM(가상 머신)이 이해할 수 있는 언어로 변환된 코드다.

JVM이라는 가상환경이 Java와 OS간의 연결을 도와주는 매개체라고 생각해보자.

이제 JVM은 OS가 이해할 수 있는 언어로 변환하는 과정이 필요하다.

OS가 이해하는 언어는 Binary Code 즉 이진 코드이다. (CPU가 이해하는 언어)

JIT Compiler

Bytecode를 Binary Code로 바꾸려면, 또다시 변환과정이 필요하게 된다.

이전에는 RunTime시에 Interpreter로 적용되어 속도가 느렸지만, 요즘은 그 단점을 해소하기 위해 JIT(Just In Time) Compiler가 도입되어 있다.

JIT(Just In Time) Compiler 는 인터프리터 방식으로 실행하다 적절한 시점에 바이트코드 전체를 네이티브 코드(ex> 바이너리 코드)로 바꾼다. 그 다음부터 인터프리터는 네이티브 코드로 컴파일된 코드를 바로 사용한다. 즉, 한번 컴파일된 코드는 계속 빠르게 수행되게 된다.

JIT Compiler

그림으로 이해해보자.

이제 우리가 만든 Java 파일이 어떻게 변환되어 OS까지 전달되는지 알수 있게 되었다.

도식도를 보고 한번 더 이해해보도록 하자.

JVM 구성

클래스 로더 (Class Loader)

JVM 내에 초기화, 클래스 파일(.class)을 로드하고, 링크를 통해 배치한다.
.class 파일을 읽고 그 내용에 따라 바이너리 데이터를 만들어 Method 영역에 저장한다. (메모리 구조는 다음 탭에서 보자)

실행 엔진 (Excution Engine)

앞서 알아본 바이너리 코드로 바꾸기 위한 Interpreter나 JIT Compiler가 존재한다.
또한, GC가 있어, 힙 메모리 영역에 생성된 객체들 중에서 참조되지 않은 객체들을 탐색하고 제거한다.

JVM의 메모리는 어떻게 구성되어 있을까?

JVM에서는 프로그램을 수행하기 위해 OS로부터 메모리 공간들을 할당 받는다. (즉 하나의 프로세스다)

그 공간들을 의미하는 Runtime Data Area에 대해 알아보기 위해 구체화된 다음 이미지를 보도록 하자.

Runtime Data Area 1

Runtime Data Area 2

Runtime Data Area 3

JVM이라는 프로세스

Runtime Data Area 4

먼저, 앞서 JVM이 하나의 프로세스라고 하였다.

Main Thread를 가진 독립된 메모리 공간을 가지며, Runtime Data Area 3 이미지 처럼 구성된다.

JVM 내에 쓰레드가 구성될 때는 크게 Main Thread(비데몬 스레드)와 Main이 아닌 Thread(데몬 쓰레드)로 구분된다.

static void main(String[] args) 가 프로그램 실행의 진입점인 것을 알고 있다. 즉, 이 진입점이 비데몬 쓰레드, Main Thread로 실행되며 Main Thread가 종료되면, 다른 데몬 쓰레드도 모두 종료된다.

PC(Program Counter) Register

OS에서 Context Switching에 대해 학습했다면, PC라는 용어를 알 것이다.

실행중인 프로세스(쓰레드)에서 다른 프로세스(쓰레드)로 넘어가 실행되기 원할 때, Context Switching이 발생하며, 이때 그 위치에 대한 정보를 포인터하는 역할을 PC가 하게된다.

즉, 현재 쓰레드의 명령 흐름을 추적하거나, 연산하는 과정에서 필요한 데이터를 저장하는 역할을 한다.

Native Method Stack

Java가 아닌 다른 언어를 JNI(Java Native Interface)를 통해 실행하기 위한 코드 공간이다. (C, C++)

JVM Stack

우리가 흔히 말하는 Stack 공간이다.

지역 변수, 파라미터, 리턴 값, 연산에 사용되는 임시 값등이 생성되는 영역으로, 프로그램 실행과정에서 임시로 할당되었다가 메소드를 빠져나가면 바로 소멸되는 특성을 가진다.

위 이미지에서 보듯, Thread에서도 자신만의 고유 공간이다.

Method Area

Method Area, 메소드 영역은, Class Area, Static Area, Code Area라고도 한다.

그림과 같이, 모든 쓰레드가 공유하는 메모리 영역이기도 하다.

클래스 로더의 설명에서도 나왔지만, 바이너리 코드로 변환된 클래스 파일들을 저장하는 공간이다.

클래스 변수(Static 변수), 인터페이스, 필드, 메소드 등 클래스 정보들이 저장된다.

또한, Runtime Constant Pool 이라는 중요한 저장 공간이 내부에 있다.

이는 상수 자료형을 저장하여 참조하고 중복을 막는 역할을 수행한다.

int a = 1;
int b = 1;
if(a == b) {
    System.out.println("a == b");
} else {
    System.out.println("a != b");
}

// a == b

간단한 소스를 보자.

위의 a와 b 변수에 할당된 1이라는 값은 Constant pool에 저장된다.

따라서, 위 두 값은 같다라는 수식에서 같다라는 걸 알 수 있다.

Integer a = new Integer(1);
Integer b = new Integer(1);
if(a == b) {
    System.out.println("a == b");
} else {
    System.out.println("a != b");
}

// a != b

new로 생성한 값은 Constant pool에 저장되지 않아, 같다라는 조건이 성립되지 않는다.

Heap

힙(heap) 영역은 자바 프로그램에서 사용되는 모든 인스턴스 변수가 저장되는 영역이다.

new 연산자로 생성되는 객체와 배열을 저장하는 공간으로 보면 되며, Method Area(Class Area)에 올라온 클래스들만 객체로 생성할 수 있다.

Heap은 또 다시 내부 구조를 가진다.이는 GC와 연결되므로, GC를 따로 공부하면서 정리하도록 하자.

Wrap Up

위와 같이 JVM의 구조에 대해 알아보았다.정리하면 다음과 같다.

JVM은 Java가 OS에 종속적이지 않도록 만들어 준다.
Java는 컴파일 언어로, Javac를 통해 .class 파일로 변경된다 (바이트 코드)
.class 파일은 JVM 내부에서 Interpreter와 JIT Compiler를 통해 바이너리 코드로 변환되어 실행된다.
JVM 내부에는 크게, 클래스 로더, 실행 엔진, Runtime Data Area(메모리)로 나누어진다.
클래스 로더는 .class 파일을 로드하고, 메모리(Method Area)에 저장하는 역할을 한다.
실행 엔진에는 바이너리 코드로 변경하기 위한 Interpreter, JIT Compiler, 그리고 Heap 메모리의 GC 가 포함되어 있다.
Runtime Data Area에는 JVM Stack, PC Register, Native Method Stack과 Method Area, Heap Area이 존재한다.
JVM Stack 은 Thread 고유 저장 영역으로 지역 변수, 파라미터, 리턴 값들이 저장되었다가, 메소드가 끝나면 해소되는 휘발성 영역이다.
Method Area는 모든 Thread이 공유하는 영역으로, 바이너리 코드로 변환된 .class 내용이 저장된다. 즉, 클래스 변수, 필드, 메서드 등 클래스 정보가 저장되는 공간이다.
Runtime Constant Pool도 가지고 있어, Primitive Type의 변수들에게 할당되는 값들이 저장되는 공간도 존재한다.
Heap 영역은 new 로 생성된 인스턴스 변수가 할당된다.

참고자료

https://steady-coding.tistory.com/305

JVM 메모리 구조란? (JAVA)

안녕하세요? 코딩 중독입니다. 오늘은 JVM 메모리 구조에 대해 알아보겠습니다. JVM이란? JVM 메모리 구조를 설명하기 전에 JVM이 무엇인지 알아야 합니다. JVM은 Java Virtual Machine의 약자로, 자바 가상

steady-coding.tistory.com

https://catsbi.oopy.io/df0df290-9188-45c1-b056-b8fe032d88ca

[1주차] JVM은 무엇이며 자바 코드는 어떻게 실행하는 것인가.

목표

catsbi.oopy.io

https://doozi0316.tistory.com/entry/1%EC%A3%BC%EC%B0%A8-JVM%EC%9D%80-%EB%AC%B4%EC%97%87%EC%9D%B4%EB%A9%B0-%EC%9E%90%EB%B0%94-%EC%BD%94%EB%93%9C%EB%8A%94-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%8B%A4%ED%96%89%ED%95%98%EB%8A%94-%EA%B2%83%EC%9D%B8%EA%B0%80

[JAVA] JVM이란? 개념 및 구조 (JDK, JRE, JIT, 가비지 콜렉터...)

JVM이란 무엇인가 Java Virtual Machine의 줄임말. 직역하면 '자바를 실행하기 위한 가상 기계(컴퓨터)'라고 할 수 있다. Java 는 OS에 종속적이지 않다는 특징을 가지고 있다. OS에 종속받지 않고 실행되

doozi0316.tistory.com

[Spring] Bean의 주입은 어떻게 하는게 좋을까?

KOOCCI — Sun, 14 Aug 2022 02:53:26 +0900

목표 : Spring Bean 생성자 주입이 많은 이유를 설명할 수 있다.

이전 포스팅으로 Bean 주입에 대해 설명한 적이 있다.

잠깐 다시 정리해보자.

Bean의 주입 방법

Bean의 주입 방법은 크게 3가지가 있다.

생성자 주입, Setter를 통한 주입은 앞선 포스팅으로 보았고, 필드를 통한 주입까지 3가지가 있다

Setter를 통한 주입

package com.example.demo.di;

import lombok.Data;

@Data
public class MyBean {
    private int msg;
}

package com.example.demo.di;

import lombok.Data;
import org.springframework.beans.factory.annotation.Autowired;

@Data
public class AnotherBean {
    private MyBean myBean;

    public void setMyBean(MyBean myBean) {
        this.myBean = myBean;
    }
}

package com.example.demo.di;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class AppConfig {

    @Bean
    public MyBean myBean() {
        return new MyBean();
    }

    @Bean
    public AnotherBean anotherBean() {
        return new AnotherBean();
    }
}

package com.example.demo.di;

import org.springframework.context.annotation.AnnotationConfigApplicationContext;

public class Main {
    public static void main(String[] args) {
        AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);

        AnotherBean aBean = context.getBean(AnotherBean.class);
        MyBean myBean = context.getBean(MyBean.class);
        myBean.setMsg(123);
        aBean.setMyBean(myBean);

        System.out.println(aBean.getMyBean().getMsg());
    }
}

Setter를 통한 주입은 잘 사용하지 않는다.

그 이유는 Setter 자체에 있다.

Setter를 사용하는 것이 자유롭다보니, 나중에 누군가에 의해 변경이 일어날 수 있다는 것이다.

즉, 객체의 불변성을 보장하지 못한다.

그리고, 순환 참조에 대한 문제도 가지고 있다.

A도 B를 가지고 있고, B도 A를 가지고 있으면 순환 참조로 인해 에러가 날 것이다.

Setter 로 인해, Bean을 생성한 후에 주입하기 때문이다.

필드를 통한 주입

위 예시에서 AnotherBean만 바꾸어 주자.

@Data
public class AnotherBean {
    @Autowired
    private MyBean myBean;
}

간단히, @Autowired를 통해 주입해줄 수 있다.

최근 프로젝트가 아니라면, 이런 방식이 정말 많이 쓰였고, 또 자주 보일 것이다.

사용하기 편리하지만 이 역시 Setter와 동일하게 순환참조와 객체의 불변성에 대한 보장이 어렵다.

생성자를 통한 주입

이 글의 목적이기도 하다.

package com.example.demo.di;

import lombok.Data;
import lombok.RequiredArgsConstructor;

@Data
@RequiredArgsConstructor
public class AnotherBean {
    final private MyBean myBean;
}

package com.example.demo.di;

import lombok.Data;

@Data
public class MyBean {
    private int msg;
}

package com.example.demo.di;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class AppConfig {

    @Bean
    public MyBean myBean() {
        return new MyBean();
    }

    @Bean
    public AnotherBean anotherBean() {
        return new AnotherBean(this.myBean());
    }
}

package com.example.demo.di;

import org.springframework.context.annotation.AnnotationConfigApplicationContext;

public class Main {
    public static void main(String[] args) {
        AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);

        AnotherBean aBean = context.getBean(AnotherBean.class);
        aBean.getMyBean().setMsg(123);

        System.out.println(aBean.getMyBean().getMsg());
    }
}

달라진 점은 크게 2가지다.

@RequiredArgsConstructor 를 통해, 생성자를 만들어준 점, 그리고, 필드에 final을 설정한 점이다.

생성자를 통한 주입을 Spring에서도 추천하는 이유는 순환참조 방지와 객체의 불변성을 보장해주기 때문이다.

앞서, 필드나 Setter를 통한 주입과 달리, 주입하고자 하는 Bean이 있는지 확인하면서 주입이 되므로 순환참조가 생길 수 없다.

또한, final 키워드를 유일하게 쓸 수 있기 때문에, 런타임에 객체가 변환되는 것에 대한 걱정을 없앨 수 있다.

Wrap Up

Bean의 주입 시, 생성자를 많이 사용하는 이유에 대해 알아보았다.

생성자 주입의 장점인 순환참조 방지, 그리고 객체의 불변성을 보장한다는 것으로 마무리하자.

[Spring] Spring에서 AOP는 어떻게 사용할까?

KOOCCI — Sat, 13 Aug 2022 07:51:36 +0900

목표 : Spring에서 AOP를 사용할 수 있다.

앞서, AOP가 무엇인지에 대해 알아보았다.

이제 Spring에서 AOP를 어떻게 쓸 수 있을지 알아보자.

Aspect Oriented Programming with Spring

다음 링크에서 Spring에서 AOP에 대한 적용은 다음과 같이 할 수 있다고 한다.

Spring provides simple and powerful ways of writing custom aspects by using either a schema-based approach or the @AspectJ annotation style. Both of these styles offer fully typed advice and use of the AspectJ pointcut language while still using Spring AOP for weaving.

즉, schema-based approach를 사용할 수도 있고, @AspectJ라는 Annotation을 사용할수도 있다고 한다.

Schema-based AOP Support

Annotation은 소스가 분산되어, 이해를 돕기위해 Schema-based 방식을 먼저 보도록 하자.

먼저, XML로 AOP를 설정하려면 aop Schema를 설정해주어야 한다.

Declaring an Aspect

그럼 Aspect부터 설정해보자.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="
        http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/aop https://www.springframework.org/schema/aop/spring-aop.xsd">

    <!-- bean definitions here -->
    <aop:config>
        <aop:aspect id="myAspect" ref="aBean">
        </aop:aspect>
    </aop:config>

    <bean id="aBean" class="com.example.demo.aop.AopBean">
    </bean>

</beans>

예시에 따라 구성하였고, AopBean 클래스를 만들어, Bean 설정에 추가해주자.

Declaring a Pointcut

Pointcut도 마찬가지로 설정할 수 있다.

Pointcut은 aspect 안에 존재한다.

<aop:config>

    <aop:pointcut id="businessService"
        expression="execution(* com.xyz.myapp.service.*.*(..))"/>

</aop:config>

바로 작성하기 전에, 위 예시를 보면, expression이 존재한다.

execution(* com.xyz.myapp.service.*.*(..))

excution 할 때 (Runtime 때) 특정 패키지(com.xyz...service)의 모든 클래스(service.*), 모든 메서드(service.*.*), 그리고 모든 Argument(*.*.(..))에 해당한다는 표현식이다.

그럼 실제로 적용해보자.

package com.example.demo.aop;

import lombok.extern.slf4j.Slf4j;

@Slf4j
public class AopBean {
}

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="
        http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/aop https://www.springframework.org/schema/aop/spring-aop.xsd">

    <!-- bean definitions here -->
    <aop:config>
        <aop:aspect id="myAspect" ref="aBean">
                <aop:pointcut id="businessService" expression="execution(* com.example.demo.aop.AopBean.*.*(..))"/>
        </aop:aspect>
    </aop:config>

    <bean id="aBean" class="com.example.demo.aop.AopBean">
    </bean>

</beans>

Declaring Advice

이제 Advice를 적용해보자.

package com.example.demo.aop;

import lombok.extern.slf4j.Slf4j;

@Slf4j
public class AopBean {
    public void beforeLog() {
        log.error(">>> before aop log");
    }

    public void afterLog() {
        log.error(">>> after aop log");
    }

    public void afterReturningLog() {
        log.error(">>> afterReturningLog aop log");
    }

    public void afterThrowingLog() {
        log.error(">>> afterThrowingLog aop log");
    }
}

package com.example.demo.aop;

import lombok.extern.slf4j.Slf4j;


@Slf4j
public class Service {
    public void log() {
        log.error(">>> aop log");
    }
}

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="
        http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/aop https://www.springframework.org/schema/aop/spring-aop.xsd">

    <!-- bean definitions here -->
    <aop:config>
        <aop:aspect id="myAspect" ref="aBean">
            <aop:pointcut id="businessService" expression="execution(* com.example.demo.aop.Service.*(..))"/>
            <aop:before pointcut-ref="businessService" method="beforeLog"/>
            <aop:after pointcut-ref="businessService" method="afterLog"/>
            <aop:after-returning pointcut-ref="businessService" method="afterReturningLog"/>
            <aop:after-throwing pointcut-ref="businessService" method="afterThrowingLog"/>
        </aop:aspect>
    </aop:config>

    <bean id="aBean" class="com.example.demo.aop.AopBean">
    </bean>

    <bean id="service" class="com.example.demo.aop.Service">
    </bean>

</beans>

package com.example.demo.aop;

import org.springframework.context.support.ClassPathXmlApplicationContext;

public class Main {
    public static void main(String[] args) {
        ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("application.xml");
        Service service = context.getBean(Service.class);
        service.log();
        context.close();
    }
}

혹시, Class Not Found 에러가 난다면, 아래 2개 Dependency를 추가해주자. (Springboot는 starter-aop 가 따로 있다)

Aspectj Runtime

aspectJ Weaver

04:39:29.454 [main] ERROR com.example.demo.aop.AopBean - >>> before aop log
04:39:29.466 [main] ERROR com.example.demo.aop.Service - >>> aop log
04:39:29.466 [main] ERROR com.example.demo.aop.AopBean - >>> after aop log
04:39:29.466 [main] ERROR com.example.demo.aop.AopBean - >>> afterReturningLog aop log

그 결과를 위와 같이 확인해 볼 수 있다.

Around Advice

그럼, 위에서 했던 것들을 한번에 해주는 Around Advice를 보자.

<aop:aspect id="aroundExample" ref="aBean">

    <aop:around
        pointcut-ref="businessService"
        method="doBasicProfiling"/>

    ...
</aop:aspect>

public Object doBasicProfiling(ProceedingJoinPoint pjp) throws Throwable {
    // start stopwatch
    Object retVal = pjp.proceed();
    // stop stopwatch
    return retVal;
}

Around에서는 method에서 Argument를 받는다.

앞선 포스팅에서 확인해 보았듯이, Proxy로 Sample 예제를 보았을 때와 동일하다.

package com.example.demo.aop;

import lombok.extern.slf4j.Slf4j;
import org.aspectj.lang.ProceedingJoinPoint;

@Slf4j
public class AopBean {
    public void aroundLog(ProceedingJoinPoint pjp) {
        log.error(">>> before aop log");
        try {
            Object proceed = pjp.proceed();
            log.error(">>> returning aop log");
        } catch (Throwable throwable) {
            log.error(">>> throwing aop log");
        }
        log.error(">>> after aop log");
    }
}

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="
        http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/aop https://www.springframework.org/schema/aop/spring-aop.xsd">

    <!-- bean definitions here -->
    <aop:config>
        <aop:aspect id="myAspect" ref="aBean">
            <aop:pointcut id="businessService" expression="execution(* com.example.demo.aop.Service.*(..))"/>
            <aop:around pointcut-ref="businessService" method="aroundLog"/>
        </aop:aspect>
    </aop:config>

    <bean id="aBean" class="com.example.demo.aop.AopBean">
    </bean>

    <bean id="service" class="com.example.demo.aop.Service">
    </bean>

</beans>

@AspectJ

그럼 이제, Annotation을 통해, 처리하는 것으로 변경해보도록 하자.

@Configuration
@EnableAspectJAutoProxy
@ComponentScan
public class AppConfig {
}

먼저, AspectJ는 외부 라이브러리이므로, Configuration에 위와 같이 넣어줄 필요가 있다.

@Slf4j
@Component
public class Service {
    public void log() {
        log.error(">>> aop log");
    }
}


@Slf4j
@Aspect
@Component
public class AopBean {

    @Pointcut("execution(* com.example.demo.aop.Service.*(..))")
    public void aopPointcut(){}

    @Around("aopPointcut()")
    public Object aroundLog(ProceedingJoinPoint pjp) {
        log.error(">>> before aop log");
        try {
            Object proceed = pjp.proceed();
            log.error(">>> returning aop log");
            return proceed;
        } catch (Throwable throwable) {
            log.error(">>> throwing aop log");
        }
        log.error(">>> after aop log");
        return null;
    }
}

package com.example.demo.aop;

import org.springframework.context.annotation.AnnotationConfigApplicationContext;

public class Main {
    public static void main(String[] args) {
        AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext();
        context.register(AppConfig.class);
        context.refresh();

        Service service = context.getBean(Service.class);
        service.log();
        context.close();
    }
}

XML 파일을 없애더라도, 정상 동작하는 것을 알 수 있다.

@Aspect 안에, Pointcut을 설정하였고, @Around로 Advice도 적용되었다는 것을 알 수 있다.

상황에 따라, Pointcut을 별도로 정리하고, Advice에는 여러 Pointcut을 적용하는 등의 동작도 가능하다.

Wrap Up

앞서 배운 지식과 합쳐서, AOP를 Spring에서 어떻게 사용하는지에 대해 알아볼 수 있었다.

[Spring] AOP는 뭘까?

KOOCCI — Sat, 13 Aug 2022 03:40:51 +0900

목표 : AOP에 대해 설명 할 수 있다.

Spring에서는 IoC Container 기능과 더불어, AOP를 아주 중요하게 생각한다.

그럼, AOP가 무엇인지부터 알아가보도록 하자.

Aspect Oriented Programming (AOP)

다음 링크를 보면, AOP에 대해 다음과 같이 설명하고 있다.

컴퓨팅에서 관점 지향 프로그래밍(aspect-oriented programming, AOP)은 횡단 관심사(cross-cutting concern)의 분리를 허용함으로써 모듈성을 증가시키는 것이 목적인 프로그래밍 패러다임이다.

어떠한 language가 만들어 지기 전에, OOP, Functional Programming 같은 패러다임이 먼저 존재한다.

이 패러다임을 기반으로 특정 Language가 만들어진다.

Java는 OOP 패러다임으로 만들어졌고, 이후에 AOP의 요구사항에 의해 AOP 패러다임도 수용한 언어다.

그럼 위 설명의 용어를 알아보도록 하자.

횡단 관심사(Cross-cutting concern)

프로그램을 개발하다보면, 공통 기능이 생기기 마련이다.

모든 Controller 혹은 특정 목적에 따라 만들어진 Service 들 등, Log와 같이 목적에 따라, 공통적으로 적용되어야 할 소스들이 있다.

다음 예시 이미지를 보도록 하자.

AOP 설명1

@Slf4j
public class Main {
    public static void main(String[] args) {
        AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext();
        context.register(AppConfig.class);
        context.refresh();
        MyService service = context.getBean(MyService.class);
        service.check();
        context.close();
    }
}

Java에 Main 메서드가 있을 것이고, Spring boot를 만들어도 Main 메서드가 있다.

위 코드에서는 context, service같은 객체들을 선언/할당하고, 메서드들을 실행하고 있다.

즉, 위 이미지에서 A~D Class Method가 이에 해당한다.

그런데, 공통 기능을 넣어주려고 한다고 해보자.

예를 들어, 트랜젝션 기능을 넣어주려고 한다.

그럼 우리는 각 Class마다, Transaction Start와 Auto Commit = false를 상위에 넣어주고, Try Catch 문으로 감싸준 다음에, Rollback 혹은 Commit 처리를 마지막에 해야할 것이다.

즉, 다음 이미지 같이 될 것이다. (보기 좋게 만들다보니, Commit/Rollback 실행 위치는 모순이 있을 수 있다. 이후에 예시로 정확히 알아보자.)

AOP 설명 2

그럼 바로 발견되는 문제점이 있을 것이다.

동일한 작업의 반복이다.

우리가 함수를 사용하는 이유 중 하나는 반복을 최소화 하기 위함이다.

그러나 위 상황에서, 각 박스들을 함수로 만든다고 하더라도, 각 클래스에서 호출해서 써야 하다보니, 그 함수 실행 자체가 반복된다.

그럼 관점을 바꾸어서 바라보도록 노력 해보자.

위 박스들을 각 Class에서 실행하지 않으면 된다.

공통된 부분이 실행되는 함수에 각 클래스에서 독립적으로 실행시키고 싶은 부분을 Argment로 넘겨주어, 실행하도록 만들면 된다.

그럼 여기서 공통된 부분들과 독립적으로 실행되어야 할 부분을 나누어 보자.

AOP 설명 3

우리가 원하는 건, 각 클래스의 성격에 따라, 독립적으로 실행될 것은 실행되고, 공통된 부분은 따로 관리되어, 실행되는 것을 원한다.

즉, 공통된 부분에 해당하는 횡단 관심사(Cross Cutting)를 찾아내어 따로 관리되었으면 한다.

AOP 설명 4

우리는 최종적으로, 위 그림처럼 횡단 관심사를 분리해내어 관리하고, 각 클래스에서 독립적으로 실행된 로직을 따로 관리하는 걸 원한다. 다시 말하면, 횡단 관심사를 비즈니스 로직에서 감추는 것을 원한다.

이에 대한 해결책이 AOP, 관점 지향 프로그래밍이다.

AOP Concepts

일단 AOP Concepts를 보도록 하자.

이는 Spring에서만 사용하는 용어는 아니고, 직관적이진 않기 때문에 개념과 용어의 정의가 먼저 선행될 필요가 있다.

Join point

A point during the execution of a program, such as the execution of a method or the handling of an exception. In Spring AOP, a join point always represents a method execution.

메서드 실행 또는 예외 처리와 같은 프로그램 실행 중 한 지점.

Spring에서는 항상 메서드 실행을 말한다. (AOP라는 것에 초점을 맞추면, 메서드가 아니라 클래스나 여러 방면에서 활용될 수 있지만, Spring에서는 메서드만 가능하다)

즉, 앞서 보았던 이미지에서 각 클래스의 독립 부분에 대한 후보지로 볼 수 있다.

프로그램이 실행되면, 여러 join point가 있을 수 있고, 어떤 클래스에서는 위 횡단 관심사가 필요없어, Join point가 없을 수 있다.

Pointcut

A predicate that matches join points. Advice is associated with a pointcut expression and runs at any join point matched by the pointcut (for example, the execution of a method with a certain name). The concept of join points as matched by pointcut expressions is central to AOP, and Spring uses the AspectJ pointcut expression language by default.

Join point에 대해서 판단할 수 있는 것.

여러 Join point에 대해서, 모든 클래스들 중에 AOP를 적용해야 할 부분에 대해서 정의한다.

1개 이상 Joint point를 묶어서 Pointcut이 될 수 있고, 1개 이상의 횡단 관심사가 실행될 수도 있다.

즉, Join point (독립 부분의 후보지) 중에서 실제로 횡단 관심사(Advice)가 적용되는 독립 부분을 나타낸다.

Advice

Action taken by an aspect at a particular join point. Different types of advice include “around”, “before” and “after” advice. (Advice types are discussed later.) Many AOP frameworks, including Spring, model an advice as an interceptor and maintain a chain of interceptors around the join point.

특정 Join point에서 aspect에 의해 취해진 행위.

다시 말해, Join point가 언제 동작할지에 대해 설정하며, JoinPoint에서 실행되어야 하는 코드를 말한다.

위 이미지의 횡단 관심사 부분에 실제적으로 적용되는 코드다.

즉, 독립 부분의 앞, 뒤 등 언제 적용될 지를 설정하고, 어떤 코드가 실행될지에 대해 정의한다.

advice의 타입은 아래를 참고하자.

Before advice: Advice that runs before a join point but that does not have the ability to prevent execution flow proceeding to the join point (unless it throws an exception).
After returning advice: Advice to be run after a join point completes normally (for example, if a method returns without throwing an exception).
After throwing advice: Advice to be run if a method exits by throwing an exception.
After (finally) advice: Advice to be run regardless of the means by which a join point exits (normal or exceptional return).
Around advice: Advice that surrounds a join point such as a method invocation. This is the most powerful kind of advice. Around advice can perform custom behavior before and after the method invocation. It is also responsible for choosing whether to proceed to the join point or to shortcut the advised method execution by returning its own return value or throwing an exception.

Aspect

A modularization of a concern that cuts across multiple classes. Transaction management is a good example of a crosscutting concern in enterprise Java applications. In Spring AOP, aspects are implemented by using regular classes (the schema-based approach) or regular classes annotated with the @Aspect annotation (the @AspectJ style).

여러 클래스를 가로지르는 관심사의 모듈화라고 말한다.

즉, 앞서 보았던 이미지의 횡단 관심사 부분이다.

좀 더 거시적인 관점의 용어라고 할 수 있다. Advice와 Pointcut을 합친 것.

Target object

An object being advised by one or more aspects. Also referred to as the “advised object”. Since Spring AOP is implemented by using runtime proxies, this object is always a proxied object.

하나 이상의 aspect에 의해 동작하게될 객체.

위 이미지의 독립 부분이 구현되는 객체다.

AOP Proxy

An object created by the AOP framework in order to implement the aspect contracts (advise method executions and so on). In the Spring Framework, an AOP proxy is a JDK dynamic proxy or a CGLIB proxy.

AOP는 Proxy 방식으로 동작한다.

아래에 별도로 설명을 한다.

Weaving

linking aspects with other application types or objects to create an advised object. This can be done at compile time (using the AspectJ compiler, for example), load time, or at runtime. Spring AOP, like other pure Java AOP frameworks, performs weaving at runtime.

Aspect들과 advise가 적용된 객체 사이의 연결이다.

다시 말해, 포인트컷으로 지정한 메소드가 호출될 때, Advice에 해당하는 메소드가 삽입되는 과정이다.

weaving은 Runtime에 진행된다.

AOP Proxy

Proxy라는 것은 A라는 Class가 있을 떄, 이 Class를 감싸는 A Proxy Class가 있고, 외부에서는 A Proxy Class를 실행시키며, A Proxy Class의 특정 동작을 한 후, A Class를 동작시키며, A Proxy Class가 원하는 대로 호출하여 동작시키는 과정이 있다.

AOP Proxy에 대해 다음 링크의 예시를 참고해 한번 보도록 하자.

public interface Pojo {
    void foo();
}

public class SimplePojo implements Pojo {

    public void foo() {
        System.out.println("run foo");
    }
}

public class Main {
    public static void main(String[] args) {
        Pojo pojo = new SimplePojo();
        pojo.foo();
    }
}

패키지를 만들어, 위와 같이 구성하였다.

Proxy

앞서, Proxy에 대한 설명 했듯이, Proxy는 Plain Object (SimplePojo)를 부르기 전에, Proxy로 감싼다.

따라서, 코드를 호출할 때, Proxy를 통해 Plain Object를 호출하고, Proxy를 통해, 코드가 동작한다.

public class Main {
    public static void main(String[] args) {
        ProxyFactory factory = new ProxyFactory(new SimplePojo());
        factory.addInterface(Pojo.class);
        factory.addAdvice(new RetryAdvice());

        Pojo pojo = (Pojo) factory.getProxy();
        // this is a method call on the proxy!
        pojo.foo();
    }
}

Proxy를 만들 때는 Java SDK에서는 Dynamic Proxy 기능을 사용하고, ProxyFactory를 만들고, 특정 Advice를 넣는 형태가 된다.

RetryAdvice가 없기 때문에, 해당 클래스도 만들어준다.

public class RetryAdvice implements MethodInterceptor {
    @Override
    public Object invoke(MethodInvocation invocation) throws Throwable {
        return null;
    }
}

invoke 메서드에 null을 리턴하다보니, pojo.foo()를 호출해도 동작하지 않는다.

public class RetryAdvice implements MethodInterceptor {
    @Override
    public Object invoke(MethodInvocation invocation) throws Throwable {
        System.out.println("Before");
        Object proceed = invocation.proceed();
        System.out.println("After");
        return proceed; 
    }
}

위와 같이, Proxy를 통해 proceed를 리턴하여, pojo.foo()가 동작하게끔 만들 수 있다.

위 방식도 Spring에서 제공하는 일종의 AOP이다.

Wrap up

AOP는 개념부터 잡아야 하다보니, 블로깅을 나누어서 할 예정이다.

우선 AOP의 개념을 알아보았고, 이후에 AOP를 어떻게 Spring에서 사용하는지 알아보도록 하자.

[Spring] Validation은 어떻게 확인할까?

KOOCCI — Fri, 12 Aug 2022 02:29:33 +0900

목표 : 스프링에서 Validation을 확인할 수 있다.

Validator

Spring은 Validator라는 Interface를 통해, Validation을 제공하고 있다.

public class Person {

    private String name;
    private int age;

    // the usual getters and setters...
}

위와 같은 클래스가 존재한다고 하자.

그리고, 위 Person 클래스의 필드에 대해, validation을 제공하는 클래스를 만들어볼 것이다.

public class PersonValidator implements Validator {

    /**
     * This Validator validates only Person instances
     */
    public boolean supports(Class clazz) {
        return Person.class.equals(clazz);
    }

    public void validate(Object obj, Errors e) {
        ValidationUtils.rejectIfEmpty(e, "name", "name.empty");
        Person p = (Person) obj;
        if (p.getAge() < 0) {
            e.rejectValue("age", "negativevalue");
        } else if (p.getAge() > 110) {
            e.rejectValue("age", "too.darn.old");
        }
    }
}

먼저 Validator Interface를 알아보자.

두 가지 메서드를 지원하고 있으며, 다음과 같다.

supports(Class): Can this Validator validate instances of the supplied Class?
validate(Object, org.springframework.validation.Errors): Validates the given object and, in case of validation errors, registers those with the given Errors object.

supports는 해당 클래스가 Person 클래스인지 확인하며, validate는 실제 validation 로직이 작성된다.

이 때, 오류 상황에 대한 내용은 Errors Object로 확인할 수 있다.

validate Method

validate 메서드를 보면, Return Type이 조금 생각한 것과 다르다.

boolean이 아닌 void 타입인 것이다.

보통 Validation을 할 때는 boolean으로 처리하거나, Exception 으로 예외처리하는데, 현재 코드는 Argument로 Errors를 받고, Errors의 값을 변경하는 형태의 코드다.

이렇게 처리되는 것은 다음 문서를 보면 이해가 쉽다.

public void check() {
   if (date == null) throw new IllegalArgumentException("date is missing");
   LocalDate parsedDate;
   try {
     parsedDate = LocalDate.parse(date);
   }
   catch (DateTimeParseException e) {
     throw new IllegalArgumentException("Invalid format for date", e);
   }
   if (parsedDate.isBefore(LocalDate.now())) throw new IllegalArgumentException("date cannot be before today");
   if (numberOfSeats == null) throw new IllegalArgumentException("number of seats cannot be null");
   if (numberOfSeats < 1) throw new IllegalArgumentException("number of seats must be positive");
 }

위 코드를 보면, 모든 데이터의 Validation에 대해 Exception 처리를 하고 있다.

그러나, 위 문서의 제목처럼 Validation에서는 Exception을 Notification 으로 변경하라고 한다.

위와 같이 Exception 처리를 하면, 제일 처음 Exception 사항 외에는 처리 결과를 알지 못한다.

따라서, 아래와 같이 변경하는 것을 추천한다.

Replace Exception

Resolving Codes to Error Messages

위에서 ValidationUtils나 Errors를 통해 에러 상황을 처리중이다.

이 때, 에러 코드를 작성해 넣어주고 있는데 이에 대한 처리를 보도록 하자.

에러 코드는 국제화(i18n)에 따라, 사용자의 Locale에 따라, 적절한 언어로 응답을 만들어 줄 수 있다.

에러 코드와 에러 메세지는 보통 messages.properties와 같은 properties 파일에서 읽어오도록 구현한다.

이 에러 메세지는 Spring에서 MessageSource를 통해, 가져오도록 할 수 있다.

MessageSource

MessageSource의 구현은 2가지가 있다.

StaticMessageSource: 코드로 메시지를 등록한다.
ResourceBundleMessageSource: 리소스 파일로부터 메시지를 읽어와 등록한다.

예시를 통해 알아보도록 하자.

위에서 사용한 Person과 PersonValidator 소스는 동일하다.

@Getter
@Setter
@AllArgsConstructor
public class Person {

    private String name;
    private int age;
}

public class PersonValidator implements Validator {

    /**
     * This Validator validates only Person instances
     */
    public boolean supports(Class clazz) {
        return Person.class.equals(clazz);
    }

    public void validate(Object obj, Errors e) {
        ValidationUtils.rejectIfEmpty(e, "name", "name.empty");
        Person p = (Person) obj;
        if (p.getAge() < 0) {
            e.rejectValue("age", "negativevalue");
        } else if (p.getAge() > 110) {
            e.rejectValue("age", "too.darn.old");
        }
    }
}

메인 함수를 통해, Validation을 체크할텐데, 이 때 Error는 Interface이기 때문에, 이에 대한 구현체 중 하나인 BindException을 사용할 것이다.

public static void main(String[] args) {
    Person person = new Person("", 200);
    PersonValidator personValidator = new PersonValidator();
    if(personValidator.supports(person.getClass())) {
        BindException error = new BindException(person, "person");
        personValidator.validate(person, error);

        log.error(">>" + error.hasErrors());
        log.error(">>>>" + error.getAllErrors());
    } else {
        log.error("invalid Class");
    }
}

23:48:15.866 [main] ERROR com.example.demo.validation.Main - >>true

23:48:15.871 [main] ERROR co
m.example.demo.validation.Main - >>>>[Field error in object 'person' on field 'name': rejected value []; codes [name.empty.person.name,name.empty.name,name.empty.java.lang.String,name.empty]; arguments []; default message [null], Field error in object 'person' on field 'age': rejected value [200]; codes [too.darn.old.person.age,too.darn.old.age,too.darn.old.int,too.darn.old]; arguments []; default message [null]]

에러에 대한 로그를 보면, 설정했던 에러 코드들을 볼 수 있다.

Validator의 단점

위와 같이, 비즈니스 로직을 하나하나 구현해줘야 하는 단점이 있다.

해당 로직이 복잡하다면, 당연히 어울리는 방향이지만, 문자열이 없는 경우 ,특정값보다 큰 경우와 같은 건 Validator로 구현하는 것보다 더 간단한 방법이 필요해보인다.

그에 따라, Annotation으로 설정하는 방법들이 있다.

Java Bean Validation

해당 링크를 보면, Annotation에 대한 설정들이 나온다.

package com.example.demo.validation;
import javax.validation.constraints.Min;
import javax.validation.constraints.NotNull;
import javax.validation.constraints.Size;
import lombok.AllArgsConstructor;
import lombok.Getter;
import lombok.Setter;

@Setter
@Getter
@AllArgsConstructor
public class PersonForm {
    @NotNull
    @Size(max=64)
    private String name;

    @Min(0)
    private int age;
}

위 과정에서 validation을 위한 Dependency를 추가했다는 것을 보기 위해, import도 추가해 두었다.

validation-api

많은 Validation을 제공해주며, 간단한 것은 Annotation으로 처리가 가능하다는 것을 볼 수 있다.

Configuring a Bean Validation Provider

위와 같이, Annotation으로 적용 가능했고, 이를 이제 어떻게 쓰는지 알아야 한다.

예시를 보며, 그 사용법을 먼저 보도록 하자.

우선, Dependency부터 확인하자.

implementation 'org.springframework.boot:spring-boot-starter-validation'

Springboot 에서는 위와 같이 등록되면 되며, Spring에서는 Hibernate Validator 와 같은 구현체가 필요하니, 유의하도록 하자.

spring-boot-starter-validation에는 Hibernate-validator가 이미 포함되어 있다.

조심해야 하는 부분은, validation-api 가 jakarta 로 3.0.2버전이길래, 해당 버전으로 적용하려 했더니, 패키지 구조가 달라 정상적이 처리가 불가능했다.

(springboot-starter에서 적용되는 버전은 2버전 대였으며, javax를 사용하고 있었다.)

AppConfig(Configuration)를 통해, validator를 Bean으로 등록하자.

@Configuration
public class AppConfig {
    @Bean
    public LocalValidatorFactoryBean validator() {
        return new LocalValidatorFactoryBean();
    }
}

위와 같이, Method를 Bean으로 등록하면, Autowired를 통해 Service에서 Validator를 가져와 쓸 수 있게 된다.

package com.example.demo.service;

import com.example.demo.validation.PersonForm;
import java.util.Set;
import javax.validation.ConstraintViolation;
import javax.validation.Validator;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
@Slf4j
public class MyService {

    @Autowired
    private Validator validator;

    public void check() {
        PersonForm personForm = new PersonForm("KOO", 25);
        // PersonForm personForm = new PersonForm("KOO", -5);
        Set<ConstraintViolation<PersonForm>> results = validator.validate(personForm);

        if(!results.isEmpty()) {
            log.error("Validate Fail");
            results.forEach(v -> {
                log.error(">> error Msg : " + v.getMessage());
            });
        } else {
            log.info("Validate Success");
        }
    }
}

마지막으로 메인에서 실행해보며, 설정에 따라, Success 혹은 Fail를 확인하자.

@Slf4j
public class Main {
    public static void main(String[] args) {
        AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext();
        context.register(AppConfig.class);
        context.refresh();
        MyService service = context.getBean(MyService.class);
        service.check();
        context.close();
    }
}

에러 상황에서 로그를 확인하면 다음과 같이, 한글로 나오는 것을 볼 수 있다. (check method 내에 Locale 설정으로, 다른 언어도 가능하다)

01:55:46.733 [main] ERROR com.example.demo.service.MyService - Validate Fail
01:55:46.737 [main] ERROR com.example.demo.service.MyService - >> error Msg : 110 이하여야 합니다 01:55:46.737 [main] ERROR com.example.demo.service.MyService - >> error Msg : 크기가 0에서 3 사이여야 합니다

Custom Annotation for Validation (Configuring Custom Constraints)

Spring의 Validator를 사용하는 것보다, Annotation을 사용하는 것이 매우 간편하다.

그런데, 지원하지 않는 기능에 대한 Validation은 어떻게 적용할 수 있을까?

앞서, Validator Interface의 구현체가 또 필요한 것일까?

다행히, 그렇지 않았다.

Custom 하게 Annotation을 적용해 볼 수 있다.

그를 위해서는 2가지를 구현해야 한다.

Constraint(제약), 그리고 Validator(검증자)다.

A @Constraint annotation that declares the constraint and its configurable properties.
An implementation of the javax.validation.ConstraintValidator interface that implements the constraint’s behavior.

@Target({ElementType.METHOD, ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy=MyConstraintValidator.class)
public @interface MyConstraint {
}

import javax.validation.ConstraintValidator;

public class MyConstraintValidator implements ConstraintValidator {

    @Autowired;
    private Foo aDependency;

    // ...
}

예시를 봐야 좀더 이해가 쉬울 것 같아, 다른 분이 적용해 둔 것을 가져와보았다.

@Target({METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER, TYPE_USE})
@Retention(RUNTIME)
@Constraint(validatedBy = NoEmojiValidator.class)
@Documented
public @interface NoEmoji{
    String message() default "Emoji is not allowed";

    Class<?>[] groups() default {};

    Class<? extends Payload>[] payload() default {};

    @Target({METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER})
    @Retention(RUNTIME)
    @Documented
    @interface List{
        NoEmoji[] value();
    }
}

public class NoEmojiValidator implements ConstraintValidator<NoEmoji, String> {
    @Override
    public boolean isValid(String value, ConstraintValidatorContext context) {
        if (StringUtils.isEmpty(value) == true) {
            return true;
        }

        return EmojiParser.parseToAliases(value).equals(value);
    }
}

public class CreateContact {
    @NoEmoji
    @Length(max = 64)
    @NotBlank
    private String uid;
    @NotNull
    private ContactType contactType;
    @Length(max = 1_600)
    private String contact;
}

Wrap up

꽤 길게 Validation에 대해 알아보았다.

Annotation을 사용하는게 바람직하면서도, Custom 하게 만들 수도 있어야 한다는 점을 유념하도록 하자.

[Spring] Resource는 어떻게 처리할까?

KOOCCI — Thu, 11 Aug 2022 01:36:32 +0900

목표 : 스프링에서 Resource 처리를 구현할 수 있다.

Resource

IoC Container에 대한 챕터를 마무리하고, Resource 챕터를 확인해보자.

먼저 Resource가 무엇인지 이해가 필요할 것 같다.

resources

intellij로 스프링 프로젝트를 시작하면, resources 폴더가 생기게 된다.

Spring에서 java 뿐 아니라, 외부의 파일들을 읽어야 하는 경우가 생긴다.

(앞서 배웠던 properties도 외부 파일 중 하나다.)

이런 외부 파일들을 읽어드리거나, URL을 통해 가져와서 프로그래밍에 활용을 하는데, Spring에서는 Resource라는 Interface를 통해, 추상화를 해주었다.

Spring이 없으면, 어떻게 할 수 있었을까?

public static void main(String[] args) throws IOException {
    String path = "C:\\Users\\lazye\\Desktop\\dev\\src\\main\\resources\\application-dev.properties";
    File file = new File(path);
    InputStream is = new FileInputStream(file);
    byte[] bytes = is.readAllBytes();
    String properties = new String(bytes);
    System.out.println(properties);
}

간단히 파일을 읽어보았다.

이렇게 특정 파일을 읽어오고 싶을 때는 위와 같이 했고, 다만 절대 경로를 알 수 없는 경우가 많으니, classPath를 설정해주는 경우가 많았다.

public static void main(String[] args) throws IOException {
    InputStream is = Main.class.getClassLoader().getResourceAsStream("application-dev.properties");
    byte[] bytes = is.readAllBytes();
    String properties = new String(bytes);
    System.out.println(properties);
}

Resource Interface

그럼 이제, Resource Interface를 보도록 하자.

public interface Resource extends InputStreamSource {

    boolean exists();

    boolean isReadable();

    boolean isOpen();

    boolean isFile();

    URL getURL() throws IOException;

    URI getURI() throws IOException;

    File getFile() throws IOException;

    ReadableByteChannel readableChannel() throws IOException;

    long contentLength() throws IOException;

    long lastModified() throws IOException;

    Resource createRelative(String relativePath) throws IOException;

    String getFilename();

    String getDescription();
}

위에서 보듯, InputStreamSource를 상속받고 있고, 이 Interface는 간단히, getInputStream을 가져올 수 있도록 되어 있다.

즉, 위에서 해본 것처럼 Byte 배열을 가져올 수 있다.

public interface InputStreamSource {

    InputStream getInputStream() throws IOException;
}

Built-in Resource Implementations

다만, 우리는 Resource의 구현체를 주로 사용한다.

Spring에서 제공하는 구현체가 있고, 관례에 따라(추후 확인할 Resource Loader에서 사용하는) 이를 가져와 사용한다.

위 구현체 중, 자주 사용하는 2가지만 알아보고 상황에 따라, 다른 구현체도 사용해볼 수 있도록 하자.

UrlResource

file:
for accessing filesystem paths,
https:
for accessing resources through the HTTPS protocol,
ftp:
for accessing resources through FTP

위와 같이, file:, https:, ftp: 같이 프로토콜을 명시하고, 해당 리소스의 위치를 URL 방식으로 알려주는 형태다.

ClassPathResource

앞서, ClassLoader를 통해, properties를 읽었듯이, ClassPath를 통해 리소스 위치를 찾는 방식이다.

ResourceLoader

실제로는 구현체의 사용보다, ResourceLoader를 통해 리소스를 가져오는 경우가 많다.

public interface ResourceLoader {

    Resource getResource(String location);

    ClassLoader getClassLoader();
}

위와 같이, ResourceLoader는 Interface다.

그리고, 우리가 사용하는 ApplicationContext의 상속구조를 타고 올라가보면 다음과 같다.

public interface ApplicationContext extends EnvironmentCapable, ListableBeanFactory, HierarchicalBeanFactory,
		MessageSource, ApplicationEventPublisher, ResourcePatternResolver
// ResourcePatternResolver Interface를 타고 들어간다.

public interface ResourcePatternResolver extends ResourceLoader

즉, Spring에서 사용하는 ApplicationContext 구현체는 ResourceLoader를 상속받아 구현하고 있다.

따라서, 다음과 같이 사용할 수 있다.

Resource template = ctx.getResource("some/resource/path/myTemplate.txt");
Resource template = ctx.getResource("classpath:some/resource/path/myTemplate.txt");
Resource template = ctx.getResource("file:///some/resource/path/myTemplate.txt");
Resource template = ctx.getResource("https://myhost.com/resource/path/myTemplate.txt");

ResourceLoaderAware

Aware라는 postfix가 붙은 Interface의 공통점은, 앞선 포스팅에서 알아봤듯이, ResourceLoader를 set하고, get하여 사용하는 형태로 Bean에서 사용한다.

Wrap up

이렇게 Resource를 사용하는 방법까지 알아보았다.

이제 validation과 AOP를 알아본 후에, Core 부분을 마무리하도록 하자.

[Spring] 환경설정은 어떻게 할 수 있을까?

KOOCCI — Wed, 10 Aug 2022 22:59:11 +0900

목표 : 스프링에서 Environment 설정을 할 수 있다.

이번에 진행하고자 하는 사항은 Environment 설정이다.

조금 더 구체적으로 Environment Abstraction이며, 그 위치는 다음과 같다.

Environment Interface

Environment Abstraction이라는 단어들로 알 수 있듯, 환경에 대한 추상화, 즉, Spring에서는 Environment Interface를 제공한다.

주로, Environment Interface는 profiles 나 properties 처럼, 프로그램의 환경 변수 그리고, Applcation의 프로필을 관리할 때 사용하게 된다.

다음 Environment Interface 문서를 보도록 하자.

모든 것들의 Super Interface는 PropertyResolver이며, acceptsProfiles나 getDefaultProfiles 등의 Method로 프로필 정보를 받아올 수 있다.

PropertyResolver 의 경우, getProperty 등으로, 환경 변수를 가져올 수 있다.

Resolver 라는 건 보통 변환기와 같은 의미로 사용된다.
PropertyResolver 역시, 환경변수를 사용하기 좋게 변환하는 역할을 한다고 보면 이해하기 쉽다.

Profile

Profile의 경우는 보통 서버환경에 따라 설정값을 달리 할 경우가 많다.

dev 환경에서는 Profile에 dev를 설정하고, Testbed, staging 서버에서는 stage 혹은 tb, 그리고 상용 서버에선 prod 로 설정하면서 Properties나 Datasource를 다르게 읽는 경우가 가장 자주 쓰이게 된다.

그럼 사용 예시를 한번 보도록 하자.

Datasource

Datasource Interface는 DB Connection 관리를 위해 사용한다.

jdbc에서 connection을 단순히 open을 하면, 하나의 Connection 만 연결된다.

그러나, 웹서버에서는 여러 요청에 따라 DB 자원을 사용해야하는데, 하나의 Connection으로는 무리가 따른다.

따라서, DataSource를 통해 Connection을 관리(Connection Pool)한다.

@Bean
public DataSource dataSource() {
    return new EmbeddedDatabaseBuilder()
        .setType(EmbeddedDatabaseType.HSQL)
        .addScript("my-schema.sql")
        .addScript("my-test-data.sql")
        .build();
}

위와 같이 dataSource를 Bean으로 등록했다고 하자.

소스를 보듯, Embedded된 Datasource로, 개발환경에서 사용하는 경우일 것이다.

@Bean(destroyMethod="")
public DataSource dataSource() throws Exception {
    Context ctx = new InitialContext();
    return (DataSource) ctx.lookup("java:comp/env/jdbc/datasource");
}

이제 application의 DataSource가 상용 서버의 JNDI 디렉토리에 등록되어 있다고 가정하고, 이를 상용 환경에 배포할 수 있는 방법을 고려해야 한다.

@Bean(destroyMethod="")

destroyMethod는 Bean이 Application Context에서 종료될 때, 호출되는 메서드이다.

Context ctx = new InitialContext();

Connection Pool에 접근하기 위해서는 JNDI 서비스를 사용해야 하며, JNDI는 서버에서 관리하고 있는 리소스에 대한 정보를 알고 있고, 특정 리소스를 찾아 사용할 수 있도록 객체를 반환한다.

ctx.lookup("java:comp/env/jdbc/datasource");

lookup은 DNS 서버에서 IP를 찾 듯, 리소스를 찾은 후 리소스를 사용할 수 있도록 객체를 반환해주는 메서드다.

찾고자 하는 리소스는 jdbc/datasource이며, WAS인 톰캣에서 리소스를 관리하는 가상의 디렉터리는 "java:comp/env"이라는 뜻이다.

JNDI : JNDI(Java Naming and Directory Interface)는 디렉터리 서비스에서 제공하는 데이터 및 객체를 발견하고 참고하기 위한 자바 API다. (분산환경에서 자원을 연결해주는 기능)

@Profile

그럼 이제, Profile을 통해 어떻게 접근할 수 있을지 보도록 하자.

@Configuration
@Profile("development")
public class StandaloneDataConfig {

    @Bean
    public DataSource dataSource() {
        return new EmbeddedDatabaseBuilder()
            .setType(EmbeddedDatabaseType.HSQL)
            .addScript("classpath:com/bank/config/sql/schema.sql")
            .addScript("classpath:com/bank/config/sql/test-data.sql")
            .build();
    }
}

@Configuration
@Profile("production")
public class JndiDataConfig {

    @Bean(destroyMethod="")
    public DataSource dataSource() throws Exception {
        Context ctx = new InitialContext();
        return (DataSource) ctx.lookup("java:comp/env/jdbc/datasource");
    }
}

위처럼 Annotation도 가능하지만, XML역시 가능하다.

<beans profile="development"
    xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:jdbc="http://www.springframework.org/schema/jdbc"
    xsi:schemaLocation="...">

    <jdbc:embedded-database id="dataSource">
        <jdbc:script location="classpath:com/bank/config/sql/schema.sql"/>
        <jdbc:script location="classpath:com/bank/config/sql/test-data.sql"/>
    </jdbc:embedded-database>
</beans>

<beans profile="production"
    xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:jee="http://www.springframework.org/schema/jee"
    xsi:schemaLocation="...">

    <jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/datasource"/>
</beans>

그리고, 다음과 같이, 어떤 Profile을 Active 시킬지, 설정할 수 있다.

AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
ctx.getEnvironment().setActiveProfiles("development");
ctx.register(SomeConfig.class, StandaloneDataConfig.class, JndiDataConfig.class);
ctx.refresh();

그러나 위처럼 하면, 소스를 수정해야 하므로, 보통 properties로 설정을 하며, 다음과 같이 설정하여 구동한다.

# properties 파일일 때 (application-prod.properties)
spring.profiles.active=prod

# yml 파일일 때 (application-prod.xml)
spring:
  profiles:
    active: prod

java -jar -Dspring.profiles.active=prod application.jar

Wrap up

아마 가장 처음에 Spring 프로젝트를 시작할 때 설정하는 부분일 것으로 보인다.

환경 설정은 아주 간단히 작성하였지만, 연동하는 point가 많을 수록 그 양이 상당해지고, 그에 따라 관리해야할 포인트도 많아진다. (특히, 배포 시에 Property 파일을 바꾸는 작업을 할 때는 주의해야한다.)

위와 같이, 단순히 환경설정하는 방법만 알고 진행하는 것보다 ,그에 대한 자세한 내용을 알아보았다.

자바스크립트 기초부터 모던 자바스크립트까지 - this편

KOOCCI — Wed, 3 Aug 2022 01:49:19 +0900

목표 : 자바스크립트의 this를 사용할 수 있다.

우리가 객체를 공부할 때 크게 2가지로 나누어진다는 것을 알았다.

프로퍼티 : 객체의 상태를 나타내는 값(Data)
메서드 : 프로퍼티(상태 데이터)를 참조하고 조작할 수 있는 동작(Behavior)

위 두가지를 하나의 논리적인 단위로 묶은 복합적인 자료구조가 객체이다.

이 때, 메서드에서는 자신이 속한 객체의 상태(프로퍼티)를 알 수 있어야 한다.

그 말은, 자신이 속한 곳이 어디인지 지칭할 수 있어야 한다는 말이며, 자신이 속한 객체를 가리키는 식별자를 참조할 수 있어야 한다는 말로 귀결된다.

그 역할을 this 가 하고 있다.

this 키워드

this는 자신이 속한 객체 또는 자신이 생성할 인스턴스를 가리키는 자기 참조 변수다.

주의해야 할 점은 this는 상황에 따라서 지칭하는 것이 달라진다.

다음 예시를 보자.

// 전역에서 this는 Window를 가리킨다.
console.log(this); // Window

// 일반 함수에서 this는 Window를 가리킨다. (전역과 동일)
function square(number) {
  console.log(this); // Window
  return number * number;
};
square(2);

// 객체 리터럴
const person = {
  name: 'Lee',
  getName() {
    // 메서드 내부에서 this는 메서드를 호출할 때 사용된 객체를 가리킨다.
    console.log(this); // {name: "Lee", getName: f}
    return this.name;
  }
}
console.log(person.getName());

// 생성자 함수
function Person(name) {
  console.log(this); // Person {name: "Lee"}
  this.name = name;
}

const me = new Person("Lee");

또한 strict mode에서는 일반 함수 내부의 this는 undefined 처리된다.

함수 호출 방식에 따른 this 바인딩

조금 더 자세히 정리해보자.

this가 가리키는 값, 즉 this 바인딩은 함수 호출 방식에 의해 동적으로 결정된다.

바인딩(binding) : 식별자와 값을 연결하는 과정

예시> 변수 선언은 변수 이름(식별자)과 확보된 메모리 공간 주소를 바인딩하는 것.

예시> this 바인딩은 this와 this가 가리킬 객체를 연결하는 과정

함수 호출 방식, 즉 함수가 어떻게 호출되었는지에 따라 결정된다는 것이다.

참고로 함수의 Scope를 공부할 때는 렉시컬 스코프를 설명했었다.

이 때, 렉시컬 스코프는 함수가 정의가 평가되어 함수 객체가 생성하는 시점에 상위 스코프를 결정했다.

그러나, this는 함수 호출 시점에 결정된다.

위와 같은 설명을 하는 것에는 이유가 있다.

this가 함수 호출 시점에 결정된다는 것은, 같은 함수더라도 어떻게 호출되냐에 따라 그 환경이 다를 수 있다는 것이다.

다시 말해, this는 선언된 위치에 따라 다르게 지칭하며, 그 선언된 위치는 함수가 어떻게 호출되냐에 따라 다르다.

먼저 함수의 호출 방식에 어떤 것들이 있는지부터 알 필요가 있다.

일반 함수 호출
메서드 호출
생성자 호출
Function.prototype.apply/call/bind 메서드에 의한 간접 호출

그리고 바로 예시를 보자.

function square(number) {
  console.log(this);
  return number * number;
};

일반적인 함수를 선언하였다.

아마 앞서 본 예시와 같이, square(2);를 호출한다면, this는 Window 혹은 strict mode일 때 undefined를 출력할 것이다.

그런데 다음과 같이 바꾸어 보면, 함수 호출 방식이라는 것이 무엇인지 감이 온다.

// 호출 방식에 따라 this 바인딩이 동적으로 결정된다.
function foo() {
  console.log(this);
};

// 1. 일반 함수 호출
// foo 함수를 일반적인 방식으로 호출
foo(); // Window

// 2. 메서드 호출
// 프로퍼티 값으로 square을 할당
// 메서드를 호출한 객체를 출력
const obj = { foo };
obj.foo(); // {foo: f}

// 3. 생성자 호출
// foo 함수가 생성한 인스턴스를 출력
new foo(); // foo {}

// 4. Function.prototype.call/appliy/bind
const bar = { name: 'bar' };
foo.call(bar); // {name: 'bar'}
foo.apply(bar); // {name: 'bar'}
foo.bind(bar); // f foo() {console.log(this);}

일반 함수 호출

가장 기본적으로 this는 전역 객체가 바인딩된다.

그리고 일반 함수는 중첩이더라도 this에는 전역 객체가 바인딩된다. 설령, 메서드 내에 있더라도, 콜백 함수더라도 말이다.

단, 앞서 말했듯이, strict mode에서는 undefined이다.

var value = 1;
const obj = {
  value: 100,
  foo() {
    // 메서드에서의 this
    console.log("foo`s this: ", this); // {value: 100, foo: f}
    console.log("foo`s this.value: ", this.value); // 100

    // 일반함수에서의 this는 전역이므로, value는 1
    function bar1() {
      console.log("bar1`s this: ", this); // Window
      console.log("bar1`s this.value: ", this.value); // 1
    };

    // strict mode에서는 undefined
    function bar2() {
      'use strict';
      console.log("bar2`s this: ", this); // undefined
      // console.log("bar2`s this.value: ", this.value); // Error
    };
    bar1();
    bar2();
  },
  // callback 내에 일반함수 역시 전역
  callback() {
    setTimeout(function() {
      console.log("callback`s this: ", this);
      console.log("callback`s this.value: ", this.value);
    }, 100);
  }
}
obj.foo();
obj.callback();

즉, 일반 함수로 호출된 모든 함수(중첩, 콜백 포함) 내부의 this는 전역 객체가 바인딩된다.

근데 중첩함수, 콜백함수에서까지, 전역 객체로 바인딩되는 것은 좀 문제가 있어보인다.

보통, 중첩함수나 콜백함수의 목적은 헬퍼 함수로서가 크다. 즉, 외부 함수의 로직을 대체할 경우가 많다.

따라서, 이에 대한 적절한 절차가 필요해 보인다.

var value = 1;
const obj = {
  value: 100,
  foo() {
    const that = this;
    setTimeout(function() {
      console.log("callback`s this: ", this);
      console.log("callback`s that: ", that);
    }, 100);
  }
}
obj.foo();

약간의 변조를 주었다.

사실 앞서 잠깐 다뤘던 apply, call, bind 메서드 혹은 화살표 함수를 사용하면 해결할 수 있다.

이에 대해서는 잠시 후에(화살표 함수는 나중에) 다루어 보도록 하자.

메서드 호출

앞서 계속해서 메서드 호출을 확인해왔다.

주의할 점은 메서드 내부의 this는 메서드를 소유한 객체가 아니라 메서드를 호출한 객체에 바인딩된다는 것이다.

소유와 호출의 개념을 정리해보자.

const person1 = {
  name: 'Lee',
  getName() {
    // 메서드 내부의 this는 메서드를 호출한 객체에 바인딩
    return this.name;
  }
};

// 메서드 getName을 호출한 객체는 person이다.
console.log(person1.getName()); // Lee

const person2 = {
	name: 'Kim'
}

// person2의 getName 메서드를 person1에게서 가져와 할당
person2.getName = person1.getName;
// getName을 호출한 객체는 person2이다.
console.log(person2.getName()); // Kim

// getName 변수에 person1.getName 메서드를 할당
const getName = person1.getName;
console.log(getName()); // ''
// Window.name이 호출되어, ''이 출력된다.

분명, getName 메서드는 처음에 person1에서 소유하고 있었다.

그런데 person2의 메서드나 변수에서 getName을 가져왔더니, this의 지칭이 바뀐 것을 알 수 있다.

이 부분은 메서드가 단지 프로퍼티에 바인딩된 함수라는 개념을 알아야 한다.

즉, getName 메서드는 독립적인 함수 객체이고, person1 객체에서 프로퍼티로 해당 함수를 지칭하고 있을 뿐이다.

위와 같이 테스트 하면 조금 헤깔릴 수 있다.

prototype으로 알아보면, 왜 호출한 객체라고 표현하는지 더 명확해진다.

function Person(name){
  this.name = name;
};

Person.prototype.getName = function() {
  console.log(this);
  return this.name;
}

const person1 = new Person('Lee');
const person2 = new Person('Kim');
const person3 = new Person('Koo');
person1.getName(); // Person {name: 'Lee'}
person2.getName(); // Person {name: 'Kim'}
person3.getName(); // Person {name: 'Koo'}

생성자 함수 호출

사실 이전 생성자를 공부하면서도 다루었기에 이해가 더 쉬울 것으로 보인다.

생성자 함수 내부의 this는 생성자 함수가 미래에 생성할 인스턴스가 바인딩된다.

function Circle(radius) {
    // 생성자 함수 내부의 this는 생성자 함수가 생성할 인스턴스를 가리킨다.
    this.radius = radius;
    this.getDiameter = function() {
    	return 2 * this.radius;
    };
}

const circle1 = new Circle(5);
const circle2 = new Circle(7);

console.log(circle1.getDiameter()); // 10
console.log(circle2.getDiameter()); // 14

또한, new가 아니라 그냥 호출한 경우, 일반 함수로 동작한다는 점을 다시 한번 되새기자.

Function.prototype.apply/call/bind

apply,call,bind 메서드를 설명하고자 할 때, 계속 Function.prototype의 메서드임을 붙여주고 있다.

이 의미는 모든 함수는 위 3가지 메서드를 호출할 수 있다는 것이다.

모든 함수 리터럴은 Function을 생성자(constructor)로 가지기 때문이다.

일단 해당 메서드들의 사용법을 보도록 하자.

먼저 apply 와 call은 다음과 같이 설명된다.

@thisArg : this로 사용할 객체
@argsArray : 함수에게 전달할 인수 리스트의 배열 또는 유사 배열 객체
@return : 호출된 함수의 반환값
func.apply(thisArg, [argsArray])
@thisArg : this로 사용할 객체
@argsArray : 함수에게 전달할 인수 리스트
@return : 호출된 함수의 반환값
func.call(thisArg[, arg1[, arg2[, ...]]])

function getThisBinding() {
  console.log(arguments);
  return this;
}

// this로 사용할 객체
const thisArg = {a: 1};
console.log(getThisBinding()); // window

console.log(getThisBinding.apply(thisArg, [1,2,3])); // {a:1}
console.log(getThisBinding.call(thisArg,1,2,3)); // {a:1}

즉, apply와 call은 둘다 기본적으로 함수를 호출하고 있다.

그 때, 특정 객체를 this로 바인딩한다.

bind는 this로 사용할 객체만 전달한다.

function getThisBinding() {
  return this;
}

// this로 사용할 객체
const thisArg = {a: 1};

// 함수를 호출하지는 않고, this로 사용할 객체만 전달한다.
console.log(getThisBinding.bind(thisArg)); // getThisBinding
// 명시적으로 호출이 필요하다.
console.log(getThisBinding.bind(thisArg)()); // {a:1}

bind 메서드는 흔히 앞서 알아봤던 중첩 함수 혹은 콜백 함수의 this가 다른 문제를 해결할 때 사용된다.

var value = 1;
const obj = {
  value: 100,
  foo() {
    setTimeout(function() {
      console.log("callback`s this: ", this);
    }.bind(this), 100);
  }
}
obj.foo();

앞서 this와 that으로 처리했던 함수를 위와 같이 처리하니 훨씬 깔끔해졌다.

Wrap Up

자바스크립트에서 this를 정리해보았다.

this는 함수 호출 시점에 따라 동적으로 할당되며, 그 종류는 일반 함수, 메서드, 생성자 함수, Function.prototype.call/apply/bind가 있었다.

그 차이점들을 잘 정리해보도록 하자.

[Spring] Classpath와 Component가 뭘까?

KOOCCI — Tue, 2 Aug 2022 00:05:53 +0900

목표 : 스프링의 Classpath와 Component를 설명할 수 있다.

현재 진행하고 있는 문서의 위치는 다음과 같다.

조금 생소하다면 생소하고, 많이 봤으면서도 설명하기 어려웠던 개념이 나오기에, 잘 정리하도록 해보자.

Classpath

먼저, Classpath가 무엇인지 부터 알도록 하자.

java는 빌드 후에 실행파일이 나오게 된다. (javac 로 컴파일 이후에 Java Byte Code인(JVM이 이해할 수 있는 언어) .class 파일이 나오는 것 정도는 알아야 한다)

즉, Classpath는 이 컴파일된 파일의 경로를 가리키게 된다.

classes 폴더

우리가 흔히, Spring을 빌드하고 나면, target 폴더에 결과물이 남는데, 이 때 classes 폴더가 바로 해당 파일의 경로가 될 것이다.

Classpath Scanning

이전 포스팅에서는 Annotation기반으로 소스코드 상에서 Metadata를 제공하는 방법을 알아보았다.

그럼에도 사실 이전까지 bean에 대한 기본적인 정의는 XML을 통해 제공해 주입시켜 주어야만 했다. (Autowired를 한다고 해도, Bean이 XML에 정의가 되어야 가능했다)

그럼 이제 자연스럽게 어떻게 Bean들을 소스코드 상에서 넣어줄 수 있을지가 궁금해진다.

그 방법이 바로 Classpath Scanning이다.

Java에서는 Classpath 경로 이후의 클래스 파일, 리소스 파일들을 읽을 수 있다.

즉, Classpath 경로 이후의 관리할 Bean을 @Component Annotation을 통해 Scanning할 수 있다.

앞서, 명시적으로 Bean을 XML에 등록해야했고, @Bean Annotation을 method에 주입해서 사용했는데, 그게 아니라, Class Level에 @Component라는 Annotation을 넣어주면서, Bean으로 넣어주라는 명령을 할 수 있다.

@Component

@Component를 주의깊게 들여다 보자.

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Indexed
public @interface Component { ... }

먼저 Runtime에 동작한다는 점이 눈에 띄며, Indexed라는 Annotation도 있다.

그리고 그 설명이 다음과 같다.

Indicates that an annotated class is a "component". Such classes are considered as candidates for auto-detection when using annotation-based configuration and classpath scanning.

주석이 달린 class가 Component임을 나타낸다. 또한 annotation으로 configuration 되고 자동 detecting되어 classpath scanning이 된다는 내용이 나온다.

그리고 Marker Interface로 Repository, Service, Controller, ClassPathBeanDefinitionScanner 들이 있음을 볼 수 있다.

@Retention : 어노테이션의 지속시간을 의미한다. RUNTIME은 RUNTIME 시 계속 지속된다는 것(.class에 존재)을 말하며, SOURCE 는 Compile 시에만 있으며, Byte Code에는 버려지고, CLASS는 class load때 버려지며 bytecode-level post-processing 때 유용하게 사용되는 기본값이다.

@Indexed : 스프링의 스테레오타입임을 나타낸다.

stereotype

Marker Interface : 일반적인 인터페이스와 동일하지만 사실상 아무 메소드도 선언하지 않고 의미만 전달하는 인터페이스

@Repository

자동으로 Bean으로 등록될 Component이며, DAO 처럼 DataBase에 Access 시 사용할 Bean일 때 설정한다.

@Service

자동으로 Bean으로 등록될 Component이며, Besiness 로직을 담당하는 Bean일 때 설정한다.

@Bean VS @Component

@Bean Annotation은 method에만 사용할 수 있다.

@Target({ElementType.METHOD, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Bean { ... }

그에 비해, @Component는 TYPE (Class, interface (including annotation type), or enum declaration)이 Target으로 등록되어 있다.

즉, 둘 사이에는 사용할 수 있는 Target이 달라, 용도가 다르다.

@Component는 개발자가 직접 개발한 클래스에 쓰이게 되며, @Bean은 외부로부터 주입받아야 하지만, 직접 수정이 어려운 사항 (Configuration에서의 DataSource 등)을 주입할 때 사용하게 된다.

명시적으로 패키지명과 클래스명으로 하는 것이 아닌, 특정 Classpath 이하에 있는 @Component로 등록된 클래스들은 bean으로 등록될 것이라고 자동 Scanning 해주는 것이다.

결국 XML 설정 등이 줄어드는 효과를 가질 수 있다.

Automatically Detecting Classes and Registering Bean Definitions

그럼 어떻게 자동으로 찾는 것일까? 그 절차에 대해 알아보자.

@Service
public class SimpleMovieLister {

    private MovieFinder movieFinder;

    public SimpleMovieLister(MovieFinder movieFinder) {
        this.movieFinder = movieFinder;
    }
}

@Repository
public class JpaMovieFinder implements MovieFinder {
    // implementation elided for clarity
}

Spring은 자동으로 위 2개와 같은 스테레오타입의 클래스를 감지하고 해당 BeanDefinition 인스턴스를 ApplicationContext에 등록할 수 있다.

@Configuration
@ComponentScan(basePackages = "org.example")
public class AppConfig  {
    // ...
}

그리고, 이런 클래스를 자동으로 감지하고 Bean을 등록하려면 @Configuration 에 @ComponentScan이 추가되어야 한다.

이 때, basePackages 는 두 클래스의 공통된 상위 패키지여야 한다. (혹은 각 클래스의 상위 패키지를 쉼표, 세미콜론, 공백 등으로 구분하여 등록해야 한다)

이를 XML로 하고 싶다면, 다음과 같이 적용할 수 있다.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        https://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/context
        https://www.springframework.org/schema/context/spring-context.xsd">

    <context:component-scan base-package="org.example"/>

</beans>

위 예시에서 annotation-config 설정이 빠진 것을 볼 수 있다.

<context:annotation-config/>

이는 @componentScan을 설정했을 때 생략이 가능하다.

AnnotationConfigApplicationContext

기존에 예시를 들 때마다, ApplicationContext에 대해 다음과 같이 선언했다.

ApplicationContext context = new ClassPathXmlApplicationContext("aop.xml");

그러나, AnnotationConfigApplicationContext를 설정하면 XML을 전혀 쓰지 않을 수 있다.

위 문서의 Constructor를 보면, componentClass 혹은 basePackage를 설정할 수 있음을 알 수 있다.

AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(Config.class);
AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext("com.test.classpath");

Filter

Component Scan을 할 때, Component 등록에 대한 Filter를 적용할 수 있다.

크게 2 가지 종류로 나뉘어 진다. (includeFilters, excludeFilters)

Filter의 타입으로는 annotation, assignable, aspectj, regex, custom 이 있다.

@Slf4j
@Configuration
@ComponentScan(basePackageClasses = Main.class,
excludeFilters = @Filter(type=FilterType.ASSIGNABLE_TYPE, classes = Test.class))
public class AppConfig {
    ConfigurableApplicationContext context = new AnnotationCOnfigApplicationContext(Main.class);
    Test test = context.getBean(Test.class);
    log.info("" + test);
    context.close();
}

위와 같이 설정한다면, 에러메세지가 나올 것이다. Test라는 Bean이 exclude 되었기 때문이다.

@Slf4j
@Configuration
@ComponentScan(basePackageClasses = Main.class,
excludeFilters = @Filter(type=FilterType.REGEX, pattern = "com.test.Test"))
public class AppConfig {
    ConfigurableApplicationContext context = new AnnotationCOnfigApplicationContext(Main.class);
    Test test = context.getBean(Test.class);
    log.info("" + test);
    context.close();
}

이번에는 REGEX를 사용했고, 역시 동일하게 에러가 나온다.

includeFilters도 사용법은 동일하니 알아두도록 하자.

Wrap Up

꽤 중요한 내용들을 다룬 것으로 보인다.

Annotation의 활용을 조금씩 깨우치면서 왜 이런 내용을 정리하고 있는지 생각해보자.

난 우선, Spring이 무엇인지, IoC Container가 무엇인지, Bean이 무엇인지, DI가 무엇인지, 그리고 나아가서 Bean의 Scope 나 LifeCycle을 정리하고 Annotation Configuration까지 정리하였다.

점진적으로 제일 처음 알아보고자 했던 2가지에 가까워지고 있다.

스프링은 무엇을 도와주는가?
스프링의 사용법은 어떻게 되는가?

Annotation을 정리하는 것은 스프링의 사용법이며, 확실히 이해하고 쓰기 위함의 준비 과정이다.

XML로 정리하던 구축방법에서 Annotation으로 설정하는 방법까지 넘어왔으며, Spring이 Annotation으로 선언된 Component들을(Bean들을) Scanning 한다는 것을 알 수 있었다.

아직 갈길이 멀고, AOP 와 같은 관점의 정리도 필요할 것이다.

차근히 하나씩 진행해보도록 하자.

[Spring] Annotation Configuration은 어떻게 할까?

KOOCCI — Mon, 1 Aug 2022 21:09:38 +0900

목표 : Spring의 Anntation 설정을 할 수 있다.

이번엔 계속 XML에서 설정해온 Configuration 정보들을 Annotation으로 어떻게 할 수 있을지 알아볼 예정이다.

해당 링크를 중심으로 하나씩 알아가 보도록 하자.

Annotation-based Container Configuration

먼저 Annotation이 XML보다 Spring configuration하는 것에 있어서 더 좋은가? 에 대한 질문으로 시작한다.

답은 역시나 "상황에 따라 다르다" 이다.

XML 방식은 소스 코드 외, XML만 보고도 설정을 알 수 있다. 즉, 설정과 소스 코드의 분리가 가능하다.

그러나, 프로젝트가 커질수록 XML 관리가 복잡해지기 시작한다.

Annotation은 더 짧고 간결한 구성이 가능하지만 소스 코드와 설정의 분리가 애매해진다.

context namespace

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        https://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/context
        https://www.springframework.org/schema/context/spring-context.xsd">

    <context:annotation-config/>

</beans>

context라는 namespace를 넣어준 것에 집중하자.

그리고, <context:annotation-config/> 를 적용하며, 이제 Annotation을 통해 설정할 수 있도록 변경되었다.

@Autowired

Autowired는 Bean과 Bean간의 관계에 대해, Spring Container가 자동으로 연결해주는 것이다.

그 때, Bean의 이름, Bean의 Type등으로 관계를 설정할 수 있다.

public class MovieRecommender {

    private final CustomerPreferenceDao customerPreferenceDao;

    @Autowired
    public MovieRecommender(CustomerPreferenceDao customerPreferenceDao) {
        this.customerPreferenceDao = customerPreferenceDao;
    }

    // ...
}

그 예시를 보자.

MovieRecommender의 생성자에 Autowired Annotation을 사용하였다.

CustomerPreferenceDao와 관계를 설정해준 것이다.

이는 이전 XML 문법의 다음과 같다.

<bean id="customerPreferenceDao" class="kr.co.test.CustomerPreferenceDao"/>
  
<bean id="movieRecommender" class="kr.co.test.MovieRecommender">
    <constructor-arg ref="customerPreferenceDao" />
</bean>

다만, Spring 버전이 올라가면서, 생성자 주입 시, 자동 Autowired 가 될 수 있고, 필드에 쓰는 경우도 많다.

public class MovieRecommender { 
	private final CustomerPreferenceDao customerPreferenceDao;
    // Autowired 생략 가능
	public MovieRecommender(CustomerPreferenceDao customerPreferenceDao) {
		this.customerPreferenceDao = customerPreferenceDao;
	}
}

@RequiredArgsConstructor // Lombok 활용
public class MovieRecommender { 
    private final CustomerPreferenceDao customerPreferenceDao;
}

public class MovieRecommender { 
    @Autowired // 필드에 설정 가능
    private final CustomerPreferenceDao customerPreferenceDao;
}

@Primary

Autowired를 할 때, 이름 혹은 타입 등으로 설정할 수 있는데, 그 중, 타입으로 연결했더니 중복인 경우, 어떤 것을 Autowired를 할지 모를 경우가 있다. 그 때 활용할 수 있는 Annotation이다.

@Configuration
public class MovieConfiguration {

    @Bean
    @Primary
    public MovieCatalog firstMovieCatalog() { ... }

    @Bean
    public MovieCatalog secondMovieCatalog() { ... }

    // ...
}

@Configuration : Bean 설정으로 등록되면서, Spring 설정과 관련있는 Bean이라는 것을 알려주는 Annotation

@Bean : XML에서 Bean 설정하는 것 대신, Java Annotation을 통해 Bean 설정할 수 있게 도와주는 Annotation

위 예시를 보았을 때, @Primary가 없다고 가정하면 에러가 나오게 된다. (No Unique Bean)

@Qualifiers

public class MovieRecommender {

    private MovieCatalog movieCatalog;

    private CustomerPreferenceDao customerPreferenceDao;

    @Autowired
    public void prepare(@Qualifier("main") MovieCatalog movieCatalog,
            CustomerPreferenceDao customerPreferenceDao) {
        this.movieCatalog = movieCatalog;
        this.customerPreferenceDao = customerPreferenceDao;
    }

    // ...
}

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        https://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/context
        https://www.springframework.org/schema/context/spring-context.xsd">

    <context:annotation-config/>

    <bean class="example.SimpleMovieCatalog">
        <qualifier value="main"/> 

        <!-- inject any dependencies required by this bean -->
    </bean>

    <bean class="example.SimpleMovieCatalog">
        <qualifier value="action"/> 

        <!-- inject any dependencies required by this bean -->
    </bean>

    <bean id="movieRecommender" class="example.MovieRecommender"/>

</beans>

같은 타입의 Bean을 만들 때, Quialifier는 Autowired 시, Qualifier 라는 Annotation과 Value를 넣으면, 선택하여 실행시킬 수 있다.

@Resource

@Autowired와 같은 역할을 한다고 보면된다.

약간의 차이는 Bean의 이름을 통해 주입하며, 생성자에 적용할 수 없다.

@Value

보통 Application에서 XML 외에 application.properties 라는 파일을 만들어, property를 읽어들인다.

@Configuration
@PropertySource("classpath:application.properties")
public class AppConfig { }

위와 같이, Property를 연결하는 구문을 만들고, application.properties를 만들어준다.

그리고, Key=Value 형태로 값을 저장하면, 해당 값을 가져와 쓸 수 있다.

@PostConstruct, @PreDestroy

LifeCycle과 관련된 Annotation이다.

@PostConstruct 는 Bean이 생성되기 전에 실행되는 함수이다.

@PreDestroy는 Bean의 소멸을 앞두고 실행되는 함수이다. 단, context.close()가 필요하다.

WrapUp

Annotation이라는 것이 사용자의 편의를 생각해, 만들어지다보니 암기해야할 것처럼 느껴질 수 있다.

다만, 사용을 하다보면 자연스럽게 알게되고, 자주 쓰다보면 당연스레 써지게 되기도 한다.

다만, 이 Annotation의 역할과 상황을 잘 기억하여 쓸 수 있도록 하자.

[Spring] Bean의 LifeCycle는 어떻게 될까?

KOOCCI — Sun, 31 Jul 2022 20:34:50 +0900

목표 : Spring에서 Bean의 LifeCycle에 대해 설명할 수 있다.

Bean에도 LifeCycle이 있을 것이고, 그에 따라 여러 설정값들도 있을 것이다.

그에 대해 알아보면서, 결국 서블릿 컨테이너를 통해 서블릿이 관리되고, 하나의 서블릿에서 Application Context가 관리하는 Bean들이 실행되는 전체적인 관점도 알아보도록 하자.

Customizing the Nature of a Bean

계속 참고하여 보던 문서의 제목이며, Bean의 성질이 어떻게 되는지 보고, 수정할 수 있는 방향을 알아보자.

그럼 LifeCycle에 대해 알아보자.

LifeCycle

Spring에서는 객체를 다루므로, 객체를 만들거나 객체를 없애는 행위를 할 수 있다.

객체를 만들 때는 new로 객체를 만드는 작업을 Spring이 한다. 즉, 해당 시점에 Callback을 호출 할 수 있다.

또한, 특정 Bean에 대해 Close, 자원 Release할 때도 Callback을 할 수 있다.

어떻게 할 수 있는지에 대해서는 크게 3가지 방법을 설명한다.

InitializingBean,DisposableBean이라는 인터페이스를 구현하는 방법
JSR-250의 @PostConstruct 및 @PreDestroy를 사용하는 방법
XML 설정을 통해, init-method, destroy-method를 하는 방법

어노테이션을 활용하는 것은 다음에 진행할 예정이므로, 2번을 제외한 다른 것들부터 보도록 하자.

Initialization Callbacks

Bean이 만들어질 때, CallBack 함수가 실행되는 것들을 알아보자.

InitializingBean

InitializingBean 을 보면, 하나의 메서드를 지원하고 있다. (afterPropertiesSet())

해당 메서드의 역할도 함께 적혀있다.

Invoked by the containing BeanFactory after it has set all bean properties and satisfied BeanFactoryAware, ApplicationContextAware etc.

모든 bean Property 설정과 BeanFactoryAware, ApplicationContextAware 등이 끝난 후에, container인 BeanFactory에 의해 호출된다.

init-method

XML로 설정하는 방법이다.

<bean id="exampleInitBean" class="examples.ExampleBean" init-method="init"/>

init-method 이름이 init이니, 해당 init 이란 이름의 메서드를 만들어 활용하면 된다.

Destruction Callbacks

Bean이 사라질 때의 Callback을 알아보자.

DisposableBean

InitailizingBean과 반대되는 개념이다.

이 역시, 문서를 보면 destroy() 메서드 한가지만 구현할 수 있게 되어있다.

bean에 대해, Interface를 구현하여 사용하면 되지만, 한가지 문제가 생길 수 있다.

ApplicationContext context = new ClassPathXmlApplicationContext("test.xml");

ClassPathXmlApplicationContext는 정말 많은 추상클래스, 인터페이스들을 상속받고 있는데, 실제로 Assign한 타입은 ApplicationContext이다.

다시말해, Java에서의 형변환 업캐스팅으로 ClassPathXmlApplicationContext의 모든 멤버 변수에 대한 메모리는 생성되지만, 변수 타입이 ApplicationContext이므로 실제로 접근 가능한 변수나 메서드는ApplicationContext의 변수와 메서드가 된다.

ClassPathXmlApplicationContext 에서는 결국 ConfigurableApplicationContext 라는 Interface를 상속받고 있고, ConfigurableApplicationContext는 ApplicationContext, Lifecycle, Closeable 을 구현하게 된다.

이중 중요한 것은 Closeable 이다.

ApplicationContext 에는 Closeable이 없기 때문에, Close 함수가 호출될 수 없다.

즉, DisposableBean을 상속받아 destroy 메서드를 구현하더라도, 해당 메서드가 호출될 수 없다.

따라서, 다음과 같이 구현해야 정상적으로 destroy 메서드가 호출되는 것을 볼 수 있다.

 ConfigurableApplicationContext context = new ClassPathXmlApplicationContext("test.xml");
 
 /**
 * TODO :
 */
 
 context.close();

Destroy-method

XML로 설정하는 방법이며 사용법은 동일하다.

<bean id="exampleInitBean" class="examples.ExampleBean" destroy-method="cleanup"/>

Default Initialization and Destroy Methods

매번 Bean들에게 init이나 destroy 메서드를 할 필요 없이, beans에 default 설정을 할 수 있다.

<beans default-init-method="init" default-destroy-method="destroy">

    <bean id="blogService" class="com.something.DefaultBlogService">
        <property name="blogDao" ref="blogDao" />
    </bean>

</beans>

즉, 각 bean들에게서 init이나 destroy 메서드가 있다면, 각각의 bean들에서 생성/삭제될 때, 해당 메서드들이 실행되는 것이다.

Startup and Shutdown Callbacks

앞서, DisposableBean 을 찾아볼 때, ConfigurableApplicationContext에 대해 찾아보았다.

public interface ConfigurableApplicationContext extends ApplicationContext, Lifecycle, Closeable {
    /*...*/
}

Lifecycle이라는 Interface가 있는 것을 볼 수 있다.

따라서, 우리가 context에서 해당 Lifecycle.class를 getBean으로 가져올 수 있고, 이를 사용할 수 있다.

public interface Lifecycle {
    void start();

    void stop();

    boolean isRunning();
}

public static void main(String[] args) {
    ApplicationContext context = new ClassPathXmlApplicationContext("test.xml");
    Lifecycle lifecycle = context.getBean(Lifecycle.class);
    log.info("isRunning : >> " + lifecycle.isRunning()); // isRunning : >> true
    context.close();
    log.info("isRunning : >> " + lifecycle.isRunning()); // isRunning : >> false
}

해당 Interface를 통해, Spring Container의 Running 유무에 따른 설정에 사용할 수 있다.

ApplicationContextAware

우리는 앞서, ClassPathXmlApplicationContext 라는 ApplicationContext를 사용하고 있었다.

이를 Bean에서 사용하고 싶을 때, ApplicationContextAware가 사용된다.

아래 예시를 보자.

@Slf4j
public class Aca implements ApplicationContextAware {
    private ApplicationContext applicationContext;
    
    void init() {
      log.info("Null Check >> " + applicationContext);  
    }

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        this.applicationContext = applicationContext;
    }
}

Aca라는 클래스는 ApplicationContextAware를 구현하고 있고, init 메서드를 통해, Bean 시작점에 자동으로 실행될 메서드도 구현하였다.

ApplicationContextAware 인터페이스는 setApplicationContext 를 구현하도록 되어 있고, 간단히 필드의 ApplicationContext에 값을 넣어주도록 하였다.

이렇게 함으로서, Aca를 Bean으로 등록만 한다면, 자동으로 Bean이 생성될 때, init 메서드가 실행될 것이고, Aca에서는 applicationContext 를 set으로 전달받아 사용할 수 있는 상태가 된다.

이렇게 ApplicationContextAware를 사용하는 방법을 알아보았다.

Aware라는 단어로 붙은 인터페이스들은 다음과 같이, 특정 목적에 따라 사용하는 방법이 위 ApplicationContextAware와 유사하다.

이를 잘 알아보고 사용하도록 하자.

Wrap Up

이렇게 Spring 내에서 Bean의 LifeCycle을 알아보았다.

빠진 내용은 아마 Annotation일 것이고, 이건 다시 한 번 정리해 나가도록 하자.

그리고, 앞서 Servlet을 알아보며 여러 자료를 찾게 되다가, 제목이 Coltoller 1개가 어떻게 수 많은 Request를 처리하는가? 라는 블로그를 보자마자 나도 순간 헤깔리게 되었다.

Bean이 생성되고 삭제될 때, 기본적으로 Singleton으로 객체가 이루어진다. (Default Bean Scope다)

그리고 Servlet은 이 Bean들을 통해 구현되어지고, Servlet은 Servlet Container 를 통해 관리되어 진다.

그렇다면, 하나의 Servlet이 하나의 Path에 대한 Client Request를 처리한다고 할 때 (DispatcherServlet이더라도), 결국 하나의 Bean Instance를 사용하는 것이다.

논리적으로 요청이 동시에 천이든 만이든 큰 단위로 들어올 수 있는데, 그럼 해당 path로 전달받는 Request는 Servlet Container의 Thread 갯수만큼 받는다고 해도, Controller를 담당하는 Servlet이 같은 Bean Instance를 바라보면 데이터가 섞이거나, 문제가 생기지 않을까?

결과부터 보면, Controller 를 담당하는 Bean은 한 개가 생성되며, 그 하나의 컨트롤러가 모든 요청을 처리한다.

어찌보면 당연하다.

Controller의 로직은 함께 쓸 수 있지만, 각 요청과 개별적인 Thread의 정보는 동기화될 필요가 없다.

Bean은 Stateless해야 하며, 멤버변수에 값을 저장하는 행위가 위험한 이유다.

멤버변수에 값을 저장하는 순간, 정보는 동기화가 되어버릴 수 있다.

Spring Bean의 LifeCycle과 함께 헤깔리지 않도록 잘 정리해두자.

자바스크립트 기초부터 모던 자바스크립트까지 - 프로토타입편

KOOCCI — Sat, 30 Jul 2022 16:10:43 +0900

목표 : 자바스크립트의 프로토타입을 설명할 수 있다.

앞서 계속해서 나오던 내용이 프로토타입이다.

__proto__ 접근자 프로퍼티나, prototype 프로퍼티를 다루기도 했고, 이제 프로토타입에 대해 정확히 알아가볼 시간이다.

자바스크립트는 어떤 언어인가?

자바스크립트는 멀티 패러다임 언어다.

다시말해, 명령형, 함수형, 프로토타입 기반 객체지향 프로그래밍을 지원하는 멀티 패러다임 프로그래밍 언어다.

다시 보자. 자바스크립트는 프로토타입을 기반으로 한 객체 지향 프로그래밍 언어다.

자바스크립트는 객체 기반의 프로그래밍 언어로 자바스크립트를 이루고 있는 거의 모든 것이 객체다.

결국 다시 객체로 돌아온다.

이제 이 객체로 상속과 프로토타입에 대해 알아보자.

상속과 프로토타입

상속은 어떤 객체의 프로퍼티 또는 메서드를 다른 객체가 상속받아 그대로 사용할 수 있는 것이다.

자바스크립트에서는 상속을 프로토타입 기반으로 구현하여, 코드를 재사용한다.

// 생성자 함수
function Circle(radius) {
    this.radius = radius;
    this.getDiameter = function() {
    	return 2 * this.radius;
    };
}

const circle1 = new Circle(5);
const circle2 = new Circle(7);

console.log(circle1.getDiameter); // ƒ () { return 2 * this.radius;}
console.log(circle1.getDiameter); // ƒ () { return 2 * this.radius;}

console.log(circle1.getDiameter === circle2.getDiameter); // false

앞서 생성자 함수에서 살펴보았듯이, 생성자 함수는 동일한 프로퍼티나 메서드 구조를 갖는 객체를 여러 개 생성할 때 유용하다.

그런데, 위 예시는 좀 아쉬운 것이 있다.

getDiameter 메서드는 단 하나만 생성해서 모든 인스턴스가 공유할 때 가장 바람직해 보인다.

그러나, 생성자 함수로 인스턴스가 생성될 때마다, 중복생성하고 중복 소유하는 형태다.

// 생성자 함수
function Circle(radius) {
    this.radius = radius;
}

Circle.prototype.getDiameter = function() {
    return 2 * this.radius;
};

const circle1 = new Circle(5);
const circle2 = new Circle(7);

console.log(circle1.getDiameter); // ƒ () { return 2 * this.radius;}
console.log(circle1.getDiameter); // ƒ () { return 2 * this.radius;}

console.log(circle1.getDiameter === circle2.getDiameter); // true

Circle 생성자 함수에 prototype 이라는 데이터 프로퍼티에 메서드로 getDiameter를 할당하였다.

생성자 함수에 prototype은 앞서 알아본 바와 같이, 생성자 함수로 호출 할 수 있는 함수 객체. 즉, constructor 만이 소유하는 프로퍼티다.

그리고, 함수가 객체를 생성하는 생성자 함수로 호출될 때, 생성자 함수가 생성할 인스턴스의 프로토타입 객체를 가리킨다.

따라서, Circle 생성자 함수가 생성하는 모든 인스턴스는 getDiameter라는 메서드를 상속받아 사용할 수 있게 된다.

프로토타입 객체

프로토타입 객체(= 프로토타입)는 객체 지향 프로그래밍의 근간을 이루는 객체 간 상속을 구현하기 위해 사용된다.

어떤 객체의 상위(부모) 객체의 역할을 하는 객체로서 다른 객체에 공유 프로퍼티(또는 메서드)를 제공한다.

프로토타입을 상속받은 하위 객체는 상위 객체의 프로퍼티를 자신의 프로퍼티처럼 사용할 수 있다.

조금 더 세부적으로 들어가보자.

[[Prototype]]이라는 내부 슬롯이 있다.

이 내부 슬롯의 값은 프로토타입 참조(null일수도 있다)다.

[[Prototype]]에 저장되는 프로토타입은 객체 생성 방식에 의해 결정된다.

즉, 객체가 생성될 때 객체 생성 방식에 따라 프로토타입이 결정된다. 그리고 그 프로토타입의 참조값은 [[Prototype]]에 저장된다.

객체 리터럴로 하나의 객체가 생성될 것이라고 하자.

이 객체의 프로토타입은 객체 생성 방식에 따라, Object.prototype이 된다.

생성자 함수에 의해 생성된 객체가 있다고 하자

이 객체의 프로토타입은 객체 생성 방식에 따라, 생성자 함수의 prototype 프로퍼티에 바인딩되어 있는 객체다.

모든 객체는 하나의 프로토타입을 갖는다. 그리고 모든 프로토타입은 생성자 함수와 연결되어 있다.

객체와 생성자함수와 프로토타입의 관계

하나의 객체를 생성하고자 한다.

위 예시에서 사용한 circle1 이라고 하자.

circle1의 생성은 생성자 함수를 통하여 되었다.

circle1(3번)의 프로토타입은 객체 생성 방식에 따라, 생성자 함수 Circle(1번)의 prototype 프로퍼티에 바인딩되어 있는 Circle.prototype 객체(2번)다.

// 생성자 함수
function Circle(radius) {
    this.radius = radius;
}

Circle.prototype.getDiameter = function() {
    return 2 * this.radius;
};

const circle1 = new Circle(5);

console.log('생성자 함수 = [1번]');
console.log(Circle);
// ƒ Circle(radius) {
//     this.radius = radius;
// }

console.log('[1번]의 prototype 프로퍼티 = [2번]');
console.log(Circle.prototype);
// {getDiameter: ƒ, constructor: ƒ}

console.log('[2번]의 constructor 프로퍼티');
console.log(Circle.prototype.constructor);
// ƒ Circle(radius) {
//     this.radius = radius;
// }

console.log('[1번] 과 [2번]의 construcotor 프로퍼티 관계');
console.log(Circle === Circle.prototype.constructor);  
// true

console.log('[1번]으로 생성된 인스턴스 = [3번]');
console.log(circle1);
// Circle {radius: 5}

console.log('[3번]의 __proto__ 접근자 프로퍼티');
console.log(circle1.__proto__);
// {getDiameter: ƒ, constructor: ƒ}

console.log('[3번]의 __proto__ 접근자 프로퍼티와 [2번]의 관계');
console.log(Circle.prototype === circle1.__proto__); 
// true

console.log('[3번]의 constructor');
console.log(circle1.constructor);
// ƒ Circle(radius) {
//     this.radius = radius;
// }

Circle 생성자 함수는 circle1 객체를 생성했다.

이때, circle1 객체는 프로토타입의 constructor 프로퍼티를 통해 생성자 함수와 연결된다.

circle1 객체는 constructor 프로퍼티가 없지만, circle1 객체의 __proto__인 Circle.prototype에는 constructor가 있다.

따라서, 상속받아서 Circle과 연결된다.

아래 예시를 보며 한번 정리해보도록 하자.

// obj 객체를 생성한 생성자 함수는 Object이다.
const obj = new Object();
console.log(obj.constructor === Object); // true

// add 함수 객체를 생성한 생성자 함수는 Function이다
const add = new Function('a', 'b', 'return a+b');
console.log(add.constructor === Function); // true

// 생성자 함수
function Person(name) {
  this.name = name;
}

// me 객체를 생성한 생성자 함수는 Person이다.
const me = new Person('Lee');
console.log(me.constructor === Person); // true

리터럴 타입으로 생성된 객체에서는 어떻게 될까?

위에서 생성자 함수에 대해 프로토타입이 어떻게 되는지 알아보았다.

그렇다면 리터럴 타입으로 생성된 객체에 대해서는 프로토타입이 어떻게될까?

// 객체 리터럴
const obj = {};

// 함수 리터럴
const add = function(a, b) { return a+b; };

// 배열 리터럴
const arr = [1,2,3];

// 정규 표현식 리터럴
const regex = /ab+c/;

console.log(obj.constructor === Object); // true
console.log(add.constructor === Function); // true
console.log(arr.constructor === Array); // true
console.log(regex.constructor === RegExp); // true

객체 리터럴로 생성한 obj임에도, 그 constructor는 Object가 나왔다.

함수 리터럴은 Function으로 생성하지 않았는데도, Function이 나온다.

이에 대해서 ECMA Script 사양에 별도로 예외적으로 적혀있다.

특히, Function은 클로져같은 제약사항이 있는 문법인데도, 함수 리터럴의 생성자라고 나오고 있다.

다만, 함수라는 그 특성 자체는 동일하므로 어느정도 연관성이 있는 것으로 보고 넘어가도록 하자.

프로토타입 체인

// 생성자 함수
function Person(name) {
  this.name = name;
}

// 프로토타입 메서드
Person.prototype.sayHello = function() {
  console.log(`Hi My name is ${this.name}`);
};

const me = new Person("James");
console.log(me.hasOwnProperty('name')); // true

위 예시를 보면 알 수 있듯이, 자바스크립트는 객체의 프로퍼티(메서드 포함)에 접근하려고 할 때, 해당 객체에 원하는 프로퍼티가 있는지 찾는다.

없다면, [[Prototype]] 내부 슬롯의 참조를 따라 자신의 부모 프로토타입에서 순차적으로 찾기 시작한다.

이를 프로토타입 체인이라고 한다.

이 체이닝의 종점은 Object.prototype일 것이다.

프로토타입 체인은 프로퍼티 검색을 위한 메커니즘이라면, 이전에 공부한 식별자는 스코프 체인으로 검색할 것이다.

이 프로토타입 체인을 통해, instanceof 같은 연산자도 사용할 수 있다.

instanceof는 객체의 체이닝 내에 존재하는 프로토타입인지 검색하여, true/false로 평가한다.

Wrap up

자바스크립트의 프로토타입에 대해 알아보았다.

이는 Class에 대한 내용이랑도 연결되며, 앞서 배웠던 생성자, 프로퍼티 등의 개념이 최종적으로 어우러지는 부분이라는 것을 알 수 있다.

결국 프로토타입은 객체간의 상속을 표현하기 위해서 사용되었고, 그로인해 오버라이딩과 같은 기능도 동일하게 구현할 수 있었다.

이제 다음은 This 객체부터 조금 자세히 알아보자.

[Spring] Bean Scope 가 뭘까?

KOOCCI — Fri, 29 Jul 2022 00:14:04 +0900

목표 : Bean Scope에 대해 설명할 수 있다.

Bean Scope라는 것은 Bean의 범위인데, 아마 바로는 이해가 쉽지 않을 것이다.

Bean Scope는 객체를 만들 때, 컨테이너가 이 객체를 한번만 호출하는지, 아니면 호출 할 때마다 여러번 만드는지에 대한 내용이다.

그래서 문서 상에 여러 Scope가 있는 걸 볼 수 있고, 대부분 singleton 혹은 prototype이다.

이 두가지를 알아보기 전에 한가지 정리가 필요하다.

용어부터 정리해보자.

Identity (동일성) 그리고 equals (동등성) 두가지가 있다

Identity (동일성) 은 객체의 주소가 같다.

이 말은 obj1 == obj2 && obj2 == obj3 를 했을 때, true가 나오는 Hashcode가 동일한 것이다.

equals(동등성) 은 객체의 값이 같은 것이다.

equals는 obj1.equals(obj2) == ture 와 같이 그 값들이 같은 것이다.

equals는 객체의 equals에 대해 Overload에 따라 달라질 수 있고, 그 내부 정보가 같다면 같을 수 있지만, Identity는 그 주소가 같다는 것으로 Singleton일 때는 하나의 객체를 재사용하므로 같을 것이다.

Singleton

Default로서, Spring IoC container에서 호출될 때 딱 하나의 객체만 만들어서 재사용하는 것이다.

그럼 위에서 배운 Identity(동일성)을 확인해보도록 하자.

<bean id="A" class="com.something.A"/>

위 처럼 선언된 bean을 getBean으로 가져와, 비교를 해볼 것이다.

ApplicationContext context = new ClassPathXmlApplicationContext("test.xml");

A a1 = context.getBean("A", A.class);
A a2 = context.getBean("A", A.class);

log.info("result Identity = " + (a1 == a2)); // true

Prototype

Spring IoC Container가 호출될 때마다 객체를 만드는 것(new 로 만드는 것과 동일)이다.

이 역시, Identity(동일성)을 확인해보도록 하자.

<bean id="B" class="com.something.B" scope="prototype"/>

ApplicationContext context = new ClassPathXmlApplicationContext("test.xml");

B b1 = context.getBean("B", B.class);
B b2 = context.getBean("B", B.class);

log.info("result Identity = " + (b1 == b2)); // false

Wrap Up

간단하게 Bean Scope에 대해 알아보았다.

IoC Container에서 Bean이 어떻게 생성되는가에 대한 내용이고, 가장 대표적인 2가지를 알아보았다.

[Spring] 스프링의 DI가 뭘까?

KOOCCI — Tue, 26 Jul 2022 23:16:16 +0900

목표 : Spring의 DI에 대해 설명할 수 있다.

이제 DI(Dependency Injection)에 대해 알아보려고 한다.

앞서 IoC Container에 대한 설명에서 Spring 공식문서에 IoC와 DI를 동일하게 표현하고 있다는 걸 먼저 볼 수 있었다.

그럼에도 용어가 다른 것에는 다른 의미가 있을 텐데, 어떻게 된건지 알아보도록 하자.

이번에도 역시, Spring 공식문서의 Dependencies 부분을 참고하여 확인해볼 것이다.

Dependencies

보통의 Application은 하나 이상의 Object로 구성된다. 그리고, 이 Object들은 서로 함께 동작하게 된다.

그 예시를 보도록 하자.

// A.java
public class A {
    private B b = new B();
    public void print() {
	    System.out.println(b.calc());
    }
}

// B.java
public class B {
    public int calc() {
    	return 1;
    }
}

// main.java
public static void main(String[] args) {
	A a = new A();
	a.print();
}

A라는 클래스(Object)는 B라는 클래스(Object)와 관련이 있고, A와 B는 함께 동작하고 있다.

즉, A는 내부에서 B를 호출하고 있다. 이런 관계를 A는 B라는 객체에 의존성(Dependency)이 있다고 말할 수 있다.

여기서 B 클래스가 조금 수정된다고 생각해보자.

public class B {
    private boolean condition;

    public B(boolean condition) {
        this.condition = condition;
    }
    public int calc() {
        return condition? 1 : 0;
    }
}

B가 condition이라는 값에 따라, calc되는 값이 바뀌도록 수정되었다.

거기다가 생성자도 추가되었다.

A는 B에 의존성이 있으므로, 코드 레벨에서 수정될 수 밖에 없다.

B의 Condition을 넣어주기 위해서는 A도 생성자를 만들거나, 인스턴스 생성 때 부터 B 생성자에 초깃값을 넣어주어야 한다.

다만, 보통 원하는 방향은 Main함수에서 condition을 조절하기 떄문에, A에 생성자를 넣어줄 필요가 있다.

// A.java
public class A {
    private B b;
    public A(boolean condition) {
        this.b = new B(condition);
    }
    public void print() {
        System.out.println(b.calc());
    }
}

//Main.java
public static void main(String[] args) {
    boolean condition = true;
    A a = new A(condition);
    a.print();
}

그럼 계속해서, 코드의 복잡도가 증가하게 된다. A는 Main에서, B는 A에서 Condition을 받아야 하고, 나중에는 개발자가 감당하기 힘들어진다.

이런 상황에서는 DI(Dependency Injection : 의존성 주입)를 통해 디커플링(Decoupling)하는 작업이 필요하다.

간결하고 유지보수가 편해야 하기 때문이다.

디커플링 : 소프트웨어 공학에서 결합도(Coupling)란 모듈간 의존도를 나타내는 것을 의미.
반대로 디커플링이란 인터페이스 등을 활용하여 모듈간 의존도를 최소화하여 개발하는 방법을 의미

DI를 통해 디커플링한다는 것이 무엇일까?

DI를 통해 디커플링한다는 것은 코드 레벨에서 관계를 맺는 작업이 아니다.

A 클래스에 B를 넣는 생성자를 만들어보자.

// A.java
public class A {
    private B b;

    public A(B b) {
        this.b = b;
    }

    public void print() {
        System.out.println(b.calc());
    }
}

// B.java
public class B {
    private boolean condition;

    public B(boolean condition) {
        this.condition = condition;
    }
    public int calc() {
        return condition ? 1: 0;
    }
}

// Main.java
public static void main(String[] args) {
    boolean condition = true;
    B b = new B(condition);
    A a = new A(b);
    a.print();
}

위와 같이 변경하면 어떻게 변할까?

A는 B가 가져야 할 값에서 독립된다(B가 가져야할 값을 A는 몰라도 된다).

즉, 디커플링 되고, 소스 복잡도가 줄어든다.

즉, IoC Container는 이런 DI 작업을 프레임워크화, 도구화한 것이다.

Spring 이라는 프레임워크가 DI 원리를 이용해 객체간의 관계를 만들어주는 것이다.

다시 말해,

DI가 IoC Container의 주요 원리다.

그럼 어디서 DI를 설정하는 것일까?

바로, 앞서 배웠던 Configuration Metadata에서의 Bean 설정이다.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        https://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="a" class="com.test.A">  
        <constructor-arg ref="b" />
    </bean>

    <bean id="b" class="com.test.B">  
        <constructor-arg value="true"></constructor-arg>
    </bean>

    <!-- more bean definitions go here -->

</beans>

constructor-arg라는 것이 새롭게 나왔지만, A 클래스에는 id가 b로 가진 Bean을 생성자에 주입해주는 것이며, 나중에 다시 한번 볼 예정이다.

B 클래스 역시, Boolean 값이 생성자에 필요하므로, value로 넣어준 것이며, 이후에 문법은 다시 한 번 보도록 하자.

문법과 별개로 위와 같이, Configuration Metadata를 설정하면 Main 함수에서 new 로 생성했던 A와 B를 없애고, ApplicationContext에서 가져올 수 있게 된다.

public static void main(String[] args) {
    ApplicationContext context = new ClassPathXmlApplicationContext(my.xml);
    A a = context.getBean("a", A.class);
    a.print();
}

그럼 DI를 명쾌하게 정리해보자.

DI는 IoC Container 의 대표적인 동작 원리로서, 객체간의 관계를 외부로 부터 주입받아, 그 관계를 느슨하고 동적으로 가져가는 것을 말한다.

외부라고 함은, Configuration Metadata에서 정의한 Bean이며, 그 객체간의 관계를 설정할 수 있다.

객체의 관계를 설정으로 빼면 어떤 면이 좋아질까?

설정으로 객체간의 관계를 알 수 있다.

Container 사용을 위한 코드를 제외하면, Business 로직만 고려할 수 있다.

문서로 잠깐 돌아가 보자.

your classes become easier to test, particularly when the dependencies are on interfaces or abstract base classes, which allow for stub or mock implementations to be used in unit tests.

요약하면, 테스트가 더 하기 쉬워진다.

테스트는 또 한번 이야기 할 것이기 때문에, 구체적인 내용은 나중에 배우도록 하고, 내용만 알아두도록 하자.

Constructor-Based / Setter-Based DI

이미, 생성자를 기준으로한 DI를 위 예시에서 보았다.

또 다른 것으로 Setter를 통해 DI가 가능하다.

// A.java
public class A {
    private B b;

    public void setB(B b) {
    	this.b = b;
    }

    public void print() {
        System.out.println(b.calc());
    }
}

// B.java
public class B {
    private boolean condition;

    public B(boolean condition) {
        this.condition = condition;
    }
    public int calc() {
        return condition ? 1: 0;
    }
}

// Main.java
public static void main(String[] args) {
    ApplicationContext context = new ClassPathXmlApplicationContext(my.xml);
    A a = context.getBean("a", A.class); // 에러 남
    a.print();
}

아마 바로하면 에러가 날 것이다.

Bean 설정이 Constructor 로 되어 있기 때문이다.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        https://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="a" class="com.test.A">  
        <property name="b" ref="b" />
    </bean>

    <bean id="b" class="com.test.B">  
        <constructor-arg value="true"></constructor-arg>
    </bean>

    <!-- more bean definitions go here -->

</beans>

문법은 나중에 다시 보도록 하고, Setter 로 가능하다는 것을 알도록 하자.

생성자와 Setter의 차이점은 생성자는 객체가 만들어질 때 단 한번만 동작하므로, 생성할 때만 필요한 코드를 넣을 수 있다.

Setter는 런타임에 Setter를 통해 객체의 관계를 재설정할 수 있다.

그러나, 보통은 관계는 변경되지 않는 것이 복잡도를 떨어트리므로, Setter보다 생성자를 권장한다.

문서에도 동일하게 나와 있으니 참고하도록 하자.

Constructor-based or setter-based DI?

Since you can mix constructor-based and setter-based DI, it is a good rule of thumb to use constructors for mandatory dependencies and setter methods or configuration methods for optional dependencies. Note that use of the @Required annotation on a setter method can be used to make the property be a required dependency; however, constructor injection with programmatic validation of arguments is preferable.

The Spring team generally advocates constructor injection, as it lets you implement application components as immutable objects and ensures that required dependencies are not null. Furthermore, constructor-injected components are always returned to the client (calling) code in a fully initialized state. As a side note, a large number of constructor arguments is a bad code smell, implying that the class likely has too many responsibilities and should be refactored to better address proper separation of concerns.

Setter injection should primarily only be used for optional dependencies that can be assigned reasonable default values within the class. Otherwise, not-null checks must be performed everywhere the code uses the dependency. One benefit of setter injection is that setter methods make objects of that class amenable to reconfiguration or re-injection later. Management through JMX MBeans is therefore a compelling use case for setter injection.

Use the DI style that makes the most sense for a particular class. Sometimes, when dealing with third-party classes for which you do not have the source, the choice is made for you. For example, if a third-party class does not expose any setter methods, then constructor injection may be the only available form of DI.

Dependency Resolution Process (의존성 해결 프로세스)

ApplicationContext가 XML, java code, annotation 를 통해 정의된 Configuration Metadata를 읽어 Beans를 생성하고 초기화 한다.
각각의 Bean에 대해서는 Property, 생성자 Argument, Static-Factory Method(기본 생성자를 쓰지 않을 때)의 Argument를 통해 의존성이 표현된다.

Circular Dependency

순환 참조가 되는 경우가 당연히 있을 수 있다.

A에서 B에 대해 의존성이 있고, B는 A에 대해 의존성을 있을 때, 에러가 날 것이다. 서로서로 참조하면서 초기화 할 것이기 때문이다.

이 때, Spring 은 BeanCurrentlyInCreationException 을 throw 하게 된다.

Wrap-up

그럼 전체적으로 한번 다시 정리해보자.

앞선 포스팅의 Bean 부분도 시원하지 않게 넘어갔으니, 같이 정리해 보도록 한다.

먼저, 앞서 배운 내용들을 나열해보자.

Spring Framework에서는 ApplicationContext를 통해 IoC Container를 제공하고 있다.
ApplicationContext는 인터페이스이며, 그 구현체는 Spring Container(=IoC Container)라고 한다.
Spring Container는 Bean이라고 하는 사용하고자 하는 객체의 생성, 인스턴스화 등을 관리하고 있다.
Bean에 대한 정보는 Configuration Metadata에 정의하여 관리된다.
DI는 객체간의 관계를 외부로 부터 주입받아, 그 관계를 느슨하고 동적으로 가져가는 것을 말하며,
IoC Container 의 대표적인 동작 원리다.

다시 전체 흐름을 정리하자.

ApplicationContext의 구현체인 Spring Container(=IoC Container)는 Bean을 생성하고 관리하고 인스턴스화 한다.

Bean은 Spring Container에 의해 관리되는 객체이며, Configuration Metadata를 통해 3가지 방법(생성자(Constructor), Static-Factory Method, Instance-Factory Method)으로 생성될 수 있다.

각각의 Bean(객체)의 관계도 Configuration Metadata에서 설정할 수 있는데, IoC Container에서는 DI(= Dependency Injection)라고 하는 대표적인 동작 원리를 통해 그 관계를 느슨하고 동적으로 연결하고 있다.

DI는 생성자를 통한 주입, Setter를 통한 주입 2가지의 종류로 제공할 수 있으며, 생성자를 통한 주입이 권장된다.

[Spring] 스프링의 Bean을 어떻게 쓸 수 있을까?

KOOCCI — Sat, 23 Jul 2022 16:45:14 +0900

목표 : Spring 의 Bean을 간단히 사용해볼 수 있다.

스프링은 무엇을 도와주는가?
스프링의 사용법은 어떻게 되는가?

라는 두가지 주제 중, 스프링은 무엇을 도와주는가? 에 대해 간략히 정의와 함께 알아보았고,

스프링의 사용법을 알기 이전에 그 사용 용어들부터 정리해보고 있다.

우선, 이전 포스트에서 Spring 의 IoC Container가 무엇인지 설명할 수 있게 되었다.

다만, 그 Detail을 조금 더 파고 들고자 한다.

Bean이라는 것

앞서 보던 Spring 공식 문서에서 Bean Overview를 통해 자세히 알아보고자 한다.

사실 우린 Bean이라는 것도 이미 배웠다.

Bean은 Spring Container (ApplicationContext 구현체) 가 관리하고 생성하고 인스턴스화 해주는 객체다.

그리고 공식 문서의 첫 문장은 IoC Container가 하는 일에 대해 적혀있다..

A Spring IoC container manages one or more beans. These beans are created with the configuration metadata that you supply to the container (for example, in the form of XML <bean/> definitions).

Spring IoC container 는 다수의 Bean들을 관리한다. 이 Bean들은 Configuration Metadata를 통해 만들어지며, 이는 XML과 같은 형태로 제공된다.

그럼 이제 Bean이라는 게 어떻게 정의되는지 알아보도록 하자.

Bean은 어떻게 생성할 수 있는가?

Annotation은 차츰 진행하면서 다시한번 공부하기로 하고, XML 형태를 먼저 보도록 하자.

XML의 <bean/>으로 정의되는 Bean은 여러가지 Property들이 있다.

용도에 따라 각기 다른 내용들이 있는데, 우선은 Class, Name 두가지에 집중해서 볼 예정이다.

Naming Beans

bean은 하나 이상의 Unique한 ID를 갖는다.

XML에서는 id나 name attribute로 설정가능하다. (ID는 유일하지만, name은 여러개 작성이 가능하다)

유니크한 값이 있는 이유는 같은 Class라도 Spring이 관리하는 Bean이 다를 수 있기 때문이다.

<bean id="dao1" name="dao2, dao3" class="com.test.myobj"/>
<bean id="new_dao"  class="com.test.myobj"/>

Instantiating Beans

Bean을 객체로 만드는 건 크게 3가지 방법이 있다.

Constructor (생성자)
Static Factory Method
Instance Factory Method

하기 예시로 설명해보자.

<bean id="exampleBean" class="examples.ExampleBean"/>

<bean name="anotherExample" class="examples.ExampleBeanTwo"/>

먼저 bean의 class를 정의하면, ExampleBean의 기본 생성자를 통해 Bean을 만든다.

만약, 기본 생성자가 없다면? 그럼 에러가 나고 별도 과정이 더 필요하다.

<bean id="clientService"
    class="examples.ClientService"
    factory-method="createInstance"/>

public class ClientService {
    private static ClientService clientService = new ClientService();
    private ClientService() {}

    public static ClientService createInstance() {
        return clientService;
    }
}

factory-method라는 attribute를 추가하였고, Static Factory Method로 생성하는 방법이다.

<!-- the factory bean, which contains a method called createInstance() -->
<bean id="serviceLocator" class="examples.DefaultServiceLocator">
    <!-- inject any dependencies required by this locator bean -->
</bean>

<!-- the bean to be created via the factory bean -->
<bean id="clientService"
    factory-bean="serviceLocator"
    factory-method="createClientServiceInstance"/>

마지막으로 Instance Factory Method이다.

이 때는 2개의 bean이 필요하다.

Bean을 만들어줄 클래스가 정의된 Bean
사용할 Bean (class 대신 factory-bean이 들어간다.)

사용할 Bean에 factory-bean이라는 attribute로 Bean을 만들어줄 클래스가 정의된 Bean을 지정하고, 동작시킬 factory-method를 정의해준다.

자기 자신이 Factory-method를 가진 경우 앞선 static factory method를 사용하고, 외부에서 자신을 정의시켜준다면, instance factory method를 사용한다.

public class DefaultServiceLocator {

    private static ClientService clientService = new ClientServiceImpl();

    public ClientService createClientServiceInstance() {
        return clientService;
    }
}

Wrap up

Configuration Metadata를 통해 간단한 Bean을 만드는 법을 알 수 있었다.

아무래도 Bean에 대해 시원하게 다루지 못한 감이 있다.

DI라는 개념과 함께 Bean Scope, Annotation으로 발전시켜나가야 하는데, 모든 걸 한번에 다룰 수 없으니

다시한번 Wrap up하는 시점이 나오지 않을까 한다.

[Spring] 스프링의 IoC Container가 뭘까?

KOOCCI — Sat, 23 Jul 2022 01:23:32 +0900

목표 : 스프링의 IoC Container 에 대해 설명할 수 있다.

앞선 포스팅에서 스프링 프레임워크가 주는 의문 두가지,

스프링은 무엇을 도와주는가?
스프링의 사용법은 어떻게 되는가?

중에서 스프링의 사용법은 어떻게 되는지 알아볼 차례다.

일단 그 전에, 용어를 정리해야 사용법도 알게 될 것이므로 용어부터 하나씩 보도록 하자.

그 중, IoC Container 에 대해 알아볼 것이고, 그 내용은 스프링 공식 문서를 기반으로 확인해 보겠다.

스프링 코어 (spring-core)

스프링 코어의 가장 처음 나오는 용어가 IoC Container 이다.

그리고 그 문장을 그대로 가져오면 다음과 같다.

Foremost amongst these is the Spring Framework’s Inversion of Control (IoC) container.

스프링 프레임워크의 가장 중요한 것은 Inversion of Control(IoC) container 다.

그리고 IoC는 Dependency Injection(DI, 종속성 주입) 이라고도 하는데 그 설명을 읽어보면 바로 직관적으로 와닿지 않는다.

그렇기에 우선은 간략하게 아래 처럼 이해해보자.

스프링 프레임워크는 ApplicationContext라는 인터페이스를 통해서 IoC Container 를 제공하고 있다.

org.springframework.context.ApplicationContext 가 IoC Container 의 핵심인데, 이 인터페이스를 기준으로 구현된 다양한 구현체를 통해서 다양한 방식, 다양한 방법으로 IoC Container 기능이 구현되어 있다.

뭔지 모르겠지만, ApplicationContext라는 친구가 스프링 프레임워크의 IoC Container 를 책임지고 있는 것 같다.

그리고 아래 이미지를 보며 좀더 구체적으로 이해해보자.

Figure 1. The Spring IoC Container

POJO(Plain Old Java Object)로 만들어진 나의 비즈니스 오브젝트(나의 소스코드, 객체들)들은

스프링에서 제공하는 방법에 따라 만들어준 설정정보(Configuration Metadata)와 결합되고,

Application Context를 구현한 구현체(Spring Container)가 생성되고 초기화되었을 때, 실행가능한 프로그램(스프링에서 구동가능한 형태)이 되는 것이다.

번역하다보니 어렵지만, 결국 프레임워크 설명과 유사하다.

내가 만든 소스코드가 잘 작성된 설정정보랑 합쳐지면, Application Context의 구현체가 스프링에서 동작 가능하도록 만들어준다는 것이다.

그럼 먼저, 설정 정보라는 것이 무엇인지 보자.

Configuration Metadata

스프링에서 제공하는 설정방법은 크게 2가지, XML 과 Annotation이다.

먼저 XML 예시를 보도록 하자. (Annotation은 나중에 다시 볼 것이다)

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        https://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="..." class="...">  
        <!-- collaborators and configuration for this bean go here -->
    </bean>

    <bean id="..." class="...">
        <!-- collaborators and configuration for this bean go here -->
    </bean>

    <!-- more bean definitions go here -->

</beans>

설명에서는 계속 등장했었지만, 뭔지 몰라도 Bean이라는게 설정 정보에도 등장했다.

일단 위와 같은 형태로 작성한다는 내용을 인지하고, ApplicationContext 설명부터 보자.

ApplicationContext 인스턴스화

ApplicationContext는 인터페이스고 그 구현체가 필요하다.

앞서 말했듯이 구현된 다양한 구현체를 통해서 다양한 방식, 다양한 방법으로 IoC Container 기능을 구현하기 때문이다.

그 예시로 다음을 들고 있다.

ApplicationContext context = new ClassPathXmlApplicationContext("services.xml", "daos.xml");

여기서는 ClassPathXmlApplicationContext 라는 구현체를 사용했다.

그 Argument로는 services.xml과 daos.xml을 넣어주고 있다. (그 예시 역시 해당 페이지에 나온다)

이제 앞선 설정정보와 연결해서 보도록 하자.

Bean은 뭐고, ApplicationContext, Configuration Metadata랑 어떻게 연결되는 거지?

Spring Framework에서는 Bean이라는 것을 만든다.

쉽게 생각하면 객체다.

이 객체를 관리하는 것이 Container다.

다시 말해, Bean은 Spring Container (ApplicationContext 구현체) 가 관리하고 생성하고 인스턴스화 해주는 객체다.

보통 우리가 java에서 객체를 만들고 사용할 때는 다음 문장처럼 작성한다.

MyObject obj = new MyObject():

그러나 위처럼 직접 객체를 만들어주지않고, 설정정보에 작성하면 Spring Framework가 이 객체를 관리/생성/인스턴스화 하게 된다.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        https://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean class="com.text.myObject"/>  

</beans>

이처럼 설정 정보에 작성해준다면, MyObject 클래스를 더이상 new 로 생성하지 않고, ApplicationContext로부터 얻어오는 것이다.

ApplicationContext context = new ClassPathXmlApplicationContext("myObject.xml"); // 설정정보
MyObject obj = context.getBean(MyObject.class);
obj.method(); // 행위

위 과정을 다시한번 정리해보자.

Spring Framework에서, ApplicationContext의 구현체인 Spring Container는 Bean이라는 것으로 사용하고자 하는 객체를 관리한다.
그 생성과 인스턴스화를 관리하며, Bean에 대한 정보는 Configuration Metadata를 통해 정의한다.

그럼 마지막, IoC Container에 대해 정리하며 마무리하도록 하자.

Wrap Up

Spring Framework에서는 ApplicationContext를 통해 IoC Container를 제공하고 있다.

ApplicationContext는 인터페이스이며, 그 구현체는 Spring Container(=IoC Container)라고 한다.

Spring Container는 Bean이라고 하는 사용하고자 하는 객체의 생성, 인스턴스화 등을 관리하고 있다.

Bean에 대한 정보는 Configuration Metadata에 정의하여 관리된다.

Configuration Metadata에 정의된 Bean이라는 객체를 관리하고 생성을 책임지고 인스턴스화 하는 ApplicationContext의 구현체인 Spring Container를 IoC Container 라고 하며, Spring Framework에게 객체에 대한 관리,제어를 넘겨 주는 것을 제어의 역전(Inversion of Control, IoC) 이라고 한다.

[Spring] 스프링 프레임워크가 뭘까?

KOOCCI — Fri, 22 Jul 2022 22:50:12 +0900

목표 : 스프링(Spring)이 무엇인지 설명할 수 있다.

서론이자 내 생각..

스프링을 별도로 공부한 적은 많이 있지만, 글을 적으려고 할 때마다, 그리고 너무 겉핥기로 알고 있다보니 난감한 부분이 있다.

특히나 어려운 부분은, 오랫동안 발전해왔고 그 히스토리를 온전히 공부하면서 쌓아가야하는 건 아닐까 하는 생각이 항상 들어, 어디부터 어떻게 시작해야하는지 감이 잘 잡히지 않는다. 게다가 Spring Security, Data, Batch, Cloud, JPA 등등 너무도 다양해지는 탓에 어떻게 시작해야하는지 모르는 경우가 많았다.

무작정 토비의 스프링을 들고 공부하면 될지, 아니면 스프링부트로 API 서버 만드는 법부터 하면 되는 건지, JSP를 비롯한 이제는 점점 Legacy라는 단어로 표현되는 부분부터 차근히 발전한 과정을 쌓아올려야 할지, 어디부터 알면 되는 건지에 대한 부담감에 선뜻 도전하기 어렵고, 그래서 당장 필요한 부분만 보고 흐지부지 된 적도 많았다.

사실 지금도 어디부터 봐야할지 잘 모르겠지만, 언젠가는 따라가겠지라는 마음으로 하나씩 진행해 보고자 한다.

Spring 은 프레임워크다.

스프링은 프레임워크다.

프레임워크라 함은 쉽게 말해 사용법을 잘 알면 하고자 하는 일을 쉽게 할 수 있게 도와주는 뼈대이다.

즉, 개발자가 사용법에 맞게 작성을 하면, 프레임워크는 Main 함수를 실행시켜 개발자가 작성한 내용을 목적에 맞게 구동시켜 준다.

이제 2가지 의문이 나온다.

스프링은 무엇을 도와주는가?
스프링의 사용법은 어떻게 되는가?

스프링은 무엇을 도와주는가?

스프링은 웹 프레임워크다.

자바, Kotlin 등의 언어로 웹 서비스를 만들고자 할 때, 좀더 쉽게 만들 수 있도록 도와준다. (자바를 기준으로 설명할 것이다)

조금더 구체적으로 말해보자.

스프링은 자바 엔터프라이즈(JAVA EE) 애플리케이션 개발을 쉽게 도와주는 프레임워크다.

옛날에 자바를 통한 서버 개발에 필요한 기능을 모아서 J2EE(현재의 Java EE) 표준을 만들었고 특히, 핵심 기술인 EJB를 사용해 왔으나 이에 대한 불편함과 난이도가 매우 높았다.

따라서, 스프링은 이를 해소하고자 하여 나오게 된 프레임워크다.

그 상세한 내용은 이 링크를 확인하도록 하자.

자바로 웹 서비스를 만들고자 한다면 Java EE API 중 하나인 서블릿(Servlet)이라는 친구의 도움이 필요하다.

서블릿은 정적인 HTML의 한계를 극복하고 자바를 사용하여 웹페이지를 동적으로 생성하는 서버측 프로그램 혹은 그 사양을 뜻한다.

쉽게 말하면, 자바로 웹 서비스를 개발하기 위해 만들어진 표준 혹은 그 프로그램이다.

표준이라는 점을 먼저 주목하자.

JAVA SE (Standard Edition)에서 Enterprise Edition으로 버전이 달라질 때, 추가되는 javax API들을 보자.

https://docs.oracle.com/javaee/7/api/toc.htm

Java(TM) EE 7 Specification APIs

docs.oracle.com

javax.servlet 라는 친구가 눈에 띌 것이다.

여기 만들어져 있는 Interface들이 앞서 말했던 Servlet, 자바로 웹 서비스를 개발하기 위해 만들어진 표준 인터페이스다.

이 스팩을 다양한 벤더들 (Apache Tomcat, 티맥스의 jeus)이 이를 구현하여, 구현체로서 그 구동 환경을 제공하고 있으며, 이를 서블릿 컨테이너라고 한다.

그 중, Apache Tomcat은 오픈소스 자바 서블릿 컨테이너로 Servlet 뿐만 아니라 JSP, WebSocket 등 핵심적인 자바 엔터프라이즈 영역을 구현하였으며, 가장 많이 사용하는 WAS 중 하나다.

요즘은 서블릿 컨테이너를 별도로 쓰지 않고, 서비스에 내장한 형태의 Embedded Tomcat, Undertow 등을 많이 사용하지만 이전에는 Apache Tomcat을 별도로 설치하고, WAR파일과 연결하기도 했다. (아직 우리 회사에서는 이렇게 쓰는 곳이 많이 있다)

요즘엔 대부분 Spring Boot로 하거나, 최소 Spring 3.0 이상인 프로젝트가 많다보니 잘 쓰지 않지만, servlet을 만들어 Controller 로서 요청을 처리할 수 있게 만들고, web.xml을 통해서 servlet 이름, 클래스를 매핑하는 작업이 필요했다. (이제는 어노테이션으로 다 처리한다)

아무튼 Spring은 서블릿 컨테이너를 통해 훨씬 간편하게 배포할 수 있고, 이전 EJB때보다 Dependency도 매우 많이 해소가 된 것이다.

Servlet Container 를 잠시 정리하고 가자.

서블릿 컨테이너는 servlet Interface의 method에 의해서 정의된 Life Cycle (Init, service, destroy)을 구현하였고, 자연스럽게 서블릿을 관리하게 된다.

조금 상세하게 풀어서 순서를 정리해보자.

서블릿 컨테이너가 시작할 때 해당 프로젝트에 대한 모든 서블릿을 가지고 있는다. (서블릿 인스턴스를 싱글턴으로 갖고 있다 - 서블릿 컨테이너가 살아있는 한, 메모리에서 해제되지 않는다.)
클라이언트로부터 요청이 들어왔을 때, Request(HttpServletRequest)와 Response(HttpServletResponse) Instance 를 생성한다.
사용자의 요청 URL을 분석하여, 어떤 서블릿이 담당인지 찾아내고, 해당 서블릿 스레드를 생성하여 앞서 생성한 Request, Response객체를 전달한다.
이 때, 컨테이너는 서블릿의 service() 메소드를 호출해 request, response 객체를 전달하고 메소드에 따라, doGet, doPost 등의 메서드가 호출된다.
해당 메서드에서는 response에 응답하고자 하는 내용을 작성한다.
서블릿 컨테이너는 response 객체를 클라이언트로 전달하고, request, response 객체를 소멸시킨다.
서블릿 인스턴스는 사라지지 않고, 여러 요청에 대한 처리를 서블릿 컨테이너가 멈추기 전까지 계속 진행한다.

그럼 Servlet과 Spring Framework 는 무슨 관계가 있는가?

열심히 servlet이라는 것과 servlet container에 대해 알아보았다.

이제 Spring Framework와 연결시켜 보도록 하자.

Javax.servlet 인터페이스는 상속관계로 서블릿 컨테이너부터 Spring까지 이어지게 된다.

https://velog.io/@jakeseo_me/%EC%9E%90%EB%B0%94-%EC%84%9C%EB%B8%94%EB%A6%BF%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90.-%EA%B7%BC%EB%8D%B0-%ED%86%B0%EC%BA%A3%EA%B3%BC-%EC%8A%A4%ED%94%84%EB%A7%81%EC%9D%84-%EC%82%B4%EC%A7%9D-%EA%B3%81%EB%93%A4%EC%9D%B8

Tomcat을 기준으로, 서블릿 인터페이스는 HttpServlet까지 구현이 되었다.

그리고, Spring에서는 DispatcherServlet까지 이를 그대로 받아서 구현한다.

이제 다시 주제로 돌아가자.

정리하자면 다음과 같다.

최초에 서버 개발을 위한 Java EE 표준이 나왔을 때는 표준에 포함된 Servlet, JSP등으로 인해 각광을 받았다.
수많은 서버가 Java EE 표준에 맞추어 어플리케이션 서버를 개발하였으나, EJB 중심의 서버에 대한 불편함과 난이도가 높아, Spring이 등장하였다.
특히, EJB 없이 개발하는 방법에 대한 내용이 주가 되었으며 그 핵심이 DI 등 현재 Spring에 중심이 되는 컨셉들이다.

그럼, 스프링은 무엇을 도와주는가?

기존에 어렵던 서버 통신, 트랜젝션과 같은 기능들을 조금의 학습만 한다면, 이제는 잊혀질 정도로 어려웠던 사항을 쉽고 간편하게 개발할 수 있도록 도와주는 프레임워크다.

결론

스프링 프레임워크가 주는 의문 두가지,

스프링은 무엇을 도와주는가?
스프링의 사용법은 어떻게 되는가?

중에서 첫번째, 스프링은 무엇을 도와주는가? 에 대해 알아보았다.

그리고, 다음에는 그 사용법에 대해 알아볼텐데 몇가지 용어 정리가 필요할 것이다.

IoC, Bean 등의 개념부터 잡고 가도록 하자.

자바스크립트 기초부터 모던 자바스크립트까지 - 생성자편

KOOCCI — Wed, 20 Jul 2022 21:43:00 +0900

목표 : 자바스크립트에서는 생성자를 어떻게 표현하는지 알아본다.

앞선 포스트에서 객체가 어떻게 생성되는지 알아본 적이 있다.

물론 객체 리터럴이 가장 생성하기 쉬운 방식이지만, Object 생성자 함수를 사용해 생성하는 방식에 대해 알아보자.

생성자 함수

생성자 함수(constructor)는 new 연산자와 함께 호출하여 객체(인스턴스)를 생성하는 함수다.

그리고, 생성자 함수에 의해 생성된 객체를 인스턴스(Instance)라고 한다.

const person = new Object();

person.name = 'Lee';
person.sayHello = function() {
    console.log('Hi! My name is ' + this.name);
}

console.log(person); // {name: 'Lee', sayHello: ƒ}
console.log(person.sayHello()); // Hi! My name is Lee

자바스크립트는 Object 생성자 함수 말고도, String, Number, Boolean, Function, Array, Date, RegExp, Promise 등의 빌트인(Built-in) 생성자 함수를 제공한다.

객체 리터럴로 생성하는게 훨씬 편하지 않은가?

맞다.

굳이, Object 생성자 함수로 객체를 생성할 필요가 없어 보인다.

그러나 불편한 점이 한가지 떠오른다.

const circle1 = {
    radius: 5,
    getDiameter() {
        return 2 * this.radius;
    }
};

console.log(circle1.getDiameter()); // 10

const circle2 = {
    radius: 7,
    getDiameter() {
        return 2 * this.radius;
    }
};

console.log(circle2.getDiameter()); // 14

객체 리터럴로 생성하는 방식은 단 하나의 객체만 생성할 수 있다.

위와 같이, 데이터 프로퍼티 값만 바뀌었고 구조가 동일한데, 두번이나 작성해야하는 번거로움이 생긴다.

이제 이를 생성자 함수를 호출하는 것으로 바꿔보자.

function Circle(radius) {
    // 생성자 함수 내부의 this는 생성자 함수가 생성할 인스턴스를 가리킨다.
    this.radius = radius;
    this.getDiameter = function() {
    	return 2 * this.radius;
    };
}

const circle1 = new Circle(5);
const circle2 = new Circle(7);

console.log(circle1.getDiameter()); // 10
console.log(circle2.getDiameter()); // 14

this는 자바스크립트에서 중요한 키워드 중 하나이므로, 언제 호출되냐에 따라 가리키는 값이 달라진다.

우선 생성자 함수 내부에서는 위 주석처럼 생성자 함수가 생성할 인스턴스를 가리키는 것으로 넘어가고, 이후에 다시 알아보도록 하자.

다시, 위 예시로 넘어가서 new 연산자로 인스턴스를 생성하는 것을 볼 수 있다.

자바스크립트는 자바와 같은 언어와 다르게 특별한 형식을 가지고 인스턴스를 생성하는 것이 아니라, 생성자 함수를 정의하고 new 연산자로 호출하면 해당 함수는 생성자 함수로서 동작하며, new 연산자 없이 호출한다면, 일반 함수와 동일하게 동작하게 된다.

조금만 더 상세히 생성되는 과정을 작성해보자.

function Circle(radius) {
    // 1. 암묵적으로 빈 객체가 생성되고 this에 바인딩된다.
    console.log(this); // Circle {}
    // 2. this에 바인딩되어 있는 인스턴스를 초기화한다.
    this.radius = radius;
    this.getDiameter = function() {
    	return 2 * this.radius;
    };
    
    // 3. 완성된 인스턴스가 바인딩된 this가 암묵적으로 반환된다.
}

const circle = new Circle(1);
console.log(circle); // Circle {radius: 1, getDiameter: f}

향후 생성자 함수가 생성한 인스턴스가 될 빈 객체가 생성된다. 그리고 이 빈 객체(인스턴스)는 this에 바인딩된다. (this가 생성자 함수의 인스턴스를 가리키는 이유)
생성자 함수에 기술되어 있는 코드가 한 줄씩 실행되어 this에 바인딩되어 있는 인스턴스를 초기화한다. (개발자가 기술한 내용)
생성자 함수 내부의 처리가 끝나면, 인스턴스가 바인딩된 this가 암묵적으로 반환된다.

여기서, 암묵적으로 this가 반환되지만, 명시적으로 객체를 반환하면 암묵적인 this 반환이 무시되며, 원시 값을 반환하면 암묵적인 this값이 반환된다. (생성자 함수 내부에 return문이 반드시 생략되야 하는 이유)

function Circle(radius) {
    this.radius = radius;
    this.getDiameter = function() {
    	return 2 * this.radius;
    };
    
    // return {}; // this를 무시해버리고, {}를 반환한다.
    // return 100; // 100을 무시해버리고, this를 반환한다.
}

const circle = new Circle(1);
console.log(circle); // {} or Circle {radius: 1, getDiameter: f}

그럼 결국 객체, 함수, 생성자 함수 셋의 관계가 어떻게 되는거지?

함수는 객체다. 그렇지만, 모든 객체는 함수가 아니다.

다시 말해보자.

함수 선언문 또는 함수 표현식으로 정의한 함수 (이 제한을 놓치지 말자!)는 일반적인 함수로서 호출할 수도 있고, new 연산자와 함께 생성자 함수로도 호출할 수 있다.

함수는 객체이므로, 일반 객체와 동일하게 동작할 수 있다. 일반 객체가 가지고 있는 내부 슬롯과 내부 메서드를 함수 객체도 가지고 있기 때문이다.

그렇지만, 일반 객체는 다르다.

일반 객체는 호출할 수 없지만, 함수는 호출할 수 있다.

함수에는 함수 객체만을 위한 [[Environment]], [[FormalParameters]] 같은 내부 슬롯과 [[Call]], [[Construct]] 같은 내부 메서드를 갖고 있기 때문이다.

함수가 일반 함수로서 호출이 되면, Call 메서드가 호출이 되고, new 연산자로 호출이 되면, Constuct가 호출이 되는 것이다.

function foo() {};

foo(); // 일반 함수 : [[Call]] 호출

new foo(); // 생성자 함수 : [[Construct]] 호출

함수는 호출할 수 있어야 하므로, [[Call]] 내부 메서드를 무조건 가지고 있다. (Callable이라고 한다)

그치만, [[Construct]]는 항상 갖고 있는 것은 아니다.

즉, 일반 함수로서만 호출할 수 있는 함수 객체가 있다는 것이다. (non-constructor라고 하며, [[Construct]]가 있다면 constructor라고 한다.)

constructor : 함수 선언문, 함수 표현식, 클래스(클래스도 함수다)
non-constructor : 메서드(ES6 함수 축약 표현), 화살표 함수

const arrow = {} => {};
new arrow(); // TypeError: arrow is not a constructor

const obj = {
	x() {} // ES6 함수 축약 표현으로, 메서드라고 할 때는 ES6의 축약 표현에서만 메서드라고 명명한다.
}

new obj.x(); // TypeError: obj is not a constructor

차근히 다 배울 내용이니, 예제로 대신하고 넘어가도록 하자.

function Circle(radius) {
    this.radius = radius;
    this.getDiameter = function() {
    	return 2 * this.radius;
    };
    
}

const circle = Circle(5); // 일반 함수로서 호출하면 어떻게 되는지 보자.
console.log(circle); // undefined

console.log(radius); // 5
console.log(getDiameter()); // 10

console.log(circle.getDiameter()); // Uncaught TypeError: Cannot read properties of undefined (reading 'getDiameter')

재밌는 건 마치 생성자 함수처럼 만들어둔 함수를 그냥 일반 함수처럼 호출을 하면 위 예시와 같이 진행된다.

또한, Circle 함수를 일반 함수로 호출했을 때, this는 전역 객체 window를 가리키게 되어, 그 값을 쓸 수 있게 된다.

이런 전역으로 생성되버리는 것을 막고자 나온 ES6 문법이 new.target이다.

function Circle(radius) {
    if(!new.target) {
        return new Circle(radius);
    }
    this.radius = radius;
    this.getDiameter = function() {
    	return 2 * this.radius;
    };
    
}

const circle = Circle(5);
console.log(circle.getDiameter()); // 10

만약, new로 생성되지 않았다면, new.target은 undefined가 되어 위와 같은 형태로 생성자 함수가 동작하도록 설정할 수 있다.

일급 객체는 한번 알고 가자.

사실 그냥 넘어가긴 했지만, 이전 포스팅에서도 일급 객체를 언급했었다.

앞서 함수가 객체라고 하는 이유이므로 알아보고 넘어가자.

일급 객체에는 조건이 있다.

자바스크립트 함수가 일급 객체 조건을 몇개나 만족하는지 보도록 하자.

무명의 리터럴로 생성할 수 있다. 즉, 런타임에 생성이 가능하다.
변수나 자료구조(객체, 배열 등)에 저장할 수 있다.
함수의 매개변수에 전달할 수 있다.
함수의 반환값으로 사용할 수 있다.

// 무명의 리터럴로 생성
const increase = function(num) {
  return ++num;
}

const decrease = function(num) {
  return --num;
}

// 객체에 저장
const predicates = { increase, decrease };

// 매개변수로 함수 전달
// 반환값으로 함수 반환
function makeCounter(predicate) {
  let num = 0;
  return function() {
    num = predicate(num);
    return num;
  };
}

// 매개변수로 함수 전달
const increaser = makeCounter(predicates.increase);
console.log(increaser()); // 1
console.log(increaser()); // 2

// 매개변수로 함수 전달
const decreaser = makeCounter(predicates.decrease);
console.log(decreaser()); // -1
console.log(decreaser()); // -2

모든 조건을 만족하고 있고, 따라서 자바스크립트에서 함수는 객체다.

앞서 말했듯이, 함수는 일반 객체랑은 다르다.

함수는 호출이 가능하지만, 일반 객체는 호출할 수 없다.

그리고 함수 객체에는 고유의 프로퍼티가 있다.

함수 객체의 프로퍼티

argument, caller, length, name, prototype 프로퍼티는 모두 함수 객체 고유의 데이터 프로퍼티다.

다른 부분은 별도로 찾아보는 것으로 넘어가도 되지만, prototype 프로퍼티는 한번 보고 넘어가자.

prototype 프로퍼티는 생성자 함수로 호출 할 수 있는 함수 객체. 즉, constructor 만이 소유하는 프로퍼티다.

따라서, non-constructor에는 prototype 프로퍼티가 없다.

함수가 객체를 생성하는 생성자 함수로 호출될 때, 생성자 함수가 생성할 인스턴스의 프로토타입 객체를 가리킨다.

다시 말하면, 모든 함수는 non-constructor가 아니라면(화살표 함수, 메서드 등) 생성자 함수로 호출될 수 있다.

이 때, 인스턴스가 생성될 수 있고 이 인스턴스의 프로토타입 객체를 생성자 함수가 prototype이라는 프로퍼티로 가지고 있는 것이다.

그러나, 일반 객체는 생성자 함수가 될 수 없기 때문에, prototype을 갖고 있을 수 없다.

__proto__ 프로퍼티는 [[Prototype]] 이라는 내부 슬롯이 가리키는 프로토타입 객체에 접근하기 위한 접근자 프로퍼티이며, 상속의 개념이 필요하므로 다음에 설명할 프로토타입에 대해 잘 알아보도록 하자.

결론

자바스크립트에서의 생성자에 대해 알아보았다.

이제 자바스크립트 생성자와 함수의 차이, 객체 생성의 차이를 좀더 명확히 할 수 있게 되었다.

이 생성자를 토대로, 다음은 프로토타입에 대해 진행해보도록 하자

자바스크립트 기초부터 모던 자바스크립트까지 - 프로퍼티편

KOOCCI — Tue, 19 Jul 2022 23:39:27 +0900

목표 : 객체 프로퍼티에 대해 알아보자.

객체는 자바스크립트의 핵심이다. (함수도 객체다)

이를 토대로, 프로토타입, this 등의 개념으로 확장시켜 나갈 예정이다.

먼저 자바스크립트에서 객체 프로퍼티의 숨은 요소들을 찾아보고, 이후에 함수와 생성자 개념으로 확장시켜 보자.

객체의 프로퍼티를 다시한번 꺼내보자.

먼저 프로퍼티가 무엇인가?

기억이 안날 수 있으니 되돌아가보자.

객체 상태를 나타내는 값(Data) 이다.

즉, Key:Value 로 되어 있으며, 객체는 0개 이상의 프로퍼티로 이루어진 집합이다.

자바스크립트 엔진은 객체의 프로퍼티를 생성할 때, 기본값으로 자동 정의하는 요소가 있다.

const person = {a:1};

console.log(Object.getOwnPropertyDescriptors(person));
// a: {value: 1, writable: true, enumerable: true, configurable: true}
// [[Prototype]]: Object

먼저 이중 대괄호로 되어있는 [[Prototype]]이 보인다.

모든 객체는 [[Prototype]]이라는 내부 슬롯을 가진다. 내부 슬롯은 자바스크립트 엔진의 내부 로직이므로 원칙적으로 접근할 수 없지만, [[Prototype]]은 __proto__를 통해 간접적으로 접근할 수 있다.

내부 슬롯 : 자바스크립트 엔진의 구현 알고리즘을 설명하기 위해 ECMAScript 사양에서 사용하는 의사 프로퍼티(psudo property)

내부 메서드 : 위 설명과 동일한 의사 메서드 (psudo method)

ECMAScript 사양에 등장하는 이중 대괄호로 감싼 이름들이 내부 슬롯과 내부 메서드다.

자바스크립트 엔진에서 실제로 동작하지만, 개발자가 직접 접근할 수 있도록 공개된 프로퍼티는 아니다.

그리고, Object.getOwnPropertyDescriptors 라는 메서드로 프로퍼티 어트리뷰트를 확인해 보고 있다.

프로퍼티 어트리뷰트 역시, 자바 스크립트 엔진이 관리하는 내부 상태 값이라서 내부 슬롯이지만, 위 메서드로 간접적으로 확인해 본 것이다.

즉, 처음으로 돌아가서 자바스크립트 엔진은 객체의 프로퍼티를 생성할 때, 기본값으로 프로퍼티 어트리뷰트를 자동 정의한다.

프로퍼티에도 종류가 있을까?

뭔지 모르겠지만, 프로퍼티라는 걸 조금 까보았더니, 프로퍼티 어트리뷰트라는게 나왔다.

그럼 또 다른 이야기로 넘어가서, 프로퍼티에는 2가지 종류가 있다.

데이터 프로퍼티 (Data Property)	접근자 프로퍼티 (Accessor Property)
키와 값으로 구성된 일반적인 프로퍼티	자체적으로 값을 갖지 않고 다른 데이터 프로퍼티의 값을 읽거나 저장할 때 호출되는 접근자 함수(Accssor Function)으로 구성된 프로퍼티

데이터 프로퍼티

데이터 프로퍼티는 우리가 일반적으로 확인해본 현재까지의 객체의 프로퍼티로 보면된다.

그리고, 데이터 프로퍼티는 위에서 살펴보았듯이, 다음과 같은 프로퍼티 어트리뷰트를 갖는다.

프로퍼티 어트리뷰트	프로퍼티 디스크립터 객체의 프로퍼티	설명
[[Value]]	value	프로퍼티 키를 통해 반환되는 프로퍼티 값 값을 변경할 때, [[Value]]를 재할당 하는 것. 프로퍼티가 없을 때는 동적 생성하고 저장한다.
[[Writable]]	writable	프로퍼티 값의 변경 가능 여부를 boolean 값으로 갖는다. false면, [[Value]]의 값을 변경할 수 없는 읽기 전용으로 만든다.
[[Enumerable]]	enumerable	프로퍼티의 열거 가능 여부를 boolean 값으로 갖는다. for...in 이나 Object.keys 사용 가능 여부가 된다.
[[Configurable]]	configurable	프로퍼티의 재정의 가능 여부를 boolean 값으로 갖는다. false인 경우, 해당 프로퍼티의 삭제, 프로퍼티 어트리뷰트 값의 변경이 금지된다. [[Writable]]이 True라면, [[Value]]의 변경과 [[Writable]]의 변경만 허용된다.

숨겨진 친구들이 설명된다.

즉, 객체라는 것은 0개 이상의 프로퍼티의 집합으로 구성되며, 이 중, 데이터 프로퍼티가 생성될 때에는 위와 같은 프로퍼티 어트리뷰트들이 함께 자동 정의가 되는 것이다.

그리고, 그 설명을 보았을 때, 왜 프로퍼티 어트리뷰트 (속성)이라고 하는 지 명시적으로 알 수 있다.

접근자 프로퍼티

접근자 프로퍼티에서는 또 다른 프로퍼티 어트리뷰트들이 정의된다.

프로퍼티 어트리뷰트	프로퍼티 디스크립터 객체의 프로퍼티	설명
[[Get]]	get	접근자 프로퍼티를 통해 데이터 프로퍼티 값을 읽을 때 호출되는 접근자 함수 접근자 프로퍼티 키로 프로퍼티 값에 접근하면 프로퍼티 어트리뷰트 [[Get]]의 값, 즉 getter 함수가 호출되고 그 결과가 프로퍼티 값으로 반환된다.
[[Set]]	set	접근자 프로퍼티를 통해 데이터 프로퍼티 값을 저장할 때 호출되는 접근자 함수 접근자 프로퍼티 키로 프로퍼티 값을 저장하면 프로퍼티 어트리뷰트 [[Set]]의 값, 즉 setter 함수가 호출되고 그 결과가 프로퍼티 값으로 저장된다.
[[Enumerable]]	enumerable	프로퍼티의 열거 가능 여부를 boolean 값으로 갖는다. for...in 이나 Object.keys 사용 가능 여부가 된다.
[[Configurable]]	configurable	프로퍼티의 재정의 가능 여부를 boolean 값으로 갖는다. false인 경우, 해당 프로퍼티의 삭제, 프로퍼티 어트리뷰트 값의 변경이 금지된다. [[Writable]]이 True라면, [[Value]]의 변경과 [[Writable]]의 변경만 허용된다.

접근자 프로퍼티에서는 우리가 흔히 아는 getter, setter 가 자동적으로 정의된다.

다만 getter, setter 모두 정의할 수 있고, 하나만 정의할 수도 있다.

예시로 다시한번 보도록 하자.

const person = {
  // 데이터 프로퍼티
  firstName: 'Ungmo',
  lastName: 'Lee',
  // 접근자 프로퍼티 (접근자 함수로 구성)
  get fullName() {
    return `${this.firstName} ${this.lastName}`;
  },
  // 접근자 프로퍼티 (접근자 함수로 구성)
  set fullName(name) {
    [this.firstName, this.lastName] = name.split(' ');
  }
};

console.log(person.firstName + ' ' + person.lastName);
// Ungmo Lee

person.fullName = 'Heegun Lee';
console.log(person);
// {firstName: 'Heegun', lastName: 'Lee'}

console.log(person.fullName);
// Heegun Lee

let descriptor = Object.getOwnPropertyDescriptors(person, 'firstName');
console.log(descriptor);
// {firstName: {…}, lastName: {…}, fullName: {…}}
// firstName: {value: 'Heegun', writable: true, enumerable: true, configurable: true}
// fullName: {enumerable: true, configurable: true, get: ƒ, set: ƒ}
// lastName: {value: 'Lee', writable: true, enumerable: true, configurable: true}
// [[Prototype]]: Object

descriptor = Object.getOwnPropertyDescriptors(person, 'fullName');
console.log(descriptor);
// {firstName: {…}, lastName: {…}, fullName: {…}}
// firstName: {value: 'Heegun', writable: true, enumerable: true, configurable: true}
// fullName: {enumerable: true, configurable: true, get: ƒ, set: ƒ}
// lastName: {value: 'Lee', writable: true, enumerable: true, configurable: true}
// [[Prototype]]: Object

위 예시를 통해 프로퍼티에 대해 조금 더 상세히 알아보았다.

번외로, 흔히 헤깔려하는 __proto__ 와 함수의 prototype은 각각 어떤 프로퍼티인지 알아보자

Object.getOwnPropertyDescriptor(Object.prototype, '__proto__');
// {enumerable: false, configurable: true, get: ƒ, set: ƒ}

Object.getOwnPropertyDescriptor(function(){}, 'prototype');
// {value: {…}, writable: true, enumerable: false, configurable: false}

즉, __proto__ 는 접근자 프로퍼티이며, 함수의 prototype은 데이터 프로퍼티다.

다음에 생성자 이야기를 하면서 조금 더 구체적으로 알아갈 것이기 때문에, 참고만 하도록 하자.

프로퍼티 어트리뷰트도 설정할 수 있다.

객체는 변경이 가능한 값이기 때문에 재할당 없이 직접 변경할 수 있다.

즉, 프로퍼티는 추가, 삭제, 갱신이 가능하며, 프로퍼티 어트리뷰트가 자동 정의가 된다고 하지만, Object.defineProperty나 Object.defineProperties와 같은 메서드를 통해, 그 값을 직접 넣어줄 수도 있다.

또한, 객체의 변경을 방지할 수 있는데, 다음과 같은 메서드들이 있으니 참고하도록 하자.

구분	메서드	프로퍼티 추가	프로퍼티 삭제	프로퍼티 읽기	프로퍼티 쓰기	프로퍼티 어트리뷰트 재정의
객체 확장 금지	Object.preventExtensions	X	O	O	O	O
객체 밀봉	Object.seal	X	X	O	O	X
객체 동결	Object.freeze	X	X	O	X	X

다만, 중첩된 객체에 대해서는 동결이 안된다. 즉, 재귀적으로 동결 시켜주어야 한다.

자바 기초부터 모던 자바까지 - 스트림(stream)편

KOOCCI — Sat, 16 Jul 2022 23:33:46 +0900

목표 : 람다를 기준으로 스트림 문법을 이해한다.

이전 포스팅으로, JAVA가 인터페이스를 통해 람다식을 어떻게 만들어 왔는지 히스토리를 보았다.

그리고, java에서는 앞서 배운 함수형 인터페이스의 주요 표현들인 Consumer, Function, Predicate, Supplier들이 어떻게 사용되어 지는지 Stream을 보면서 이해해보도록 하자.

Stream(스트림) 부터 알아보자.

보통 Stream(스트림)이라는 단어는 어떤 데이터의 흐름을 뜻한다.

특히, java.io에서는 I/O 프로그래밍을 사용하는 클래스 명에 Stream이라는 단어를 사용하고 있다.

그러나, 지금 배우고자 하는 Stream은 주로 컬렉션 프레임워크나 이와 유사한 형태의 데이터를 처리할 때 도움을 줄 수 있는, 자바 8에서 새롭게 제안한 API다.

즉, Stream API의 주 목적은 람다 표현식과 메서드 참조 등의 기능과 결합해서 매우 복잡하고 어려운 데이터 처리 작업을 쉽게 처리하도록 도와주는 것에 있다.

Integer[] intArr = new Integer[] {1,2,3,4,4,4,5,7,8,8,8,8,8};
List<Integer> numberList = Arrays.asList(intArr);

for(int i = 0; i < numberList.size(); i++) {
    System.out.println(numberList.get(i));
}

이 코드의 문제점은 인덱스 변수인 i를 사용한 점이다.

물론, 초창기 방식이지만 여전히 보편적으로 많이 사용하는 방법이다.

다만, 매번 반복되는 코드이면서도 명확성이 흐려지고, List의 끝지점을 알기 위해서는 항상 i가 List 크기와 비교하는 작업이 선행된다.

for(Iterator<Integer> iter = numberList.iterator(); iter.hasNext();) {
    System.out.println(iter.next());
}

조금 깔끔해졌다.

Iterator를 통해 별도로 변숫값을 증가 시키는 로직을 삭제하고, next 메서드를 활용하고 있다.

다만, 매번 Iterator 객체를 생성하고 for 루프를 작성해야 하는 번거로움은 여전히 유사하게 남아있다.

for(Integer value : numberList) {
	System.out.println(value);
}

for each 구문은 자바5에서 새롭게 도입된 것으로 훨씬 깔끔해졌다.

numberList.forEach(System.out::println);

마지막으로 스트림 API를 통해 바로 결과를 출력하는 방식이다.

단지 메서드 참조로 println을 전달하였다.

스트림을 이용한 컬렉션 프레임워크의 가장 큰 특징은 기존 컬렉션 프레임워크처럼 개발자가 정의한 외부 코드로 for 루프를 실행하는 것이 아니라 스트림 내부에서 개발자가 정의한 코드가 반복적으로 실행된다는 것을 의미한다.

따라서, 개발자가 별도로 for 루프 구문을 만들고 인덱스 변수를 처리하거나 Iterator 객체를 생성하는 반복적이고 에러 확률을 높이는 수고를 하지 않아도 된다.

스트림 인터페이스

java.util.stream에는 자바 8의 스트림에 대해 정의되어 있다. 대부분 interface로 되어 있고, 몇가지 Util성 클래스가 있는 걸 볼 수 있다.

스트림 API가 주로 인터페이스로 구성되어 있는 이유는 실질적인 구현체는 데이터의 원천에 해당하는 컬렉션 프레임워크 기반의 클래스에 위임하고 있기 때문이다.

또한, 앞서 말했듯이 스트림은 람다 표현식이나 메서드 참조를 통해 구체적인 구현체를 전달받아 동작하기 때문에 함수형 인터페이스와 관련이 있다.

조금 세부적으로 들어가면, 스트림에서 가장 기본이 되는 인터페이스는 BaseStream이다.

선언문 부분만 간단히 보면, 다음과 같다.

public interface BaseStream<T, S extends BaseStream<T, S>> extends AutoCloseable {
    Iterator<T> iterator(); // 스트림 항목에 대한 인덱스를 Iterator 객체로 리턴
    Spliterator<T> spliterator(); // 스트림이 포함하고 있는 항목들을 분할하기 위한 Spliterator 객체 리턴
    boolean isParallel(); // 스트림이 병렬로 실행되었는지 여부를 리턴
    S sequential(); // 절차적으로 처리 가능한 스트림을 리턴
    S parallel(); // 병렬 처리 가능한 스트림을 리턴
    S unordered(); // 데이터가 정렬되지 않은 스트림을 리턴
    @Override
    void close(); // 스트림 종료. 해당 스트림의 파이프라인과 연결되어 있는 모든 핸들러를 종료
}

T: 스트림에서 처리할 데이터의 타입 (요소의 타입)
S: BaseStream을 구현한 스트림 구현체. 스트림을 자동으로 종료하기 위한 AutoCloseable도 구현되어야 함

BaseStream은 일반적으로 개발자가 쓰지 않고, 이를 상속한 Stream 인터페이스를 주로 사용한다.

그리고 자바 API 문서에는 이 Stream 인터페이스에 대한 내용은 설명이 많고, 제공하는 메서드도 많다.

그 중 대표적인 것만 먼저 보도록 하자.

메서드	설명
concat	입력 파라미터로 전달된 두 개의 스트림을 하나의 스트림으로 합친다. 합쳐진 스트림의 데이터는 첫번째 스트림을 먼저 처리하고 두번째 스트림을 뒤이어서 처리한다.
collect	스트림의 항목들을 컬렉션 프레임워크 기반의 객체로 리턴한다. 주로 List 객체로 리턴해서 많이 사용한다.
count	스트림에 포함된 항목의 수를 리턴한다.
distinct	중복된 항목을 제외하고 스트림 객체를 만들어서 리턴한다. 이 기능을 사용하기 위해서는 항목의 equals 메서드가 정확히 정의되어 있어야 한다.
filter	스트림 항목을 필터링한다. 필터 조건은 Function 인터페이스를 위한 람다 표현식 혹은 메서드 참조를 전달한다.
forEach	스트림 연산을 종료하고 최종 결과를 처리하기 위한 메서드다. 종료 연산의 일종이다.
limit	특정 개수만큼만 항목을 처리한다. 제한된 개수 한도에서 새로 생성한 스트림을 리턴한다.
reduce	람다 표현식을 기반으로 데이터를 소모하고 그 결과를 리턴하는 최종 연산이다. 다른 메서드가 특정한 기능에 제한적으로 지원되는 반면, 이 메서드는 다양하게 활용될 수 있다.
skip	스트림 처리중 특정한 숫자만큼 항목을 건너 뛴다.
sorted	스트림에 포함된 항목을 정렬한다.
toArray	스트림의 항목들을 배열로 만들어서 리턴한다.

주의할 점은 BaseStream 인터페이스와 Stream 인터페이스에 정의된 메서드들의 리턴 타입이 대부분 Stream(정확히는 제네릭에서 정의한 Stream 인터페이스의 구현 객체)이거나 void 인 것이다.

리턴 타입이 Stream인 메서드들은 리턴 결과를 통해, 데이터를 중간에 변형하거나 필터링한 후 다시 Stream 객체를 만들어서 리턴한다. 이러한 작업을 반복적으로 할 수 있고, 중간 연산 메서드라고 한다.
리턴 타입이 void인 메서드들은 주로 Stream을 이용해서 데이터를 최종적으로 소비한다. 이를 최종 연산 메서드라고 한다.

그리고 중요한 점은 Stream 객체는 불변성이 특징이다.

즉, Stream 객체의 메서드 호출 결과로 리턴 받은 Stream 객체는 원천 데이터를 수정한 것이 아니라 완전히 새롭게 생성한 데이터다.

이렇게 만들어진 이유는 중간 연산 작업과 함께 병렬 처리가 가능하기 때문에 데이터 정합성을 확보하기 위해서이며, 스트림 API 뿐아니라, 자바8 이후에 소개된 대부분의 API에서 공통적으로 보이는 특징이다.

스트림 연산 파이프라인

스트림의 중간 연산자와 최종 연산자는 함수형 인터페이스를 기반으로 하고 있어서, 개발자가 람다 표현식으로 동작을 정의할 수 있다는 장점이 있다.

다음 이미지를 보자.

스트림 연산

스트림 연산 파이프라인

스트림 API 기반의 연산 작업을 선호하는 이유는 리눅스의 파이프라인과 유사하게 기능을 조합할 수 있다는 점이다.

그리고, 그 과정에서 우리가 앞서 배운 함수형 인터페이스들이 기반이 되고 있는 것을 볼 수 있다.

[java] Number of Islands

KOOCCI — Sat, 16 Jul 2022 15:52:41 +0900

[참고문제] : https://leetcode.com/problems/number-of-islands/

Number of Islands - LeetCode

Level up your coding skills and quickly land a job. This is the best place to expand your knowledge and get prepared for your next interview.

leetcode.com

문제 풀이

DFS/BFS 문제이고, 연결된 구간의 갯수를 찾는 문제다.

특히나, 전형적인 문제라 BFS로 풀어보기로 했다.

생각의 흐름 - 방문 여부는 누적되도 된다.

이전에 풀었던 문제는 중복적으로 체크하면 안되었기 때문에, 다시 돌려주는 방법을 사용했지만 이번에는 중복해서 활용해야만 한다.

생각의 흐름 - Count에 대한 분리를 잘하자.

외딴 섬이 몇개인지 알아봐야 하므로, Count 측정 지점을 잘 체크해야 한다.

즉, 새로운 '1'이 나오면 count를 올리고, 인접한 상,하,좌,우에 '1'인 지점을 bfs로 모두 방문했다고 체크해야 한다.

그래야 외딴 섬의 갯수가 정확하게 나온다.

class Solution {
    public int numIslands(char[][] grid) {
        int m = grid.length;
        int n = grid[0].length;
        int count = 0;
        boolean[][] isVisited = new boolean[m][n];

        for(int i = 0; i < m; i++) {
            for(int j = 0; j < n; j++) {
                if(!isVisited[i][j] && grid[i][j] == '1') {
                    count ++;
                    // BFS
                    Queue<Node> que = new LinkedList<>();
                    que.add(new Node(i,j));
                    while(!que.isEmpty()) {
                        Node tmp = que.poll();
                        if(isVisited[tmp.row][tmp.col] || grid[tmp.row][tmp.col] != '1')
                            continue;
                        isVisited[tmp.row][tmp.col] = true;
                        if(tmp.row != 0) {
                            que.add(new Node(tmp.row-1, tmp.col));
                        }
                        if(tmp.row != m-1) {
                            que.add(new Node(tmp.row+1, tmp.col));
                        }
                        if(tmp.col != 0) {
                            que.add(new Node(tmp.row, tmp.col-1));
                        }
                        if(tmp.col != n-1) {
                            que.add(new Node(tmp.row, tmp.col+1));
                        }
                    }
                }
            }
        }

        return count;
    }
    class Node {
        int row;
        int col;
        Node(int row, int col) {
            this.row = row;
            this.col = col;
        }
    }
}

[java] Word Search

KOOCCI — Sat, 16 Jul 2022 15:08:50 +0900

[참고문제] : https://leetcode.com/problems/word-search/

Word Search - LeetCode

Level up your coding skills and quickly land a job. This is the best place to expand your knowledge and get prepared for your next interview.

leetcode.com

문제 풀이

전형적인 DFS 문제다.

생각의 흐름 - Recursive하게 풀어보자.

DFS는 Stack을 사용하거나, Recursive로 풀면 된다.

이 문제는 Stack을 사용하기 보단, 파라미터가 많아 Recursive하게 풀어주면 좀 더 편하게 풀 수 있을 것으로 생각했다.

생각의 흐름 - 좌,우,상,하를 체크하자.

좌,우,상,하 방향으로 갈 수 있으니 적절한 예외처리와 최종적으로 True가 반환되는 경우를 잘 체크해서 4가지 방향 중 한 방향으로라도 성공하면 True를 제공하면 된다.

생각의 흐름 - Visit 체크를 하자?

방문 여부를 항상 체크해야 한다.

java에서는 Call By Value지만, 객체에 대한 주소위치값을 전달하기 때문에 주의해야 한다.

단순히 visit만 넘기게 되면, 이전에 지나갔던 기록도 고스란히 남아있게 된다. (다시 봐야 하는데 마치 이미 확인한 길인 것처럼)

따라서, 들어갔다가 나올때는 다시 false를 해주자.

class Solution {
    public boolean exist(char[][] board, String word) {
        int M = board.length;
        int N = board[0].length;
        boolean result = false;

        boolean[][] isVisited = new boolean[M][N];

        for(int i = 0; i < M; i++) {
            for(int j = 0; j < N; j++) {
                if(word.charAt(0) == board[i][j])
                    result = result || dfs(isVisited, board,word.substring(1),i,j,M,N);
                if(result)
                    return true;
            }
        }
        return false;
    }
    
    public boolean dfs(boolean[][] isVisited, char[][] board, String word, int row, int col, int M, int N) {
        if(word.isEmpty())
            return true;
        isVisited[row][col] = true;
        boolean result = false;
        if(col != 0) {
            if(!isVisited[row][col-1] && board[row][col-1] == word.charAt(0))
                result = result || dfs(isVisited,board, word.substring(1), row, col-1, M, N);
        }

        if(col != N-1) {
            if(!isVisited[row][col+1] && board[row][col+1] == word.charAt(0))
                result = result || dfs(isVisited,board, word.substring(1), row, col+1, M, N);
        }

        if(row != 0) {
            if(!isVisited[row-1][col] && board[row-1][col] == word.charAt(0))
                result = result || dfs(isVisited,board, word.substring(1), row-1, col, M, N);
        }

        if(row != M-1) {
            if(!isVisited[row+1][col] && board[row+1][col] == word.charAt(0))
                result = result || dfs(isVisited,board, word.substring(1), row+1, col, M, N);
        }
        
        isVisited[row][col] = false;
        return result;
    }
}

[java] Minimum Size Subarray Sum

KOOCCI — Sat, 16 Jul 2022 14:12:55 +0900

[참고문제] : https://leetcode.com/problems/minimum-size-subarray-sum/

Minimum Size Subarray Sum - LeetCode

Level up your coding skills and quickly land a job. This is the best place to expand your knowledge and get prepared for your next interview.

leetcode.com

문제 풀이

연속된 subArray를 어떻게 관리할지가 포인트인 문제다.

생각의 흐름 - 한번만 배열을 읽자

물론 문제를 풀면서 달라질 수 있지만, 일단 주어진 nums배열은 한번만 읽는게 중요할 것으로 보였다.

생각의 흐름 - SubArray를 어떻게 관리하지?

처음에는 단지 배열에 저장하자고 생각했는데, sum을 계산한 배열이 필요할 거라 생각했다. 그래야 배열을 다시 읽어 합치는 과정을 안해도 된다.

그러나 최소 길이를 찾아야 하니, 시작과 끝 지점을 알아야 하는데, 처음에는 queue에 저장하고 길이를 알아볼까 했지만, 그러면 계산된 sum 처리가 어려워서 left, right 인덱스를 관리하자고 생각했다.

생각의 흐름 - 언제 left와 right를 늘리거나 줄여주는가?

right는 자연스럽게 배열을 읽어나가면서 늘리면 된다. 내가 필요한건 결과값인 minLength이고, left와 right 둘다 길이 계산에서 필요한 값이기 때문에 minLength계산만 되면 어떻게 되든 상관없다.

right가 문제가 아니라 left가 문제다.

결국 sumArr에 대해, 현재까지 더해진 값에 left를 늘려주며 그 값을 빼면, 앞에서부터 left 까지 누적된 sumArr를 뺄 수 있다.

그 값을 통해, sum 값이 target보다 크거나 같게되는 지점을 찾는다.

public int minSubArrayLen(int target, int[] nums) {
    int result = 0;
    int left = 0;
    int right = 0;
    int[] sumArr = new int[nums.length];
    Arrays.fill(sumArr, 0);
    int minLength = Integer.MAX_VALUE;

    for(int i = 0; i < nums.length; i++) {
        if(nums[i] >= target) {
            return 1;
        }

        if(i == 0) {
            sumArr[i] = nums[i];
        } else {
            sumArr[i] = sumArr[i-1] + nums[i];
        }
        right ++;

        if(sumArr[i] >= target) {
            while(left < right) {
                if((sumArr[i] - sumArr[left]) >= target) {
                    left ++;
                } else {
                    break;
                }
            }

            minLength = Math.min(minLength, right - left);
        }
    }

    if(minLength != Integer.MAX_VALUE)
        result = minLength;

    return result;
}

[java] Find Minimum in Rotated Sorted Array

KOOCCI — Thu, 14 Jul 2022 22:46:54 +0900

[참고문제] : https://leetcode.com/problems/find-minimum-in-rotated-sorted-array/

Find Minimum in Rotated Sorted Array - LeetCode

Level up your coding skills and quickly land a job. This is the best place to expand your knowledge and get prepared for your next interview.

leetcode.com

문제 풀이

이미 정렬되어 있지만, Rotate되어있는 배열에 대해 최소값을 찾는 문제다.

생각의 흐름 - 양쪽에서 바라보자.

이미 정렬이 되어 있으니, 최소값을 찾는 것에만 집중해야 한다.

그 중에서도 양쪽에서 찾아 나가는 방법이 포인트라고 생각된다.

값이 더이상 증가하지 않거나(왼쪽에서) 줄어들지 않는 곳(오른쪽에서)이 최소값이다.

생각의 흐름 - 그런 부분이 없다면?

그럼 당연히 첫번째 값이다.

class Solution {
    public int findMin(int[] nums) {
        int start = 0;
        int end = nums.length -1;
        while(start < end) {
            if(start+1 < nums.length) {
                if(nums[start] < nums[start+1]) {
                    start ++;
                } else {
                    return nums[start+1];
                }
            }
            
            if(end-1 >= 0) {
                if(nums[end-1] < nums[end]) {
                    end --;
                } else {
                    return nums[end];
                }
            }
        }
        return nums[0];
    }
}

자바스크립트 기초부터 모던 자바스크립트까지 - 스코프편

KOOCCI — Thu, 7 Jul 2022 02:00:24 +0900

목표 : 자바스크립트에서 스코프가 무엇인지 이해한다.

그냥 javascript라는 언어만 사용하다가, 어느 순간부터 공부를 하려고 하다보면, 언제나 맞닥드리는 부분이 스코프(Scope)다.

게다가 ES6에서 꽤 큰 변화가 있었기에, 그리고 javascipt만의 동작이 어떻게 되는지 알고싶다면 반드시 알아야 할 개념이다.

스코프(Scope)가 뭐지?

이전 포스팅에서 함수의 매개변수의 스코프에 대해 잠깐 다루었다.

매개변수를 참조할 수 있는 유효범위, 즉 매개변수의 스코프는 함수의 몸체 내부로 한정된다.

변수는 자신이 선언된 위치에 의해 자신이 유효한 범위, 즉 다른 코드가 변수 자신을 참조할 수 있는 범위가 결정된다.

정리해 보면, 모든 식별자(변수 이름, 함수 이름, 클래스 이름 등)는 자신이 선언된 위치에 의해 다른 코드가 식별자 자신을 참조할 수 있는 유효 범위가 결정된다. 이를 스코프라 한다. 즉, 스코프는 식별자가 유효한 범위를 말한다.

다음 예제를 보도록 하자.

var x = 'global';

function foo() {
	var x = 'local';
    console.log(x); // 1
}

foo();

console.log(x); // 2

자바스크립트 엔진은 스코프를 통해 어떤 변수를 참조해야 할 것인지 결정한다. 또한 코드를 실행할때 코드의 context(문맥)을 고려한다.

"코드가 어디서 실행되며 주변에 어떤 코드가 있는지?"를 렉시컬 환경(lexical environment)라고 한다.

즉, 코드의 문맥(context)은 렉시컬 환경으로 이루어진다. 이를 구현한 것이 실행 컨텍스트(execution context)이며, 모든 컨텍스트에서 평가되고 실행된다.

스코프의 종류

코드는 전역과 지역으로 나누어진다.

변수는 자신이 선언된 위치(전역 혹은 지역)에 의해 자신의 유효 범위인 스코프가 결정된다.

전역 변수는 어디서든지 참조할 수 있다.

즉, 전역 지역에는 전역 스코프를 만들고, 지역에는 지역 스코프를 만든다.

전역은 코드의 가장 바깥 영역을 말하며, 지역은 함수 몸체 내부를 말한다.

지역 변수는 자신의 지역 스코프와 하위 지역 스코프에서 유효하다.

스코프 체인

중첩 함수(Nested Function)의 존재는 지역 스코프의 중첩과 이어진다.

즉, 함수는 중첩될 수 있으므로, 함수의 지역 스코프도 중첩될 수 있다. 즉, 계층적 구조를 가질 수 있다.

이렇게 스코프가 계층적으로 연결된 것을 스코프 체인이라고 한다.

변수를 참조할 때 자바스크립트 엔진은 스코프 체인을 통해 변수를 참조하는 코드의 스코프에서 시작하여 상위 스코프 방향으로 이동하여 선언된 변수를 검색한다.

스코프 체인은 물리적인 실체로 존재한다. 자바스크립트 엔진은 코드(전역 코드와 함수 코드)를 실행하기에 앞서 렉시컬 환경을 실제로 생성한다.

변수 선언이 실행되면 변수 식별자가 이 자료구조(렉시컬 환경)에 키로 등록되고, 변수 할당이 일어나면 이 자료구조의 변수 식별자에 해당하는 값을 변경한다.

스코프 체인은 실행 컨텍스트의 렉시컬 환경을 단방향으로 연결한 것이다.

전역 렉시컬 환경은 코드가 로드되면 곧바로 생성되고 함수의 렉시컬 환경은 함수가 호출되면 곧바로 생성된다.

따라서, 상위 스코프에서 유효한 함수는 하위 스코프에서 자유롭게 참조가 가능하지만, 하위 스코프에서 유효한 변수를 상위 스코프에서는 참조할 수 없다.

앞서, 이전 포스팅에서 함수 생성 시점과 함수 호이스팅에 대해 알아보았다.

즉, 함수 선언문으로 함수를 정의하면 런타임 이전에 함수 객체가 생성된다.

자바스크립트 엔진은 함수 이름과 동일한 이름의 식별자를 암묵적으로 선언하고 생성된 함수 객체를 할당한다.

함수 레벨 스코프

지역 스코프를 설명할 때, 함수의 몸체 내부라고 설명하였다. 즉, 코드 블록이 아닌 함수에 의해서만 지역 스코프가 생성된다는 것이다.

C나 자바등의 언어는 함수 뿐 아니라, 모든 코드 블록(if, for, while 등)이 지역 스코프를 가진다. 이를 블록 레벨 스코프(Block Level Scope)라고 한다.

javascript 에서는 var 키워드로 선언된 변수는 오로지 함수의 코드 블록(함수 몸체)만을 지역 스코프로 인정한다.

이를 함수 레벨 스코프라고 한다.

var i  = 10;

for(var i = 0; i < 5; i++) {
	console.log(i); // 0 1 2 3 4
}

console.log(i); // 5

렉시컬 스코프

var x = 1;

//정의
function foo() {
	var x = 10;
    bar();
}

//정의
function bar() {
	console.log(x);
}

//정의된 곳의 x값이 출력된다.
foo(); // 1 (전역)
bar(); // 1

얼핏 보면 조금 헤깔릴 수 있다.

두가지 쟁점이 있다.

함수를 어디서 호출했는지에 따라 함수의 상위 스코프를 결정
함수를 어디서 정의했는지에 따라 함수의 상위 스코프를 결정

첫번째 방식을 동적 스코프(dynamic scope)라고 한다. 함수를 정의할 때는 어디서 호출될지 모르므로, 호출되는 시점에 상위 스코프가 결정된다.

두번째는 정적 스코프 혹은 렉시컬 스코프(lexical Scope)라고 한다.

자바스크립트는 렉시컬 스코프를 따른다. 즉, 함수의 호출위치는 상위 스코프 결정에 어떠한 영향도 주지 않는다.

함수의 상위 스코프는 언제나 자신이 정의된 스코프다.

함수 정의(함수 선언문 혹은 함수 표현식)가 실행되어 생성된 함수 객체는 이렇게 결정된 상위 스코프를 기억한다. (스코프 체인)

변수의 생명 주기

스코프를 배워보았으니, 변수의 생명 주기를 한번 알아보자.

전역 변수의 생명 주기는 애플리케이션의 생명 주기와 같다.

지역 변수의 생명 주기는 함수의 생명 주기와 일치한다.

즉, 호이스팅도 함수 내에서 일어난다.

다시 말해, 호이스팅은 스코프를 단위로 일어난다.

var x = 'global';

function foo() {
	console.log(x);
    var x = 'local';
}

foo(); // undefined
console.log(x); // global

전역 코드는 명시적인 호출 없이 실행된다. 즉, 특별한 진입점이 없고 코드가 로드되면 곧바로 해석되고 실행된다.

또한 반환문이 없어, 마지막 문이 실행되면 종료된다.

var 키워드로 선언한 전역 변수는 전역 객체의 프로퍼티가 된다. 이는 전역 변수의 생명 주기가 전역 객체의 생명 주기와 일치한다는 것을 말한다.

전역 객체는 코드가 실행되기 이전 단계에 자바스크립트 엔진에 의해 어떤 객체보다도 먼저 생성되는 특수한 객체다.

브라우저에서는 window, Node.js에서는 global 객체다.

전역 변수의 문제점

암묵적 결합

전역 변수를 선언한 의도는 코드 어디서든 참조하고 할당할 수 있는 변수를 사용하겠다는 것이다.

즉, 모든 코드가 전역 변수를 참조하고 변경할 수 있는 암묵적 결합(implicit coupling)을 허용하는 것이다.

긴 생명 주기

전역 변수는 생명 주기가 길다.

따라서, 메모리 리소스도 오랜기간 소비하고, 전역 변수의 상태를 변경할 수 있는 기간도 길고 기회도 많다.

스코프 체인 상에서 종점에 존재

전역 변수는 스코프 체인 상에서 종점에 존재한다.

즉, 전역 변수가 가장 마지막에 검색된다. 따라서 전역 변수의 검색 속도가 가장 느리다.

네임스페이스 오염

자바스크립트의 가장 큰 문제점 중 하나는 파일이 분리되어 있다 해도 하나의 전역 스코프를 공유한다는 점이다.

전역 변수 사용을 억제하자.

즉시 실행 함수

모든 코드를 즉시 실행함수로 감싸면 모든 변수는 즉시 실행 함수의 지역변수가 된다.

(function() {
    var foo = 10; // 즉시 실행 함수의 지역 변수
    // ...
}());

console.log(foo); // ReferenceError: foo is not defined

네임스페이스 객체

전역에 네임스페이스 역할을 담당할 객체를 만들어 전역 변수로 사용할 객체를 따로 추가한다.

var MYAPP = {}; // 전역 네임스페이스 객체
MYAPP.name = 'Lee';
console.log(MYAPP.name); // Lee

MYAPP.person = {
    name: 'Lee',
    address: 'Seoul'
};

console.log(MYAPP.person.name); // Lee

모듈 패턴

모듈 패턴은 클래스를 모방해서 관련이 있는 변수와 함수를 모아 즉시 실행 함수로 감싸 하나의 모듈을 만든다.

모듈은 클로져를 기반으로 동작한다.

클로져는 추후에 학습할 예정이다.

객체지향 프로그래밍 언어는 클래스를 구성하는 멤버에 대해 접근제한자(public, private, protected 등)를 통해 공개 범위를 한정한다. (캡슐화:정보은닉)

캡슐화(encapsulation)는 객체의 상태(state)를 나타내는 프로퍼티와 프로퍼티를 잠조하고 조작할 수 있는 동작(behavior)인 메서드를 하나로 묶는 것이다. 캡슐화는 객체의 특정 프로퍼티나 메서드를 감출 목적으로 사용하기도 하는데 이를 정보 은닉(information hiding)이라 한다.

하지만, 자바스크립트는 이런 접근 제한자가 없어, 정보 은닉을 한정적으로 구현하기 위해 모듈 패턴을 사용한다.

var Counter = (function() {
    //private 변수
    var num = 0;

    // 외부로 공개할 데이터나 메서드를 프로퍼티로 추가한 객체를 반환
    return {
        increase() {
            return ++num;
        },
        decrease() {
            return --num;
        }
    };
}());

// private 변수는 외부로 노출되지 않는다.
console.log(Counter.num); //undefined

console.log(Counter.increase()); // 1
console.log(Counter.increase()); // 2
console.log(Counter.increase()); // 3
console.log(Counter.decrease()); // 2
console.log(Counter.decrease()); // 1

ES6 모듈

ES6 모듈은 파일 자체의 독자적인 모듈 스코프를 제공한다.

즉, 모듈 내에서 var 키워드로 선언한 변수는 더는 전역 변수가 아니며 window 객체(전역 객체)의 프로퍼티도 아니다.

script 태그에 type="module" 어트리뷰트를 추가하면 로드된 자바스크립트 파일은 모듈로서 동작한다.

모듈의 파일 확장자는 mjs를 권장한다.

<script type="module" src="lib.mjs"></script>
<script type="module" src="app.mjs"></script>

ES6 모듈은 IE를 포함한 구형 브라우저에는 동작하지 않는다.

브라우저의 ES6 모듈 기능을 사용하더라도 트랜스파일링이나 번들링이 필요하기 때문에, 아직은 ES6 모듈 기능보다는 Webpack 등의 모듈 번들러를 사용하는 것이 일반적이다.

let, const 키워드와 블록 레벨 스코프

var 키워드가 문제가 있으니, let과 const라는 키워드가 등장했을 것이다.

앞서, 공부한 내용을 복습해보면 금방 알 수 있다.

변수 중복 선언 허용

var x = 1;
var y = 1;

// var 키워드 무시
var x = 100;
// 변수 선언 무시
var y;

console.log(x); // 100
console.log(y); // 1

함수 레벨 스코프

var x = 1;
if(true) {
    var x = 100;
}

console.log(x); // 100

var i = 10;

for(var i = 0; i < 5; i++) {
    console.log(i); // 0,1,2,3,4
}

console.log(i); // 5

변수 호이스팅

// 이미 foo는 선언되어 있음 (1. 선언 단계)
// foo는 undefined로 초기화 (2. 초기화 단계)
console.log(foo); // undefined

// 변수에 값을 할당(3. 할당 단계)
foo = 123;

console.log(foo); // 123

// 런타임 이전에 암묵적 실행
var foo;

let 키워드

위 var의 단점들을 ES6에서 보완한 것이 let과 const이다.

변수 중복 선언 금지

let bar = 123;
let bar = 234; // Uncaught SyntaxError: Identifier 'bar' has already been declared

블록 레벨 스코프

let foo = 1; // 전역 변수
{
    let foo = 2; // 지역 변수
    let bar = 3; // 지역 변수
{

console.log(foo); // 1
console.log(bar); // ReferenceError: bar is not defined

변수 호이스팅

var 키워드로 선언한 변수는 런타임 이전에 자바스크립트 엔진에 의해 암묵적으로 선언단계와 초기화 단계가 한번에 진행된다.

즉, 선언 단계에서 스코프에 변수 식별자를 등록해 자바스크립트 엔진에 변수의 존재를 알린다.

그리고, 즉시 초기화 단계에서 undefined 변수를 초기화한다.

따라서, 변수 선언문 이전에 변수에 접근해도 스코프에 변수가 존재하기 때문에 에러가 발생하지 않는다.

let 키워드로 선언한 변수는 선언 단계와 초기화 단계가 분리되어 진행된다.

let 키워드로 선언한 변수는 스코프의 시작 시점부터 초기화 단계 시작 지점(변수 선언문)까지 변수를 참조할 수 없다.

스코프의 시작 지점부터 초기화 시작 지점까지 변수를 참조할 수 없는 구간을 일시적 사각지대(TDZ)라고 한다.

따라서, 마치 호이스팅이 발생하지 않는 것처럼 보인다.

let foo = 1; // 전역

{
    console.log(foo); //ReferenceError
    let foo = 2; // 지역
}

만약 변수 호이스팅이 발생하지 않는다면 전역 변수 foo 값을 출력해야 한다.

그러나 let 키워드로 선언한 변수도 여전히 호이스팅이 발생하기 때문에, ReferenceError가 발생한다.

전역 객체와 let

var로 선언한 전역 변수와 전역 함수, 그리고 선언하지 않은 변수에 값을 할당한 암묵적 전역은 전역 객체 window의 프로퍼티가 된다.

let 키워드로 선언한 전역 변수는 전역 객체의 프로퍼티가 아니라, 보이지 않는 개념적인 블록(전역 렉시컬 환경의 선언적 환경 레코드)내에 존재한다.

const 키워드

const 키워드는 상수(constant)를 선언하기 위해 사용한다. 대부분은 let과 동일하다.

선언과 초기화

const 키워드로 선언한 변수는 선언과 동시에 초기화 해야한다.

let과 마찬가지로 블록 레벨 스코프를 가지며, 변수 호이스팅이 발생하지 않는 것처럼 동작한다.

재할당 금지

const 키워드로 선언한 변수는 재할당이 금지된다.

상수

상수는 재할당이 금지된 변수다. const 키워드로 선언된 변수에 원시 값을 할당한 경우 원시 값은 변경할 수 없는 값이고, const 키워드에 의해 재할당이 금지되므로 할당된 값을 변경할 방법이 없다.

const 키워드와 객체

const 키워드로 선언된 변수에 객체를 할당한 경우 값을 변경할 수 있다.

변경 가능한 값인 객체는 재할당 없이도 직접 변경이 가능하기 때문이다.

const 키워드는 재할당을 금지할 뿐 불변을 의미하지 않는다.

자바 기초부터 모던 자바까지 - 람다편

KOOCCI — Wed, 6 Jul 2022 01:09:59 +0900

목표 : 람다가 필요한 이유와 자바에서 적용된 내용을 알아본다.

이전 함수형 프로그래밍 포스트에 이어서, 람다에 대해 하나씩 알아가볼 예정이다.

자바에 람다와 함수형 프로그래밍이 왜 필요하지?

아래와 같이 정리해보고자 한다.

이름 없는 함수를 선언할 수 있다. 메서드는 반드시 특정 클래스나 인터페이스 안에 포함되어야 하고 메서드의 이름이 있어야 하지만, 람다 표현식은 이러한 제약에서 벗어난다. 즉, 유연성이 생긴다.
소스 코드의 분량이 획기적으로 줄어들 수 있다. 반복적인 작업이 필요한 기존소스의 비효율성을 낮출 수 있다.
코드를 파라미터로 전달할 수 있다. 외부에서 동작을 정의해서 메서드에 전달할 때 편리하게 사용할 수 있다.

기존의 자바에서 탈피하여 지금 우리가 람다를 공부하는 이유다.

람다 표현식을 조금더 구체적으로 알아보자.

람다는 축약이 매우 많다. 따라서 한번에 이해하기가 어려울 수 있으니, 하나씩 차근히 바꾸어 나가보려고 한다.

public static void main(String[] args) {
    //쓰레드를 생성한다.
    Thread thread = new Thread(new Runnable() {
        // run 메서드를 구현한다.
        @Override
        public void run() {
            System.out.println("Hello World");
        }
    });
}

쓰레드 프로그래밍의 Runnable 인터페이스의 run 메서드다.

익명 클래스를 이용해서 내용을 구현하고 있는 것을 볼 수 있다. (Runnable)

인터페이스를 생성자의 파라미터로 받거나 메서드의 파라미터로 받아서 처리할 때 유용하게 사용할 수 있다.

이때, 주요하게 봐야할 점은 패턴이 반복된다는 것이다.

메서드의 이름
메서드에 전달되는 파라미터 목록
메서드를 구현한 본문
메서드의 리턴 타입

위 4가지는 메서드의 필수 규격이다.

중요도로 따졌을 때, 파라미터 목록, 그리고 본문이 제일 중요하다.

그리고 리턴 타입이 중요하며 마지막으로 이름은 제일 중요하지 않다.

람다에서는 리턴 타입과 이름을 과감히 생략해버린다.

람다 표현식으로 전환해보자.

1단계 : 익명 클래스 선언 부분 제거

//쓰레드를 생성한다.
Thread thread = new Thread(
    // run 메서드를 구현한다.
    @Override
    public void run() {
        System.out.println("Hello World");
    }
);

실제로 동작하는 소스는 아니지만, new Runnable 부분을 삭제 했다.

Thread 의 생성자 인수로 들어갈 수 있는 것 유일하게 Runnable 인터페이스 혹은 이를 구현한 클래스밖에 없으니 생략이 가능하다.

2단계 : 메서드 선언 부분 제거

//쓰레드를 생성한다.
Thread thread = new Thread(
    () {
        System.out.println("Hello World");
    }
);

이 역시 실제로 동작하진 않지만, Override한 run 메소드 명과 메소드 리턴 타입을 없애버렸다.

리턴 타입이 없다면, void고, 있다면 이미 정해져 있기 때문에 생략이 가능하다.

3단계 : 람다 문법으로 정리

Thread thread = new Thread(() -> System.out.println("Hello World"));

단, 한줄로 정리되었다.

감싸고 있던 중괄호를 없애고, 세미콜론을 정리해주었다.

람다에서는 파라미터 목록을 메서드의 본문으로 전달한다는 의미로 '->'기호를 사용한다.

추가적으로 알아야 할 것은 Runnable 인터페이스의 run 메서드의 경우 입력 파라미터가 없지만, 이경우에도 ()를 남겨놔야 한다는 것이다.

순서를 다시한번 정리하자.

익명 클래스를 이용해서 메서드를 정의한다.
익명 클래스를 생성하기 위해서 선언한 인터페이스 이름 부분을 삭제한다. 삭제 후에는 메서드 선언 부분만 남는다.
메서드의 파라미터 목록과 구현한 바디 영역을 제외하고 리턴 타입, 메서드 명을 삭제한다. 삭제 후에는 파라미터 목록과 바디 영역만 남는다.
람다 문법에 맞게 '->'를 이용해서 문장을 완성한다.

형식 추론

한가지를 더 줄어보고자 한다.

인터페이스에 정의되어 있는 메서드의 파라미터 타입은 이미 정해져있거나, 제네릭을 통해 선언되어 있다.

즉, 굳이 데이터 타입을 전달할 필요가 없다.

(String a) -> System.out.println(a);
(a) -> System.out.println(a); // String 생략

위 두가지는 동일한 람다 표현식이다.

람다 표현식과 변수

지금까지는 람다 표현식에서 내부에서 선언한 변수들만 사용해 왔다.

그러나, 외부에서 생성한 변수도 참조해 사용할 수 있다.

예를 들면, 클래스에서 정의한 멤버 변수나 메서드 내부에서 생성한 로컬 변수를 참조할 수 있다.

int threadNumber = 100;
list.stream().forEach((String s) -> System.out.println(s + ", " + threadNumber));

단, 주의할 점은 외부 변수의 참조는 final 혹은 final과 유사한 조건이어야 한다.

final 키워드를 붙이지 않더라도 값이 할당된 이후에 변경될 가능성이 없다면 컴파일러는 final 변수와 동일하게 취급하며, 람다 표현식에서 활용하더라도 컴파일 오류가 발생하지 않는다.

함수형 인터페이스

함수형 프로그래밍 포스트 에서 함수형 인터페이스에 대해 간단히 설명했었지만, 조금 더 구체적으로 배워보자.

익명 클래스를 구현해야할 인터페이스는 통상적으로 여러개의 메서드를 포함하고 있다.

그에 비해 람다 표현식은 이름이 없고 단지 파라미터와 리턴 타입만으로 식별하는데 어떻게 자바 컴파일러가 이를 인식하고 인터페이스의 구현체로 컴파일 할 수 있을까?

결론은 람다 표현식을 쓸 수 있는 인터페이스는 오직 public 메서드를 하나만 가지고 있는 인터페이스여야 한다.

이를 함수형 인터페이스라 부르며, 함수형 인터페이스에서 제공하는 단 하나의 추상 메서드를 함수형 메서드라고 한다.

(default, static 메서드는 있어도 상관없다)

그리고 개발자 입장에서 람다 표현식을 쓰기 위해 매번 메서드가 하나뿐인 인터페이스를 제공해야 하는 번거로움을 없애기 위해, 가장 자주 사용할법한 패턴으로 java.util.function 패키지로 제공하고 있다.

참고로, @FunctionalInterface 어노테이션은 없어도 문제 없지만, 명시적으로 넣어주는 것이 좋다.

함수형 인터페이스의 주요 패턴은 무엇이 있을까?

인터페이스 명	메서드 명	내용
Consumer<T>	void accept(T t)	- 파라미터를 전달해서 처리한 후 결과를 리턴 받을 필요가 없을 때 사용한다. - 받기만 하고 리턴하지 않아서 Consumer(소비자)라는 이름을 사용한다.
Function<T, R>	R apply(T t)	- 전달할 파라미터를 다른 값으로 변환해서 리턴할 때 사용한다. - 주로 값을 변경하거나 매핑할 때 사용한다.
Predicate<T>	boolean test(T t)	- 전달받은 값에 대해 true/false 값을 리턴할 때 사용한다. - 주로 데이터를 필터링하거나, 조건에 맞는지 여부를 확인하는 용도로 사용한다.
Supplier<T>	T get()	- 파라미터 없이 리턴 값만 있는 경우 사용한다. - 받지는 않고 리턴만 하기 때문에 Supplier(공급자)라는 이름을 사용한다.

위 4가지에 대해서는 반드시 기억해 두도록 하자

Consumer 인터페이스

앞서 설명한 대로 소비에만 집중하는 인터페이스다. 리턴 타입도 void다.

제네릭 타입은 파라미터에 사용된다.

public class ConsumerExample {
    public static void excuteCunsumer(List<String> nameList, Consumer<String> consumer) {
        for(String name : nameList) {
            // 메서드의 두 번째 인수로 전달된 람다 표현식을 실행
            consumer.accept(name);
        }
    }
}

public static void main(String[] args) {
    List<String> nameList = new ArrayList<>();
    nameList.add("A");
    nameList.add("B");
    nameList.add("C");
    nameList.add("D");

    ConsumerExample.excuteCunsumer(nameList, new Consumer<String>() { // 람다 표현식 미사용
        @Override
        public void accept(String s) {
            System.out.println(s);
        }
    });
    ConsumerExample.excuteCunsumer(nameList, (String s) -> System.out.println(s));
    ConsumerExample.excuteCunsumer(nameList, s -> System.out.println(s)); // 형식 추론
    ConsumerExample.excuteCunsumer(nameList, System.out::println); // 참조 메소드
}

조금 헤깔릴 수 있는 사항을 정리하고 가자.

위 식에서 excuteCunsumer는 두번 째 인수로 람다 표현식을 사용중이다.

람다 표현식의 실행 결과를 메서드의 두번째 인수로 전달할 것이라고 생각해버릴 수 있다.

람다 표현식은 그 자체로 실행되는 것이 아니다.

함수형 인터페이스에 포함되어 있는 함수형 메서드의 내부 코드를 정의하는 것이다.

아래 변환 소스를 보도록 하자.

public Consumer<String> getExpression() {
    return (String name) -> System.out.println(name);
}

ConsumerExample.excuteCunsumer(nameList, getExpression());

getExpression의 리턴 타입은 Consumer 인터페이스이고, 람다 표현식을 리턴값으로 넣어주었다.

그래서 getExpression을 excuteConsumer의 두번째 인수로 넣었고 람다 표현식의 실행 결과가 리턴될 것이라 볼 경우가 있는데 그렇지 않다.

즉, 람다 표현식은 Consumer 인터페이스의 accept 메서드의 동작을 정의했을 뿐이다.

어떤 데이터가 넘어올지 모르지만, 이렇게 처리하겠다는 것이다.

Function 인터페이스

Function 인터페이스는 두 개의 제네릭 타입을 정의해야 하고, T와 R이라는 이름을 갖는다.

그리고 함수형 메서드에서는 T를 인수로 받아서 R로 리턴하는 apply 메서드를 가지고 있다.

역할은 특정한 클래스를 파라미터로 받아서 처리하고 리턴하는 형태다.

public class FunctionExample {
    public static int executeFunction(String context, Function<String, Integer> function) {
        return function.apply(context);
    }
}

public static void main(String[] args) {
    FunctionExample.executeFunction("HELLO! WELCOME TO JAVA WORLD", (String context) -> context.length());
}

apply 메서드가 어떻게 정의될지 모르지만, 전달받은 첫 번째 context문장을 처리하고, 그 결과를 리턴하는 코드가 만들어졌다.

그리고, 그 로직은 main에서 설정되어 들어가게 된다.

주로 데이터를 가공하거나 매핑하는 용도로 많이 사용하고, 비즈니스 로직에 대한 리턴 값이 필요할 때 자주 사용한다.

Predicate 인터페이스

리턴 타입 중 특별히 참/거짓 중 하나를 선택하는 bool 타입을 필요로 할 때 사용한다.

함수형 메서드는 test다. 제네릭 타입으로 선언된 객체를 파라미터로 받아서 처리한 후 참/거짓 중 하나를 리턴한다.

제네릭 타입은 파라미터에 사용된다.

public class PredicateExample {
    public static boolean isValid(String name, Predicate<String> predicate) {
        return predicate.test(name);
    }
}

public static void main(String[] args) {
    PredicateExample.isValid("", (String name) -> !name.isEmpty());
}

Supplier 인터페이스

마지막으로 Supplier 인터페이스다.

아무것도 받지 않고, return만 존재하며, 함수형 메서드는 get이다.

제네릭 타입은 리턴값에 사용된다.

public class SupplierExample {
    public static String executeSupplier(Supplier<String> supplier) {
        return supplier.get();
    }
}

public static void main(String[] args) {
    SupplierExample.executeSupplier(() -> {return "HELLO WORLD"});
}

java.util.function

이외에도 많은 인터페이스가 있지만, 정말 대부분이 위 4가지를 응용했거나, 상속받아서 구현되어 있다.

박싱/언박싱의 비용을 이름으로서 구별하는 IntConsumer, DoubleToLongFunction 등도 있고, Operator 인터페이스는 Function 인터페이스를 상속받아 구현되어 있다.

메서드 참조

함수를 메서드의 파라미터로 전달하는 것을 메서드 참조라고 한다.

매서드 참조는 람다 표현식과는 달리 코드를 여러 곳에서 재사용할 수 있고, 직접 개발한 메서드도 사용할 수 있다.

또한, 람다 표현식을 한번 더 축약할 수 있고, 코드의 가독성도 높일 수 있다.

메서드 참조는 함수형 인터페이스와 연관되어 있지만 람다 표현식을 대체하기 위한 것은 아니며 상호 보완적이다.

메서드 참조 역시 람다 표현식 처럼 결과가 아닌, 코드 자체를 전달하는 것이니 헤깔리지 말자.

(String name) -> System.out.println(name) // 람다 표현식 구문
System.out::println // 메서드 참조 구문

System 클래스의 out 객체에 있는 println 메서드를 호출한다는 뜻이다.

당연히 출력해야 할 값이 파라미터로 전달되어야 하는데, 이 때 사용하는 값은 왼편에 생략된 String name이다.

public static void main(String[] args) {
    List<String> list = new ArrayList<>();

    ...

    for(String entity : list) {
        System.out.println(entity);
    }
}

자바7까지는 위 코드가 정석적이였다.

자바 8부터는 컬렉션 프레임워크를 개선하기 위해 스트림이라는 개념을 도입했고, 스트림에는 람다 표현식과 메서드 참조를 사용할 수 있게 되었다.

list.stream().forEach((String entity) -> System.out.println(entity));
list.stream().forEach(System.out::println);

조금 더 심화 예시를 보자.

public class MethodReferenceExample {
    public static MethodReferenceExample of() {
        return new MethodReferenceExample();
    }
    
    // 데이터 처리 로직 정의
    public static void executeMethod(String entity) {
        if(entity != null && !"".equals(entity)) {
            System.out.println("Contents : " + entity);
            System.out.println("Length : " + entity.length());
        }
    }
    
    // 대문자로 변경하는 코드
    public void toUpperCase(String entity) {
        System.out.println(entity.toUpperCase());
    }
    
    // 실행하는 예
    public static void main(String[] args) {
        List<String> list = new ArrayList<>();
        list.add("a");
        list.add("b");
        list.add("c");
        
        // 정적 메서드 참조
        list.stream().forEach(MethodReferenceExample::executeMethod);
        // 한정적 메서드 참조
        list.stream().forEach(MethodReferenceExample.of()::toUpperCase);
        // 비한정적 메서드 참조
        list.stream().map(String::toUpperCase).forEach(System.out::println);
    }
}

위 예시에서 메서드 참조를 정의하는 문법은 두 가지다.

클래스명::메서드명
객체 변수명::메서드명

그리고 메서드 참조는 3가지로 구분된다.

정적 메서드 참조
비한정적 메서드 참조
한정적 메서드 참조

정적 메서드 참조

static으로 정의한 메서드를 참조할 때 사용하며 가장 일반적이다.

static 메서드는 호출할 때 객체를 생성하지 않기 때문에 명확히 확인해볼 수 있다.

Integer::parseInt
(String s) -> Integer.parseInt(s)

비한정적 메서드 참조

비한정적(unbound) 메서드 참조는 static 메서드를 참조하는 것과 유사하게 작성한다.

비한정적이라는 표현은 작성하는 구문 자체가 특정한 객체를 참조하기 위한 변수를 지정하지 않는다는 의미다.

String::toUpperCase

String 클래스의 toUpperCase 메서드는 public 메서드이며 static이 아니기 때문에 반드시 String 클래스가 객체화되어야만 호출 할 수 있다.

그러나, 마치 static 메서드를 참조하는 것처럼 정의하였다. 위 코드를 람다 표현식으로 보자.

(String str) -> str.toUpperCase()

풀어서 보면, 객체의 생성을 파라미터로 받았다. 즉, 람다 표현식 내부에서 객체 생성이 일어났기 때문에 객체를 참조할만한 변수가 외부에 존재하지 않는다.

만약, 처리해야 하는 데이터가 여러개라면 조금 복잡해질 수 있다.

List에서 연속된 2개의 데이터를 뽑아서 크기를 구하는 방식을 작성하면 다음과 같다.

List<String> list = new ArrayList<>();

...
list.stream().sorted((String a, String b) -> a.compareTo(b));
list.stream().sorted(String::compareTo); // 위와 동일

매우 함축적이라, 이해하고 해석하는데 어려울 수 있다.

한정적 메서드 참조

한정적(bound)이라는 단어를 사용한 이유는 참조하는 메서드가 특정 객체의 변수로 제한되기 때문이다.

Calendar.getInstance()::getTime

Calendar cal = Calendar.getInstance();
() -> cal.getTime()

Calendar cal = Calendar.getInstance(); // 객체 생성
cal::getTime // 메서드 참조 구문. cal 변수를 참조

자바8 이후 많은 클래스가 생성자를 이용한 객체 인스턴스화 보다는, of 와 같은 메서드로 생성하는 경향이 많다.

이러한 경우, 한 줄 소스로 메서드 참조를 정의할 수 있다.

그러나 매번 instance를 만들 수 있으므로, 외부에 한번 생성하고, 재활용하는 경우가 많다.

한정적 메서드 참조와 비한정적 메서드 참조의 차이는 다음과 같다.

한정적 메서드 참조는 외부에서 정의한 객체의 메서드를 참조할 때 사용하며, 비한정적 메서드 참조는 람다 표현식 내부에서 생성한 객체의 메서드를 참조할 때 사용한다.

생성자 참조

생성자는 메서드와 엄연히 다르다.

return이 없으며, 객체 생성 시에만 사용되고 객체 생성 시, 초기화의 개념을 가진다.

생성자 참조는 아래 문법을 가진다.

클래스명::new

람다 표현식 조합

마지막으로 한가지만 더 알아볼 것이다.

람다 표현식은 예전 재귀 호출과 같은 작업으로 진행했던, 마치 파이프라인 명령어처럼 기능을 조합하고 연결할 수 있다.

Consumer 조합

Consumer<String> consumer = System.out::println;
Consumer<String> andThen = text -> System.out.println("text length : " + text.length());
consumer.andThen(andThen).accept("JAVA");

JAVA
text length : 4

Consumer 인터페이스에 들어가보면, andThen이라는 default 메서드가 있다. (함수형 메서드는 accept다)

그리고 실행 결과를 보면, 두가지 Consumer가 순차적으로 호출됨을 볼 수 있다.

호출되고 처리되는 순서를 보도록 하자.

accept 메서드에 "JAVA" 문자열을 파라미터로 전달하여 함수형 인터페이스를 실행
첫번째 람다 구문이 실행
두번째 람다 구문이 실행

이건 Consumer 인터페이스의 함수형 메서드의 리턴타입이 void라서 그렇다.

즉, 리턴값을 그대로 받아서 처리하지 않고, 마치 두개의 Consumer를 연속해서 실행한 것과 동일한 결과를 준다.

Predicate 조합

Predicate 인터페이스에도 Consumer의 andThen처럼 어떤 메서드들이 있는지 보면, and/or와 같이 참/거짓 판별에 사용하는 메서드들이 있다. 즉, 여러 개의 참과 거짓에 대한 조건식을 합친다는 것이다.

public class Person {
    private String name;
    private String sex;
    private int age;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getSex() {
        return sex;
    }

    public void setSex(String sex) {
        this.sex = sex;
    }

    public int getAge() {
        return age;
    }

    public void setAge(int age) {
        this.age = age;
    }
}

public class PredicateAndExample {
    public static Predicate<Person> isMale() {
        return (Person p) -> "male".equals(p.getSex());
    }

    public static Predicate<Person> isAdult() {
        return (Person p) -> p.getAge() > 20;
    }
}

public static void main(String[] args) {
    Predicate<Person> isMan = PredicateAndExample.isMale();
    Predicate<Person> isAdult = PredicateAndExample.isAdult();
    Predicate<Person> isManNAdult = isMan.and(isAdult);

    Person p = new Person();
    p.setAge(21);
    p.setName("ASD");
    p.setSex("male");

    System.out.println(isManNAdult.test(p));

}

첫번째로, 람다 표현식을 별도의 static 메서드로 정의해둔 것을 집중하자.

이런 형태의 개발 방향이 가독성을 높여준다.

두번째로, 람다 표현식의 조합은 반드시 지켜야 하는 규정이 있는데, 두 함수형 인터페이스의 제네릭 타입이 동일해야 한다는 것이다.

따라서, 위 예제는 객체로 별도로 만들어 비교해둔 것이다.

Function 조합

Function 인터페이스에도 andThen 이 있지만, Consumer 인터페이스와는 많이 다르다.

public static void main(String[] args) {
    Function<String, Integer> parseIntFunction = (String str) -> Integer.parseInt(str) + 1;
    Function<Integer, String> intToStrFunction = (Integer i) -> "String : " + i;

    System.out.println(parseIntFunction.apply("1000"));
    System.out.println(intToStrFunction.apply(1000));
    System.out.println(parseIntFunction.andThen(intToStrFunction).apply("1000"));
}

1001
String : 1000
String : 1001

눈치 챘겠지만, andThen으로 연결되는 제네릭 타입 두가지에 대해, 파라미터, 리턴타입이 잘 연결될 수 있는 형태가 되어야 한다. (String -> Integer -> String)

또, Function이 지원하는 compose라는 메서드가 있다.

public static void main(String[] args) {
    Function<String, Integer> parseIntFunction = (String str) -> Integer.parseInt(str) + 1;
    Function<Integer, String> intToStrFunction = (Integer i) -> "String : " + i;

    System.out.println(parseIntFunction.apply("1000"));
    System.out.println(intToStrFunction.apply(1000));
    System.out.println(intToStrFunction.compose(parseIntFunction).apply("1000"));
}

compose는 뒤에서 앞으로 호출된다고 보면 된다.

다음 포스팅에서는 본격적으로 스트림에 대해 알아볼 예정이다.

지금까지 공부한 함수형 인터페이스가 자바에서 어떻게 쓰였는지 알아볼 수 있을 것이다.

[java] House Robber

KOOCCI — Tue, 5 Jul 2022 23:00:46 +0900

[참고문제] : https://leetcode.com/problems/house-robber/

House Robber - LeetCode

Level up your coding skills and quickly land a job. This is the best place to expand your knowledge and get prepared for your next interview.

leetcode.com

문제 풀이

DP 문제다.

점화식을 찾기 위해서 나열해보자.

이번에도 꽤 많이 나열해보았다.

생각의 흐름 - 초깃값 찾기

이번에도 초깃값부터 찾아보았다.

arr[n] 부터 생각해보았으나, 역시 최초 1일때부터 고민하는 것이 나았다.

6번째 정도 적어보니, 이전에 적어둔 식들이 다시 쓰이기 시작했다.

현재 들어온 값과 2칸전에 확인한 MAX값을 더하거나, 1칸 전의 MAX값을 비교하는 것이다.

public int rob(int[] nums) {
    int arr[] = new int[101];

    int len = nums.length;
    if(len == 1)
        return nums[0];
    else if(len == 2)
        return Math.max(nums[0], nums[1]);
    else if(len == 3)
        return Math.max(nums[0] + nums[2], nums[1]);
    else if(len == 4)
        return Math.max(Math.max(nums[0] + nums[2], nums[1] + nums[3]), nums[0] + nums[3]);
    arr[0] = nums[0];
    arr[1] = Math.max(nums[0], nums[1]);
    arr[2] = Math.max(nums[0] + nums[2], nums[1]);
    arr[3] = Math.max(Math.max(nums[0] + nums[2], nums[1] + nums[3]), nums[0] + nums[3]);

    for(int i = 4; i < len; i++) {
        arr[i] = Math.max(arr[i-2] + nums[i], arr[i-1]);
    }
    return arr[len-1];
}

수정

그렇게 많은 작업을 할 필요 없다.

class Solution {
    public int rob(int[] nums) {
        int[] dp = new int[nums.length];       
        if(nums.length == 1)
            return nums[0];
        else if(nums.length == 2) {
            return nums[0] > nums[1] ? nums[0]:nums[1];
        }
        else {
            dp[0] = nums[0];
            dp[1] = nums[0] > nums[1] ? nums[0]:nums[1];

            for(int i = 2; i < nums.length; i++) {
                dp[i] = Math.max(dp[i-1], dp[i-2] + nums[i]);
            }

            return dp[nums.length - 1]; 
        }
    }
}

[java] Climbing Stairs

KOOCCI — Tue, 5 Jul 2022 22:35:45 +0900

[참고문제] :https://leetcode.com/problems/climbing-stairs/

Climbing Stairs - LeetCode

Level up your coding skills and quickly land a job. This is the best place to expand your knowledge and get prepared for your next interview.

leetcode.com

문제 풀이

DP문제다.

DP는 일단 규칙찾기, 점화식 찾기다. 못찾으면 끝나는 문제라고 할 수 있다.

생각의 흐름 - 초기값들을 찾자.

문제에서 보이듯, n = 1, n = 2, n = 3일 때를 보여주고 있다.

점화식 문제처럼 초기값들을 먼저 설정해보자.

생각의 흐름 - 일단 적어보자.

바로 안보이면, 난 일단 적어본다. 생각날 때까지 적다보면, 규칙이 보인다.

이번에도 n=6정도까지 적어보니, 금방 규칙이 보였다.

public int climbStairs(int n) {
    int[] arr = new int[45];

    arr[1] = 1;
    arr[2] = 2;
    if(n == 1) {
        return 1;
    }

    else if(n == 2) {
        return 2;
    }

    else {
        for(int i = 3; i <= n; i++) {
           arr[i] = arr[i-1] + arr[i-2];
        }
    }

   return arr[n];
}

[java] Flood Fill

KOOCCI — Mon, 4 Jul 2022 22:26:52 +0900

[참고문제] :https://leetcode.com/problems/flood-fill/

Flood Fill - LeetCode

Level up your coding skills and quickly land a job. This is the best place to expand your knowledge and get prepared for your next interview.

leetcode.com

문제 풀이

어려운 문제는 아니며, 기초를 다지기 위해 풀어보았다.

생각의 흐름 - 보자마자 떠올라야 한다.

BFS혹은 DFS 문제임을 알아야 한다.

이차원 배열과 queue, 그리고 적절한 Pair와 같은 자료구조가 필요하다.

java에서는 pair와 같은게 없기 때문에, Node라는 class를 만들어 써보자.

생각의 흐름 - 조건을 명확히 보자

image[sr][sc] 로 인해 넘치는 부분들을 찾아나가야 한다.

채우고자 하는 값(fill)을 명확히 하고, index 들의 제한 범위를 잘 고려하자

생각의 흐름 - visited 체크가 필요하다.

그냥 돌려보았더니, 갔던 길을 계속 다시 가는걸 발견했다.

이런 부분을 놓치는 경우가 많으니 항상 기초부터 다지도록 하자.

public int[][] floodFill(int[][] image, int sr, int sc, int color) {
    int N = image.length;
    int M = image[0].length;
    Queue<Node> que = new LinkedList<>();
    int[][] isVisited = new int[N][M];
    int fill = image[sr][sc];
    que.add(new Node(sr,sc));
    while(!que.isEmpty()) {
        Node node = que.poll();
        if(isVisited[node.row][node.col] != -1) {
            isVisited[node.row][node.col] = -1;
            image[node.row][node.col] = color;
            if(node.row -1 >= 0 && image[node.row -1][node.col] == fill)
                que.add(new Node(node.row -1, node.col));
            if(node.row+1 <= N -1 &&  image[node.row +1][node.col] == fill)
                que.add(new Node(node.row +1, node.col));
            if(node.col -1 >= 0 && image[node.row][node.col-1] == fill)
                que.add(new Node(node.row, node.col-1));
            if(node.col+1 <= M -1 &&  image[node.row][node.col+1] == fill)
                que.add(new Node(node.row, node.col+1));
        }
    }
    return image;
}

class Node {
    int row;
    int col;
    Node(int row, int col) {
        this.row = row;
        this.col = col;
    };
}

[java] Longest Substring Without Repeating Characters

KOOCCI — Mon, 4 Jul 2022 21:12:03 +0900

[참고문제] : https://leetcode.com/problems/longest-substring-without-repeating-characters/\

Longest Substring Without Repeating Characters - LeetCode

Level up your coding skills and quickly land a job. This is the best place to expand your knowledge and get prepared for your next interview.

leetcode.com

문제 풀이

MAP을 써야 하는 문제라는 걸 인식했다.

생각의 흐름 - MAP을 어떻게 구성할까?

인덱스를 갖고 있어야 한다고 생각했다. 똑같은게 나왔을 때, 기존 인덱스를 어떻게든 활용해야 한다고 생각했다.

생각의 흐름 - 현재의 흐름과 최대값의 흐름을 별도로 가져가야 한다.

최대값은 반환값을 위해, 그리고 계산을 위해 현재 값도 갖고 가면서 비교해야 한다고 판단했다.

생각의 흐름 - if문을 어떻게 구성할까?

MAP에 있는지 없는지를 비교하는건 자명했다.

MAP에 없을 때는 값을 넣어주어야 하고 현재 길이를 늘린다.

MAP에 있을 때가 주요한 것으로 보였다.

이미 MAP에 있다면 현재 크기와 최대값을 비교해서 저장해야 했다.

그렇다면, 그 이후는 어디부터 계산해야할까?

단순히 계속 나가는 건 advdf 와 같은 예시에서 틀리기 마련이다.

바로 이전에 나온 위치. 즉, 앞서 고민했던 기존 인덱스 다음부터 계산을 했어야 한다.

그럼 어떻게 돌아가야 할까? i를 그냥 돌려버리면 된다.

생각의 흐름 - return 값은?

누락해버린 것이 있었다.

currLen을 maxLen과 비교안해버리는 경우가 있었다.

이를 최종적으로 처리해준다.

public int lengthOfLongestSubstring(String s) {
    Map<Character, Integer> map = new HashMap<>();
    int maxLen = 0;
    int currLen = 0;
    int len = s.length();
    for(int i = 0; i < len; i++) {
        char curr = s.charAt(i);
        if(!map.containsKey(curr)) {
            map.put(curr, i);
            currLen ++;
        } else {
            maxLen = Math.max(maxLen, currLen);
            i = map.get(curr);
            currLen = 0;
            map.clear();
        }
    }
    return Math.max(maxLen, currLen);
}

자바스크립트 기초부터 모던 자바스크립트까지 - 함수편

KOOCCI — Mon, 4 Jul 2022 01:12:16 +0900

목표 : 자바스크립트의 함수에 대해 알아본다.

자바스크립트에서 가장 중요한 개념이다.

스코프, 실행 컨텍스트, 클로저, this, 프로토타입, 모듈화 등 모두 함수에서부터 시작된다.

프로그래밍 언어에서 함수는 일련의 과정을 문(statement)으로 구현하고 코드 블록으로 감싸서 하나의 실행 단위로 정의한 것이다.

간단히 용어를 정리해보자.

매개변수(parameter) : 함수 내부로 입력을 전달받는 변수
인수 (argument) : 입력
출력 (return value) : 출력

function add(x, y) { // parameter
	return x+y; // return value
}

add(2,5); // argument

함수 리터럴

자바스크립트의 함수는 객체 타입의 값이다. 따라서 숫자 값을 숫자 리터럴로 생성하고 객체를 객체 리터럴로 생성하듯, 함수도 함수 리터럴로 생성할 수 있다.

var f = function add(x, y) {
	return x+y;
}

위 예제를 보면 함수 리터럴을 변수에 할당하고 있다.

리터럴 정의는 이전 포스팅에서 다루었다. 리터럴은 값을 생성하기 위한 약속된 표기법이다.

함수 리터럴도 평가되어 값을 생성하며, 이 값은 객체다. 즉, 함수는 객체다.

다른 점은 일반 객체는 호출할 수 없지만, 함수는 호출할 수 있다.

함수 정의

함수를 정의하는 방법은 4가지가 있다.

// 1. 함수 선언문
function add(x,y) {
	return x+y;
}

// 2. 함수 표현식
var add = function(x,y) {
	return x+y;
}

// 3. Function 생성자 함수
var add = new Function('x', 'y', 'return x+y');

// 화살표 함수 (ES6)
var add = (x,y) => x+y;

함수 선언문

함수 선언문은 함수 리터럴과 형태가 동일하다.

단, 함수 리터럴은 함수 이름을 생략할 수 있으나 함수 선언문은 함수 이름을 생략할 수 없다.

함수 선언문은 표현식이 아닌 문(statement)이다.

이전 포스팅 내용처럼 값으로 평가할 수 있는 문이 표현식이다.

즉, 값으로 평가할 수 없다는 것이다. 실제로, 위 함수 선언문을 개발자 환경에서 실행하면 undefined가 나온다.

표현식이라면 그 값이 찍혀야 한다.

그런데 조금 이상한 경우가 있다.

var add = function add(x,y) {
	return x+y;
}

console.log(add(3,5)); // 7

분명 표현식이 아닌 문인데, 변수에 들어가는 것처럼 보인다.

이는 자바스크립트 엔진의 해석차이다.

엔진에서 위 식을 함수 리터럴로 볼수도 있고, 표현식이 아닌 문으로 볼 수도 있다.

중이적인 표현이 된다는 것이다.

즉 위 예시에서는 함수 리터럴로 판단하였고, 정상적인 방식으로 정의 된 것이다.

function foo() { console.log('foo')};
foo(); // foo

(function bar() { console.log('bar'); });
bar(); // ReferenceError: bar is not defined

foo는 함수 선언문으로 해석되었다.

그러나, 그룹 연산자()안에 들어간 bar는 함수표현식으로 해석된 것이다.

그룹연산자에는 값으로 평가될 수 있는 표현식만 들어갈 수 있다.

또한, 함수 리터럴에서는 함수명이 내부에서만 쓸수 있는 식별자다.

외부에서는 함수 리터럴의 함수명을 호출 할 수 없다. 따라서, 외부에서는 bar라는 존재를 알지 못하게 된다.

그런데 foo를 호출할 수 있었던 이유는 무엇인가?

함수 리터럴의 함수명은 외부에서 호출 할 수 없는데, 함수 선언문은 예외인것일까라고 생각할 수 있다.

자바스크립트 엔진은 생성된 함수를 호출하기 위해 함수 이름과 동일한 이름의 식별자를 암묵적으로 생성하고, 거기에 함수 객체를 할당한다.

즉, 우리는 함수 이름으로 호출하는 것처럼 보였지만 사실은 함수 객체를 가리키는 식별자로 호출하는 것이다.

var add = function add(x,y) { // 식별자add와 함수이름 add를 구분하자
	return x+y;
};

console.log(add(2,5)); // 7, 식별자 add다.

함수 표현식

자바스크립트 함수는 객체 타입의 값이라고 앞서 설명하였다.

즉, 값처럼 변수에 할당하거나 프로퍼티가 되거나 배열이 될 수 있다.

이렇게 값의 성질을 갖는 객체를 일급 객체라고 한다.

일급 객체이므로, 함수 리터럴로 생성한 함수 객체를 변수에 할당할 수 있다. 이런 함수 정의 방식을 함수 표현식이라 한다.

함수 리터럴의 함수 이름은 생략할 수 있고, 이를 익명 함수라 한다.

함수 표현식의 함수 리터럴은 함수 이름을 생략하는 것이 일반적이다.

함수 생성 시점과 함수 호이스팅

//함수 참조
console.dir(add); // f add(x,y)
console.dir(sub); // undefined

//함수 호출
console.log(add(2,5)); // 7
console.log(sub(2,5)); // TypeError

//함수 선언문
function add(x,y) {
	return x+y;
}

//함수 표현식
var sub = function(x,y) {
	return x-y;
}

위 예시의 특징을 분석해보면 다음과 같다.

함수 선언문으로 정의한 함수는 함수 선언문 이전에 호출할 수 있다.
함수 표현식으로 정의한 함수는 함수 표현식 이전에 호출할 수 없다.

즉, 함수 선언문으로 정의한 함수와 함수 표현식으로 정의한 함수의 생성 시점이 다르다.

함수 선언문도 다른 선언문(변수 선언 등)과 동일하게 코드가 한 줄씩 순차적으로 실행되는 시점인 런타임 이전에 자바스크립트 엔진에 의해 먼저 실행된다.

함수 선언문이 코드의 선두로 끌어올려진 것처럼 동작하는 자바스크립트 고유의 특징을 호이스팅이라고 한다.

단, 함수 호이스팅과 변수 호이스팅은 약간의 차이가 있다.

var 키워드를 통한 변수 선언문과 함수 선언문은 런타임 이전에 엔진에 의해 먼저 실행되어 식별자를 생성하는 건 동일하다.

하지만 var 키워드로 선언된 변수는 undefined로 초기화되고, 함수 선언문을 통해 암묵적으로 생성된 식별자는 함수 객체로 초기화된다.

즉, 함수 선언문으로 정의한 함수를 함수 선언문 이전에 호출하면 함수 호이스팅에 의해 호출이 가능하다

함수 표현식은 변수에 함수 리터럴이 할당되는 문이다.

변수 할당문의 값은 할당문이 실행되는 시점, 즉 런타임에 평가되므로 함수 표현식의 함수 리터럴도 할당문이 실행되는 시점에 평가되어 함수 객체가 된다.

즉, 함수 표현식으로 함수를 정의하면 함수 호이스팅이 발생하는 것이 아니라 변수 호이스팅이 발생한다.

Function 생성자 함수

매개변수 목록과 함수 몸체를 문자열로 전달 받아 new로 생성이 가능하다. (new가 없어도 가능하다)

일반적이지도 않고, 바람직한 방법도 아니다.

추후 알아볼 클로저를 생성하지 않는 등, 앞서 알아본 것들과 다르게 동작한다.

화살표 함수

ES6에 도입되었으며, 항상 익명함수로 정의한다.

표현만 간략한게 아니라, 내부 동작 또한 간략화되어 있어 함수 선언문 혹은 함수 표현식을 완전히 대체하지는 못한다.

그 특징을 간략히 알아보고, 추후에 다시한번 만나보도록 하자.

생성자 함수로 사용할 수 없다.
기존 함수와 this 바인딩이 다르다.
prototype 프로퍼티가 없다.
arguments 객체를 생성하지 않는다.

함수의 호출

매개변수(parameter)와 인수(argument)

함수가 호출되면 함수 몸체 내에 암묵적으로 매개변수가 생성되고 일반 변수와 마찬가지로 undefined로 초기화된 이후 인수가 순서대로 할당된다.

그리고 별도로 알아보겠지만, 매개변수의 스코프(유효 범위)는 함수 내부다.

또한, 매개변수의 갯수와 인수의 갯수는 같은지 체크하지 않는다.

매개변수가 인수보다 많다면, 할당되지 않은 매개변수에는 undefined가 들어가게 되며, 초과된 인수는 암묵적으로 arguments 객체의 프로퍼티로 보관된다.

타입이 없는 자바스크립트에서는 어떤 타입이 파라미터로 전달되는지 알지 못한다.

이를 방지하기 위해 타입스크립트같은 정적 타입 선언 언어를 사용하기도 한다.

참조에 의한 전달과 외부 상태의 변경

함수 파라미터로 객체를 받을 때 주의해야 할 점은 참조의 의한 전달이 있다는 것이다.

원시 타입은 변경이 불가능 하니, 파라미터에서 재할당을 통해 새로운 원시값으로 교체하여 기존 값의 변경이 되지 않는다.

그러나 객체 타입으로 인수를 받는다면, 참조 값이 복사되어 원본에도 영향이 간다.

다양한 함수의 형태

즉시 실행 함수

함수의 정의와 동시에 즉시 실행되는 함수다.

단 한번만 호출되며 다시 호출할 수 없다.

(function() {
    var a = 1;
    var b = 2;
    return a+b;
}());

보통 이름없는 익명함수를 사용한다. (있어도, 사용할 수 없다)

즉시 실행함수는 반드시 그룹 연산자로 감싸야 한다. 그렇지 않으면 에러가 발생한다.

function() { //Uncaught SyntaxError: Function statements require a function name
    var a = 1;
    var b = 2;
    return a+b;
}();

위 에러가 나는 이유는 함수 정의가 함수 선언문에 맞지 않기 때문이다. (이름을 생략할 수 없다)

그럼 이름을 넣어보자.

function foo() { //Uncaught SyntaxError: Unexpected token ')'
    var a = 1;
    var b = 2;
    return a+b;
}();

에러 내용이 바뀌었다.

자바스크립트 엔진은 암묵적으로 수행하는 세미콜론 자동 삽입 기능으로, 함수 선언문 이후에 자동으로 세미콜론을 넣게 된다. (함수 코드 블록의 닫는 중괄호 뒤)

function foo(){}(); // function foo(){};();

함수 선언문 뒤의 ()는 함수 호출 연산자가 아닌 그룹 연산자로 해석된다. 따라서, 그룹 연산자에 피연산자가 없어 에러가 나는 것이다.

그룹 연산자의 피연산자는 값으로 평가되므로, 기명 또는 무명 함수를 그룹 연산자로 감싸면 함수 리터럴로 평가되어 함수 객체가 된다.

즉, 그룹 연산자로 묶는 이유는 먼저 함수 리터럴을 평가해서 함수 객체를 생성하기 위해서다.

따라서 함수 객체를 생성할 수 있으면, 다른 연산자를 사용해도 된다.

(function() {
	// ...
}());

(function() {
	// ...
})();

!function() {
	// ...
}();

+function() {
	// ...
}();

중첩 함수

함수 내부에 정의된 함수를 중첩 함수(Nested Function) 또는 내부 함수(Inner Function) 이라고 한다.

중첩 함수는 외부 함수 내부에서만 호출 할 수 있다.

일반적으로 중첩 함수는 자신을 포함하는 외부 함수를 돕는 헬퍼 함수(Helper Function) 역할을 한다.

function outer() {
    var x = 1;

    // 중첩 함수
    function inner() {
        var y = 2;
        // 외부 함수의 변수를 참조할 수 있다.
        console.log(x+y); // 3
    }

    inner();
};

outer();

ES6부터 함수 정의는 문이 위치할 수 있는 문맥이면 어디든 가능하다. (if 문이나 for문 내에서도 가능하다.)

단, 호이스팅으로 혼란이 올 수 있으므로, if문이나 for 문 등의 코드 블록에서 함수 선언문을 통해 함수를 정의하는 것은 바람직하지 않다.

중첩 함수는 이후 스코프나 클로져를 배울 때 한번 더 보도록 하자.

콜백 함수

함수의 매개변수를 통해 다른 함수의 내부로 전달되는 함수를 콜백 함수라고 하며, 매개 변수를 통해 함수의 외부에서 콜백함수를 전달받는 함수를 고차 함수라고 한다.

중첩 함수는 고정되어 있어 교체하기 곤란하지만, 콜백 함수는 함수 외부에서 고차 함수 내부로 주입하기 때문에, 자유로운 교체가 가능하다. 즉, 고차 함수는 콜백 함수를 자신의 일부분으로 합성한다.

고차 함수는 매개변수를 통해 전달받은 콜백 함수의 호출 시점을 결정해 호출한다.

즉, 고차함수에 의해 호출되며 이 때, 고차 함수는 필요에 따라 콜백 함수에 인수를 전달할 수 있다.

function repeat(n, f) {
    for(var i = 0; i < n; i++) {
        f(i);
    }
};

var logAll = function(i) {
	console.log(i);
};

repeat(5, logAll);

순수 함수와 비순수 함수

함수형 프로그래밍에서 어떤 외부 상태에 의존하지도 않고 변경하지도 않는, 즉 부수 효과(Side Effect)가 없는 함수를 순수함수라고 한다.

순수 함수는 동일한 입력이면 동일한 결과를 반환한다.

함수형 프로그래밍은 순수함수와 보조 함수의 조합을 통해 외부 상태를 변경하는 부수 효과를 최소화해서 불변성을 지향하는 프로그래밍 패러다임이다.

로직 내 존재하는 조건문과 반복문을 제거해서 복잡성을 해결하고, 변수 사용을 억제하거나 생명주기를 최소화해서 상태 변경을 피해 오류를 최소화하는 것을 목표로 한다.

다음에는 스코프에 대해 배워보도록 하자.

자바스크립트 기초부터 모던 자바스크립트까지 - 객체편

KOOCCI — Sun, 3 Jul 2022 17:04:21 +0900

목표 : 자바스크립트의 객체가 무엇인지 알아본다.

자바스크립트의 이해를 위해 중요한 부분인 함수&스코프를 이해하기 위해서는 객체부터 들어가야 한다.

따라서, 객체의 성질을 먼저 확인한 후 조금씩 확장해 보도록 하자.

객체란?

자바스크립트는 객체(Object)기반의 프로그래밍 언어이며, 자바스크립트를 구성하는 대의 대부분이 객체다.

원시 값을 제외한 나머지 (함수, 배열, 정규 표현식 등) 모두 객체로 이루어져있다.

원론적인 개념이 아니라 자바스크립트에서 객체는 다양한 타입의 값(원시 값 또는 다른 객체)을 하나의 단위로 구성하는 복합적인 자료구조(Data Structure)다. (원시 값은 단 하나의 값만 나타낸다)

또한, 원시 값은 변경 불가능한 값이지만, 객체타입의 값, 즉 객체는 변경 가능한 값이다. (변수를 변경하지 못하는 것이 아니라, 값 자체를 의미한다. 변수는 재할당이 가능하다.)

즉, 원시 값은 pass by value이지만, 객체타입은 pass by reference 이다.

객체는 0개 이상의 프로퍼티로 구성된 집합이고, 프로퍼티는 Key: Value로 이루어진다.

프로퍼티 : 객체의 상태를 나타내는 값(Data)
메서드 : 프로퍼티(상태 데이터)를 참조하고 조작할 수 있는 동작(Behavior)

자바스크립트에서 사용할 수 있는 모든 값은 프로퍼티 값이 될 수 있고, 자바스크립트의 함수는 일급 객체이므로 값으로 취급이 가능하다.

즉, 함수도 프로퍼티가 가능하다. 이 때, 프로퍼티로서의 함수는 메서드라고 명명한다.

객체의 생성

클래스 기반의 다른 객체 지향 언어에서는 new와 같은 키워드를 통해 사전에 정의된 클래스의 생성자로 인스턴스를 생성한다.

자바스크립트는 객체 생성방법이 다양하며, 그 리스트는 아래와 같다.

객체 리터럴
Object 생성자 함수
생성자 함수
Object.create 메서드
클래스(ES6)

가장 대중적인 방법은 객체 리터럴이다.

객체 리터럴은 중괄호 내에 0개 이상의 프로퍼티를 정의한다.

var person = {
    name: 'Lee',
    sayHello: function() {
        console.log(`Hello: My name is ${this.name}.`);
    }
}

console.log(typeof person); // object
console.log(person); //{name: 'Lee', sayHello: f}

몇가지 문법을 하기 예시로 대체한다.

var person = {
    name: 'Lee',
    'last-name': 'foo', // 네이밍 규칙을 준수하지 않을 경우 사용 방법
    sayHello: function() {
        console.log(`Hello: My name is ${this.name}.`);
    }
}

console.log(person.name); // 접근 방법 1
console.log(person['name']); // 접근 방법 2

person.age = 20; // 동적 프로퍼티 생성
delete person.age; // 프로퍼티 삭제

//ES6
let x = 1, y = 2;
const obj = {x, y}; // 변수 이름과 프로퍼티 키가 동일할 때, 프로퍼티 키를 생략할 수 있다.
console.log(obj); // {x: 1, y: 2}

//ES5
var prefix = 'prop';
var i = 0;

var obj = {};

obj[prefix + '-' + ++i] = i;
obj[prefix + '-' + ++i] = i;
obj[prefix + '-' + ++i] = i;

console.log(obj); // {prop-1: 1, prop-2: 2, prop-3: 3}

//ES6
const prefix = 'prop';
let i = 0;

const obj = {
    [`${prefix}-${++i}`]: i,
    [`${prefix}-${++i}`]: i,
    [`${prefix}-${++i}`]: i
};

console.log(obj); // {prop-1: 1, prop-2: 2, prop-3: 3}

//ES6
var person = {
    name: 'Lee',
    sayHello() {
        console.log(`Hello: My name is ${this.name}.`);
    } // function을 축약하여 표현할 수 있다. 단, 다르게 동작하는 면이 있으므로, 추후에 알아보자
}

객체에 존재하지 않는 프로퍼티에 접근하면, undefined를 반환한다. 즉, ReferenceError가 발생하지 않으니 주의해야 한다.

또한, delete는 없는 프로퍼티라도 에러를 뱉지 않는다.

문자열의 경우는 조금 특이한 점이 있다.

var str = 'hello';
str = 'world';

str은 변수이므로 재할당이 가능하다.(문자열 변경이 아니다)

그런데 문자열은 유사 배열 객체라고 하여 이터러블하여 배열과 유사하게 각 문자에 접근이 가능하다.

var str = 'string';

console.log(str[0]); // s
console.log(str.length); // 6
console.log(str.toUpperCase()); // STRING

str[0] = 'S'; // 문자열 자체는 원시 타입으로 변경이 불가능 하다.
console.log(str); // string

위처럼 원시타입이라 변경은 불가능하지만, 접근은 가능하다.

참조에 의한 전달

앞서, 원시 값은 pass by value이며 객체는 pass by reference라고 했다.

원시 값은 변경이 불가능하므로, 변수의 값을 변경하는 것은 재할당밖에 없다.

그러나 객체는 재할당 없이 변경이 가능하다. 동적 프로퍼티 추가나 갱신, 삭제가 가능하다.

새로운 공간을 만들고, 그곳을 바라보도록 재할당하는 원시타입과 달리, 메모리에 저장된 객체를 직접 수정할 수 있다는 것으로, 변수에 할당된 변수의 참조 값은 변경되지 않는다.

이는 여러 개의 식별자가 하나의 객체를 공유할 수 있다는 것이다.

따라서, 얕은 복사, 깊은 복사 문제가 나오기도 한다.

const o = {x : {y: 1}};

const c1 = { ...o };
console.log(o === c1); // false;
console.log(o.x === c1.x); // true; // 같은 것을 바라본다. (얕은 복사)

var person = {
	name: 'Lee'
}

var copy = person;

console.log(copy === person); // true
copy.name = 'foo';
person.address = 'Seoul'; // 프로퍼티 추가

console.log(copy); // {name: 'foo', address: 'Seoul'}
console.log(person); // {name: 'foo', address: 'Seoul'}

자바 기초부터 모던 자바까지 - 함수형 프로그래밍 편

KOOCCI — Sun, 3 Jul 2022 15:55:54 +0900

목표 : 자바에서의 함수형 프로그래밍에 대해 알아본다.

왜 함수형 프로그래밍이 도입되기 시작했을까?

객체 지향 프로그래밍의 정수였던 java에서 왜 새로운 패러다임을 도전하게 된 것일까?

결국에는 애플리케이션의 요구 조건 변경에 대응하는 절차였다.

먼저 그 흐름을 따라가 보도록 하자

여행 정보를 조회하는 클래스가 있다.

국가명을 통해 조회하며, 그 결과를 리스트로 제공한다.

SearchTravel 이라는 이 클래스에는 searchTravelInfo(String country) 라는 메소드로 이를 제공하고 있었다.

새로운 요구사항이 등장했다.

국가명도 제공해야하지만, 도시명으로도 제공해야했다.

그에 따라 2가지 변경 방안이 등장하게 된다.

도시 정보를 파라미터로 받아서 처리할 수 있는 메서드를 추가한다.
1. searchTravelInfo를, searchTravelInfoByCountry로 변경한다.
2. searchTravelInfoByCity를 추가한다.
기존 메서드에 파라미터를 추가한다.
1. searchTravelInfo(String country)를 searchTravelInfo(String searchType, String searchValue) 로 변경해, 로직으로 구분한다.
2. 함수 내부에서 searchType에 따라, 국가명 혹은 도시명을 검색하도록 한다.

문제점은 동일하게 등장한다.

새로운 요구사항이 등장할 때 마다, 메소드를 늘리거나, 논리적 구분 소스를 추가해야 한다.

그러나 AND 요건 OR 요건 등에 따라 결국 또다른 문제가 등장하게 된다.

인터페이스로 대응

AND 조건 등이 등장함에 따라 결국에는 이리저리 유지보수하면서 개발할 수는 있다.

그러나 유연한 대처를 위해 전체 소스를 변경하기로 하였다.

검색 메서드를 인터페이스로 노출하고, 실제 실행 결과는 별도로 분리한다.

여행 상품을 관리하는 클래스와 상품을 조회하는 로직을 분리하겠다는 것이다.

즉, 너무나 다양하게 요청되는 조회 조건 및 처리 메서드는 인터페이스로 분리해 외부에서 정의하고, 여행사 소프트웨어는 상품을 관리하고 요청에 대응하는 것이다.

public interface TravelInfoFilter {
    public boolean isMatched(TravelInfoVO travelInfo);
}

딱 한개의 메소드만 가진 인터페이스를 구현하였다.

아래에 다시한번 설명하겠지만, 자바8부터 한개의 메소드를 정의한 것을 함수형 인터페이스라고 한다.

그럼 searchTravelInfo 메소드를 변경해보도록 하자.

public class SearchingTravel {
    private List<TravelInfoVO> travelInfoList = new ArrayList<>();
    public List<TravelInfoVO> searchTravelInfo(TravelInfoFilter searchCondition) {
        List<TravelInfoVO> returnValue = new ArrayList<>();
        
        for(TravelInfoVO travelInfo : travelInfoList) {
            if(searchCondition.isMatched(travelInfo)) {
                returnValue.add(travelInfo);
            }
        }
        return returnValue;
    }
}

매개변수로 인터페이스를 받아서, 인터페이스의 메소드를 통해 isMatched를 비교하는 로직으로 변경하였다.

즉, 해당 인터페이스로 구현된 클래스는 외부에게 맞기는 것으로 변경한 것이다.

public class Main {
    public static void main(String[] args) {
        SearchingTravel st = new SearchingTravel();
        
        List<TravelInfoVO> searchTravel = st.searchTravelInfo(new TravelInfoFilter() {
            @Override
            public boolean isMatched(TravelInfoVO travelInfo) {
                if(travelInfo.getCountry().equals("vietnam")) {
                    return true;
                }
                return false;
            }
        })
    }
}

해당 클래스를 호출하는 로직을 구현하였다. (익명 클래스를 활용하였다)

이제 람다 표현식으로 조금씩 바꿔보도록 하자.

람다 표현식으로 코드 함축

익명 클래스를 활용하면 코드의 중복이 매우 심해질 것이다.

위에서는 베트남 하나였지만, 한국, 중국, 일본 등 추가할 때마다 변화는 적은데 코드는 매우 많이 늘어난다.

따라서 람다 표현식으로 함축하면 다음과 같아진다.

List<TravelInfoVO> searchTravel = st.searchTravelInfo((TravelInfoVo travelInfo) -> travelInfo.getCountry().equals("vietnam"));

꽤 많은 것이 함축되었다.

한가지 더 알아보도록 하자.

메서드 참조

자바 7까지 변수 혹은 메서드의 파라미터로 전달할 수 있는 것은 객체나 기본 데이터뿐이였다.

자바 8부터는 메서드 자체를 넘길 수 있게 되었고, 이를 메서드 참조(Method Reference)라고 한다.

익명 함수로 소스 코드 중복은 줄일 수 있을지 몰라도, 재사용성을 줄어들었는데, 이렇게 함수 자체를 넘길 수 있다면 재사용성 역시 개선될 수 있다.

public static boolean isVietnam(TravelInfoVO travelInfo) {
    if(travelInfo.getCountry().equals("vietnam")) {
        return true;
    }
    return false;
}

위 함수를 SearchTravel 클래스에 추가한다.

그리고 메인 함수는 이렇게 변경될 수 있다.

List<TravelInfoVO> searchTravel = st.searchTravelInfo(SearchingTravel::isVietnam);

파라미터조차 적지 않는 방식을 확인할 수 있다.

다음 포스팅 부터는 람다 표현식으로 변경하는 방법을 이제 알아볼 예정인데, 그 전에 한번 용어를 정리하고 가도록 하자.

용어 정리

함수형 프로그래밍

위에서 간단히 알아본 람다를 공부하려면 가장 먼저 함수형 프로그래밍을 알아야 한다.

또한, 람다라는 용어는 자바에서만 사용하는 것도 아니며 다른 언어(자바스크립트 등)에서 활용하는 것을 보았을 때, 사용법은 달라도 메소드 명까지 동일하게 활용되는 경우가 많다.

함수형 프로그래밍은 순수 함수(pure function)를 구현하고 호출함으로써 외부 자료에 부수적인 영향(Side Effect)를 주지 않도록 구현하는 방식이다.

순수 함수(pure function)는 매개변수만을 사용하여 만드는 함수다.

즉, 함수 내부에서 함수 외부에 있는 변수를 사용하지 않아 함수가 수행되더라도 외부에는 영향을 주지 않는다.

이 말은 함수의 기능이 데이터에 독립적임을 보장하게 된다.

즉, 동일한 데이터에 대해 동일한 결과를 보장하고, 다양한 데이터에 대해 같은 기능을 수행한다는 것이다.

따라서, 병렬 처리에 안정성과 확장성을 제공하게 된다.

람다식

람다식은 자바에서 함수형 프로그램을 구현한 방식이다.

함수형 인터페이스를 선언하며 클래스를 호출하지 않고 메소드만 호출하여 기능을 수행한다.

몇 가지 특징들을 예시와 함께 알아보도록 하자.

매개 변수가 하나인 경우 생략이 가능하다.
중괄호 안의 구현부가 1문장이면 중괄호를 생략할 수 있다.
중괄호 안 구현부가 1문장이더라도, return 문이라면 생략할 수 없다.
만약 반환문 1개라면, return과 중괄호 모두 생략할 수 있다.

str -> {System.out.println(str);}; // 1번
str -> System.out.println(str); // 2번
str -> return str.length(); // 3번 에러
str -> str.length(); // 4번
(x,y) -> x+y; // 4번

함수형 인터페이스

람다식을 선언하기 위한 인터페이스다.

익명 함수와 매개 변수만으로 구현되므로, 단 하나의 메서드만을 선언해야 한다.

(두개 이상의 메서드가 생성되면, 어떤 메서드를 호출할지 애매해진다.)

@FunctionalInterface 어노테이션을 사용한다.

@FunctionalInterface
public interface MyNumber {
    int getMax(int num1, int num2);
}

public class Main {
    public static void main(String[] args) {
        MyNumber max = (x,y) -> x>=y? x:y;
        System.out.println(max.getMax(10,20));
    }
}

람다식을 구현하면 익명 내부 클래스가 만들어지고, 이를 통해 익명 객체가 생성된다.

앞선 포스팅에 익명 내부 클래스를 알아보았다.

자바 기초부터 모던 자바까지 - 인터페이스 편

KOOCCI — Sun, 3 Jul 2022 15:04:21 +0900

목표 : 자바의 인터페이스에 대해 알아본다.

인터페이스

인터페이스가 무엇인지 그에 대한 개념을 설명하지는 않겠다.

자바는 다중상속을 지원하지 않는다거나, 추상화에 대한 내용을 모른다면 잘 정리된 다른 포스팅을 찾아 보도록 하자.

자바8부터 람다와 함수형 프로그래밍을 적용하기 위해 인터페이스를 활용하기 시작한다.

그럼 기존의 인터페이스에는 무슨 문제점이 있었고, 어떻게 진화해 온 것인지 먼저 알아보려 한다.

인터페이스의 문제점

인터페이스는 주로 여러 개의 구현체를 통일화한 명세서로 정의하기 위해 사용한다.

그러면 인터페이스를 구현한 클래스들은 동일한 메소드 명으로 통일성을 확보하고, 구현 방법에 상관없이 자신이 원하는 메서드를 호출해 목적을 이룰 수 있다.

그러나, 가장 치명적인 단점은 명세서기 때문에 수정이 어렵다는 것이다.

딱 메소드 2개의 아래 인터페이스를 보자.

public interface EncryptionIF {
    public byte[] encrypt(byte[] bytes) throws Exception;
    public byte[] decrypt(byte[] bytes) throws Exception;
}

암호화 알고리즘 인터페이스로, 위 2가지 메소드 명세서를 만들어 배포했다.

수십개의 팀이 이 인터페이스를 활용해 잘 사용하고 있었는데, 기능을 추가해야하는 경우가 생겼다.

몇몇 팀이 파라미터로 들어온 값이 암호화 알고리즘으로 암호화된 것인지 확인하는 기능이었다.

public interface EncryptionIF {
    public byte[] encrypt(byte[] bytes) throws Exception;
    public byte[] decrypt(byte[] bytes) throws Exception;
    public boolean isEncoded(byte[] bytes) throws Exception;
}

이렇게 수정/배포하면 다음과 같은 문제점들이 속출한다.

인터페이스 배포 후 해당 인터페이스를 구현한 모든 클래스에서 컴파일 에러가 발생한다.
구현한 클래스가 너무 많아 이를 모두 한번에 수정하는 것이 어렵다.
내부에서 사용하는 인터페이스가 아니라 외부 노출되는 오픈된 규격이였다.
클래스를 수정하지 않고 인터페이스를 컴파일하여 배포하면 NoSuchMethod 에러가 발생한다.

그럼 그 다음으로 고민하는 과정은 버져닝이다.

업그레이드가 아닌 새로운 규격을 내는 것이다.

public interface EncryptionChecker {
    public boolean isEncoded(byte[] bytes) throws Exception;
}

임시 방편은 될 수 있지만, 매번 수정이 일어날 때마다 인터페이스를 새롭게 제공할 수는 없었다.

이런 사고가 자바에서 제공하는 API 중 컬렉션 프레임워크에서 발생했다.

자바의 버전이 올라갈 수록 새로운 환경(멀티 쓰레드 등)에 대응하고자 하는 자료 구조는 계속 생겨나는데, 컬렉션 프레임워크의 핵심 인터페이스는 수정을 못하는 것이다.

인터페이스의 진화

결국 인터페이스의 기능을 대대적으로 변경하게 된다.

그 핵심이 디폴트(default) 메서드이다.

최초의 자바 버전(1.x)에서는 인터페이스 제약이 다음과 같았다.

상수를 선언할 수 있다. 해당 상수는 반드시 값이 할당되어 있어야 하며 변경하지 못한다. 명시적으로 final처리를 안해도 final로 인식한다.
메서드는 반드시 추상(abstract)메서드여야 한다. 즉, 구현체가 아니라 메서드 명세만 정의되어야 한다.
인터페이스를 구현한 클래스는 인터페이스에서 정의한 메서드를 구현하지 않았다면 반드시 추상 클래스로 선언되어야 한다.
인터페이스에 선언된 상수와 메서드에 public을 선언하지 않더라도 public으로 인식한다.

자바 버전 1.2부터는 몇가지 추가가 된다.

중첩(Nested) 클래스를 선언할 수 있다. 선언은 내부(Inner)클래스 같지만, 실제로는 중첩 클래스로 인식한다.
중첩(Nested)인터페이스를 선언할 수 있다.
위의 중첩 클래스와 중첩 인터페이스는 모두 public과 static이어야 하며 생략 가능하다.

이전 포스팅에서 내부 클래스를 설명할 때도 설명했지만, 현재 참고중인 자료에는 중첩 클래스와 내부 클래스를 구분하고 있다.

중첩 클래스는 클래스나 인터페이스 내부에 static으로 선언된 클래스임을 확인하자.

중첩클래스를 통해 인터페이스 내부에서 세부 동작에 대해 상세히 규정할 수 있고, 개발자가 구현할 필요 없이 인터페이스 차원에서 제어할 수 있게 되었다.

자바 버전 5부터는 새로운 기능인 제네릭, Enum, 어노테이션이 인터페이스에 영향을 주었다.

중첩(Nested) 열거형(Enum)을 선언할 수 있다.
중첩(Nested) 어노테이션을 선언할 수 있다 (위의 중첩 열거형과 중첩 어노테이션은 모두 public과 static이어야 하며 생략가능하다)

제네릭의 등장으로 인터페이스 선언문과 메서드 선언에 모두 타입 파라미터를 사용할 수 있게 되었다.

단, 타입파라미터로 변수나 상수를 선언할 수 없고, 오직 메서드의 리턴 타입과 인수 타입에만 사용할 수 있다.

그리고, 자바 8부터는 또다시 2가지가 추가된다.

실제 코드가 완성되어 있는 static 메서드를 선언할 수 있다.
실제 코드가 완성되어 있는 default 메서드를 선언할 수 있다. (위의 static 메서드와 default 메서드는 모두 public 메서드로 인식하며 public 선언은 생략할 수 있다.

가장 중요한 변화는 실제 구현된 코드를 정의할 수 있다는 것이다.

물론, static메서드나 default 둘 중 하나가 전제 조건이다.

물론 클래스에서도 별도로 정의할 필요가 없다. 이를 통해 굳이 메서드를 사용하는 클래스에서 구현하지 않아도 컴파일 에러가 나지 않는다.

이런 변화는 8버전부터 Collection 인터페이스에 메서드를 추가하게 되었다.

자바 9버전 부터는 또 한가지가 추가된다.

private 메서드를 선언할 수 있다.

기존에는 public 메소드만 가능했고, 접근자를 선언하지 않고 메서드를 정의해도 public으로 인식했다.

이 변화는 클래스의 외부에는 공개되지 않더라도 인터페이스 내부의 static 메서드와 default 메서드의 로직을 공통화하고 재사용하는데 유용해졌다.

단, private 메서드는 실제 동작하는 소스 코드까지 구현해야한다는 제약이 있다. 즉, 자바 8의 static 혹은 default 메서드와 동일한 개념을 가진 기능의 발전이었다.

정리해보면 현재 인터페이스에는 총 9가지를 선언할 수 있다.

상수
추상 메서드
중첩 클래스
중첩 인터페이스
중첩 열거형
중첩 어노테이션
static 메서드
default 메서드
private 메서드

클래스와의 차이점과 제약 조건

인터페이스가 구현이 되게 된다면, 클래스와의 차이는 어떻게 될 것인가?

추상클래스와 인터페이스의 차이점은 하기와 같다.

추상 클래스는 멤버 변수를 가질 수 있지만 인터페이스는 멤버 변수를 가질 수 없다. static으로 정의된 변수를 내부적으로 선언할 수 있지만 멤버 변수는 선언할 수 없다.
클래스를 구현할 때 오직 하나의 클래스만을 상속받을 수 있는 반면에 인터페이스는 여러 개를 상속받거나 구현할 수 있다.

즉, 가장 큰 차이점은 멤버 변수의 선언 유무다.

멤버변수는 그 객체의 속성을 담아두기 위한 용도인데, 인터페이스에서 멤버 변수가 없다는 것은 인터페이스 자체를 객체화 할 수 없다는 것이다.

자바는 다중 상속이 허용되지 않지만, 인터페이스를 통해 여러 인터페이스를 구현할 수는 있다.

마치 상속과 비슷하게 default 메서드, private, static 메서드의 기능을 이어 받을 수 있게 되었고 특히 default 메서드는 오버라이드도 가능하다.

public interface HouseAddress {
    public static final String DefaultCountry = "Korea";
    
    public String getPostCode();
    default public String getCountryCode() {
        return getDefaultCountryCode();
    }
    
    private String getDefaultCountryCode() {
        return HouseAddress.DefaultCountry;
    }
}

위 인터페이스를 구현한 클래스를 보자.

public class KoreaHouseAddress implements HouseAddress {
    private String postCode;

    @Override
    public String getPostCode() {
        return null;
    }

    @Override
    public String getCountryCode() {
        return HouseAddress.super.getCountryCode();
    }
}

대부분 super 키워드를 통해 상위 클래스의 메서드 혹은 속성에 접근하는데, 당연히 인터페이스다 보니 Object 클래스가 연결된다.

HouseAddress.super.getCountryCode();

따라서, 자바 8부터는 위와 같은 방법으로 상위 인터페이스의 메소드로 연결지을 수 있다.

다중 상속 관계

자바에서는 다중 상속을 지원하지 않는다.

복잡성이 높아져 버그가 많이 발생하고 유지보수가 어려워진다는 것이 그 이유다.

그러나 인터페이스의 default의 등장은 조금 난감한 이슈가 되었다.

우선 private 메서드는 자바의 접근 규칙에 따라, 하위 클래스로 상속되지 않는다. 즉, private 메서드가 인터페이스에 있더라도 문제가 되지 않는다.

static 메서드도 인터페이스 레벨 혹은 클래스 레벨로 정의되므로(컴파일 타임에 생성되는 사항이라 상속이 불가하다) 메서드 오버라이드의 범위에 속하지 않는다.

그러나 default 메소드는 가능하다.

따라서, 흔히 다중 상속의 문제점인 다이아몬드 상속과 같은 문제가 발생한다.

다이아몬드 상속

Worker 입장에서 default 메소드로 만들어진 성별을 가져오려고 하면, Duplicate 에러가 날 수 밖에 없다.

어떤 클래스에서 받아야 할지 모호하기 때문이다.

이를 피하기 위해서는 결국 Worker에서 오버라이드를 필수적으로 해야한다. (앞서 확인한 super 키워드를 통해서도 가능하다)

다만, 만약에 Man이 Abstract 클래스라면 어떻게 될 것인가?

성별을 가져오는 getSex() 메소드가 있을 때, Person에서는 default로 구현되었을 것이다.

Man이라는 클래스에서는 이를 Abstract 클래스로 가져왔고, Woman은 인터페이스로 가져왔다.

문제는 없다. 다만, Worker에서 오버라이드를 하지 않아도 에러가 나지 않는다는 것이다.

이때는 클래스가 우선적으로 적용된다. 즉, Man에 적용된 getSex()메소드가 호출되는 것이다.

요약하면 다음과 같다.

클래스가 인터페이스에 대해 우선순위를 가진다. 동일한 메서드가 인터페이스와 클래스에 둘 다 있다면 클래스가 우선이다.
위의 조건을 제외하고 상속관계에 있을 경우 하위 클래스/인터페이스가 상위 클래스/인터페이스보다 우선된다.
위의 두가지 조건을 제외하고 메서드 호출 시 어떤 메서드를 호출해야할지 모호할 경우, 컴파일 에러가 발생할 수 있으며, 명확한 지정이 필요하다.

하나 신경써야 할 것은 버전이 올라갈 수록 인터페이스 기능이 많아졌다고 하여, 남용하는 것은 좋지 않다.

본연의 인터페이스 역할에 충실하고 영향을 최소화하도록 구현하는 것이 가장 명확한 해답이다.

자바 기초부터 모던 자바까지 - 내부&중첩 클래스편

KOOCCI — Sat, 2 Jul 2022 15:57:46 +0900

목표 : 자바의 내부&중첩 클래스에 대해 알아본다.

Inner Class

클래스에 전반적인 내용을 모두 적진 않을 것이다.

객체 지향의 거대한 3요소인 상속, 다형성, 캡슐화 등에 대해서는 너무나도 많은 자료가 있으니 별도로 알아보도록 하자.

지금 알아볼 것은 Class안의 Class의 동작에 대해 알아볼 에정이다.

Inner Class(내부 클래스)는 중첩 클래스라고도 표현하는 사람도 많지만, 약간 다르게 설명하는 경우도 있다.

중첩 클래스는 클래스나 인터페이스 내부에 static으로 선언된 클래스다.

포스팅을 위해 참고한 자료에서도 중첩 클래스는 내부 클래스와 동일 시하여 표현하고 있어, 하기 내용이 조금 헤깔릴 수 있으나 명확하게 구분하는 사람도 있으니 참고하도록 하자.

클래스 내부에 선언한 클래스로 이 클래스를 감싸고 있는 외부 클래스와 밀접한 연관이 있는 경우가 많고, 다른 외부 클래스에서 사용할 일이 거의 없는 경우에 내부 클래스로 선언해서 사용하기도 한다.

그 종류로는 4가지 정도로 구분될 수 있다.

인스턴스 내부 클래스
정적(static) 내부 클래스
지역(local) 내부 클래스
익명(anonymous) 내부 클래스

한가지씩 알아보도록 하자.

인스턴스 내부 클래스

내부적으로 사용할 클래스를 선언하는 것이다.

내부적으로 사용하다 보니, private로 선언하는 것을 권장한다.

외부 클래스가 생성된 후에 생성되며, public으로 선언하면 외부 클래스에서도 호출을 할 수 있게 된다.

아래에 예시 코드는 static 변수나 메서드를 함께 확인해볼 것이다.

어떤 차이가 있는지 비교해보면서 보도록 하자.

class OuterClass {
    private int num = 10;
    private static int sNum = 20;
    private InnerClass innerClass;

    public OuterClass(){
        innerClass = new InnerClass(); // 내부 클래스 생성
    }
    class InnerClass {
        int inNum = 100;
        //        static int staticInNum = 200; // 에러남
        void inTest() {
            System.out.println("OuterClass num = " + num + "(외부 클래스의 인스턴스 변수)");
            System.out.println("OuterClass sNum = " + sNum + "(외부 클래스의 스태틱 변수)");
            System.out.println("InnerClass inNum = " + inNum + "(내부 클래스의 인스턴스 변수)");
        }
    }

    public void usingClass() {
        innerClass.inTest();
    }
}


public class Main {
    public static void main(String[] args) {
        OuterClass outClass = new OuterClass();
        outClass.usingClass(); // inClass의 inTest가 실행

        // private가 아니면 외부 실행 가능
        OuterClass.InnerClass inner = outClass.new InnerClass(); // 만들 수 있지만, 사용하길 지양해야 함
        inner.inTest();

    }
}

그 결과는 아래와 같이 출력된다

OuterClass num = 10(외부 클래스의 인스턴스 변수)
OuterClass sNum = 20(외부 클래스의 스태틱 변수)
InnerClass inNum = 100(내부 클래스의 인스턴스 변수)
OuterClass num = 10(외부 클래스의 인스턴스 변수)
OuterClass sNum = 20(외부 클래스의 스태틱 변수)
InnerClass inNum = 100(내부 클래스의 인스턴스 변수)

위 예시에서 보면, InnerClass내의 static 변수는 선언할 수 없다.

앞서 말했지만, OuterClass가 먼저 생성되고 InnerClass가 생성되게 된다. (생성자로 InnerClass를 생성해야 한다)

static 변수는 OuterClass랑 상관없이 사용하게 되버린다. (메소드도 마찬가지다) (앞선 포스팅을 확인하자)

정적 내부 클래스 (Static Inner Class)

내부 클래스 선언에 static을 붙여보자.

외부 클래스와 무관하게 사용할 수 있다. (static 변수, static 메소드 사용)

class OuterClass {
    private int num = 10;
    private static int sNum = 20;

    static class InnerStaticClass {
        int inNum = 100;
        static int sInNum = 200;

        void inTest() {
//            num ++; // 에러남
            sNum ++;
            inNum ++;
            sInNum ++;
//            System.out.println("OuterClass num = " + num + "(외부 클래스의 인스턴스 변수)"); // 에러남
            System.out.println("OuterClass sNum = " + sNum + "(외부 클래스의 스태틱 변수)");
            System.out.println("InStaticClass inNum = " + inNum + "(내부 클래스의 인스턴스 변수 사용)");
            System.out.println("InStaticClass sInNum = " + sInNum + "(내부 클래스의 스태틱 변수 사용)");
        }

        static void sTest() {
            //num += 10;   // 외부 클래스의 인스턴스 변수는 사용할 수 없음.
            //inNum += 10; // 내부 클래스의 인스턴스 변수는 사용할 수 없음.
            sInNum += 10;

//            System.out.println("OuterClass num = " + num + "(외부 클래스의 인스턴스 변수)"); // 에러남
            System.out.println("OuterClass sNum = " + sNum + "(외부 클래스의 스태틱 변수)");
//            System.out.println("InStaticClass inNum = " + inNum + "(내부 클래스의 인스턴스 변수 사용)"); // 에러남
            System.out.println("InStaticClass sInNum = " + sInNum + "(내부 클래스의 스태틱 변수 사용)");
        }
    }
}

public class Main {
    public static void main(String[] args) {
        //외부 클래스 생성하지 않고 바로 정적 내부 클래스 생성
        OuterClass.InnerStaticClass sInClass = new OuterClass.InnerStaticClass();
        System.out.println("정적 내부 클래스 일반 메서드 호출");
        sInClass.inTest();
        System.out.println();
        System.out.println("정적 내부 클래스의 스태틱 메소드 호출");
        OuterClass.InnerStaticClass.sTest();
    }
}

정적 내부 클래스 일반 메서드 호출
OuterClass sNum = 21(외부 클래스의 스태틱 변수)
InStaticClass inNum = 101(내부 클래스의 인스턴스 변수 사용)
InStaticClass sInNum = 201(내부 클래스의 스태틱 변수 사용)

정적 내부 클래스의 스태틱 메소드 호출
OuterClass sNum = 21(외부 클래스의 스태틱 변수)
InStaticClass sInNum = 211(내부 클래스의 스태틱 변수 사용)

static 이라는 용어의 성질을 알면 에러나는 이유를 유추할 수 있을 것이다.

언제 메모리에 로드되는지 잘 생각해보자.

외부의 멤버 변수는 당연히 호출할 수 없고, 자신의 멤버변수라고 하더라도, static 메소드에서는 호출 할 수 없다.

지역 내부 클래스

지역 변수와 같이 메서드 내부에서 정의한다.

메서드의 호출이 끝나면 메서드에 사용된 지역변수의 유효성은 사라진다.

메서드 호출 이후에도 사용해야 하는 경우가 있을 수 있으므로 지역 내부 클래스에서 사용하는 메서드의 지역 변수나 매개 변수는

final로 선언된다.

하기의 Runnable을 활용한 예시를 보도록 하자.

class OuterClass {
    private int outNum = 10;
    private static int sNum = 20;

    Runnable getRunnable(int i) {
        int num = 100; // 로컬 변수 = stack 메모리

        class MyRunnable implements Runnable {
            int localNum = 10; // 클래스 멤버 변수

            @Override
            public void run() {
//                num = 200; // 에러남. 지역변수는 상수로 바뀐다.
//                i = 100; // 에러남. 매개 변수 역시 지역변수처럼 상수로 바뀐다.
                outNum ++;
                sNum ++;

                System.out.println("i = " + i);
                System.out.println("num = " + num);
                System.out.println("localNum = " + localNum);

                System.out.println("outNum = " + outNum + "(외부 클래스 인스턴스 변수)");
                System.out.println("sNum = " + OuterClass.sNum + "(외부 클래스 정적 변수)");
            }
        }
        return new MyRunnable();
    }

}

public class Main {
    public static void main(String[] args) {
        OuterClass out = new OuterClass();
        Runnable runner = out.getRunnable(10);
        runner.run();
    }
}

i = 10
num = 100
localNum = 10
outNum = 11(외부 클래스 인스턴스 변수)
sNum = 21(외부 클래스 정적 변수)

getRunnable함수 자체는 생성되고 사라지지만, run함수는 다시 호출될 수 있다.

stack메모리에 잡히면 쓸 수 없으므로, final처리가 된다.

익명 내부 클래스

이름이 없는 클래스다. (위 지역 내부 클래스의 MyRunnable 클래스 이름은 실제로 호출되는 경우가 없다)

클래스의 이름을 생략하고 주로 하나의 인터페이스나 하나의 추상 클래스를 구현하여 반환한다.

인터페이스나 추상 클래스 자료형의 변수에 직접 대입하여 클래스를 생성하거나 지역 내부 클래스의 메서드 내부에서 생성하여 반환 할 수 있다.

안드로이드 widget의 이벤트 핸들러에 활용된다.

class OuterClass {
    private int outNum = 10;
    private static int sNum = 20;

    Runnable getRunnable(int i) {
        int num = 100; // 로컬 변수 = stack 메모리

        return new Runnable() {
            int localNum = 10; // 클래스 멤버 변수

            @Override
            public void run() {
//                num = 200; // 에러남. 지역변수는 상수로 바뀐다.
//                i = 100; // 에러남. 매개 변수 역시 지역변수처럼 상수로 바뀐다.
                outNum ++;
                sNum ++;

                System.out.println("i = " + i);
                System.out.println("num = " + num);
                System.out.println("localNum = " + localNum);

                System.out.println("outNum = " + outNum + "(외부 클래스 인스턴스 변수)");
                System.out.println("sNum = " + OuterClass.sNum + "(외부 클래스 정적 변수)");
            }
        };
    }

    Runnable runner = new Runnable() {
        @Override
        public void run() {
            System.out.println("Runnable 이 구현된 익명 클래스 변수");
        }
    };

}

public class Main {
    public static void main(String[] args) {
        OuterClass out = new OuterClass();
        Runnable runnable = out.getRunnable(10);
        runnable.run();
        out.runner.run();
    }
}

i = 10
num = 100
localNum = 10
outNum = 11(외부 클래스 인스턴스 변수)
sNum = 21(외부 클래스 정적 변수)
Runnable 이 구현된 익명 클래스 변수

이렇게 inner class에 대해 간단히 알아보았다.

자바 기초부터 모던 자바까지 - 객체 편

KOOCCI — Sat, 2 Jul 2022 15:57:07 +0900

목표 : 자바의 객체의 개론을 알아본다.

Object

객체가 무엇인지를 정의하고자 한다기 보다, 내가 아는 내용을 정리하고자 한다.

세상 모든 것을 개체라고 할 수 있다.

개체 중에서 내가 관심을 가지는 영역을 객체로 바라보자.

그리고, 그 객체의 성격과 행동, 서로간의 소통들을 정의해나갈 수 있을 것이다.

결국 그 객체에 대해 내가 관심이 있고, 다루고자 하는 영역들을 성격과 행동이라는 용어로 정리하다 보면 특정해 나갈 수 있게 된다.

이를 클래스라는 용어로 불러본다.

사람이라는 객체가 있다.

철학적인 물음으로 사람이란 무엇인가?에 대해서 대답하고자 하는건 아니다. (나라는 것은 무엇인가? 라는 질문으로 넘어가면 철학과 과학의 오묘한 결합이 나오게 된다)

그렇지만 우리가 원하는 어떠한 결과물을 위해서는 원하는 바를 정리해보며 사람을 만들어가야 한다.

눈이 있고, 코가 있고, 귀가 있으며, 옆 사람과 대화할 수 있는 것 이라고 먼저 정의했다고 하자.

그럼 사람이라는 것의 특징은 눈, 코, 귀가 있다는 것. 그리고 옆 사람과 대화를 한다는 행동을 정의할 수 있다.

class Person {
    private Eye eye;
    private Nose nose;
    private Ear ear;

    public void conversation(Person person) {
    
    }
}

아주 간단한 클래스가 만들어졌다.

민수, 철수, 영희 모두 사람이라고 하자.

클래스를 통해 민수를 만들고, 철수, 영희를 만들면 그것이 인스턴스라는 용어로 통용될 수 있게 된다.

심지어, 대화도 할 수 있다.

Person minsoo = new Person();
Person chulsoo = new Person();
Person younghee = new Person();

minsoo.conversation(chulsoo);
minsoo.conversation(younghee);

성격 혹은 특징(속성)은 클래스의 멤버 변수(Member Variable)로 표현했으며, 그 행동은 메서드(Method)를 통해 만들어 주었다.

붕어빵과 붕어빵 틀이라는 유명한 비유가 있다. (위 사람과도 비교해보자)

비유는 모든 것을 설명하지 못하지만, 이해력을 높여주는 좋은 도구다.

붕어빵이라는 것에 내가 관심이 있고, 그 관심에 대한 성격과 행동, 소통들을 정의해 나가다보면 하나의 틀이 만들어진다.

붕어빵 사장님은 관심사들을 찍어내기 위해 붕어빵 틀이라는 것을 만든다.

그럼 붕어빵들을 열심히 찍어낼 수 있게 되는 것이다.

프로그램도 결국 내가 관심을 가지는 영역을 프로그램 언어로서 성격을 규정하고, 행동, 소통들을 정의해 원하고자 하는 바를 구현한 결과물이다.

조금 다른 용어로 이를 정의해보면, 클래스는 객체의 청사진(BluePrint)라고 할 수 있다.

Object Class

위와 같이 객체라는 용어에 대해 정리해보았다.

Java에서도 모든 객체의 최상위 클래스는 Object 클래스다.

굳이, import하지 않아도 자동으로 import되며, 모든 클래스는 Object에서 상속받고, Object 클래스의 메서드 중 일부는 재정의해서 사용할 수 있다.

즉, 자동으로 extends Object가 되는 것이라 보면 된다.

그리고, Object의 메소드 중 가장 많이 쓰는 것은 toString(), equals(), hashCode()가 있을 것이다.

[java] Remove Nth Node From End of List

KOOCCI — Sat, 2 Jul 2022 13:55:59 +0900

[참고문제] : https://leetcode.com/problems/remove-nth-node-from-end-of-list/

Remove Nth Node From End of List - LeetCode

Level up your coding skills and quickly land a job. This is the best place to expand your knowledge and get prepared for your next interview.

leetcode.com

문제 풀이

자체적인 자료구조를 제공하고 푸는 문제다.

자바는 Call By Value지만, 그 주소값(정확히는 주소를 가리키는 값)을 가지므로 마치 Call By Reference처럼 동작한다.

위 문장에 가끔 Deep Copy, Shallow Copy의 개념을 흔들 때가 있다.

생각의 흐름 - 일단 전체 길이부터 구하자.

전체 길이를 제공하지 않는다. 별도 함수를 만들어 Count를 먼저 알아보기로 했다.

생각의 흐름 - 마지막에서 N번째라면 Step이 어떻게 계산될 수 있을지 생각하자.

몇번이나 Next로 넘어가야 하는지를 알아야 한다.

전체 Count했으니, 거기서 N을 빼면 몇번째인지 알 수 있고,

Next값을 바꿔주면 될 것이다.

여기서 Head를 가지고 Next를 계산하면, 당연히 안된다.

그럼 Tmp변수에 Head를 할당시키면 문제 없을까?

내부 값을 변경시키는 거면, 당연히 문제가 된다. Tmp의 주소값이 결국 Head의 주소값이기 때문이다.

그렇지만, Tmp도 결국 변수기 때문에, Tmp에 Head.next를 대입시킨다는 개념이면 문제가 되지 않는다.

ListNode가 5개라고 가정하면,

ListNode 1

위와 같은 주소값(100~104)들을 가지는 Node가 5개 있다고 가정하자.

Head는 100이라는 주소값에 위치한다.

Tmp = Head라고 했을 때, Tmp도 Head와 동일한 주소값을 가진다.

그렇지만, Tmp = Tmp.next로 변화시키는 것은 Head에 영향을 주지 않는다. (tmp가 100에서 101을 보게 되는 것 뿐이며, Head는 여전히 100을 바라본다)

물론, Tmp.value 를 변경시키면 Head.value도 영향을 가지게 된다.

이 두가지를 적절히 혼합시켜야 한다.

ListNode 2

ListNode 3

Prev라는 변수를 만들어, Head와 동일 시 시킨다.

Tmp를 Next시키면서, Prev 변수에는 Next이전 값을 계속 가지게 한다.

그리고 Step이 마무리 되었을 때 (위의 경우 tmp가 3번의 Step을 넘어간 후 103번에 위치한 경우),

Prev.next = Tmp.next 로 동일하게 만들면, 102번의 next는 104번으로 변경이 된다.

결국 Head에서 next로 가다보면, 100 -> 101 -> 102 -> 104 로 변경되는 것이다.

생각의 흐름 - Step이 0이 나온다면?

움직이지 않는다가 아니라, 첫 시작이 바뀐다는 것을 캐치해야 했다.

Head를 Head.next로 대치해야 했다.

public ListNode removeNthFromEnd(ListNode head, int n) {
    int count = chkCount(head);
    ListNode tmp = head;
    ListNode prev = head;
    int step = count - n;
    if(step == 0) {
        head = head.next;
    } else {
        while(step > 0) {
            prev = tmp;
            tmp = tmp.next;
            step --;
        }
        prev.next = tmp.next;
    }
    return head;
}

public int chkCount(ListNode head) {
    ListNode tmp = head;
    int count = 1;
    while(tmp.next != null) {
        tmp = tmp.next;
        count ++;
    }
    return count;
}

[java] Container With Most Water

KOOCCI — Sat, 2 Jul 2022 12:59:32 +0900

[참고문제] : https://leetcode.com/problems/container-with-most-water/

Container With Most Water - LeetCode

Level up your coding skills and quickly land a job. This is the best place to expand your knowledge and get prepared for your next interview.

leetcode.com

문제 풀이

간단히 2중 포문으로 풀 수 있겠지만, Time 제한에 걸릴게 뻔해보였다.

생각의 흐름 - 일단 2중 포문으로는 잘 구현되는지 보자.

이중포문을 구현했지만 역시나 시간 이슈가 생겼다.

생각의 흐름 - 양쪽에서 줄여나가자.

늘 그렇듯, 이런 문제는 양쪽에서 줄여나갈 필요가 있다.

left, right 인덱스를 설정하고 총량을 계산해, MAX를 비교하고자 했다.

생각의 흐름 - 언제 left와 right를 늘리거나 줄여주는가?

while문은 left와 right가 같지 않을때로 설정하면 될 것으로 보였다.

그러나, 언제 left를 늘리고, 언제 right를 줄이는지 제한이 있어야 했다.

예시 문제를 통해 볼 때, 중간에 매우 긴 벽이 있을수도 있었다.

left와 right를 비교해야만 할 것으로 보였고, width를 같이 고민했다.

width가 줄어드는 것보다 더 이득일 경우에만 늘려야 한다고 판단했으나, 그러면 이중 포문과 다를 것이 없었다.

그럼 약간 Greedy하게 보기로 했다. 당장 left와 right중 작은게 결국 문제가 될 것이고, 작은걸 변화시키자고 생각했다.

left와 right를 비교했을 때 더 작은 것을 변화시켰다.

public int maxArea(int[] height) {
    int left = 0;
    int right = height.length - 1;
    int maxMount = 0;

    while(left != right) {
        int width = right - left;
        maxMount = Math.max(width*(Math.min(height[left], height[right])), maxMount);
        if(height[left] > height[right]) {
            right --;
        } else {
            left ++;
        }
    }
    return maxMount;
}

자바스크립트 기초부터 모던 자바스크립트까지 - 기초편

KOOCCI — Sat, 2 Jul 2022 12:03:46 +0900

목표 : 자바스크립트의 가장 기초적인 내용부터 알아본다.

변수

하나의 값을 저장하기 위해 확보한 메모리 공간 자체 또는 그 메모리 공간을 식별하기 위해 붙인 이름

변수 선언

변수를 생성하는 것

값을 저장하기 위한 메모리 공간을 확보하고, 변수 이름과 확보된 메모리 공간의 주소를 연결하여 값을 저장할 수 있게 준비하는 것

변수를 사용하려면 반드시 선언이 필요하며, var, let, const 키워드를 사용한다.

선언 단계
- 변수 이름을 등록해서 자바스크립트 엔진에 변수의 존재를 알린다.
초기화 단계
- 값을 저장하기 위한 메모리 공간을 확보하고 암묵적으로 undefined를 할당해 초기화한다.

변수 선언의 실행 시점과 변수 호이스팅

console.log(score) // undefined
var score; // 변수 선언

변수 선언이 소스코드가 한 줄씩 순차적으로 실행되는 시점, 즉 런타임이 아니라 그 이전 단계에서 먼저 실행된다.
자바스크립트 엔진은 소스코드를 한 줄씩 실행하기 전에 먼저 소스코드의 평가, 실행 두 가지로 진행이 되며, 평가 과정에서 변수 선언을 포함한 모든 선언문(변수, 함수 등)을 소스코드의 어디에 있든 상관없이 먼저 실행한다.
변수 선언(선언 + 초기화)이 소스코드가 순차적으로 실행되는 런타임 이전 단계에서 먼저 실행된다.
변수 선언문이 코드의 선두로 끌어 올려진 것처럼 동작하는 자바스크립트 고유 특징을 변수 호이스팅이라고 한다.
변수 뿐만이 아니라, var, let, const, function, function*, class 키워드를 사용해 선언하는 모든 식별자(변수, 함수, 클래스 등)은 호이스팅된다.

값의 할당 & 재할당

var score; // 선언
score = 80; // 할당

변수 선언은 소스코드가 순차적으로 실행되는 시점인 런타임 이전에 먼저 실행되지만, 할당은 소스코드가 순차적으로 실행되는 시점인 런타임에 실행된다.

var score = 80; // 변수 선언과 값의 할당
score = 90; // 재할당

var 키워드로 선언한 변수는 선언과 동시에 undefined로 초기화되기 때문에 엄밀히 말하면 변수에 처음 값을 할당하는 것도 재할당이다.

재할당은 변수에 저장된 값을 다른 값으로 변경한다. 그래서 변수라고 하며, 만약 값을 재할당할 수 없어서 변수에 저장된 값을 변경할 수 없다면 변수가 아니라 상수(constant)라 한다.

즉, 상수는 단 한번만 할당할 수 있는 변수다.

표현식과 문

값

식(표현식: expression)이 평가(evaluate)되어 생성된 결과

// 10 + 20은 평가되어 숫자 값 30을 생성한다.
10 + 20; // 30

리터럴

사람이 이해할 수 있는 문자 또는 약속된 기호를 사용해 값을 생성하는 표기법(notation)

자바스크립트 엔진은 코드가 실행되는 시점인 런타임에 리터럴을 평가해 값을 생성한다.

리터럴	예시	비고
정수 리터럴	100
부동소수점 리터럴	10.5
2진수 리터럴	0b0100001	0b로 시작
8진수 리터럴	0o101	ES6에서 도입, 0o로 시작
16진수 리터럴	0x41	ES6에서 도입, 0x로 시작
문자열 리터럴	'hello' "hello"
불리언 리터럴	true false
null 리터럴	null
undefined 리터럴	undefined
객체 리터럴	{ name : 'Lee', address: 'Seoul' }
배열 리터럴	[ 1, 2, 3]
함수 리터럴	function() {}
정규 표현식 리터럴	/[A-Z]+/g

표현식

var score = 100;

var score = 50 + 50;
score; // 100

값으로 평가될 수 있는 문(statement)

표현식이 평가되면 새로운 값을 생성하거나 기존값을 참조한다.

리터럴 역시 값으로 평가되므로, 표현식 중 하나다.

문

프로그램을 구성하는 기본 단위이자 최소 실행 단위

문의 집합으로 이뤄진 것이 프로그램이며, 문을 작성하고 순서에 맞게 나열하는 것이 프로그래밍이다.

문은 여러 토큰으로 이루어진다.

토큰: 문법적인 의미를 가지며, 문법적으로 나눌 수 없는 코드의 기본 요소
키워드, 식별자, 연산자, 리터럴, 세미콜론이나 마침표 등 특수 기호는 문법적인 의미를 가지므로 모두 토큰이다. 문은 명령문이라고도 한다. 즉, 컴퓨터에 내리는 명령이다.
선언문, 할당문, 조건문, 반복문 등으로 구분이 된다.

데이터 타입

데이터 타입 종류

구분	데이터 타입	설명
원시타입(primitive type)	숫자(number) 타입	숫자, 정수와 실수 구분없이 하나의 숫자 타입만 존재
	문자열(string) 타입	문자열
	불리언(boolean) 타입	논리적 참(true)과 거짓(false)
	undefined 타입	var 키워드로 선언된 변수에 암묵적으로 할당되는 값
	null 타입	값이 없다는 것을 의도적으로 명시할 때 사용하는 값
	심벌 타입	ES6에서 추가된 7번째 타입
객체 타입		객체, 함수, 배열 등

개발자는 명확한 의도를 가지고 타입을 구별해서 값을 생성한다.

자바스크립트 엔진은 타입을 구별해서 값을 취급한다.

숫자 타입

자바스크립트는 정수, 실수를 구분하지 않고 하나의 숫자 타입을 갖는다.

ECMAScript 사양에 따르면, 64비트 부동소수점 형식 을 따른다.

즉, 모든 수를 실수로 처리하며, 정수만은 따로 취급하지 않는다.

console.log(1 === 1.0) // true

추가적으로 세 가지 특별한 값도 표현할 수 있다.

Infinity : 양의 무한대
-Infinity : 음의 무한대
NaN: 산술 연산 불가(Not a Number)

단, 자바스크립트는 대소문자를 구별하므로 NAN, Nan, nan은 하나의 식별자로 해석한다.

문자열 타입

텍스트 데이터를 나타낼 때 사용하고, 0개 이상의 16비트 유니코드 문자(UTF-16)의 집합으로 전 세계 대부분의 문자를 표현할 수 있다.

자바스크립트는 문자열은 원시 타입이며, 변경 불가능한 값(Immutable) 이다. (C는 배열이며, 자바는 객체로 표현한다.)

템플릿 리터럴(백틱(`))은 런타임에 문자열로 변경된다.

템플릿 리터럴

ES6 부터 새로운 문자열 표기법이 도입되었다.

템플릿 리터럴은 멀티라인 문자열, 표현식 삽입, 태그드 템플릿등 편리한 문자열 처리 기능을 제공한다.

런타임에 일반 문자열로 변환된다.

단 줄바꿈 등의 공백을 표현하려면 백슬래시를 활용해야 한다.

// 멀티라인 문자열
var str = `Hello
world.`;

//표현식 삽입
 var first = 'Hello';
 var last = 'world';
 console.log(`first is ${first}, last is ${world}`);
 console.log(`1 + 2 = ${1+2}`);

불리언 타입

논리적 참과 거짓을 나타내는 true, false뿐이다.

undefined 타입

undefined타입의 값은 undefined가 유일하다.

앞서, 변수를 선언한 이후 값을 할당하지 않은 변수를 참조하면 undefined가 반환되는 점을 배웠다.

즉, 개발자는 undefined로 초기화하는 것을 지양하고, null로 표현하는 것이 좋다. (명시적으로 값이 없다는 것을 알려줄 때)

null 타입

null타입의 값은 null이 유일하다. (Null, NULL은 해당하지 않는다.)

의도적으로 변수에 값이 없다는 것을 명시할 때 사용한다.

이는 이전에 할당되어 있던 값에 대한 참조를 명시적으로 제거하는 것이고, 자바스크립트 엔진은 누구도 참조하지 않은 메모리 공간에 대해 가비지 콜렉션을 수행한다.

함수가 유효한 값을 반환할 수 없는 경우 명시적으로 null을 반환하기도 한다.

심벌 타입

심벌(Symbol)은 ES6에서 추가된 7번째 타입으로, 변경 불가능한 원시 타입의 값이다.

심벌 값은 다른 값과 중복되지 않는 유일무이한 값이다.

주로, 이름이 충돌할 위험이 없는 객체의 유일한 프로퍼티 키를 만들 때 사용한다.

다른 원시 값은 리터럴을 통해 생성하지만, 심벌은 Symbol 함수를 통해 생성한다.

이 때, 생성된 심벌값은 외부에 노출되지 않고, 다른 값과 절대 중복되지 않는 유일한 값이다.

//심벌 값 생성
var key = Symbol('key');
console.log(typeof key); // symbol

//객체 생성
var obj = {};

//이름이 충돌할 위험이 없는 유일무이한 값이 심벌을 프로퍼티 키로 사용한다.
obj[key] = 'value';
console.log(obj[key]); // value

객체 타입

자바스크립트는 가장 크게 타입을 원시타입과 객체타입으로 구분한다.

근본적으로 다르다고 할 수 있고, 자바스크립트를 이루고 있는 거의 모든 것이 객체이다.

객체 타입은 방대하므로, 이후에 별도로 정리하도록 하자.

데이터 타입의 필요성

값을 저장할 때 확보해야 하는 메모리 공간의 크기를 결정하기 위해
값을 참조할 때 한번에 읽어야 하는 메모리 공간의 크기를 결정하기 위해
메모리에서 읽어들인 2진수을 어떻게 해석할지 결정하기 위해

동적 타이핑

정적 타입 언어는 변수 타입을 변경할 수 없고, 변수에 선언한 타입에 맞는 값만 할당 가능하다.

정적 타입 언어는 컴파일 시점에서 타입 체크를 수행한다.

타입 체크를 통과하지 못하면 에러를 발생시키고 실행을 막는다.

자바스크립트는 변수를 선언할 때 타입을 선언하지 않는다. 다만 var, let, const 키워드를 통해 변수를 선언할 뿐이다.

자바스크립트에서는 값을 할당하는 시점에 변수의 타입이 동적으로 결정되고 변수의 타입을 언제든지 자유롭게 변경할 수 있다.

자바스크립트의 변수는 선언이 아닌 할당에 의해 타입이 결정(타입 추론) 된다.

그리고 재할당에 의해 변수의 타입은 언제든지 동적으로 변할 수 있다. 즉 동적 타이핑이 된다.

동적 타입 언어는 유연성은 높지만 신뢰성은 떨어진다.

연산자

연산자에 대해서는 기초적인 내용이라, 별도로 정리하진 않는다.

단, 새로운 개념이 등장하는 부분은 정리하고 넘어가자.

단축 평가

단축 평가 표현식	평가 결과
true \|\| anything	true
false \|\| anything	anything
true && anything	anything
false && anything	false

논리 연산자를 사용한 단축 평가 시, 무엇을 반환하는지를 알아볼 필요가 있다.

논리곱 연산자는 두 개의 피연사자가 모두 true 로 평가될 때, true를 반환한다.

그러나, 평가 결과가 불리언 값이 아닐 수 있다.

'Cat' && 'Dog' // -> "Dog"

좌항부터 우항으로 평가가 진행되며, 우항까지 평가가 되었을 때 평가 결과가 결정되므로, 두번째 피연산자를 반환한다(Dog)

'Cat' || 'Dog' // -> "Cat"

논리합 연산자는 하나만 true여도 true를 반환하므로, 첫번째 피연산자를 반환한다. (Cat)

여기서, 논리곱(&&)연산자와 논리합(||)연산자는 논리 연산의 결과를 결정하는 피연산자를 타입 변환하지 않고 그대로 반환한다.

단축 평가는 다음 같은 상황에서 유용하게 사용할 수 있다.

객체를 가리키기를 기대하는 변수가 null 또는 undefined가 아닌지 확인하고 프로퍼티를 참조할 때

var elem = null;
var value = elem.value; // TypeError: Cannot read property 'value' of null

var elem = null;
// elem이 null이나 undefined와 같은 Falsy 값이면 elem으로 평가되고
// elem이 Truthy값이면 elem.value로 평가된다.
var value = elem && elem.value; // null

함수 매개변수에 기본값을 설정할 때

함수를 호출할 때 인수를 전달하지 않으면 매개변수에는 undefined가 할당된다. 이때 단축 평가를 사용해 매개변수의 기본값을 설정하면 undefined로 인해 발생할 수 있는 에러를 방지할 수 있다.

// 단축 평가를 사용한 매개변수의 기본값 설정
function getStringLength(str) {
  str = str || '';
  return str.length;
}

// ES6의 매개변수 기본값 설정
function getStringLength(str = '') {
  return str.length;
}

옵셔널 체이닝 연산자

ES11에서 도입된 옵셔널 체이닝 연산자 ?.는 좌항의 피연산자가 null 또는 undefined인 경우 undefined를 반환하고, 그렇지 않으면 우항의 프로퍼티 참조를 이어간다.

var elem = null;

var value = elem?.value;
console.log(value); // undefined

이전 논리곱 연산자로 판단한것과 유사하지만, 논리 연산자 &&은 좌항 피연산자가 false로 평가되는 값 (false, undefined, null, 0, -0, NaN, '')이면 좌항 피연산자를 그대로 반환한다.

그러나, 옵셔널 체이닝 연산자는 null 또는 undefined가 아니면 우항의 프로퍼티 참조를 이어간다.

var str = '';

var length = str?.length;
console.log(length); // 0

null 병합 연산자

ES11에서 도입된 null 병합 연산자 ??는 좌항의 피연산자가 null 또는 undefined인 경우 우항의 피연산자를 반환하고, 그렇지 않으면 좌항의 피연산자를 반환한다.

var foo = null ?? 'default string';
console.log(foo); // default string

이 역시, 변수 기본값 설정에 유용하다.

논리합 연산자도 위 논리곱 연산자와 같은 이유가 있으며, null 병합 연산자는 옵셔널 체이닝과 같은 이유로 null / undefined만 판단한다.

var foo = '' || 'default string';
console.log(foo); // default string

var boo = '' ?? 'default string';
console.log(boo); // ''

제어문

제어문 역시 기초적인 내용으로, 별도 정리하지 않는다.

별도 사이트를 참고하도록 하자

https://ko.javascript.info/intro

자바스크립트란?

ko.javascript.info

이후에는 객체부터 알아볼 것이며, 스코프, 실행컨텍스트 등을 알아볼 예정이다.

자바 기초부터 모던 자바까지 - 기초편

KOOCCI — Fri, 1 Jul 2022 23:34:47 +0900

목표 : 자바의 가장 기초적인 내용부터 알아본다.

java만큼 아직 대중적인 프로그래밍 언어는 없다.

점차 포스팅으로 모던 자바에 대해 정리하겠지만, 알았으면서도 오랜만에 보면 새로울 수 있는 포인트들이 있다.

변수가 무엇인지, 자료형이 무엇인지 이런 내용은 아니지만, 조금은 익숙해져야 할 내용으로 작성하려 한다.

상수와 리터럴이 뭐지?

상수(constant)는 알다 시피, 변하지 않는 수를 말하고 final이라는 키워드를 쓴다.

final을 쓰면, 변수는 상수가 되고, 상수는 변할 수 없다.

리터럴(literal)은 프로그램에서 사용하는 모든 숫자, 값, 논리 값 (ex> 10, 3.14, 'A', true)을 의미 한다.

그 중에서 리터럴은 상수풀(constant pool) 영역에 저장되어 있다.

변수는 해당 리터럴이 상수풀에 있는지 확인하고 사용하게 된다.

switch문이 바뀌고 있다?

기존에 사용하던 switch 문은 다음과 같다.

switch (today) {
    case 1:
    case 2:
    case 3:
    case 4:
    case 5:
        System.out.println("today is Weekday");
        break;
    case 6:
    case 7:
        System.out.println("today is Weekend");
        break;
}

여기서 java 버전이 업그레이드 되면서 다음과 같은 기능이 생겼다.

쉼표로 구분이 가능하다.
식으로 표현하여 반환 값을 받을 수 있고, 리턴이 없으면 오류
1. switch라는 함수명을 가지고, 파라미터로 비교대상을 받는 형태로 가능하다.
break를 안쓰고 괄호로 묶을 수 있다. 또한, -> 수식을 쓴다.
switch case에서 yield 문으로 반환이 가능하다.

int day = switch(month) {
	case 1,3,5,7,8,10,12 -> 31;
    case 2 -> 28;
    case 4,6,9,11 -> 30;
    default -> {
    	System.out.println("x");
        yield -1; // 수행과 반환이 같이 쓰여서, yield를 써서 반환함을 알려주어야 한다.
    }
}; // day의 끝이므로 세미콜론 필요

Public 클래스는 하나다.

자바 파일 하나에 여러 개의 클래스가 존재할 수는 있다.

단, public 클래스는 하나이고, public 클래스와 자바 파일 이름은 동일해야 한다.

접근 제어 지시자(Access Modifier)

클래스 외부에서 클래스의 멤버 변수, 메서드, 생성자를 사용할 수 있는지 여부를 지정하는 키워드다.

private : 같은 클래스 내부만 접근 가능 (외부 클래스, 상속 관계 클래스라도 접근 불가)
default : 같은 패키지 내부에서만 접근 가능 (상속 관계라도 패키지가 다르면 접근 불가)
protected : 같은 패키지나 상속관계의 클래스에서 접근 가능하고 그 외 외부에서는 접근할 수 없음.
public : 클래스 외부 어디서나 접근 가능

Call by Value VS Call by Reference

java는 Call By Value밖에 없다. Object의 경우 주소값을 넘기는 Call By Value이기 때문에 헤깔리지만 염두해두자.

static 변수, static 메서드

여러 인스턴스가 공통으로 사용하는 변수를 static 변수라고 한다.

인스턴스가 생성될 때가 아닌, 처음 프로그램이 메모리에 로딩될 때 메모리를 할당하는 변수다.

인스턴스 생성과 상관 없이 사용가능하여, 클래스 이름으로 직접 참조한다.

static 메서드는 클래스 메서드라고도 하며, 멤버변수를 사용할 수 없는 메서드다.

이 역시, 클래스 이름으로 사용할 수 있다.

인스턴스 생성 전에 호출 될 수 있으므로, static 메서드 안에는 인스턴스 변수를 사용할 수 없다.

싱글톤 패턴에서 주로 사용하는 방법이다.

static class Singleton {
	private static Singleton instance;
    
    private Singleton() {}
    public static Singleton getInstance() {
    	if(instance == null) {
        	instance = new Singleton();
        } 
        return instance;
    }

}

public class ExampleClass {

    //private construct
    private ExampleClass() {}

    private static class InnerInstanceClazz() {
        private static final ExampleClass instance = new ExampleClass();
    }

    public static ExampleClass getInstance() {
        return InnerInstanceClazz.instance;
    }
}

형변환은 왜 이렇게 쓰고 있을까 ?

Customer c = new VIPCustomer();

위 형태를 자주 볼 것이며, 업캐스팅하여 형 변환한 케이스다.

아래 예시처럼, 상속된 구조에서 사용할 수 있는 부분으로 VIPCustomer 클래스의 모든 멤버 변수에 대한 메모리는 생성되지만, 변수 타입이 Customer이므로 실제로 접근 가능한 변수나 메서드는 Customer의 변수와 메서드가 된다.

class Customer {
    private String customerId;
    private String name;
    public String getCustomerId() {
        return customerId;
    }
}

class VIPCustomer extends Customer {
    private String vipId;
    public String getVipId() {
        return vipId;
    }
}

이 때, 오버라이딩이 되면 인스턴스 타입을 따라가게 된다.

java는 항상 인스턴스의 메서드가 호출된다 (가상 메서드 원리)

자바의 모든 메서드는 가상 메서드 (virtual method)다.

인터페이스를 구현한 클래스는 인터페이스 형으로 선언한 변수로 형 변환할 수 있다.

이 역시 인터페이스에 선언된 메서드만 사용가능하다.

가상 메서드(virtual method) 간단하게 알아보면?

메서드의 이름은 주소값을 나타낸다. (메서드는 명령어의 set이고 프로그램이 로드되면 메서드 영역(코드영역)에 명령어 set이 위치한다.)

메서드가 호출되면 명령어 set이 있는 주소를 찾아 명령어가 실행된다.

메서드 변수들은 stack에 위치하게 될 것이고, 인스턴스 변수는 힙 메모리에 있을 것이다.

메서드는 메서드 영역에 있으니 처음 한번만 호출된다.

final 예약어를 정리해보자.

final 변수 : 값이 변경될 수 없는 상수
final 메서드 : 하위 클래스에서 재정의 할 수 없는 메서드
final 클래스 : 상속할 수 없는 클래스

String의 선언은 달라질 수 있다.

String str1 = new String("AAA");
String str2 = "AAA";

1. 힙메모리에 인스턴스를 생성한 경우

2. 상수 풀(constant pool)에 있는 주소를 참조

힙 메모리는 매번 다른 주소지만, 상수 풀의 문자열은 모두 같은 주소를 가진다.

String str1 = new String("abc");
String str2 = new String("abc");

System.out.println(str1 == str2); // false

String str3 = "abc";
String str4 = "abc";

System.out.println(str3 == str4); // true

String 도 하나의 Wrapper Class이고, Reference 타입이므로 주소값(참조값)을 가진다.

상수 풀에 있는 주소를 참조하여 생성했을 때 == 연산자가 정상인 것처럼 보일 떄도 있겠지만, equal 연산자를 쓰는게 옳다.

String은 Immutable(불변)한다?

한번 생성된 String은 변하지 않는다. 즉, String을 연결하면 기존 String에 연결되는게 아니라, 완전 새로운 문자열이 생성된다. (메모리 낭비가 생길 수 있다)

그래서 StringBuilder, StringBuffer 가 나온다.

특징은 다음과 같다.

1. 내부적으로 가변적인 char[]를 가지고 있다. (새로운 인스턴스를 생성하지 않고, char[]를 변경한다)

2. StringBuffer는 멀티 쓰레드 프로그래밍에서 동기화(Synchronization)을 보장한다.

3. 단일 쓰레드 프로그램에서는 StringBuilder 사용을 권장한다.

4. toString()메서드로 String을 반환한다.

제네릭(Generic) 프로그래밍

1. 클래스에서 사용하는 변수의 자료형이 여러개일 수 있고, 그 기능(메서드)은 동일한 경우 클래스의 자료형을 특정하지 않고 추후 해당 클래스를 사용할 수 있게 지정할 수 있도록 선언한다.

2. 실제 사용되는 자료형 변환은 컴파일러에 의해 검증된다.

3. Collection 프레임워크에서 많이 사용한다.

public class GenericPrinter<T> {
	private T material;
	
	public void setMaterial(T material) {
		this.material = material;
	}
	
	public T getMaterial() {
		return material;
	}
	
	public String toString(){
		return material.toString();
	}
}

자료형 매개변수 T(type parameter) : 이 클래스를 사용하는 시점에 실제 사용할 자료형을 지정, static 변수는 사용할 수 없음

T라는 자리에 Powder, Plastic 과 같은 다른 클래스가 들어갈 수 있다. 즉, Object로도 취환해서 class를 만들 수 있다.

다만, 그렇게 안하는 이유는 형 변환을 결국 해야하기 때문.

public class ThreeDPrinter{

	private Object material;
	
	public void setMaterial(Object material) {
		this.material = material;
	}
	
	public Object getMaterial() {
		return material;
	}
}

//

ThreeDPrinter printer = new ThreeDPrinter();

Powder powder = new Powder();
printer.setMaterial(powder);

Powder p = (Powder)printer.getMaterial();

제네릭 메서드는 또 뭐지?

자료형 매개 변수를 메서드의 매개변수나 반환 값으로 가지는 메서드는 자료형 매개 변수가 하나 이상인 경우도 있다.

꼭 제네릭 클래스가 아니어도 내부에 제네릭 메서드는 구현 가능하다.

public class Point<T, V> {
	T x;
	V y;
	
	Point(T x, V y){
		this.x = x;
		this.y = y;
	}
	
	public  T getX() {
			return x;
	}

	public V getY() {
		return y;
    }
}

포인트를 만드는 간단한 제네릭 클래스이다.

이를 활용하는 제네릭 메서드도 만들어 보자.

public class GenericMethod {

	public static <T, V> double makeRectangle(Point<T, V> p1, Point<T, V> p2) {
		double left = ((Number)p1.getX()).doubleValue();
		double right =((Number)p2.getX()).doubleValue();
		double top = ((Number)p1.getY()).doubleValue();
		double bottom = ((Number)p2.getY()).doubleValue();
		
		double width = right - left;
		double height = bottom - top;
		
		return width * height;
	}
	
	public static void main(String[] args) {
		
		Point<Integer, Double> p1 = new Point<Integer, Double>(0, 0.0);
		Point<Integer, Double> p2 = new Point<>(10, 10.0);
		
		double rect = GenericMethod.<Integer, Double>makeRectangle(p1, p2);
		System.out.println("두 점으로 만들어진 사각형의 넓이는 " + rect + "입니다.");
	}
}

makeRectangle이라는 함수로 그 형태를 확인해보자.

public static <T, V> double makeRectangle(Point<T, V> p1, Point<T, V> p2)

public <자료형 매개 변수> 반환형 메서드 이름(자료형 매개변수.....) { }

메서드의 매개변수로 T,V라는 Type Parameter(자료형 매개변수)를 사용하였기 때문에, Generic Method로 볼수 있다.

다음 으로는 컬렉션, 람다, 스트림 등 jdk 1.8 이후에 격변한 내용들을 알아보려고 한다.

다만, 그 내용을 조금 간단히 먼저 알아보고, 하나씩 조금 심화해서 볼 예정이다.

[java] Rotate Array

KOOCCI — Fri, 24 Jun 2022 23:51:54 +0900

[참고문제] : https://leetcode.com/problems/rotate-array/

Rotate Array - LeetCode

Level up your coding skills and quickly land a job. This is the best place to expand your knowledge and get prepared for your next interview.

leetcode.com

문제 풀이

생각의 흐름 - Circular Linked List 다.

보자마자, Circular Linked List로 구현하면 될 것이란 건 알았다. 다만, 자료구조를 만드는게 목표가 아니니 list로 처리하기로 함.

생각의 흐름 - 어디부터 끊어지는 지 보자.

k는 받지만, 모듈러 연산은 해야겠다고 판단.

생각의 흐름 - 끊어지는 부분 앞을 그냥 뒤에 추가하고, 거기부터 읽어내자.

List에 넣어두고, 앞부분을 그냥 반복해서 넣어주고, 읽을 때 끊어졌던 부분 부터 읽자고 판단.

class Solution {
    public void rotate(int[] nums, int k) {
        k %= nums.length;
        List<Integer> arr = Arrays.stream(nums).boxed().collect(Collectors.toList());
        List<Integer> arr2 = arr.subList(nums.length - k, nums.length);
        arr2.addAll(arr.subList(0, nums.length - k));
        for(int i = 0; i < nums.length; i++) {
            nums[i] = arr2.get(i);
        }
    }
}

[java] Median of Two Sorted Arrays

KOOCCI — Thu, 23 Jun 2022 23:41:06 +0900

[참고문제] : https://leetcode.com/problems/median-of-two-sorted-arrays/

Median of Two Sorted Arrays - LeetCode

Level up your coding skills and quickly land a job. This is the best place to expand your knowledge and get prepared for your next interview.

leetcode.com

문제 풀이

생각의 흐름 - 이미 정렬되어 있다.

이미 정렬이 되어 있으니, 각각의 배열에서 계속 더 작은 수를 확인한다.

생각의 흐름 - 중앙값 까지만 확인해도 된다.

어짜피 필요한 건 중앙값이고, 중앙값까지만 확인하면 계산할 수 있다.

생각의 흐름 - 한쪽만 완료될 수 있다.

작은 수가 한쪽에만 있을 수도 있다.

이미 끝의 인덱스까지 확인했으면 다른 한 쪽만 확인하자.

public double findMedianSortedArrays(int[] nums1, int[] nums2) {
    int n = nums1.length;
    int m = nums2.length;
    int len = n + m;
    int nIndex = 0;
    int mIndex = 0;
    double result = 0.0;
    List<Integer> arr = new ArrayList<>();
    while(nIndex <= n && mIndex <= m) {
        if(nIndex + mIndex == (len / 2) + 1) {
            if(len % 2 == 0) {
                result = (arr.get((len / 2) - 1) + (double)arr.get((len / 2))) / 2;
            } else {
                result = arr.get((len / 2));
            }
            break;
        } else {

            if(nIndex != n && mIndex == m) {
                arr.add(nums1[nIndex]);
                nIndex ++;
            }

            else if(nIndex == n && mIndex != m) {
                arr.add(nums2[mIndex]);
                mIndex ++;
            } else {
                if(nums1[nIndex] <= nums2[mIndex]) {
                    arr.add(nums1[nIndex]);
                    nIndex ++;
                } else {
                    arr.add(nums2[mIndex]);
                    mIndex ++;
                }
            }
        }
    }
    return result;
}

[java] Longest Substring Without Repeating Characters

KOOCCI — Thu, 23 Jun 2022 00:45:10 +0900

[참고 문제] : https://leetcode.com/problems/longest-substring-without-repeating-characters/

Longest Substring Without Repeating Characters - LeetCode

Level up your coding skills and quickly land a job. This is the best place to expand your knowledge and get prepared for your next interview.

leetcode.com

문제 풀이

생각의 흐름 - 저장하자.

필요한 건 가장 긴 길이가 무엇이냐? 그리고 이 문자가 나왔는가?

이 2가지를 저장할 필요가 있었다.

가장 긴 길이 여부는 max 계산을 하고, 이 문자가 이미 나왔는지 여부는 Map에 저장하자고 판단.

생각의 흐름 - 언제 초기화를 하는가?

Loop를 돌면서, map이 가지고 있는지 확인한다.

그리고, 없으면 현재 길이를 늘리면서, map에 저장한다.

있다면, 1. max 여부를 판단, 2. 현재 길이 초기화, 3. map 초기화

생각의 흐름 - 어디부터 다시 확인해야 하는가?

가장 긴 길이를 확인할 때, 이미 나왔던 문자가 다시 나왔다면, 어디부터 시작해야하는지 고민해야 했다.

해당 문자가 처음 나온곳부터 계산하면 되겠다고 판단, Map의 Value에 Index를 저장하기로 판단.

생각의 흐름 - 초기화를 항상 하는가?

마지막 문자까지 간 경우도 고민해주어야 하기에, return 시에 한번 더 max 체크하는 로직을 넣었다.

public int lengthOfLongestSubstring(String s) {
    int max = 0;
    int currLen = 0;
    Map<Character, Integer> map = new HashMap<>();
    for(int i = 0; i < s.length(); i++) {
        if(map.containsKey(s.charAt(i))) {
            max = Math.max(max, currLen);
            currLen = 0;
            i = map.get(s.charAt(i));
            map.clear();
        } else {
            map.put(s.charAt(i), i);
            currLen ++;
        }
    }
    return Math.max(currLen, max);
}

자바스크립트는 무엇일까?

KOOCCI — Wed, 22 Jun 2022 22:05:10 +0900

목표 : 자바스크립트가 무엇인지, 생김새(?) 를 알아보자!

자바스크립트로 처음 개발을 시작해보았으니, 거의 10년 가까이 보고 지낸 언어다.

그럼에도 제대로 공부한건 불과 얼마 안되었기에, 한번 기초이론을 정리해보고자 한다.

자바스크립트는 기본적으로 웹페이지의 보조적인 기능(생동감을 불어주는)을 수행하기 위해 만들어졌다.

처음에는 여러 파생 언어들이 나와, 호환이 완결적이지 않은 크로스 브라우징 이슈가 발생하기 시작한다.

그로 인해, 꾸준히 발전하며 ECMAScript라는 표준 고유 명세를 가지게된 언어다.

어떻게 성장해왔을까?

최초에는 앞서 말한 대로, 웹페이지의 보조역할을 하였고 대부분 웹 서버로직 + HTML/CSS 랜더링 수준이었다.

랜더링 : HTML, CSS, 자바스크립트로 작성된 문서를 해석하여 브라우저에 시각적으로 출력하는 것

때로는 서버에서 데이터를 HTML로 변환하여 브라우저에 전달하는 과정(SSR: Server Side Rendering)을 말하기도 한다.

Ajax

서버와 브라우저가 비동기 방식으로 데이터를 교환할 수 있는 통신 기능인 Ajax(Asynchronous Javascript And XML)가 등장한다.

기존에 완전한 HTML을 전송받고, 전체를 랜더링하던 방식으로 화면이 전환되면 전체 웹페이지를 처음부터 렌더링하던 방식에서 필요한 부분의 데이터만 전송받아 변경하는 한정적 랜더링 방식이 가능해졌다.

jQuery

아직도 너무나 보편적인 라이브러리다.

jQuery의 가장 큰 역할은 다소 번거롭던 DOM(Document Object Model)을 좀 더 쉽게 제어할 수 있게 되고, 크로스 브라우징 이슈가 어느정도 해소될 수 있게 도와준 라이브러리다.

자바스크립트 엔진

자바스크립트는 브라우저뿐만 아니라 서버에서도 실행할 수 있다. 그 외에도 자바스크립트 엔진이 있으면 동작이 가능하다.

브라우저는 자바스크립트 가상 머신이라 불리는 엔진이 내장되어 있다.

엔진의 종류는 다양한데, 특유의 코드네임을 가지고 있다.

V8 - 구글에서 개발하고 Chrome과 Opera에서 쓰인다.
SpiderMonkey - Firefox에서 쓰인다.
IE - 버전에 따라, Trident, Chakra 등이 쓰인다.
Edge - ChakraCore 가 쓰인다.
Safari - SquirrelFish가 쓰인다.

즉, 엔진마다 지원 기능의 차이가 있을 수 있다.

또한 V8 엔진과 같은 엔진의 등장은 과거 웹 서버가 담당하던 로직들을 클라이언트(브라우저)로 이동했고, 이로 인해 웹 애플리케이션에서 프런트엔드 영역이 주목받게 되었다.

Node.js

Node.js는 V8엔진으로 빌드된 자바스크립트 런타임 환경이다.

조금 더 자세히 말하면 브라우저의 자바스크립트 엔진에서만 동작하던 자바스크립트를 브라우저 이외의 환경에서도 동작할 수 있도록 자바스크립트 엔진을 브라우저에서 독립시킨 자바스크립트 실행 환경이다.

Node.js는 모듈, 파일 시스템, HTTP 등 빌트인(built-in, 내장) API를 제공한다.

Node.js는 서버 환경에서도 자주 사용하기에, 백엔드와 클라이언트가 동일한 언어를 사용할 수 있어, 별도의 언어 학습없이 시작할 수 있는 좋은 길이기도 하다. (내가 그러한 경우다)

비동기I/O를 지원하며 단일 쓰레드 이벤트 루프 기반으로 동작해, 요청 처리 기능이 좋다.

즉, 데이터를 실시간으로 처리하기 위해, I/O가 빈번히 일어나는 SPA(Single Page Application)에 적합하지만, CPU 사용률이 높다면 권장되지 않는다.

CPU 사용률 : 한 컴퓨터 프로그램이 CPU를 차지하여 일을 한 시간의 양

Single Thread 이므로, 하나의 CPU를 오래 점유하면 그만큼 전체 퍼포먼스는 내려간다.

SPA 프레임워크

모던 웹 애플리케이션은 데스크톱 애플리케이션과 비교해도 손색없는 성능과 사용자 경험을 제공하는 것이 필수가 되었다. 즉, 개발 규모와 복잡도도 상승했다.

이전의 개발 방식으로는 복잡해진 개발 과정을 수행하기 어려워 지면서, 변경이 유연하고 확장이 쉬운 아키텍처를 요구하게 되고, 프레임워크가 등장한다.

그에 따라, CBD(Component Based Development) 방법론을 기반으로 하는 SPA 가 대중화 된다.

흔히, Angular, Vue.js, React 등이 그 대표적인 예시다.

CBD(Component Based Development)

모든 에러 확인의 시작점은 Divide & Conquer 이듯, 부품을 조립하듯 만드는 개발 방법이다.

Component는 독립적인 기능(서비스)을 제공하는 단위 소프트웨어 모듈을 의미하며, 이런 컴포넌트들은 결국 재사용성이나 대체성을 강화해준다.

ECMAScript

자바스크립트 표준 사양인 ECMA-262를 말한다.

프로그래밍 언어의 값, 타입, 객체와 프로퍼티, 함수, 표준 빌트인 객체 등 핵심 문법을 규정한다.

즉, 각 브라우저 제조사는 ECMAScript 사양을 준수해서 브라우저에 내장되는 자바스크립트 엔진을 구현한다.

자바스크립트는 일반적으로 기본 뼈대(Core)를 이루는 ECMAScript와, 브라우저가 별도로 지원하는 클라이언트 사이드 Web API, 즉 DOM, BOM, Canvas, XMLHttpRequest, fetch, requestAnimationFrame, SVG, Web Storage, Web Component, Web Worker등을 아우르는 개념이다.

자바스크립트의 특징은?

자바스크립트는 결국 웹 브라우저에서 동작하는 유일한 프로그래밍 언어다.

기본적으로 개발자가 별도로 컴파일을 하지 않는 인터프리터 언어이며, 대부분의 모던 자바스크립트 엔진은 인터프리터와 컴파일러의 장점을 결합해 비교적 처리 속도가 느린 단점을 해결하고 있다.

또한, 명령형, 함수형, 프로토타입 기반 객체지향 프로그래밍을 지원하는 멀티 패러다임 프로그래밍 언어다.

컴파일러 언어	인터프리터 언어
코드가 실행되기 전 컴파일 타임에 소스코드 전체를 한번에 머신 코드로 변환한 후 실행	코드가 실행되는 단계인 런타임에 한줄씩 중간 코드인 바이트 코드로 변환한 후 실행
실행 파일을 생성	실행 파일을 생성하지 않음
컴파일 단계와 실행 단계가 분리, 명시적인 컴파일 단계를 가지고, 명시적으로 실행 파일을 실행	인터프리트 단계와 실행 단계가 구분되어 있지 않음. 한 줄씩 바이트코드로 변환하고 즉시 실행
컴파일과 실행단계가 분리되어 있으므로 코드 실행 속도가 빠르다.	인터프리터 단계와 실행 단계가 분리되어 있지 않고 반복 수행되어 코드 실행 속도가 느리다.

실행 환경이 중요하다?

모든 브라우저는 자바스크립트 엔진을 내장하며, Node.js도 자바스크립트 엔진을 가지고 있다.

즉, 위와 같은 환경에서 자바스크립트는 실행할 수 있다.

다만, 브라우저와 Node.js는 용도가 다른점이 있다.

브라우저
- HTML, CSS, 자바스크립트를 실행해 웹페이지를 화면에 렌더링 하는 것이 목적
- 파싱된 HTML 요소를 선택하거나 조작하는 기능의 집합인 DOM API를 기본 제공
- 보안상의 이유로 파일 CRUD(운영체제 역할), 디바이스 상호작용 (마이크 등), Same Origin Policy 등 제약이 있다.
Node.js
- 브라우저 외부에서 자바스크립트 실행 환경을 제공하는 것이 목적
- DOM API를 제공하지 않는다.
- 파일의 생성과 수정을 지원하는 파일 시스템을 기본 제공한다.

조금 더 설명하자면, 모던 자바스크립트는 매우 안전한 프로그래밍 언어다.

메모리나 CPU같은 저수준 영역의 조작을 허용하지 않는다.

이런 접근이 불필요한 브라우저를 대상으로 만들어졌기 때문이다.