Tech Log 🛠️

조합 메소드 

추상화 수준이 비슷한 메소드 호출로 하나의 메소드를 구성하라

관련된 코드만 모아놓고 관련성이 떨어지는 코드는 분리!

메소드를 구성할 때는 추측이 아닌 사실에 근거하라

-> 일단 동작하는 코드를 만들고 구성 방식 결정

의도 제시형 이름

메소드의 이름을 통해서 의도를 전달하고 그 외 정보는 다른 방식으로 전달하라

Customer.linearSearch(String id) // x
Customer.find(String id) // o

메소드 가시성

메소드를 적게 노출시키면 유연성에서 이득을 얻을 수 있음

가시성을 선택할 때 고려해야할 사항 두가지

1. 미래의 유연성

2. 객체 사용 비용

먼저 제한적인 가시성을 선택하고 필요에 따라 차츰 확장시키자 !

오버로드

메소드 오버로드는 파라미터 타입만 다를 뿐, 같은 연산을 수행해야한다.

의도가 다르다면 새로운 이름을 갖는 메소드를 사용하자 !!

메소드 반환 타입

구상 클래스가 같은 인터페이스를 공유한다면 유사점과 차이점을 명확하게 나타낼 수 있다.

메소드 주석

주석은 정보를 중복으로 나타낼 수 있다.

따라서 코드만으로 분명하지 않은 정보는 주석을 사용하라

하지만 주석은 코드와의 일관성을 유지하기 위해 노력이 든다. 

그렇기 때문에 이런 노력을 감안할 만큼 가치가 있어야한다.

도우미 메소드

당장 관련도가 떨어지는 세부 구현을 숨기고 메소드 이름을 통해 프로그래머의 의도를 나타냄으로써,

복잡하고 거대한 연산 코드를 읽기 좋게 만들 수 있다.

디버그 출력 메소드

toString() 메소드를 사용하면 객체를 문자열로 나타낼 수 있다.

프로그래머에게 유용한 객체의 정보를 알려주기 위해 사용하자 !

변환

변환 메소드

유사한 타입의 객체 간 변환을 표횬하기 위해, 기존 객체에 메소드를 추가해서 변환을 나타낼 수 있다.

class Polar {
	Cartesian asCartesian() {
    	...
    }
}

변환 생성자

원본 객체를 파라미터로 취해서 대상 객체를 반환한다.

구상 클래스가 아닌 클래스를 반환해서 변환을 구현하고 싶다면 , 변환 생성자를 좀더 일반적인 타입을 반환하는 공장 메소드로 표현할 수 있다.

생성

의미있는 객체 생성을 위해서는 명확하고 직접적인 표현과 유연성 사이에서 균형을 잡아야한다.

완결 생성자

객체를 생성하는 방법이 여러가지라면 , 각 경우마다 제대로 된 객체를 반환하는 생성자를 제공하라

niew Rectangle(0,0,50,200)

이와같이 4개의 인자를 취하는 생성자가 있다면, 4개의 인자가 필요한 것이라는 사실을 바로 알 수 있다.

공장 메소드

공장메소드는 추상 타입을 반환할 수 있고 메서드 네이밍을 통해 의도를 명확하게 할 수 있다.

하지만 복잡성이 증가하므로 이득이 있을 경우에만 사용해야한다 !

Rectangle.create(0,0,50,200);

내부 공장

getX() {
	if (x== null){
    	x = computeX();
    return x;
    }
}

컬렉션 접근자 메소드

사용자가 컬렉션을 직접 조작하게 되면 위험하다 !

수정할 수 없는 컬렉션 형태로 바꿔서 반환하자 !

Iterator getBooks() {
	return books.iterator();
}

불린 설정 메소드

불린 상태를 설정하는 가장 좋은 방법은 메소드를 사용하는 것이다.

void setValid(boolean newState) {
	...
}

질의 메소드

객체가 다른 객체의 결정을 도와야 할 경우에는 be동사나 have동사를 이용한 질의 메소드를 사용하라

동등성 메소드

객체의 동일성이 아닌 동등성을 비교해야 하는 경우 equals와 hashcode를 구현하라

https://cb036133.tistory.com/127

여기 아주 정리가 잘 돼있다 !

취득 메소드

객체 상태에 대한 접근을 허용하기 위한 한 가지 방법은 상태를 반환하는 메소드를 반환하는 것이다.

int getX() {
	return x;
}

설정 메소드

필드 값을 설정하는 메소드가 필요하다면, 다음과 같이 set 접두어를 붙인 메소드를 사용한다.

int setX(int newX) {
	x = newX;
}

안전한 복사

객체를 반환하거나 저장하기 전에 복사본을 만드는 방식으로 이런 문제를 피할 수 있다.

List<Books> getBooks() {
	List<Books> results =.new ArrayList<Book>();
    result.addAll(books);
    return result;
}

List<Books> setBooks(List<Book> newBooks) {
	books = new ArrayList<Books>();
    books.addAll(newBooks);
}

MQTT 란?

MQTT 프로토콜은 기계 간 통신을 위해 설계된 통신 방식입니다.

REST 통신 방식과는 다르게 서버 간 직접 통신이 아닌 중간에 중계 서버를 두고 게시-구독 형태로 데이터를 전송합니다.

제한된 리소스로 통신을 해야하는 IOT의 특성으로 인해, 구현이 쉽고 효율적인 통신이 가능한 MQTT 프로토콜을 사용합니다.

MQTT의 특징

확장성

MQTT는 적은 전력과 최소한의 코드로 여러 디바이스와 통신할 수 있습니다. 

또한 모든 디바이스는 제한없이 정보(토픽)를 구독하거나 게시할 수 있습니다.

만약 통신 가능한 디바이스를 늘리고 싶다면 단순히 디바이스가 해당 토픽을 구독하면 됩니다.

신뢰성

기존 무선 통신은 정보의 손실이 있었지만 MQTT는 브로커가 메세지를 보관 , 관리할 수 있습니다.

따라서 메시지를 받는 디바이스가 준비가 될 때까지 메시지 전송을 대기할 수 있습니다.

MQTT의 구성 요소

클라이언트

