클린코드 9장 (클래스), 10장 (시스템), 11장(창발성), 12장(동시성)

JAVA/클린코드|2020. 7. 10. 09:14

클래스


  • 내부에서 동작하는 변수나 유틸리티는 protected로 선언하여 테스트에 사용하기도 한다.
  • 클래스에 기본 규칙은 작게 만드는 것. 많을수록 클래스에 대한 책임이 너무 커진다.
    SPR을 지키기 위해 클래스가 너무 많아지면 사용에 더 어렵다고 우려할 수 있으나 하나의 여러 책임을 가지고 있는 클래스를 사용하는 것 보다 더 직관적 이므로 사용하기 더 편하다.
  • 클래스 내부에 인스턴스 변수가 많아 진다는건 결국 클래스 내부에 함수와 인스턴스 변수들 사이에 응집도가 높아진다는 뜻이다. 이럴 수록 클래스를 분리해야 한다는 걸 의미한다.
  • 긴 함수를 쪼갠다 → 작은 함수 여러 개로 만든다. → 몇몇 변수와 몇몇 함수만 사용 되는 경우가 보이면 클래스로 쪼갠다.
  • 특정 기능이 변경 될 때 마다 코드가 변경되어야 하는 함수가 있다고 한다면 이는 SRP를 위반하는 행위이다. 그럴 경우 인터페이스를 만들어 기능 마다 필요한 코드를 구현하도록 하면 SRP와 OCP를 모두 위반하지 않을 수 있다.
  • 인터페이스를 선언하고 구현 클래스를 사용하는 것이 깔끔한 경우도 있으나 특정 기능이 매번 바뀌어야 하는 경우에는 변경의 위험이 있을 수 있다. 예를 들어 상황에 따라서 호출하는 api가 변경될 수 있는 경우에는 구현 클래스 레벨에서 모두 할 것이 아니라 api를 호출하는 인터페이스를 전달 받아서 처리하는 것이 더 좋다.
public interface StockExchange {
	Money currentPrice(String symbol);
}

public Portfolio {
	private StockExchange stockExchange;
	public Portfolio (StockExchange stockExchange) {
		this.stockExchange = stockExchange;
	}

	//...
}

 

 

 

 

시스템


  • 모든 애플리케이션에서 가장 중요한 부분은 관심사 분리이다.
    아래와 같은 코드의 경우 Lazy Initialization 또는 Lazy Evaluation을 사용하여 실제 필요한 순간에 할당하여 사용할 수 있다는 장점이 있으나 테스트 할 때 런타임 시에 객체 생성 로직이 합쳐져 있어서 Mock 작업도 진행해 줘야 하고 정상적으로 생성 되는지도 테스트 해야하는 두 가지의 책임이 생기기에 이는 SRP를 위반하는 행위이다. 이처럼 시스템 설정 부분과 런타임 시 필요한 부분이 연동되어 있으면 안된다. 모듈화와 관심사 분리가 잘 고려되어야 한다.
public Service getService() {
	if (this.service == null) 
		this.service = new WedulServiceImpl();
	return this.service;
}
  • Main과 application은 서로 관심사가 분리되어 있어 main은 적절하게 객체를 생성하고 application은 그 것이 잘 생성되었다는 걸 가정하에 실행하도록 하여 시스템 설정과 실행을 분리하도록 한다.
  • 객체는 인스턴스로 만드는 책임을 지지 않고 이에 대한 책임은 main이나 특수 컨테이너 제공하는 것을 DI (의존성 주입)이라고 한다.
  • 시스템은 깨끗해야하고 깨끗하지 못한 아키텍처는 도메인 논리를 흐리며 기민성을 떨어뜨린다. 도메인 논리가 흐려지면 제품 품질이 떨이지고 버그가 숨어들기 쉬워지고 생산성이 떨어진다.
  • 시스템이든 모듈이든 실제로 돌아가는 가장 단순한 수단을 사용해야 한다는 사실을 명심하자.

 

 

 

창발성


설계 규칙 4가지

 

 

모든 테스트를 실행하라.

  • 테스트를 통해 의도대로 돌아가는지 확인하는 건 당연한 역할
  • 테스트를 진행하다 보면 설계 품질은 더불어서 상승한다.
  • 결합도가 높으면 테스트가 어렵기 때문에 테스트를 작성하면서 DIP, DI, 인터페이스, 추상화 등과 같은 도구를 사용해 결합도를 낮출 수 있다.
  • 완벽한 테스트 코드를 만들고 나면 코드를 수정하는 리팩토링 과정을 거친다 하더라도 검증이 잘 되기 때문에 기존 코드가 잘 동작하지 않을거라는 불안에서 벗어 날 수 있다. 그래서 장기적으로 보나 단기적으로 보나 테스트 코드는 중요하다.
  • 핵심은 응집도를 높이고, 결합도를 낮추고, 관심사를 분리하고, 시스템 관심사를 모듈로 나누고, 함수와 클래스 크기를 줄이고, 더 나은 이름을 선택하는 것.

 

중복을 없애라

  • 같은 기능을 여러곳에서 생성하는 건 수정이 있을 때 여러곳에 작업이 필요로 하다.
  • 중복을 해결 하기 위해서는 TEMPLATE METHOD 패턴을 참고하라.