MQTT를 사용하여 통신하는 디바이스를 클라이언트라고 합니다.

클라이언트는 구독을 하여서 데이터를 받을 수 있고 게시를 하여서 데이터를 전송할 수 있습니다.

브로커

브로커는 클라이언트 간 메시지를 중개하는 라우팅서버입니다.

클라이언트가 보낸 메세지는 브로커를 거쳐가며 브로커는 이 메세지를 관리하고, 해당 토픽을 구독하는 클라이언트에게 메세지를 전송합니다.

MQTT의 동작 방식

주제(Topic)

주제를 이용하여 브로커가 메시지를 수신받을 클라이언트를 필터링 할 수 있습니다.

해당 주제를 구독한 클라이언트만 메시지를 받고 , 주제는 계층 구조로 이루어져 있습니다.

게시

클라이언트는 주제 및 데이터를 다양한 형식으로 브로커에 전송합니다.(XML,JSON etc...)

구독

클라이언트는 구독한 주제의 메시지만 브로커로부터 수신 받습니다.

QOS

브로커는 메시지를 받고 지정된 QOS 레벨에 따라서 메시지를 전송합니다.

MQTT QOS 0

메세지를 한번만 보내고 확인 메세지(PUBACK) 을 받지 않습니다.

데이터의 유실이 크게 문제 되지 않을 때 사용합니다.

유실 가능성이 있지만 적은 비용으로 메세지를 보낼 수 있습니다.

MQTT QOS 1

메세지를 적어도 한번 이상 보냅니다.

PUBACK을 받으며 만약 확인 메세지가 오지 않는 다면 메세지를 여러번 다시 보낼 수 있습니다.

모든 메세지를 받을 수 있으며 , 클라이언트가 오프라인일 때 메세지를 저장(큐)할 수 있습니다.

MQTT QOS 2

딱 한번의 전송으로 메세지 전송을 완료할 수 있습니다.

핸드 쉐이크 과정을 통해서 메세지 전송을 확인하며 가장 느리지만 가장 확실합니다.

*QOS 레벨은 게시자와 구독자가 정한 레벨 중에서 가장 낮은 값이 사용됩니다.

메시지

메시지 수신자가 메시지를 받으면, 발신자의 상태는 바뀌지 않지만 수신자의 상태는 바뀔 수 있다.

메시지를 사용하는 프로시저는 당장 중요하지 않은 세부 구현이 존재한다 라는 의미를 내포할 수 있다. (캡슐화)

function() {
	input();
    process();
    output();
}

선택 메시지

선택 메시지를 사용하면 명시적 조건문의 사용을 크게 줄일 수 있다.

하지만 과도한 선택메시지의 사용은 가독성을 저해할 수 있다.

public void display(Subject subject, Brush brush) {
	brush.display(subject);
}

더블 디스패치

2개의 선택 메시지를 직렬로 연결할 수 있다.

https://www.youtube.com/watch?v=s-tXAHub6vg&loop=0 

분리 메시지

여러 단계로 구성되는 복잡한 알고즘을 단계별로 모으로 메시지를 보낼 수 있다.

되돌림 메시지

도우미 메소드를 사용하면 메소드의 가독성을 높일 수 있다.

void process() {
	helper.process(this);
}

void compute() {
	input();
    process(helper);
    output();
}

초청 메시지

로직에 대한 기본 구현되어있지 않다면 추상 메소드로 선언해서 추상 메시지임을 분명히하라

설명 메시지

highlight 메소드와 같이 프로그래머의 의도를 전달하기 위한 메소드가 있을 수 있다.

highlight() {
	reverse();
}

또 주석을 붙이고 싶은 코드는 다음과 같이 변경 가능하다,.

flags |= LOADED_BIT; // 로드 비트를 설정

setLoadedFlag() {
	flags |= LOADED_BIT;
};

이러한 한줄짜리 메소드는 커뮤니케이션을 돕는다.

예외 흐름

예외 흐름은 수행 빈도가 낮고 수정 빈도가 낮으며, 주요 흐름에 비해 커뮤니케이션의 중요성이 떨어진다.

주료 흐름은 명료하게 나타내고 예외 흐름은 주요 흐름의 명료성을 훼손하지 않는 범위 내에서 명료하게 나타내라 !

보호절

보호절을 사용해서 복잡한 제어 구조를 사용하지 않고 같은 코드를 표현할 수 있다.

void conpute() {
	Server server = getServer();
    if (server != null) {
    	Client client = server.getClient();
        if(client != null) {
        	....
        }
    }
}

void conpute() {
	Server server = getServer();
    if (server != null)
    	return;
    Client client = server.getClient();
    if(client != null)
    	return;
    ...
}

예외

메소드가 예외를 던지면 메소드의 설계와 구현의 영향을 미친다.

따라서 가능하면 순차적 구문 , 메시지 , 루프 제어문을 사용해서 제어 흐름이 안될 경우 예외를 사용하는 것이 좋다

예외 전달

하위 수준의 예외는 문제를 진단하는 데 유용한 정보를 제공해주는 경우가 많다.

하위 수준의 예외를 상위 수준 예외로 포장하라 

객체는 외부에 드러나는 행위와 행위를 지원하기 위한 상태를 묶어주는 편리한 단위다.

상태

-  상태를 효과적으로 관리하기 위해서 유사한 상태를 묶어서 관리하고 각 상태는 별도로 관리해야한다.

두 개의 상태가 유사한 지 알려면

1. 두 개의 상태가 동일한 연산 안에서 사용되는가?

2. 동일한 시점에 생성되고 소멸되는가?

를 확인하면 된다.

직접 접근

- 직접 접근의 장점은 명확성이다.

x=10 // 매우매우 명확하다.

하지만 코드를 통해 자세한 내용을 알려주기는 어렵다.

예를 들어

doorRegister = 1; // 직관적이지 않음
door.open(); // 매우 직관적임

따라서 직접 접근이 많다면 원활한 커뮤니케이션을 방해할 수 있다.

간접 접근

- 명확성과 직접성을 희생해서 유연성을 얻을 수 있다.

- 2개 이상의 데이터 간의 의존 관계가 존재하는 경우 매우 유용하다.

void setValue(int number){
	this.number = number;
    value = width * number;
}

공용 상태

- 같은 데이터 요소는 클래스에 필드를 선언해서 사용하면 좋다.

- 각 객체의 공용 상태는 모두 범위와 생명 기간이 같아야한다.

class Point {
	int x;
    int y;
}

가변 상태

- 데이터 요소의 이름을 키로하고 값을 데이터로 하는 맵으로 표현한다.

- 유연하긴 하지만 커뮤니케이션이 어렵다.

- 각 필드의 상태에 따라 다른 필드를 필요로 하는 경우 유용하다.

외재 상태

어떤 객체와 관련된 특수 목적 정보는 객체가 아니라 필요로 하는 부분에 두는 게 낫다.

다만 외재 상태를 사용하면 객체의 복사가 어려워진다.

변수

대부분의 경우에는 지역 변수를 시용하고 간간히 정적 변수와 전용 변수를 사용해서 객체 간의 의존성을 줄이는 것이 좋다.

변수의 종류를 줄이면 문맥만으로도 쉽게 구분할 수 있다.

변수의 생명 시간은 변수의 범위에 가까운게 좋다.

같은 범위에서 정의되는 변수들은 모두 같은 생명 기간을 가져야한다.

지역변수 

지역 변수는 가급적 최소 범위 내에서 선언하라

지역 변수는 도우미 메소드로 바꿀 수 있다.

이때 연산에 필요한 표현은 메소드 내용이 되고, 변수 이름은 메소드 이름이 된다.

필드

필드의 범위와 생명기간은 필드를 가지고 있는 객체와 같다.

만약 필드를 가장 앞에 선언하면 , 어떻게 사용될지에 대한 문맥을 제공해줄 수 있다.

뒤에 선언한다면 중요성이 상대적으로 떨어진다는 것을 암시한다.

불린 플래그를 통해 "객체가 두 가지 다른 방식으로 동작한다" 는 것을 내포할 수 있다.

파라미터

하나의 객체에서 다른 객체에 대한 여러 메시지가 같은 파라미터를 필요로 한다면 , 파라미터를 호출되는 객체에 포함하라

Server s = new Server();
s.a(this);
s.b(this);
s.c(this);

이 코드를 다음과 같이 변경할 수 있다.

Server s = new Server(this);
s.a();
s.b();
s.c();

이렇게 함으로써 의존성을 줄일 수 있다.

옵션 파라미터

반드시 필요한 파라미터를 앞에서 전달하고 , 옵션 파라미터는 뒤에 전달한다.

public Server();
public Server(int port);
public Server(int port, int log)

이를 망원경식 파라미터 패턴이라고도 한다.

가변 인자

아래와 같은 방법으로 임의의 수의 인자를 사용하여 메소드를 호출할 수 있다.

method(Class... classes)

파라미터 객체

여러 개의 파라미터가 함께 여러 메소드로 전달된다면, 이들을 하나로 묶어서 하나의 객체로 만들 수 있다.

예를 들어 x,y,heigh,width 를 묶어서 파라미터로 만들 수 있다.

setOuterBounds(x, y, width, height)

setOuterBounds(bounds)

파라미터 객체를 사용하면 코드가 짧아지고 의도를 명확히 전달할 수 있다.

또한 해당 파라미터들이 밀접한 연관성을 가지고 있다는 것을 보여줄 수 있다.

하지만 만약 객체의 생성으로 인해 성능 저하가 일어난다면 파라미터 객체를 없애는 쪽으로 수정하면 된다.

상수

변화하지 않는 데이터를 static final을 통해 선언하고 그 변수를 참조하게끔 하는 것이 좋다.

초기화

초기화는 변수가 사용되기 전에 알고 있는 상태로 만드는 작업이다.

초기화는 가급적 선언과 함께 하는 것이 좋다.

만약 초기화에 드는 비용이 비싸다면 생성과 초기화를 분리하는 것이 좋다..

열성적 초기화(eager)

모든 변수가 초기화 이후에 사용되는 것을 보장할 수 있다.

변수가 선언되거나 생성되자마자 초기화한다.

선언문에서 변수를 초기화하면 선언 타입과 실제 타입을 쉽게 확인할 수 있다.

List<Integer> number = new ArrayList<>();

선언문에서 필드를 초기화할 수 없다면 생성자에서 초기화하라

class Point {
	int x,y;
    Point(int x,int y){
    	this.x = x;
        this.y = y;
    }
}

게으른 초기화(lazy)

초기화 비용이 크거나 비용 부담을 늦추고 싶다면 메소드가 호출될 때 객체를 초기화하면 된다.

리플렉션이란?

자바 공식 문서에서는 리플렉션을 다음과 같이 정의하고 있다.

 Reflection enables Java code to discover information about the fields, methods and constructors of loaded classes, and to use reflected fields, methods, and constructors to operate on their underlying counterparts, within security restrictions. The API accommodates applications that need access to either the public members of a target object (based on its runtime class) or the members declared by a given class. It also allows programs to suppress default reflective access control.

간단하게 해석해보면, 자바 코드를 통해 로드된 클래스에 대해 접근 제한자와 관계 없이 필드 , 생성자 , 메소드를 이용할 수 있고 할 수 있다고 한다.

로드된 클래스란 , 클래스 로더 내에서 클래스를 로드한 후에 해당 클래스의 정보를 담은 객체를 힙에 저장해 둔 것이다.

https://cb036133.tistory.com/132

왜 사용할까?

리플렉션을 사용하면 접근 제한자와 상관없이 모든 클래스를 이용할 수 있다.

사실 이것은 캡슐화, 은닉화를 무력화 시키는 건데 오히려 사용을 지양해야 하지 않을까?

소규모의 프로그램에서는 리플렉션의 사용이 부적합할 수 있다.

하지만 패키지 , 모듈 구조가 복잡하고 의존 관계 파악이 힘든 프로젝트에서는 리플렉션이 주는 이점이 많다.

대표적으로 어노테이션이 있는데 어노테이션을 사용하면 프레임워크에서 탐색 후 해당 클래스를 관리해준다.