// 중복으로 들어가는 코드는 추상 클래스 내부에서 정의하고 
// 개별적으로 사용되는 부분만 abstract 메소드 선언한 뒤, 그 코드들을 공용으로 쓰는 메소드를 만들어라.



// 직원들 임금을 정하는 템플릿 클래스
public abstract class Pay {

  public int salary() {
	return commonSalary() + ratingBouns();
  }

  public int commonSalary() {
	return 100000;
  }

  abstract protected int ratingBonus();
}

// 정규직 임금
public class regularPay extends Pay {

  @Override
  protected int ratingBonus() {
	return 12321;
  }
}

// 비정규직 임금
public class temporaryPay extends Pay {
  
  @Override
  protected int ratingBonus() {
	return 21251;
  }
}

 

의도를 표현하라.

  • 표준 명칭과 가식성 좋은 이름을 사용하고 함수와 클래스 크기등을 잘 조절하여 같은 동료가 이해하기 쉽게 작성하라.

 

클래스와 메서드의 수를 최소로 줄여라

  • 클래스와 메서드 수를 줄이기 위해 무조건 인터페이스먼저 선언하고 진행을 하거나 하는 습관도 좋다.
  • 중복을 제거하고 테스트케이스를 잘 만들어 나가서 클래스와 메서드의 수를 최대한으로 줄여보자.

 

 

 

동시성


  • 대량의 데이터를 동시에 실행시키면 단일로 실행시킬 때 보다 더욱 효율적이다.
  • 원칙적으로 각 서블릿 스레드는 다른 서블릿 스레드와 무관하게 자신만의 세상에서 돌아간다.
  • 동시성은 부하를 유발할 수 있고 복잡하며 버그가 발생할 시 재현이 어렵다.
  • 동시성을 방어하기 위해서는 우선 동작 단위를 작게 하여 SRP를 꼭 지켜야 한다.
  • 그리고 임계영역을 제한하고 그 임계영역을 최대한 작게 만들어서 다른 동작에 영향 없게 설계 해야 한다.
  • ConcurrentHashMap과 같은 다중 스레드 환경에서 안전한 라이브러리를 활용하라.
  • 동기화 코드를 실행할 시 알수 없는 에러가 발생할수도 있는데 이를 단순 일회성 오류라고 생각하지 말고 실패할 수 있는 모든 경우의 테스트를 실행하라.

 

 

 

그 이후 내용은 특정 라이브러리를 개선하는 작업등이 남아있는데 이 부분은 따로 정리하지는 않는다.

결론은 기본에 충실하고 코드의 나쁜 품질을 지키기 위해서 컨벤션 정의가 필요하다고 생각된다. 결국 일은 혼자하는 것이 아니기 때문에 컨벤션 정의가 없으면 새로들어오는 사람이나 기존의 사람도 계속 코드를 유지하기는 어렵다고 판단된다. 이 기회에 이 규칙과 기존에 공부했던 내용들을 토대로 컨벤션을 한번 만들어 봐야겠다.

댓글()

클린코드 7장(경계), 8장 (단위 테스트)

JAVA/클린코드|2020. 7. 1. 09:18

 

 

경계


  • Map과 같은 공개된 인터페이스를 사용할 때 2가지 문제가 있다
    1. 전달되는 map에 clear와 같은 삭제 명령어가 있어서 전달해주는 쪽에서 알지 못하고 지워지는 이슈가 있을 수 있다.

    2. 전달된 Map 형태가 generic 하게 전해 졌어도 받는 쪽에서 Map map 등으로 받아 버린다면 캐스팅을 해서 사용하는 등의 문제나 변경의 소지가 크다. 또한 Map의 사용 방식이 변경된다면 이를 해결하기 위해 모든 부분에서 수정되어야 하는 문제가 있다.

    그래서 이를 해결하기 위해서 Map에 사용 되는 Value 값의 객체에서 Map을 품어서 쓰는 방식으로 캡슐화하여 사용하기도 한다.
public classs Sensors {
	private Map<String, Sensors> = new HashMap<>();

	public Sensor getById(String id) {
		return (Sensor) sensors.get(id);
	}

}
  • 외부 라이브러리를 사용할 경우 시간 단축에 효과가 있지만 잘못 사용함에 있어서 발생하는 영향도가 얼마나 있을지 알지 못하기 때문에 학습 테스트를 통해 외부 api에 대한 테스트를 미리 진행한다.
  • 외부 라이브러리에 대한 학습 테스트를 진행하여 사용하면 해당 라이브러리의 버전이 올라갔을 때 우리가 사용하는 목적에 맞게 정상적으로 돌아가는지 쉽게 테스트를 해볼 수 있어서 좋다.
  • Adapter pattern을 이용하여 변경의 요지가 있는 인터페이스를 방어할 수 있다.
public interface Bark {
	void speak();
}

// dog는 짖으므로 Bark 인터페이스 사용가능
public Dog implements Bark {
	@Override
	public void speak() {
		..
	}
}

// 고양이 야용 인터페이스
public interface Meow {
	void speak();
}

// 고양이는 짖기 어려움
public Cat implements Meow {
	@Override
	public void speak() {
	
	}
}