여기서 리플렉션의 기술이 사용되었는데 , 즉 런타임 시점에 객체를 생성할 수 있는 것이다

리플렉션은 주로 프레임워크나 라이브러리에서는 컴파일 시점에 알 수 없는 정보를 런타임 시점에 불러오기 위해 사용한다.

어떻게 사용할까?

1. 클래스 찾기

Class<Test> ReflectionTest = Test.class;

2.생성자 찾기

Test test = new Test();
Class<? extends Test> getClassTest = test.getClass();

3.메소드 찾기

Class<?> ReflectionTest = Class.forName("Test");

여기서 중요한 점은 어떤 방법으로 인스턴스를 가져오던 모두 같은 인스턴스라는 것이다 !

이제 가져온 인스턴스들을 어떻게 활용하는 지 알아보자

예시 코드

먼저 생성자를 가져오는 코드 !

// 모든 생성자들을 가져올 수 있다.
Arrays.stream(testClass.getConstructors()).forEach(System.out::println);

//생성자를 리플렉션으로 가져와서 객체를 생성할 수 있다.
Constructor<? extends Test> constructor = 
				getClassTest.getConstructor(null);
                
// 리플랙션으로 가져온 생성자를 통해 객체 생성                
Test test1 = constructor.newInstance();

// 생성자에 필요한 파라미터 타입들을 설정할 수 있다.
Constructor<? extends Test> stringConstructor = 
        		getClassTest.getConstructor(String.class, String.class, String.class);
                
// 리플랙션으로 가져온 생성자를 통해 객체 생성                     
Test test2 = stringConstructor.newInstance("param1", "param2", "param3");
}

다음은 메소드를 가져와서 이용해보자

//인스턴스 필드를 가져올 수 있다.
Field c = getClassTest.getDeclaredField("field1");

// 필드 접근은 허용시켜준다.
field1.setAccessible(true);

// 필드를 변경할 수 있다.
c.set(test, "fieid1_modified"); 

// 메소드도 가져올 수 있다.
Method func = getClassTest.getDeclaredMethod("func");

// 메소드 호출!
func.invoke(test);

리플렉션의 장/단점

장점

1. 런타임에 객체를 생성하고 생성자 , 메소드 , 필드를 이용할 수 있다.

단점

1. 캡슐화를 저해할 수 있다.

2. 가독성을 저해시킬 수 있다.

3. 일반적으로 사용했을 때보다 처리 성능이 떨어진다.

참고자료

https://papimon.tistory.com/82

https://medium.com/msolo021015/%EC%9E%90%EB%B0%94-reflection%EC%9D%B4%EB%9E%80-ee71caf7eec5

https://brunch.co.kr/@oemilk/172

자바는 기본적으로 Call By Value 방식으로 동작한다.

본문에 앞서 다음 코드를 보자

자바에서 전달 받은 값을 수정할 경우 원본 값이 변하는 지 알아보기 위한 코드이다.

public static void mian() {
        
        int x = 1;
        int y = 2;
       
        assertEquals(x, 1); // true
        assertEquals(y, 2); // true
        
        modify(x, y);
        
        assertEquals(x, 1); // true
        assertEquals(y, 2); // true
    }
    
    public static void modify(int x1, int y1) {
        x1 = 5;
        y1 = 10;
    }

넘겨받은 값을 수정했는데 원본 값은 변화하지 않았음을 알 수 있다.

이 이유는 오늘 알아볼 Call By Value 라는 방식 때문이다.

Call By Value 와 Call By Reference 의 차이는 ?

- Call By Value 방식은 값만 넘겨준다. 따라서 전달 받은 값을 수정하더라도 원본값에 영향이 없다. (참조값을 수정하는 경우 제외)

- Call By Reference 는 방식은 주소값 자체를 넘겨준다. 넘겨준 값 , 전달 받은 값 모두 동일한 변수이다.

   따라서 전달 받은 값을 수정할 경우 원본 값도 변경된다.

Call By Value는 어떻게 동작할까 ?

- 먼저 JVM에서 어떻게 변수를 저장하는 지 알아보자

원시 타입

스택 영역에 변수와 함께 값이 저장된다.

참조 타입

참조 타입의 경우, 변수를 복사하여 주소값을 저장한다.

여기서 오해하지 말아야 하는것은 주소값 자체를 받는 것이 아닌 복사하여 받는 다는 것이다.

따라서 참조하는 값을 변경할 경우 원본 값에도 영향을 미친다.

이제 변수를 변경할 경우 각각 어떻게 동작하는 지 알아보자

원시 타입

원시 타입의 경우 넘겨 받은 값은 아예 다른 변수이기 때문에 수정하더라도 원본 값에 아무런 영향이 없다.

참조 타입

참조 타입 또한 단순히 복사된 변수이기 때문에 넘겨 받은 값에 새로운 값을 할당하더라도 원본 값에는 영향이 없다.

하지만 참조하는 값을 직접적으로 수정할 경우는 논외이다. (ex. 배열)

Call By Reference 와의 차이는?

근데 주소값을 받기 때문에 Call By Reference 방식과 헷갈릴 수 있다.

명확히 해야할 것은 Call By Reference 방식은 변수 자체를 넘겨주고 자바는 변수를 복사해서 받기 때문에

엄연히 차이가 있다.

참고자료

https://www.baeldung.com/java-pass-by-value-or-pass-by-reference

클래스

내부 클래스

작은 전용 클래스를 사용하면 클래스 사용에 대한 비용을 지불하지 않고 클래스의 장점을 취할 수 있다.

내부 클래스는 내부 클래스를 감싼 클래스에 대한 정보를 암묵적으로 전달받는다.

명시적으로 클래스 간의 관계를 정하지 않으면서도 감싼 클래스의 데이터를 접근할 수 있다.

public class Enclose {
	private String field;
    
    public class Inner {
    	public String example() {
        	return field;
        }
     }

}

만약 외부 클래스와 완전히 분리된 내부 클래스를 사용하려면, 내부 클래스를 정적으로 선언하면 된다.

인스턴스별 행위

객체의 로직이 클래스에 의해 완전히 정의될 때, 코드 독자는 어떤 일이 벌어지는지 이해한다.

하지만 인스턴스 별로 로직이 다르다면 코드를 쉽게 이해할 수 없다.

효과적인 프로그래밍을 위해 인스턴스 생성 후에는 인스턴스 별 행동을 변화시키지 않는 것이 좋다.

조건문

조건물을 사용하면 인스턴스 별 행동을 지원하면서도 모든 로직을 하나의 클래스 안에 넣을 수 있다.

히자민 프로그램 수행 경로가 많으면 많을 수록 오류가 생길 확률이 높아진다.

아래와 같은 스위치 문을 생각해보자

public boolean contains(Point p) {
	switch (getType()) {
    	case A :
        // ...
        case B :
        // ...
    }
}

여기서 case C 를 추가하고 싶다면 , 스위치문에 새로운 절을 삽입하고 클래스 또한 수정해야 할수도 있다.

따라서 하위 클래스나 위임 중 하나를 선택해서 조건문을 메세지로 바꾸는 것으로 해결할 수 있다.

위임

위임을 통해서 각 인스턴스앳서 다른 로직을 수행하게 할 수 있다.

공통으로 사용되는 로직은 위임 클래스를 참조하는 클래스에 들어있지만 , 변형은 여러 객체에 각각 구현된다.

public void mouseDown() {
	getTool().mouseDown();
}

플러그인 선택자

한두개의 메소드에서만 인스턴스별 행동이 필요한 경우 리플렉션을 통해 메소드를 호출하는 것도 좋다

String name;
public void runTest() throws Exception {
	Class[] noArgument = new class[0];
    Method method = getClass().getMethod(name,noArguments);
    method.invoke(this,new Object[0]);
}

익명 내부 클래스

익명 내부 클래스는 한곳에서만 사용되는 클래스를 생성해서 오버라이드 한 후에 지역적으로만 사용하는 것이다.

이때 클래스 이름은 지정하지 않는다.

효율적인 사용을 위해 API가 매우 간단하거나 상위 클래스가 대부분의 구현을 담당해서 내부 클래스를 쉽게 구현할 수 있어야한다.

익명 내부 클래스를 사용하려면 클래스를 생성할 때 인스턴스에서 사용할 코드를 알아야한다.

또한 테스트하기 어려워서 복잡한 로직에 적절치않다.

클래스

클래스는 비슷한 성질을 가진 것을 총칭하며, 객체는 클래스가 구체화된 것이다.

클래스

클래스의 로직과 데이터는 함꼐 사용되며, 로직은 데이터에 비해 변화율이 낮다. 클래스 내부의 데이터는 
관련 로직에 의해 변화하며, 클래스 내부에서 사용하는 데이터의 변화율은 비슷하다.

대체로 이 선언을 내포하기는 하지만 절대적이지는 않다.

따라서 효과적인 프로그래밍을 위해서 로직을 클래스 단위로 어떻게 구성해야 하난지, 로직 사이의 차이점을 어떻게 효과적으로 

표현해야하는지 배워야 한다.

클래스 계층을 사용하면 하위 클래스를 이해하기 위해 상위 클래스 또한 모두 이해해야 하므로 읽기 어려워진다.

모든 클래스를 상속받기 보단 선별적으로 클래스를 상속하자

클래스는 프로그램의 설계 요소 중 값이 비싼 편이므로, 의미 있는 작업에만 클래스를 사용해야한다.

다른 클래스의 크기를 유지하면서 클래스의 수를 줄이는 것이 프로그램을 개선한 것이라고 볼 수 있다.

단순한 상위 클래스 이름

적합한 클래스 이름은 코드를 단순화하고 향상 시켜준다.

중요한 클래스 이름에 대해서는 한 단어로 된 이름을 사용하고 , 메타포(은유)를 사용하면 좋다 !

한정적 하위클래스 이름

하위클래스 이름은 상위 클래스와 달리 간결성은 포기하더라도 표현성을 택하는 것이 좋다.

하지만 그 하위클래스가 다른 클래스의 상위 클래스라면 다시 단순성을 선택해야한다.

다른 경우는 다단계 클래스 계층이다. 

기계적으로 바로 위의 상위 클래스 이름에 수식어를 붙이기 보단 , 가장 유사한 상위 클래스의 이름을 바탕으로

짓는 것이 좋다.

효과적인 커뮤니케이션을 위해 좋은 클래스 이름이 필요하다.

이름에 연관성이 없는 클래스는 이해하기도 기억하기도 어렵다.

클래스 이름은 코드의 내용을 반영해야한다.

추상 인터페이스

설계상의 결정을 필요 이상으로 노출하지 않아야한다.

인터페이스란 구현이 빠진 여러 연산의 집합을 의미한다.

하지만 인터페이스 추가에는 비용이 발생한다.

따라서 유연성을 얻을 수 있는 경우에만 추가 설계에 대한 비용을 지불해야한다.

실제로 유연성이 필요하지 않는 경우도 매우 많다.

저번 장에도 말했듯이 불확실한 미래를 예측하기 보단 당장의 이익을 취하자

추후 필요해지는 경우에만 시스템에 유연성을 부여하는 편이 바람직하다.

인터페이스

자바 인터페이스를 사용하는 것은 "여기까지가 내가 원하는 것이고 , 이외의 내용은 상관하지 않는다."

라는 내용을 내포한다.

인터페이스는 필드를 배제하고 연산만을 나타내므로 사용자는 구현이 변경되더라도 신경 쓸 필요가 없다.

반대로 구현을 바꾸는 것은 쉽지만 인터페이스 자체를 변경하는 것은 쉽지 않다.

변경 시에 모든 구현 클래스를 수정해야하기 때문이다.

버전 인터페이스

만약 인터페이스를 바꾸고 싶은데 설계를 수정하는 것이 부담스러운 경우, 버전 인터페이스를 사용할 수 있다.

이렇게 하면 기존 인터페이스를 생속헤서 새로운 연산을 추가하므로 사용자는 기존 인터페이스에 대해 알 필요가 없다.

하지만 버전 인터페이스는 그리 좋은 방법이 아니다.