// 고양이가 짖을 수 있는 adpater 생성
public BarkCat implements Bark {
	private Meow meow;

	public BarkCat(Meow meow) {
		this.meow = meow;
	}
	
	@Override
	public void speak() {
		meow.speak();
	}
	
}

 

 

 

단위 테스트


  • 단위 테스트
    1. 실패하는 단위 테스트를 작성할 때 까지 실제 코드를 작성하지 않는다.
    2. 컴파일이 실패하지 않으면서 실행이 실패하는 정도로만 단위테스트를 작성한다.
    3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

    하지만 이렇게 모두 작성하면 시간이 너무 걸려서 사실 어렵다.
  • 실제 코드가 변경될 때 마다 테스트 코드는 계속 변경의 여지가 있기에 지저분한 테스트 코드를 짜느니 없으니만 못하다. 그렇기에 실제 코드 못지 않게 중요하게 테스트 코드를 작성하라.
  • 테스트 코드 없는 실제 코드 변경은 잠정적인 버그와 같다.
  • 깨끗하고 효율성있는 테스트 코드를 작성하기 위해서는 무엇보다 중요한 건 가독성이다.
  • BUILD-OPERATE-CHECK 패턴을 사용하여 테스트 구조를 간결하게 작성한다.
  • 테스트 코드의 가독성을 위해서 실제 코드에서 지켜야 할 모든 규칙을 지킬 필요는 없다.
  • 하나의 테스트당 assert문이 많으면 좋지 않지만 그렇다고 테스트당 하나의 assert문을 사용하는건 중복코드를 양성할 수 있다. (적절하게 사용)
  • 하나의 테스트당 assert문이 많으면 좋지 않지만 그렇다고 테스트당 하나의 assert문을 사용하는건 중복코드를 양성할 수 있다. (적절하게 사용)
  • 깨끗한 테스트 코드의 FIRST 규칙
    F : 테스트는 빨라야 한다.
    I : 테스트는 서로 의존적이면 안된다.
    R : 테스트는 어떤 환경에서도 반복 가능해야 한다.
    S : 테스트는 통과 실패 두가지 검증 결과를 내보내야 한다.
    T : 단위테스트는 적시에 테스트 코드가 존재해야한다. (실제 구현 코드를 작성하기 이전에 작성되어야 한다.)

 

 

 

결론


개발을 하다보면 일정에 쫓기거나 테스트 코드 작성이 번거로워서 넘어가는 경우가 있는데 무조건 작성할 수 있도록 해야겠다. 그리고 테스트를 내가 알아볼 수 있도록 기능 동작에 중점을 주어서 했었는데 그게 결국 가독성과 재사용성을 떨어트려서 팀의 개발 속도를 저해 할수도 있다는 걸 알게 되어 조심해야겠다.

 

댓글()

클린코드 5장(객체와 자료구조), 6장 (오류처리)

JAVA/클린코드|2020. 6. 29. 11:25

 

객체와 자료구조


  • 객체에서 자료를 세세하게 공개하는 것 보다 추상화를 통해 표현하는 것이 더 좋다.
  • 객체는 동작을 공개하고 자료를 숨긴다.
  • 복잡한 시스템을 짜다보면 새로운 함수가 아니라 새로운 자료타입이 필요한 경우가 발생하는데 이 때는 클래스와 객체 지향 기법이 적합하다. 하지만 새로운 함수가 필요하다면 절차지향 코드와 자료구조 형태가 더 적합한 코드이다.

 

 

 

 

오류처리


 

  • 오류를 일일히 처리하는 것보다 차라리 예외를 던저버리는게 더 깔끔하다.
  • 확인된 예외를 처리하기 위해서 하위 메소드에서 throws를 하게되면 상위 메소드에서 이 예외에 대한 명시가 되어야 하기 때문에 하위의 예외 때문에 상위 메소드가 수정되어야 하는 불상사가 발생하기 때문에 수정에 닫혀 있어야 하다는 OCP규칙을 위반한 것이다.
  • 예외에 의미있는 내용을 함께 던져서 의미 파악에 도움이 되게 하라.
  • 에러가 발생하였을 때 null을 반환하는 코드는 일거리를 늘릴 뿐만 아니라 호출자에게 일감을 더 주게 되는 문제가 있다.
  • 에러를 모두 한 곳에서 처리하게 되면 아래와 같이 귀찮게 된다. 이를 매번 open()을 사용하는 곳에서 처리하게 되면 엄청나게 귀찮게 되고 의존성이 있어 하나의 오류가 늘어나게 되면 모든 사용하는 곳에서 처리를 해줘야 한다. 그래서 이를 별도의 클래스를 만들어서 클래스 내부에서 innerPort.open()을 실행시키게 해서 그 곳에서만 에러 내용을 처리해주고 정재된 Exception만 다시 던지게 하는 것도 방법이다.
// 문제
public void open() {
	try { 
		innerPort.open();
	} catch (DeviceResponseException e) {
		...
  } catch (NetworkErrorException e) { 
		...
  } catch (BindingException e) {
    ....
  } catch ....

} 


// 감싸기 클래스 사용
public class LocalPort {

  private ACMEPort innerPort;

  public void open() {
		try { 
			innerPort.open();
		} catch (DeviceResponseException e) {
			// 내부에서 약속된 하나의 에러 패턴을 사용.
			throw new PortDeviceFailuer(e);
	  } catch (NetworkErrorException e) { 
			throw new PortDeviceFailuer(e);
	  } catch (BindingException e) {
			throw new PortDeviceFailuer(e);
	  } catch ....
	  }
	}
}

 

 

 

 