버전 인터페이스가 늘어날 수록 결국 관리해야할 로직,클래스가 많아지므로 클라이언트가 할 일이 늘어난다.

이는 설계 자체를 수정할 때가 되었다는 것이다.

추상 클래스

추상 인터페이스를 구현하는 또 다른 방법은 추상 클래스를 사용하는 것이다.

인터페이스와 비교했을 때 장단점이 있다.

먼저 수정의 관점에서 보면 추상 클래스는 수정에 용이하다.

기존 설계를 유지하면서 얼마든지 새로운 연산을 추가할 수 있다.

하지만 추상 클래스는 단 1개의 상위 클래스만을 지정할 수 있다.

이는 여러 개의 인터페이스를 구현할 수 있는 것과 대조된다.

자바 클래스에서 abstract 키워드를 씀으로써, 해당 클래스를 사용하기 위해서는

반드시 구현이 필요하다는 사실을 전달할 수 있다.

값 객체

함수형(값) 스타일 연산은 상태를 변화시키지 않으며 새로운 값을 생성한다.

고정적인 상황을 표현하고 함수형 스타일이 적절하고 , 상황이 변하는 경우라면 상태를 사용하는 편이 낫다.

값 스타일 객체의 문제점은 성능이다.  (하지만 매우 미비하다)

다른 문제는 값 스타일과 상태로 부분을 구별하기 쉽지 않다는 것이다.

따라서 두 스타일을 적절히 섞어서 사용하는 것이 좋다.

특화

연산 간의 유사점과 차이점을 부각시키는 방향으로 코드를 작성하면 , 프로그램을 읽고 수정하기 쉬워진다.

이런 방식을 사용하면 명확히 코드를 이해하고 새로운 요구 사항을 처리할 수 있을 지를 알 수 있다.

또한 수정이 필요한 경우 기존 코드를 변형할지 새로 만들지를 판단할 수 있다.

대부분의 프로그래밍은 두 가지의 극단적 변형 사이에 존재한다.

현실에서는 약간 변형된 입력 데이터를 시용하거나 약간 변형된 로직을 사용하는 경우가 많다.

하위 클래스

제대로 된 상위클래스를 가지고 있다면 하위 클래스는 강력한 힘을 발휘할 수 있다.

하지만 하위 클래스의 사용은 여러 문제를 야기한다.

1. 하위 클래스의 사용을 되돌리기 어렵다.

2. 하위클래스를 이해하기 위해 상위 클래스까지 이해해야한다. 

3. 상위 클래스의 수정이 조심스러워진다.

이러한 문제점을 잘 알고 있다면 하위 클래스는 강력한 도구가 될 수 있다.

상위 클래스의 로직을 여러 개의 메소드로 잘게 쪼개면 각 메소드를 따로 오버라이드 할 수 있다.

하위 클래스는 동적으로 변화하는 로직을 나타낼 수 없다.

따라서 이 경우네는 조건문이나 위임을 사용하는 것이 바람직하다. 

구현자

객체지향 프로그램에서는 다형적 메시지를 통해 선택을 표현할 수 있다.

덕분에 연산의 내부 구현에 대해서는 신경 쓰지 않아도 된다.

다형적 메세지는 여러 가지 변경을 수용할 수 있다.

프로그램이 다른 시스템에 일련의 데이터를 전송하는 경우, 추상 클래스를 사용하면 호출 코드에 영향을 주지 않고

구현을 자유롭게 바꿀 수 있다.

이는 효과적으로 프로그래머의 의도와 구현을 분리할 수 있다.

또한 상상하지 못했던 미래의 확장을 수용할 수 있다.

프로그래밍 이론

프로그래밍 이론은 새로운 문제가 발생해도 해결책을 찾을 수 있도록 도와준다.

실제 프로그래밍에서는 동력이 존재한다.

1. 가치

- 가치는 모든 프로그래밍에 적용된다. 

- 커뮤니테이션 , 유연성 등 모든 의사 결정에 영향을 미친다.

2. 원칙

- 직접 적용하기 어려운 가치와 , 지엽 적인 패턴 사이에 가교 역할을 한다.

- 패턴 중 하나를 선택해야 할 때 원칙을 따른다. 

패턴은 지금 당장 무엇을 해야할지를 알려주고, 가치는 사용해야 하는 동기를 알려주며, 원칙은 동기를 행동으로 어떻게 바꿀지를 알려준다.

가치

세가지 가치는 서로 충돌하는 경우도 있지만 상호 보완적인 경우가 많다.

커뮤니케이션

다른 개발자가 봤을 때의 관점으로 코드를 작성하라

코드를 쉽게 이해하고, 수정하고, 사용할 수 있어야한다

이렇게 작성하면 추후 코드 수정 시에 내가 쓴 코드를 쉽게 이해할 수 있으므로, 개발 비용이 감소한다.

또한 타인의 시선에서 생각하다보면 더 많은 생각을 하기 때문에 코드의 질이 좋아진다.

단순성

불필요한 복잡도는 소프트웨어의 수정을 어렵게 하기 때문에 프로그램의 가치가 떨어진다.

코드에서 불필요한 부분을 제거하라. 

과도한 요소와 의미없는 코드를 제거하면 프로그램의 단순성을 높일 수 있다.

커뮤니케이션과 단순성은 협업 관계에 있다.

커뮤니케이션의 신경을 쓸수록 어떤 부분이 과도하게 복잡한 지 알기 쉬우며, 단순할수록 시스템을 이해하기 쉽다.

유연성

유연성을 위해서 복잡한 설계를 정당화할 수 있다.

하지만 이러한 복잡도가 아무런 이득을 가져오지 않는다면 단순성을 선택해야한다.

설계 초기 유연성이 필요했다고 생각하도, 이후 필요한 상황이 오지 않을 수 있다.

그렇기 때문에 초기 설계 비용을 불필요하게 증가시키는 것보다 당장의 이득을 선택하는 것이 좋다.

추측에 의거해 설계에 유연성을 부여하기 보단 단순성을 유연하게 적용한후 테스트를 철저하게 하는 것이 효과적이다.

단순성은 유연성을 촉진시킨다. 예를 들어 옵션을 제거하면 프로그램의 수정은 더욱 간단해진다.