결론

에러처리를 잘못하면 코드가 굉장히 더러워진다. 실제로 많이 경험해봤고 아직도 어렵다. 중요한건 내부에서 발생한 에러로 인해 상위에서 호출하는 함수의 코드가 변해야 하는 OCP 위반 사항을 발생시키지 않도록 하는 것 같다.

댓글()

클린코드 3장 (함수), 4장 (주석)

JAVA/클린코드|2020. 6. 20. 23:04

 

함수


- 함수를 만드는 기본 규칙은 작게 만드는 것!

 

- 함수 내부에 if 문 등의 1단이나 2단 그 이상의 중첩 구조가 발생되면 안된다.

 

- 함수의 활동은 한가지 그 이상을 하지마라.

 

- switch문에 다음과 같이 한가지 작업만 해야한다는 SRP 이론과 코드의 변경이 있으면 안된다는 OCP 규칙을 위반한다. 이를 해결하기 위해서는 다형성을 이용해서 해결해야 한다.

// 문제 코드
public int calEmployeePay(Employee e) {
	switch (e.type) {
		case SALARIED:
			return calculateSalariedPay();
		case HOURLY:
			return calculateHourlyPay();
		case .....
	}
}

// 변경 내용
public interface Employee {
	int calPay();
}


public SalaryEmployee implements Employee {
		
		@Override
		public int calPay() {
				...
		}
}

public int calEmployeePay(Employee e) {
	return e.calPay();
}

- 함수 이름이 길어지더라도 서술적으로 한방에 이해가 가능한 이름이 오히려 더 깔끔하고 좋은 코드다.

  ex) includeSetupAndTeardownPages..

 

- 함수의 인수는 기본적으로 3개 까지가 사실 마지노선이라고 생각하고 그 이상은 절대 오지 않도록 해라. 인수가 있으면 함수 자체를 이해하는데 더 어려움을 겪게 된다.

 

- 인수가 늘어난다면 별도의 인수 객체를 만들어서 묶어서 보내는 게 더 낫다.

  ex) int x, int y ⇒ Point point

 

- 함수의 이름과 인자가 한꺼번에 이해가 가능한 이름에 가장 좋다.

  ex) write(name), assertExpectedEqualsActual(expected, actual)

 

- 함수의 이름과 다른 행위를 함수안에 실행 시키지 마라 ex) checkPassword() 함수내에서 사용자 세션을 초기화 한다거나 하는 행위는 자칫하면 엄청 큰 버그를 일으킬 가능성이 크다.

 

- 에러 코드를 사용하는 것보다는 try catch를 이용해서 에러 코드를 분리하는 것이 좋고, try catch블록은 모든 영역이 아닌 별도 함수내에서 처리하도록 하는 것이 좋다.

 

- 중복된 코드를 계속 양산하지 마라.

- 모든 함수와 함수 내 모든 블록에 입구와 출구는 하나만 존재해야 한다.

 

 

 

 

주석


- 잘 작성된 주석은 이해가 되지만 경솔하고 근거없는 주석은 코드를 더 이해하기 어렵게 만든다.

 

- 주석은 코드로 의도를 표현하지 못해서 실패를 만회하기 위해 적은 코드이다. 그러므로 주석을 달고 있다면 코드를 잘 못 작성한 건 아니지 잘 생각해봐라.

 

- 주석은 언제나 코드를 따라가지 못하기 때문에 언젠가 주석은 코드와 분리되어 고아가 되어버리는 순간이 오기 때문에 조심해야 한다.

 

- 저작권 등의 정보를 알리거나 외부 라이브러리 등의 사용이나 내부 규약으로 인해 어쩔수 없이 사용하는 인자 등의 부분에 대해서 명료한 설명을 위한 주석 또는 결과 값에 대한 결과에 대한 주석 정도는 괜찮다.

 

- 누군가의 공을 달거나 HTML 주석을 위해 사용하거나 근처 코드가 아닌 다른 코드에 대한 주석 등을 다는 이런 코드들은 코드 개선에 시간을 들이는 게 더 낫고 클래스 파일에 바이트나 낭비하지 말아라.

 

 

 

결론

함수

함수는 당연히 나도 의미가 있도록 사용하기 위해서 네이밍에 많은 고민을 하고 있고 같이 일하시는 분들이 잘 이해할 수 있도록 간결하게 만들려고 노력은 하고 있다. 근데 사실 프로젝트가 커지고 하다보면 쉽지 많은 않다. 흑

 

주석

주석은 15년도에 일을 시작했을 때만해도 선배들이나 주변 개발 컨벤션에서 보면 항상 주석을 달라고 되어 있었고 오픈소스로 나와있는 라이브러리들에도 자세한 설명이 기재되어 있었다. 그래서 따라하는 습관을 들였는데 주석이 말한 그대로 코드를 따라가기 어려웠고 어느순간부터는 주석이 도움이 되는게 아니라 오히려 방해가 된다는 생각을 나 또한 들게 되어 지금은 주석대신 코드를 더 명확하게 짜기 위해서 노력하고 있다.

 

 