커뮤니케이션을 중시하면 코드를 이해하기 쉬워지므로 수정이 쉬워진다. 이로써 유연성이 증대된다.

원칙 

각 패턴은 가치 중 하나 이상을 내표하고 있다.

원칙은 일반적인 생각을 담고 있으며, 패턴의 근간을 이룬다.

원칙을 명확하게 알고 있다면 새로운 패턴들을 만들어낼 수 있다.

또한 패턴을 사용하는 근본적인 이유를 알 수 있다.

지역적 변화

코드를 수정할 때 함께 바꿔야하는 부분을 최소화하라

지역적 변화만을 일으키는 코드는 커뮤니케이션이 쉽다.

최소 중복

중복된 코드가 많을 수록 코드의 수정이 어려워진다.

어떤 개념을 수정했을 때 클래스를 2개 이상 수정해야한다면, 이는 지역적 변화의 원칙을 위배한다.

하지만 코드의 중복은 상황에 따라 불가피할 수 있다.

따라서 절대적으로 피하기 보단 위험 요소로 보는 것이 좋다.

로직과 데이터의 결합

데이터와 그 데이터를 처리하는 로직을 같은 메소드 , 같은 객체 , 같은 패키지 내에 배치하라

이렇게 하면 프로그램을 수정하더라도 그 영향이 일정 영역에 머물게 된다.

대칭성

대칭성에 따라 아이디어를 일관된 방식으로 표현하자

메소드를 하나의 구현으로 통합할 수 있어서 중복을 제거할 수 있다.

void process() {
	input();
    	tally(); // 일치시키다
   	output();
}

선언적 표현

수행 순서가 중요한 구문이나 조건부 구문이 없는 경우, 선언적 표현을 통해 코드를 작성하는 것이 좋다.

(아마 어노테이션인 듯)

@RunWith(Suite.class)
@TestClasses({
	SimpleTest.class,
    ComplicatedTest.class
}
)
class AllTests {
}

이런 방식으로 내부를 볼 필요없이 읽기 쉬운 코드를 작성할 수 있다.

변화율

로직과 데이터를 함께 관리하고 변화율이 다른 로직과 데이터를 분리하라

변화율은 시간적 대칭성에 해당한다.

하나의 객체에 있는 모든 필드는 가급적 함께 변해야한다.

특정 메소드가 수행될 때만 사용되는 필드는 그 메소드의 지역 변수로 선언되어야한다.

예를 들어 함께 변화하는 두 개의 필드(value, currency)가 있다면 하나의 도우미 객체(Money)에 넣는 것이 좋다.

setAmount(Money value) {
	this.money = money;
}

Gradle 이란?

자바를 이용해서 코딩을 하다보면 Gradle 을 사용해서 빌드하는 경험을 많이 한다.

근데 이 Gradle 은 정확히 어떤 역할을 할까?

공식문서를 먼저 찾아보면,

Gradle is an open-source build automation tool flexible enough to build almost any type of software.

Gradle 은 스스로 빌드 자동화(build automation) 툴이라고 소개하고 있다.

🧐 빌드란 무엇일까?

자바코드를 컴파일 과정을 거쳐서 컴퓨터가 실행할 수 있는 파일로 만들어 주는 과정을 말한다.

그렇다면 일단 Gradle이 이러한 과정을 관리해줌으로써 개발자의 삶을 좀 더 윤택하게 해준다는 것은 알거같다.

구체적으로 Gradle은 다음과 같은 일을 한다. (스프링 기준)

Compile

- 자바 파일을 컴퓨터가 읽을 수 있는 바이트 코드로 변환해준다.

Test

- 프로그램이 제대로 돌아갈 수 있는 지에 대한 테스트를 지원해준다.

Pakaging

- 컴파일 된 코드로 실행 파일을 만든다.

Deploy & Run

- 실제로 프로그램을 실행시킨다. 예를 들면 스프링 서버를 돌리는 것과 같다.

하지만 Gradle이 다른 툴과 비교했을 때 어떤 장점이 있어서 많은 개발자들이 사용하는 걸까?

Gradle, 왜 쓰는 걸까?

다른 툴들과 비교해봤을 때 Gradle이 가지는 장점이 몇가지 있다.

그 장점들에 대해서 하나씩 알아보자

간결한 스크립트

Gradle의 장점은 먼저 스크립트만 봐도 알 수 있다.

먼저 경쟁자인 Maven의 스크립트를 보자 !

Maven의 경우에는 XML 형식의 스크립트 구조를 사용하고 있어서 가독성도 떨어지고 작성하기도 어렵다.

하지만 Gradle 같은 경우 설정 주입 방식으로 스크립트를 작성해줌으로써 가독성도 좋아지고 프로젝트 구조를 보다 쉽게 파악할 수 있다.

멀티 프로젝트 빌드

프로젝트를 진행하다 보면 여러 개의 모듈로 구성되는 경우가 많다.

하지만 이 때 여러 개의 모듈을 따로 빌드하게 되면 번거롭기도 하고 실수할 가능성도 생긴다.

Gradle은 이런 문제를 해결하기 위해 여러 개의 모듈들을 동시에 빌드할 수 있다.

또한 모듈마다 공통된 코드 , 별도의 코드를 분리해 줌으로써 코드의 중복을 줄일 수 있다.

빠른 빌드 속도

위에서 말한 것들만 모두 해준다고 해도 충분히 쓸만한 툴이다.

근데 여기에 속도까지 빠르다면 ? 그 어려운 걸 Gradle 이 다시 해내버렸다.

표를 보면 Gradle 은 경쟁사 대비 월등히 빠른 속도를 보여주고 있다.

편리하고 빠른 Gradle .. 안 쓸 이유가 없지 않을까?

잠깐 Gradle 은 대체 어떻게 만들었길래 빠른걸까?

Gradle, 왜 빠른 걸까?

다시 Gradle의 공식 문서를 보자

Gradle avoids unnecessary work by only running tasks that need to do work because inputs or outputs have changed. Gradle uses various caches to reuse outputs from previous builds. With a shared build cache, you can even reuse outputs from other machines.