댓글()

클린코드 1장(깨끗한 코드), 2장 (의미있는 이름)

JAVA/클린코드|2020. 6. 17. 20:39

 

깨끗한 코드


태도

  • 나쁜 코드는 생산성을 떨어트리고 갈수록 생산성 0로 수렴하게 만든다.
  • 일정에 쫓겨서 만든 나쁜 코드를 나중에 고치려는 습관은 버려라. 르블랑의 법칙 대로 나중은 결코 오지 않는다.
  • 핑계될 것 없다 모두 개발자 탓이다.
  • 시간이 없어서 만든 잘못된 코드는 결국 일정을 빠르게 앞당기는 것이 아니라 결국 그 잘못된 코드로 일정을 지연시킨다.

깨끗한 코드란?

  • 논리가 간단해야 한다.
  • 의존성이 줄어 유지보수가 쉬워야 한다.
  • 성능이 최적화 되어 있어야 한다.
  • 오류는 확힐 하게 처리해야 한다.
  • 많은 일을 하지말고 한가지 잘하는 일을 잘하는 코드를 만들어라.
  • 테스트 케이스가 없는 코드는 깨끗한 코드가 아니다.
  • 중복이 없다.
  • 코드를 최대한 줄인다.
  • 지속적으로 나빠지는 코드를 개선한다.

결론

  • 백날 좋은 코드에 대한 이론만 공부해서는 도움이 되지 않는다. 남의 코드를 지켜보고 개선하면서 꾸준히 연습하자.

 

 

의미 있는 이름


  • 의미있는 이름을 지어라.
  • 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.
  • 약어를 사용하지 말고 명확한 이름을 기재하라. 비슷한 이름을 사용하지마라. ex) studentAccont, studentAccountNum 두 개 의미가 어떤건지 모호해진다.
  • Info, Data는 a, an과 같은 불용어로써 불분명하니 사용하지 마라.
  • 불용어를 계속 사용하면 중복을 만들게 된다. ex) AccountInfo는 Account와 헷갈리고 BankAccoutData는 BankAccount와 헷갈리게 된다.
  • 단축시키려 하지말고 읽기 좋게 명확하게 코드를 작성하라 ex) genymdhms → generationTimestamp;
  • 상수는 변수로 선언해서 의미를 부여하라.
  • 인터페이스에 I 접두어를 붙이지 말아라. ex ) IShapeFactory → ShapeFactory, 구현 클래스 ShapeFactoryImpl
  • 클래스 이름은 명사나 명사구가 좋고 Data, Info 같은 명사구는 피하고 동사는 사용하지 마라
  • 메소드 이름은 동사나 동사구를 사용하라
  • 의도를 분명하게 솔직한 이름을 사용하라
  • 하나의 개념에 단어는 하나의 이름을 사용하라ex) fetch, retrieve, get 필요 시 마다 제각각 다른 단어를 선택 하지말고 하나로 통일해서 사용하라.
  • 행동이 다르다면 굳이 동일한 이름을 사용하지 말고 다른 이름을 사용하라
  • 클래스이름으로 너무 범용적인 이름을 사용하게 된다면 동일한 기능을 하는 다른 클래스가 생길 때 이름을 정하기 어려워진다. ex) CustomerAddress를 고객 주소관리 클래스로 썼다면 고객 주소가 하나 더 늘거나 관리 데이터가 변경된다면?

 

결론

개발하다보면 진짜 어려운게 이름 규칙이다. 근데 하다보면 위에 써있는 대로 동일한 이름의 클래스들이 많이 만들어진다. 중복되는 불용어들을 줄이고 명확한 의미가 있는 클래스를 만들 수 있도록 노력해보자. 말 그대로 이름을 짓는 시간보다 잘못된 이름을 만들어 드는 시간이 더 크다는 걸 잊지말자.

댓글()

모던 자바 인 액션 내용 정리

JAVA/고급 자바|2020. 4. 12. 16:46

 

포킹 

자바 8에서 추가된 스트림 api에서 데이터를 필터링, 추출, 그룹화 등의 기능을 진행할 수 있다. 이러한 동작들을 병렬화 할 수 있어 여러 cpu에서 작업을 분산해서 처리할 수 있다. 이런 작업을 포킹 단계라고 한다.

 

 

함수형 인터페이스

- 하나의 추상메서드를 가지고 있는 함수형 인터페이스지만 상속을 받은 인터페이스는 추상메서드를 하나만 가지고 있다고 하여도 함수형 인터페이스가 아니다.

- 디폴트 메소드가 아무리 많아도 추상 메소드가 하나이면 함수형 인터페이스이다.

- @FunctionalInterfeace 애노테이션을 붙이면 함수형 인터페이스가 아닌 경우 컴파일 에러를 발생 시킬 수 있다.

 

 

람다에서 지역변수를 final로 제약하는 이유 

람다에서 지역변수가 final로 사용되는지 궁금한데 이는 인터페이스 변수는 힙에 저장되고 지역변수는 스택에 저장되는 이유가 대표적이다. 람다에서 지역변수에 바로 접근할 수 있다는 가정하에 람다가 스레드에서 실행된다면 변수가 할당한 스레드가 사라져서 변수 할당이 해제되었는데도 람다를 실행하는 스레드에서는 해당 변수에 접근하려 할 수 있다. 그렇기 때문에 람다 내부에서 사용하는 값은 복사본으로써 그 값은 변경되면 안된다는 제약이 존재한다. (그래서  무조건 final로 제약하는 것)

 

 