이 문장을 요약하면 Gradle은 기본적으로 불필요한 작업을 방지하고 캐시를 통해 재사용한다는 것을 알 수 있다.

이것을 구현하는 방법은 대표적으로 3가지가 있다.

점진적 빌드

빌드를 할 때 모든 파일들을 다시 빌드하는 게 아닌 , 바뀐 파일들만 추적해서 해당 파일만 빌드하는 것을 말한다.

예를 들어 20개의 파일을 빌드할 때 15개의 파일이 그대로면 나머지 5개의 파일만 빌드하는 형식이다.

빌드 캐시

여러 번의 빌드를 실행할 때 Gradle은 이미 빌드가 된 결과물들을 빌드 캐시에 담아놓는다.

추후에 해당 파일에 대해 다시 빌드를 하게 되면, 다시 빌드할 필요성을 줄여줌으로써 빌드를 더욱 빨리할 수 있다.

혹은 빌드 캐시를 로컬에서만 사용하는 것이 아닌 , 팀원들끼리 빌드 캐시를 공유해서 빌드 결과들을 캐시에 담아 재사용할 수 있다.

데몬 프로세스

데몬 프로세스를 알아보기 전에 데몬은 무엇일까?

Gradle에서 또 친절하게 데몬의 정의를 말해주고 있다.

A daemon is a computer program that runs as a background process, rather than being under the direct control of an interactive user.

해석하자면 , 데몬은 사용자가 직접 제어하지 않고 백그라운드 프로세스로 돌아가는 프로그램이다.

이것을 빌드에 어떻게 도입했을까?

Gradle은 JVM이라는 가상 장치 위에서 실행되며 이 JVM은 여러 초기화 라이브러리들을 사용하며, 이 과정은 꽤 시간이 걸릴 수 있다.

때문에 매번 새로 빌드하는 것이 아닌 동일한 빌드는 이미 실행중인 데몬을 이용하여서 빌드 시간을 줄여준다.

예를 들어서 노트북을 사용하지 않을 때 아예 끄는 것이 아니라 다음 사용을 위해 슬립 모드로 두는 것과 같다.

Gradle, 어떻게 쓰는 걸까?

이렇게 좋은 Gradle , 어떻게 쓰는 지 정도는 알아보자 !

오늘은 빌드 스크립트에서 의존성을 설정하는 부분을 알아볼 것이다.

의존성 설정을 위해선 build.gradle의 dependencies 부분을 봐야한다.

Gradle에선 예시 코드처럼 간편하게 의존성을 설정할 수 있다.

근데 앞에 있는 코드를 보면 모두 다른 코드를 사용하고 있다.

이 코드들은 왜 있고 어떤 기능들을 수행하는 지 알아보자!

compileOnly

컴파일 시에만 의존성을 정의한다.

예를 들어 롬복같은 경우 , 어노테이션을 보고 getter , setter를 컴파일 해주고 런타임에는 넣지 않는다.

runtimeOnly

런타임 시에만 의존성을 정의한다.

예를 들어 DB관련 혹은 로그 의존성 주입 시에 사용한다.

test

앞에 test가 붙어있으면 해당 의존성을 테스트 시에만 사용한다는 의미이다.

의존성이란?

모듈 간의 관계를 예로 들면, A 모듈이 B 모듈을 사용하고 있다.

이것을 A 모듈이 B 모듈에 의존하고 있다고 말한다.

즉 의존성이란 모듈 간 서로 사용하는 관계이다.

Api vs Implementation

dependencies를 보면 api 도 있고 implementation도 있다.

둘은 어떤 차이가 있을까?

먼저 전이 의존성이란 개념을 짚고 넘어갈 필요가 있다.

만약 서로 의존하고 있는 모듈 3개가 있다고 가정하자

여기서 A 모듈이 변경된다면 나머지 모듈들은 어떻게 될까?

만약 여기서 의존하고 있는 모듈들이 모두 영향을 받는다면 전이 의존성이 허용된 경우이다.

여기서 말한 전이 의존성의 특성을 가지고 있는 지가 차이를 결정한다.

공식 문서를 참고해보자

api 또는 compile(지원 중단됨) 대신 이 종속 항목 구성을 사용하면 빌드 시스템에서 다시 컴파일해야 하는 모듈 수가 줄어들기 때문에 빌드 시간이 크게 개선될 수 있습니다.

예를 들어 implementation 종속 항목이 API를 변경하면 Gradle은 이 종속 항목과 이에 직접적으로 종속된 모듈만 다시 컴파일합니다. 대부분의 앱과 테스트 모듈은 이 구성을 사용해야 합니다.

implementation을 사용하면, 종속 항목과 직접적으로 종속된 모듈만 다시 컴파일한다고 나와있다.

그래서 모듈 하나가 변경 된다고 해서 다른 모듈들까지 모두 영향을 주지 않는 것이다.

즉 전이 의존성을 가지지 않는다고 할 수 있다.

반대로 api는 전이 의존성을 가지기 때문에 의존하고 있는 모든 모듈들이 영향을 받고 이것은 곧 컴파일 시간에 영향을 준다.

왜 api를 사용하면 다른 모듈들까지 영향을 받을까?

API는 컴파일 class-path 에도 노출되어 있기 때문에 컴파일 시에 다른 모듈들이 영향을 받게 된다.

하지만 implementation은 런타임 class-path 에만 노출이 되어 있기 때문에 다시 컴파일 할 필요가 없다.

🧐 두 가지 class-path 의 차이를 알아보자

컴파일 class-path : Java 코드를 class 파일로 컴파일 할 때 탐색하는 경로

런타임 class-path : 컴파일 된 자바 코드를 JVM이 실행할 때 탐색하는 경로

정리하자면,

api 는 컴파일 class-path , 런타임 class-path 에 노출된다.

implementation은 런타임 class-path에만 노출된다.

implementation을 사용하면 꽤 많은 장점들이 있다.

1. 컴파일 , 런타임 class-path를 분류함으로써 더 빠른 컴파일이 가능하다.
2. 컴파일 시에 다른 모듈에서 원치않는 라이브러리까지 의존할 필요가 없다.