predicate에는 여러 and, or, negete등이 사용이 가능하다.

and와 or로 predicate를 연결 할 수 있고 negete로 반대의 값을 가져올수도 있다.

 

List<String> dish = Arrays.asList("banana", "pizza", "chicken");

Predicate<String> isBanana = new Predicate<String>() {
	@Override
	public boolean test(String s) {
    	return s.equals("banana");
	}
};

Predicate<String> isChicken = new Predicate<String>() {
	@Override
	public boolean test(String s) {
    	return s.equals("chicken");
	}
};

Predicate<String> isNotPizza = new Predicate<String>() {
	@Override
	public boolean test(String s) {
    	return !s.equals("pizza");
	}
};

// predicate or
System.out.println(dish.stream().filter(isBanana.or(isChicken)).collect(Collectors.joining(", ")));

// predicate and
System.out.println(dish.stream().filter(isBanana.and(isChicken)).collect(Collectors.joining(", ")));

// predicate negate
System.out.println(dish.stream().filter(isBanana.negate()).collect(Collectors.joining(", ")));

 

 

Map의 문제 FlatMap으로 해결

- 문제상황

["hello", "world"] 두개의 단어에서 알파벳 중복된 걸 빼고 하나의 알파벳 배열로 합쳐 보자. 구하고자 하는 결과물은 다음과 같다. ["H", "e", "l", "o", "W", "r", "d"]

 

- Map으로 진행

List<String> str = Arrays.asList("hello", "world");

str.stream()
    .map(data -> data.split(""))
    .distinct()
    .collect(Collectors.toList());

이렇게 하면 각 문자열에서 문자로 쪼개고 거기서 distinct작업을 한뒤 합쳐서 성공적으로 하나의 list안에 중복된 문자가 없을 것 같지만 실제로는 ["hello"], ["world"]가 노출 된다. 

 

왜냐하면 실제로 동작하는은 다음과 같이 진행되기 때문이다.

hello → ["h","e","l","l","o"] (split하면 문자열 배열로 반환) 
world → ["w", "o", "r", "l", "d"] (split하면 문자열 배열로 반환) 

최종
→ distinct 대상이 string[] 결국 두개가 합쳐져 Stream<String[]>이 된다.

그럼 이를 해결 하기 위해서 map에서 생성된 배열이 dinstinct로 넘어갈 때 각 값을 다른 스트림으로 만든 다음 모든 스트림을 하나의 스트림으로 연결해야 하는데 이를 flatMap으로 해결이 가능하다.

 

List<String> str = Arrays.asList("hello", "world");
        System.out.println(str.stream()
            .map(data -> data.split(""))
            .flatMap(Arrays::stream)
            .distinct()
            .collect(Collectors.toList()));

map으로 반환된 Stream<String[]>에서 각 String[]을 Stream으로 변형한 후 하나의 stream으로 합쳐서 distinct를 진행하면 정상적인 결과가 도출된다.

 

flatmap은 각 요소를 별도의 스트림으로 만든 후 다시 합쳐준다. 또한 flatMap은 스트림을 받아 다른 스트림으로 변경해주는 역할을 한다.

예를 들어 (1, 2, 3) 배열과 (4, 5) 배열이 있을 때 이 두개를 합쳐서 (1, 4), (1, 5), (2, 4), (2, 5), (3, 4), (3,5) 이렇게 묶고 싶으면 다음과 같이 flatMap을 사용하여 두개를 합칠 수 있다.

List<Integer> data1 = Arrays.asList(1, 2, 3);
List<Integer> data2 = Arrays.asList(4, 5);
data1.stream()
	.flatMap(
		data -> data2.stream().map(j -> new int[] {data, j})
	)
	.collect(Collectors.toList());

만약 map(data → data.2stream().map(j → new int[] {data, })로 사용했으면 결국 최종적으로 Stream<Stream<int[]>>가 만들어지는 아쉬운 결과가 나올 수 있다.

 

 

findFirst와 findAny 차이

findFirst와 findAny는 같은 결과를 가져오지만 병렬 스트림에서는 findFirst로 첫 번째 요소를 가져오는게 어렵기 때문에 그런 경우에는 findAny를 사용한다.

 

 

parallel stream과 fork/join

parallel을 사용하여 fork/join 병렬을 진행 할 수 있다. 병렬 스트림은 기본적으로 ForkJoinPool을 사용하는데 이는 프로세스 수 즉 Runtime.getRuntime().availableProcessor()가 반환하는 값에 상응하는 스레드를 갖는다. 이 fork/join의 스레드 수는 조절이 가능하다.

 

 

Optional Serialize

Optional의 경우에 serialize를 구현하지 않았기 때문에 이는 직렬화 될 수 없다.

 

 

옳지 못한 상속 차단

코드 양이 많고 동작이 변경 되기를 원치 않는 클래스의 경우 final로 선언 또는 private 생성자를 지정한다. 이렇게 되어 있는 클래스의 기능을 이용하기 위해서는 델리게이션 즉 멤버 변수로 이용해서 클래스에서 필요한 메서드를 직접 호출하는 메서드를 작성하는 것이 좋다.

 

 

다중 상속 상황에서 동일한 이름의 메소드 우선순위

1. 클래스가 무조건 이긴다.

2. 서브 인터페이스가 이긴다. 예를 들어 B 클래스가 A 클래스를 상속받는다면 B 클래스가 무조건 A 클래스를 이긴다.

3. 이래도 불명확한 경우에는 여러 인터페이스를 상속받은 클래스에서 명시적으로 받고자 하는 곳을 지정할 수 있다.

 

 

CompletableFuture와 리액티브 프로그래밍 컨셉

값이 있을 때는 onNext, 도중에 에러가 발생했을 때는 onError, 값을 다 소진했거나 에러가 발생해서 더 이상 처리할 데이터가 없을 때 onComplete 등 각각의 콜백이 호출 된다. 이런 이벤트는 보통 순서의 개의치 않는다.

 

CompletableFuture 클래스의 join는 Future 인터페이스의 get 메소드와 동일한 의미로써 작업이 끝날 때 까지 기다린다. 다만 join은 어떠한 예외도 발생시키지 않는다는 차이점이 존재한다.

 

publisher는 subscriber가 자신을 구독하는 경우 최초로 onSubscribe를 호출하여 SubScription 객체를 전달한다. 이 Subscription 인터페이스는 publisher에게 이벤트 요청을 알리는 request 메소드가 있고 더 이상 받지 않겠다고 하는 cancel이 존대한다. 

 

publisher는 반드시 Subscription의 request 메소드에 정의된 개수 이하의 요소만 Subscriber에게 전달 할 수 있다. 해당 요청을 받은 publisher는 subscriber에게 onNext를 통해 여러번에 통해 데이터를 전달 할 수 있고 전달된 값에 따라 onComplete, onError를 통해 publisher에게 데이터 전달 성공 유무를 전달 할 수 있다. 이 대화는 publisher가 subscriber에게 전달한 subscription을 통해서 이루어진다.

 

 

 

 

 

책 전체가 조금 재미없게 구성되어 있다. 그래도 정리할 수 있어 좋았다.

댓글()

Java 메모리 구조 및 GC 알고리즘 정리

JAVA/고급 자바|2019. 9. 23. 22:07

자바 메모리 구조는 1.8 이후로 일부분 바뀌었다.

이 부분에 대한 정리를 다시 하고 싶었고 GC 알고리즘에 대한 종류와 상세 내용을 정리하고 싶었다. 그럼 이 두 가지 사항에 대해 가볍게 정리해보자.

Java 메모리 구조

Method Area

프로그램이 실행되는 도중에 아직 사용되지 않은 클래스들의 코드는 new를 통해 클래스의 인스턴스가 생성되면 JVM Method Area에 인스턴스 변수, 메스드 코드, 클래스 변수등을 저장한다. 해당영역은 모든 쓰레드 사이에서 공유되고 static 키워드로 생성된 변수 또한 저장을 Runtime Constant Pool 영역에 저장한다. 실 데이터를 저장하는 것이 아니라 레퍼런스만 저장하며 실제 데이터는 Heap 영역에 저장한다.

 

JVM Language stack

각 스레드들은 생성과 동시에 각자의 stack을 생성하게 되는데 이 영역에 메소드가 실행될 때 사용된 메스드의 데이터들을 저장한다. 그리고 메서드 실행이 끝나면 해당 stack영역은 사라진다.

 

PC Registers

각 스레드별로 PC Registers가 존재하며 JVM 머신이 가장 최근에 실행한 명령어의 주소를 저장한다.

 

Native Method Area

Native Library에 의존하는 native 코드들을 저장하는 곳이다. (JNI)

 

Permenent (Java8 metaspace 대체)

permenent 영역에 로드된 클래스의 메타 정보와 static한 변수들 정보들이 담겨져 있는데 그 중 static 영역과 상수 영역은 heap으로 옮겨졌다.

-XX:MetaspaceSize : JVM이 사용하는 네이티브 메모리 
-XX:MaxMetaspaceSize : metaspace의 최대 메모리 

 

Heap 영역

GC가 발생되는 대표적인 영역이며 new를 통해 인스턴스가 동적으로 생성된 데이터와 배열정보를 저장하는 공간으로 xms, xmx등의 옵션으로 기본 힙사이즈를 설정할 수 있다. 해당 힙사이즈도 모든 쓰레드 사이에서 공유된다.

-Xms : JVM 시작 시 힙 영역 크기
-Xmx : 최대 힙 영역 크기

힙 영역은 GC가 발생되는 방법에 따라 Young, Old영역으로 나뉘게 된다.

1. Young 영역 

Eden

새롭게 할당된 데이터가 쌓이는 곳으로 일정주기 동안 참조가 유지되면 Survivor로 옮겨진다. Survivor로 옮겨지지 못한 데이터는 GC에 의해 청소된다.

Survivor

Eden영역에서 넘어온 데이터가 1 또는 2영역으로 나눠서 저장된다. 참조가 살아있는 경우 주기에 맞춰서 다른 Survivor영역으로 이동하고 그렇지 못한 데이터들은 GC에 의해서 처리된다. 위와 같은 경우를 Minor GC라고 한다. 

-XX: NewRatio      : New영역과 Old 영역의 비율
-XX: NewSize       : New 영역의 크기
-XX: SurvivorRatio : Eden 영역과 Survivor 영역의 비율

 

2. Old 영역

Survivor 영역에서 오래 살아남은 데이터의 경우 Old 영역으로 넘어가게 된다. Old 영역은 이렇게 넘어온 데이터가 많기 때문에 Young크기 보다 더 크게 설계되며 이부분에서 발생된 GC를 Major GC라고 한다.

 

GC 알고리즘

YOUNG, OLD GC가 발생되는 알고리즘 종류에 대해 정리해보자. 우선 GC의 경우 mark > sweep > compaction 작업이 순서대로 동작한다. 우선 GC 대상을 고르는 mark 작업이 선행되고 실제 제거를 수행하는 sweep가 동작한다. 그리고 메모리의 파편화가 된 부분을 채워 나가는 Compaction 작업으로 마무리한다.

Serial GC

위에서 언급한 3가지 작업이 진행되는 간단한 GC 알고리즘이다. 이 GC의 경우 처리하는 쓰레드가 단 하나이기 때문에 처리하는 과정 동안에 발생하는 STW (Stop the world) pause 시간이 길다.

 

Parallel GC

Serial GC에서 동작하는 스레드가 하나였기 때문에 문제가 자주 발생하였는데, 여기에 작업을 진행하는 스레드를 추가하여 병렬로 작업을 진행한 알고리즘 이다.

왼쪽부터 Serial GC, Parallel SerialGC (https://www.oracle.com/technetwork/java/index.html)

CMS GC

기존에 사용되던 GC 알고리즘 보다 STW pause 시간을 줄이기 위해 고안된 방법으로 없애야 하는 데이터를 정확하게 선별하는 작업이 추가로 진행된다. 그만큼 연산작업이 추가되어 CPU같은 리소스 자원 사용이 증가하였다. 최초 GC 판단하는 initial Mark, initial mark때 선정된 객체를 참조 하는 객체의 GC 대상인지 판단하는  Concurrent Mark, 마지막 검증 작업을 하는 Remark작업을 통해 대상을 선정한 후 Concurrent Sweep 작업을 통해 데이터를 지운다. 그리고 기존 Serial GC와의 차이점은 데이터를 sweep한 후 compaction 작업을 자주 진행하지 않는다. 파편화된 메모리를 자주 매꾸면 그만큼 오버헤드가 많이 발생할 수 있기 때문에 심각한 파편화가 발생했을 때만 매꾼다.

 

G1GC

기존에 GC 알고리즘과는 다른 알고리즘이 나온게 G1GC이다. 기존에는 Eden, Survivor, Old, Permanent영역으로 정확하게 나누어져 있었다. 하지만 G1GC 사용할 경우 heap 영역을 2048개 region 영역으로 쪼개고 이 지역의 크기는 G1HeapRegionSize를 통해 32mb 까지 지정이 가능하다.

또한 새로운 형태의 상태값이 생겼는데 Humongous와 Available/Unused이다. Humongous는 region크기의 50%를 초과하는 큰 데이터를 저장하기 위한 곳이고 Available/Unused는 아직 사용하지 않는 region을 뜻 한다.

각 Region은 Eden, Survivor, Old, Permanent, Humongous, Available/Unused 상태로 지정이 가능하고 데이터가 가장 많이 찬 Region에서 GC가 발생된다. 

G1GC 사용 시 heap 영역 (https://c-guntur.github.io/java-gc/#/6)

 

 

출처

https://www.guru99.com/java-virtual-machine-jvm.html
https://d2.naver.com/helloworld/1329

댓글()

백준 4673번 셀프 넘버

JAVA/알고리즘|2019. 6. 14. 23:45

1 ~ 10000까지의 숫자중에 셀프 넘버가 아닌 데이터를 noSelfNumber에 집어넣고 loop를 순회하면서 selfNumber 여부를 체크하면 된다. 간단한 문제이다.

https://www.acmicpc.net/problem/4673

 

4673번: 셀프 넘버

문제 셀프 넘버는 1949년 인도 수학자 D.R. Kaprekar가 이름 붙였다. 양의 정수 n에 대해서 d(n)을 n과 n의 각 자리수를 더하는 함수라고 정의하자. 예를 들어, d(75) = 75+7+5 = 87이다. 양의 정수 n이 주어졌을 때, 이 수를 시작해서 n, d(n), d(d(n)), d(d(d(n))), ...과 같은 무한 수열을 만들 수 있다.  예를 들어, 33으로 시작한다면 다음 수는 33 + 3 + 3 = 39이고, 그 다음 수는

www.acmicpc.net

import java.util.ArrayList;
import java.util.List;

public class Main {

    public static void main(String[] args) {
        getNonSelfNumber();
    }

    public static void getNonSelfNumber() {
        List<Integer> nonSelfNumber = new ArrayList<>();

        for (int i = 1; i < 10000; i++) {
            if (!nonSelfNumber.contains(i)) {
                System.out.println(i);
            }

            nonSelfNumber.add(func(i));
        }

    }

    public static int func(int num) {
        int result = num;

        while (num != 0) {
            result += num % 10;
            num /= 10;
        }

        return result;
    }

}

댓글()