Gravity

[IntelliJ] 콘솔 한글깨짐 처리 (console log encoding .. with tomcat)

Gravity___ — Thu, 30 Mar 2023 09:26:25 +0900

https://thingsthis.tistory.com/328

[CleanCode]6장 객체와 자료구조

Gravity___ — Fri, 19 Aug 2022 22:50:01 +0900

CleanCode - 로버트 C.마틴

▷ 6. 객체와 자료구조

자료 추상화

public class Point {
    public double x;
    public double y;
}

public interface Point {
    double getX();
    double getY();
    void setCartesian(double x, double y);
    double getR();
    double getTheta();
    void setPolar(double r, double theta)
}

위 코드는 구현을 외부로 노출하고 아래는 구현을 완전히 숨긴다.
아래 코드는 자료 구조의 이상을 표현한다.
위 코드에서 구현을 감추려면 추상화가 필요하다. 그저 조회 함수와 설정 함수(게터, 세터)로 변수를 다룬다고 클래스가 되지는 않는다.

public interface Vehicle {
    double getFuelTankCapacityInGallons();
    double getGallonsOfGasoline();
}

public interface Vehicle {
    double getPercentFuelRemaining();
}

자료를 세세하게 공개하기 보다는 아래처럼 추상적인 개념으로 표현하는 편이 좋다.
인터페이스나 조회/설정 함수만으로는 추상화가 이뤄지지 않는다. 아무 생각없이 조회/설정 함수를 추가하는 방법이 가장 나쁘다.

자료/객체 비대칭

위의 두 가지 예제는 객체와 자료 구조 사이에 벌어진 차이를 보여준다.
객체는 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 제공한다. 자료 구조는 자료를 그대로 공개하며 별다른 함수는 제공하지 않는다.

public class Square {
    public Point topLeft;
    public double side;
}

public class Rectangle {
    public Point topLeft;
    public double height;
    public double width;
}

public class Circie {
    public Point center;
    public double radius;
}

public class Geometry {
    public final double PI = 3.141592653589793;
    
    public double area(Object shape) throws NoSuchShapeException {
        if (shape instanceof Square) {
            Square s = (Square) shape;
            return s.side * s.side;
        } else if (shape instanceof Rectangle) {
            Rectangle r = (Rectangle) shape;
            return r.side * r.side;
        } else if (shape instanceof Circle) {
            Circle c = (Circle) shape;
            return c.side * c.side;
        }
    }
}

public class Square implements Shape {
    private Point topLeft;
    private double side;
    
    public double area() {
        return side * side;
    }
}

public class Rectangle implements Shape {
    private Point topLeft;
    private double height;
    private double width;
    
    public double area() {
        return height * width;
    }
}

public class Circle implements Shape {
    private Point center;
    private double radius;
    public final double PI = 3.141592653589793;
    
    public double area() {
        return PI * radius * radius;
    }
}

위 코드는 절차지향적이다. 만약 Geometry 클래스에 둘레 길이를 구하는 함수를 추가한다면 도형 클래스는 아무런 영향도 받지 않는다.
반대로 새 도형을 추가하고 싶다면? Geometry 클래스에 속한 함수를 모두 고쳐야한다.
아래 코드는 객체지향적인 도형 클래스이다. 여기서 area()는 다형 메서드이다. Geometry 클래스는 필요없다. 따라서 새 도형을 추가해도 기존 함수에 아무런 영향을 미치지 않는다.
반면 새 함수를 추가하고 싶다면 도형 클래스 전부를 고쳐야 한다.
즉 자료 구조를 사용하는 절차적 코드는 기존 자료 구조를 변경하지 않으면서 새 함수를 추가하기 쉬우며 객체 지향 코드는 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다.
같은 말로 절차적인 코드는 새로운 자료 구조를 추가하기 어려우며 객체 지향 코드는 새로운 함수를 추가하기 어렵다.(모든 클래스를 고쳐야 한다.)
복잡한 시스템을 짜다 보면 새로운 함수가 아니라 새로운 자료 타입이 필요한 경우가 생긴다. 이때는 절차적인 코드와 자료 구조가 좀더 적합하다.
분별있는 프로그래머는 모든 것이 객체라는 생각이 미신임을 잘 안다. 때로는 단순한 자료 구조와 절차적인 코드가 가장 적합한 상황도 있다.

디미터 법칙

잘 알려진 휴리스틱으로 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙이다.
클래스 C의 메서드 f는 다음과 같은 객체의 메서드만 호출해야 한다고 주장한다.

1. 클래스 C
2. f가 생성한 객체
3. f 인수로 넘어온 객체
4. C 인스턴스 변수에 저장된 객체

기차 충돌

final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

디미터 법칙을 어기는 다음 코드는 기차 충돌이라 부른다.
일반적으로 조잡하다고 여겨져 피하는 편이 좋으며 다음과 같이 나누는 편이 좋다.

Options opts = ctxt.getOptions();
File scrachDir = opts.getScratchDir();
final String outputDir = scrachDir.getAbsolutePath();

위 예제가 디미터 법칙을 위반하는지 여부는 ctxt, Options, ScrachDir이 객체인지 자료 구조인지에 달렸다.
객체라면 내부 구조를 숨겨야하므로 디미터 법칙을 위반하며 자료 구조라면 당연히 내부 구조를 노출하므로 디미터 법칙이 적용되지 않는다.
위 예제는 조회 함수를 사용하는 바람에 혼란을 일으킨다. 코드를 다음과 같이 구현했다면 디미터 법칙을 거론할 필요가 없어진다.

final String outputDir = ctxt.options.scratchDir.absolutePath;

이와 같이 자료 구조는 무조건 함수 없이 공개 변수만 포함하고 객체는 비공개 변수와 공개 함수를 포함한다면 문제는 훨씬 간단하다.

구조체 감추기

만약 ctxt, options, scratchDir이 진짜 객체라면? ctxt가 뭔가를 하라고 말해야지 속을 드러내라고 말하면 안된다.
다음은 같은 모듈에서 한참 아래로 내려가서 가져온 코드이다.

String outFile = outputDir + "/" + className.replace('.', '/') + ".class";
FileOutputStream fout = new FileOutputStream(outFile);
BufferedOutputStream bos = new BufferedOutputStream(fout);

점, 슬래시, 파일 확장자, File 객체를 마구 뒤섞으면 안된다. 어찌됐든, 위 코드를 통해 임시 디렉터리의 절대 경로를 얻으려는 이유가 임시 파일을 생성하기 위한 목적이라는 사실을 알게되었다.

BufferedOutputStream bos = ctxt.createScratchFileStream(classFileName);

때문에 ctxt 객체에 임시 파일을 생성하라고 시킴으로써 ctxt는 내부 구조를 드러내지 않으며 여러 객체를 탐색할 필요가 없다. 따라서 디미터의 법칙을 위반하지 않는다.

자료전달 객체

DTO : 공개 변수만 있고 함수는 없는 클래스
Bean : 비공개 변수를 조화/설정 함수로 조작
활성 레코드 : 공개, 비공개 변수와 조회/설정 함수 그리고 탐색 함수도 제공한다.

결론

객체는 동작을 공개하고 자료를 숨긴다. 때문에 기존 동작을 변경하지 안흐면서 새 객체 타입을 추가하기는 쉬우며 기존 객체에 새 동작을 추가하기는 어렵다.
자료 구조는 별다른 동작없이 자료를 노출한다. 그래서 기존 자료 구조에 새 동작을 추가하기는 쉬우나 기존 함수에 새 자료 구조를 추가하기는 어렵다.
시스템을 구현할 때 새로운 자료 타입을 추가하는 유연성이 필요하면 객체가 더 적합하다. 새로운 동작을 추가하는 유연성이 필요하면 자료 구조와 절차적인 코드가 더 적합하다.

[CleanCode]4, 5장 주석 / 형식 맞추기

Gravity___ — Mon, 15 Aug 2022 14:23:58 +0900

CleanCode - 로버트 C.마틴

▷ 4. 주석

들어가며

잘 달린 주석은 그 어떤 정보보다 유용하다. 하지만 근거 없고 경솔한 주석은 코드를 이해하기 어렵게 만든다.
우리는 코드로 의도를 표현하지 못해, 즉 실패를 만회하기 위해 주석을 사용한다.
주석은 오래될수록 코드에서 멀어진다. 주석을 유지보수하기란 현실적으로 쉽지 않다.

코드로 의도를 표현하라.

// 직원에게 복지 혜택을 받을 자격이 있는지 검사한다.
if ((employee.flags && HOURLY_FLAG)) && (employ.age > 65) {}

if (employee.isEligibleForFullBenefits()) {}

몇 초만 더 생각하면 아래 코드처럼 의도를 명확하게 드러낼 수 있다.

좋은 주석

법적인 주석
결과를 경고하는 주석 - 아래 코드는 정적 초기화 함수를 사용하려면 프로그래머가 주석을 보고 실수를 면할 수 있다.

public static SimpleDateFormat makeStandardHttpDateFormat() {
    // SimpleDateFormat은 스레드에 안전하지 못하다.
    // 따라서 각 인스턴스를 독립적으로 생성해야 한다.
    SimpleDateFormat df = new SimpleDateFormat("EEE, dd MMM yyyy HH:mm:ss z");
    df.setTimeZone(TimeZone.getTimeZone("GMT"));
    return df;
}

TODO 주석

나쁜 주석

주절거리는 주석
같은 이야길 반복하는 주석
오해의 여지가 있는 주석
의무적으로 다는 주석 - 모든 함수에 javadocs를 달거나 모든 변수에 주석을 달아야한다는 규칙
닫는 괄호에 다는 주석
주석으로 처리한 코드
HTML 주석

좋은 주석을 사용한 소스

/**
 * 이 클래스는 사용자가 지정한 최대 값까지 소수를 구한다.
 * 알고리즘은 에라스토테네스의 체이다.
 * 2에서 시작하는 정수 배열을 대상으로 작업한다.
 * 처음으로 남아 있는 정수를 찾아 배수를 모두 제거한다.
 * 배열에 더 이상 배수가 없을 때까지 반복한다.
 */
public class PrimeGenerator {
    private static boolean[] crossedOut;
    private static int[] result;

    public static int[] generatePrimes(int maxValue) {
        if (maxValue < 2) {
            return new int[0];
        } else {
            uncrossIntegersUpTo(maxValue);
            crossOutMultiples();
            putUncrossedIntegerIntoResult();
            return result;
        }
    }

    private static void uncrossIntegersUpTo(int maxValue) {
        crossedOut = new boolean[maxValue + 1];
        for (int i = 2; i < crossedOut.length; i++) {
            crossedOut[i] = false;
        }
    }

    private static void crossOutMultiples() {
        int limit = determineIterationLimit();
        for (int i = 2; i <= limit; i++) {
            if (notCrossed(i)) {
                crossOutMultiplesOf(i);
            }
        }
    }

    private static int determineIterationLimit() {
        // 배열에 있는 모든 배수는 배열 크기의 제곱근보다 작은 소수의 인수이다.
        // 따라서 이 제곱근보다 더 큰 숫자의 배수는 제거할 필요가 없다.
        double iterationLimit = Math.sqrt(crossedOut.length);
        return (int) iterationLimit;
    }

    private static void crossOutMultiplesOf(int i) {
        for (int multiple = 2 * i; multiple < crossedOut.length; multiple += i) {
            crossedOut[multiple] = true;
        }
    }

    private static boolean notCrossed(int i) {
        return crossedOut[i] == false;
    }

    private static void putUncrossedIntegerIntoResult() {
        result = new int[numberOfUncrossedIntegers()];
        for (int j = 0, i = 2; i < crossedOut.length; i++) {
            if (notCrossed(i)) {
                result[j++] = i;
            }
        }
    }

    private static int numberOfUncrossedIntegers() {
        int count = 0;
        for (int i = 2; i < crossedOut.length; i++) {
            if (notCrossed(i)) {
                count++;
            }
        }
        return count;
    }

    public static void main(String[] args) {
        int[] resultArr = generatePrimes(10);
        for (int each : resultArr) {
            System.out.println(each);
        }
    }
}

첫 번째 주석은 알고리즘 자체를 이해하기 쉽도록 만들어 준다.
두 번째 주석은 루프 한계값으로 제곱근을 사용한 이유를 설명한다.

▷ 5. 형식 맞추기

형식을 맞추는 목적

코드 형식은 의사소통의 일환이며 의사소통은 전문 개발자의 일차적인 의무이다. 때문에 매우 중요하다.

적절한 행 길이를 유지하라

JUnit, FitNesse, Time and Money 등의 프로젝트는 500줄이 넘어가는 파일이 없으며 대부분 200줄 미만이다.
작은 파일들을 통해서 커다란 시스템을 구축할 수 있다.

신문기사처럼 작성하라

독자는 위에서 아래로 기사를 읽는다. 최상단에 기사를 몇 마디로 요약하는 표제가 나온다.
소스 파일도 비슷하다. 소스 파일 첫 부분은 고차원 개념과 알고리즘을 설명한다. 아래로 내려갈수록 세세하게, 마지막에는 가장 저차원 함수와 세부내역이 나온다.

세로 밀집도

서로 밀접한 코드 행은 세로로 가까이 놓아야 한다.

수직 거리

지역 변수는 각 함수 맨 처음에 선언한다.
인스턴스 변수는 클래스 맨 처음에 선언한다.

[Java]JVM 동작 방식과 메모리 구조

Gravity___ — Sat, 6 Aug 2022 06:31:48 +0900

▷ JVM 동작 방식

1. 자바 프로그램을 실행하면 JVM은 OS로부터 메모리를 할당받는다.
2. 자바 컴파일러가 자바 소스코드(.java)를 자바 바이트코드(.class)로 컴파일한다.
3. Class Loader를 통해 바이트코드를 JVM Data Runtime Area로 로딩한다.
4. Runtime Data Area에 로딩된 바이트코드는 Execution Engine을 통해 실행된다.

▷ JVM 구조

JVM

Java Virtual Machine
Java와 OS 사이에서 중계자 역할을 수행
자바가 OS 종류와 플랫폼에 관계없이 독립적으로 실행 가능하도록 지원한다.
GC를 통하여 자동으로 메모리 관리를 해준다.

Class Loader

생성된 바이트코드를 묶어 JVM이 운영체제로부터 할당받은 영역인 Runtime Data Area에 배치

Execution Engine

배치된 바이트코드를 기계어로 변경하여 명령어 단위로 실행
바이트코드를 운영체제에 맞게 해석해주는 역할
명령어 단위로 실행할 때 인터프리터와 JIT 두 가지 방식을 사용한다.

Garbage Collector

생성된 객체의 생존 여부를 판단하여 더 이상 참조되지 않거나 Null인 객체의 메모리를 해제한다.
Runtime Data Area 영역의 Heap 영역을 관리한다.

Runtime Data Area

JVM이 실행되면서 OS로부터 할당받은 메모리 공간

▷ JVM 메모리 구조

Method Area

클래스 파일의 바이트 코드가 로드되는 곳으로써 JVM이 무엇인가를 실행하려면 먼저 그 바이트 코드들이 메모리 공간에 저장되어 있어야 함
JVM이 동작해서 클래스가 로딩될 때 생성
클래스정보(멤버변수명), 변수정보(데이터 타입, 접근 제어자 정보), 메소드 정보, static 변수, 전역 변수, 상수풀 등이 저장되는 영역
프로그램의 시작부터 종료가 될 때까지 메모리에 남아있음

Heap Area

New 키워드로 생성된 객체와 배열이 생성되는 영역
주기적으로 GC가 제거하는 영역

Stack Area

지역변수, 파라미터, 리턴 값, 연산에 사용되는 임시 값 등이 생성되는 영역
해당 메소드가 호출될 때 메모리에 할당되고 종료되면 메모리가 해제

PC Register

스레드가 생성될 때마다 생성되는 영역
스레드가 실행되는 부분의 주소와 명령을 저장하고 있는 영역

Native Method Stack

자바 이외의 언어로 작성된 네이티브 코드가 실행될 때 사용되는 메모리 영역

[CleanCode]3장 함수

Gravity___ — Tue, 2 Aug 2022 12:33:51 +0900

CleanCode - 로버트 C.마틴

▷ 3. 함수

작게 만들어라!

함수를 만드는 첫 번째 규칙은 '작게!'다. 함수를 만드는 두 번째 규칙은 '더 작게!'다.
함수는 100줄을 넘어서는 안 된다. 아니 20줄도 길다.
다시 말해 if, else, while문 등에 들어가는 블록은 한 줄이어야 한다는 의미이다.
함수에서 들여쓰기 수준은 1단이나 2단을 넘어서면 안된다. 그래야 함수는 읽고 이해하기 쉬워진다.

한 가지만 해라!

함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다 . 그 한 가지만을 해야 한다.

public static String RenderPageWithSetupAndTeardowns(
    PagaData pagaData, boolean isSuite) throws Exception {
    if (isTestPage(pageData)) {
        includeSetupAndTeardownPages(pageData, isSuite);
    }
    return pageData.getHtml();
}

위 함수가 하는 일은 다음과 같다.

1. 페이지가 테스트 페이지인지 판단한다.
2. 그럴 경우 설정 페이지와 해제 페이지를 넣는다.
3. 페이지를 HTMLfh 렌더링한다.

그렇다면 이 함수는 한 가지만 하는가? 아니면 세 가지를 하는가?
위의 세 단계는 지정된 함수 이름 RenderPageWithSetupAndTeardowns 아래에서 추상화 수준이 하나다. 따라서 간단한 TO 문단으로 기술할 수 있다.

TO RenderPageWithSetupAndTeardowns, 페이지가 테스트 페이지인지 확인 한 후 테스트 페이지라면 설정 페이지와 해제 페이지를 넣는다. 테스트 페이지든 아니든 페이지를 HTML로 렌더링한다.

지정된 함수명 아래에서 추상화 수준이 하나인 단계만 수행한다면 그 함수는 한 가지 작업만 하는 것이다.
우리가 함수를 만드는 이유는 큰 개념을(함수 이름을) 다음 추상화 수준에서 여러 단계로 나눠 수행하기 위해서이기 때문이다.

함수 당 추상화 수준은 하나로!

함수가 확실히 '한 가지' 작업을 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 한다.
하나의 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다. 즉, 위에서 아래로 프로그램을 읽으면 함수 추상화 수준이 한 번에 한 단계씩 낮아진다. 저자는 이것을 '내려가기 규칙'이라고 부른다.

추상화 수준

책에서는 해당 챕터에서 '추상화 수준'에 대하여 계속 언급하고 있다.

public void nameCheckAndSignUp() {
    if (!isEmptyUserName()) {
        doJoinProcess(duplicateCheck());
    } else {
        setNameCheck("닉네임이 공백입니다.");	
    }
}

위 코드는 추상화를 통하여 구체적인 것을 감추고, 보고 싶어하는 전체적인 특성을 드러내고 있다. 즉 추상화 수준이 높은 코드이다.
덕분에 각 함수 내부를 보지 않더라도 위 함수의 역할이 무엇인지 파악할 수 있다.

Switch문

Switch문은 작게 만들기 어려우며 완전히 피할 방법은 없다. 하지만 각 Switch문을 저차원 클래스에 숨기고 절대로 반복하지 않는 방법은 있다. 이는 다형성을 이용한다.

public Money calculatePay(Employee e) throws InvaildEmployType {
    switch (e.type) {
        case COMMISSIONED:
            return calculateCommissionedPay(e);
        case HOURLY:
            return calculateHourlyPay(e);
        case SALARIED:
            return calculateSalariedPay(e);
        default:
            throw new InvalidEmployeeType(e.type);
    }
}

위 함수가 하는 일은 다음과 같다.

1. 함수가 길다. 새 직원 유형을 추가하면 더 길어진다.
2. '한 가지' 작업만 수행하지 않는다.
3. SRP(단일 책임 원칙)을 위반한다. 코드를 변경할 이유가 여럿이기 때문이다.
4. OCP(개방 폐쇄 원칙)을 위반한다. 새 직원 유형을 추가할 때마다 코드를 변경해야 하기 때문이다.
5. 위 함수와 구조가 동일한 함수가 무한정 존재한다는 것이다. isPayday(Employee e, Date date); 혹은 deliverPay(Employ e, Money pay); ...

따라서 아래 코드와 같이 해결해야 한다.

public abstract class Employee {
    public abstract boolean isPayday();
    public abstract Money calculatePay();
    public abstract void deliverPay(Money pay);
}

public interface EmployeeFactory {
    public Employee makeEmployee(EmployeeRecord r) throws InvaildEmployType;
}

public class EmployeeFactoryImpl implements EmployeeFactory {
    public Employee makeEmployee(EmployeeRecord r) throws InvaildEmployType {
        switch (r.type) {
            case COMMISSIONED:
                return new CommissionedEmployee(r);
            case HOURLY:
                return new HourlyEmployee(r);
            case SALARIED:
                return new SalariedEmployee(r);
            default:
                throw new InvalidEmployeeType(r.type);
        }
    }
}

Switch문을 추상 팩토리에 숨긴다. 아무에게도 보여주지 않는다.
팩토리는 Switch문을 사용해 적절한 Employee 파생 클래스의 인스턴스를 생성한다.
calculatePay, isPayday, deliverPay 등과 같은 함수는 Employee 인터페이스를 거쳐 호출된다. 그러면 다형성으로 인해 실제 파생 클래스의 함수가 실행된다.

서술적인 이름을 사용하라!

이름이 길어도 괜찮다. 겁먹을 필요 없다. 길고 서술적인 이름이 짧고 어려운 이름보다 좋다.
이름을 붙일 때는 일관성이 있어야 한다. includeSetupPage, includeTeardownPage 등이 그 예이다.

함수 인수

함수에서 이상적인 인수 개수는 0개(무항)이다. 다음은 1개(단항)이고, 그 다음은 2개(이항)이다. 3개는 가능한 피하는 편이 좋으며 4개 이상은 특별한 이유가 있어야 한다.(그러나 특별한 이유가 있어도 사용하면 안된다.)
인수는 개념을 이해하기 어렵게 만든다. 코드를 읽는 사람에게는 includeSetupPageInfo(new PageContent)보다 includeSetupPageInfo()가 더 이해하기 쉽다.
테스트 관점에서 보면 인수는 더 어렵다.
출력 인수는 입력 인수보다 이해하기 렵다.
최선은 입력 인수가 없는 것이며 차선은 입력 인수가 1개뿐인 경우다.

많이 쓰는 단항 형식

함수에 인수 1개를 넘기는 이유로 가장 흔한 경우는 두 가지이다. 이 외의 케이스에서는 단항 함수는 가급적 피한다.

1. 인수에 질문을 던지는 경우다. boolean fileExists("MyFIle")
2. 인수로 뭔가를 변환해 결과를 반환하는 경우다. inputStream fileOpen("MyFile") : String형의 파일 이름을 InputStream으로 변환한다.

플래그 인수

플래그 인수는 추하다. 함수로 boolean 값을 넘기는 관례는 함수가 한꺼번에 여러 가지를 처리한다고 대놓고 공표하는 셈이니까.

이항 함수

인수가 2개인 경우에는 1개인 경우보다 이해하기 어렵다.
Point p = new Point(0,0)처럼 이항 함수가 적절한 경우도 있다.
당연하게 여겨지는 이항 함수 assertEquals(expected, actual)도 문제가 있다. 두 인수의 순서를 인위적으로 기억해야 한다.
불가피한 경우도 있지만 가급적 위험이 따른다는 사실을 인지하고 가능하면 단항 함수로 바꾸도록 애써야한다.

writeField(outputStream, name)을 writeField(name) 단항 함수로 바꾸기
1. writeField 메서드를 outputStream 클래스 구성원으로 만들어 outputStream(name)으로 호출한다.
2. outputStream을 현재 클래스 구성원 변수로 만들어 인수로 넘기지 않는다.
3. FieldWriter라는 새 클래스를 만들어 구성자에서 outputStream을 받고 write메서드를 구현한다.

동사와 키워드

단항 함수는 함수와 인수가 동사/명사 쌍을 이뤄야한다. write(name)보다는 writeField(name)이 더 좋은 코드이다.
함수 이름에 키워드를 추가할 수 있다. 그러면 인수 순서를 기억할 필요 없다. ex) assertExpectedEqualsActual(expected, actual)

부수 효과를 일으키지 마라

public boolean checkPassword(String uesrName, String password) {
    Uesr user = UesrGateway.findByName(userName);
    if (user != User.NULL) {
        String codedPhrase = user.getPhraseEncodeByPassword();
        String phrase = cryptographer.decrypt(codedPhrase, password);
        if ("Vaild Password").equals(phrase) {
            Session.initialize();
            return true;
        }
    }
    return false;
}

위 코드에서 함수가 일으키는 부수 효과는 Session.initialize() 호출이다. 함수명만 봐서는 세션을 초기화한다는 사실이 드러나지 않는다.
함수 이름만 보고 함수를 호출하는 사용자는 사용자를 인증했을 뿐인데 기존 세션 정보를 지워버릴 위험에 처한다.
위 함수는 checkPasswordAndInitializeSession이라는 이름이 훨씬 좋다. 물론 함수가 '한 가지'만 한다는 규칙을 위반하지만

출력 인수

일반적으로 우리는 인수를 함수 입력으로 해석하며 인수를 출력으로 사용하는 함수에 어색함을 느낀다.
객체지향 언어에서 출력 인수를 사용할 필요가 거의 없다. 출력 인수로 사용하라고 설계한 변수가 this이기 때문이다.
다시 말해 public void appendFooter(StringBuffer report)보다는 report.appendFooter()로 호출하여 출력 인수를 피해야 한다.

명령과 조회를 분리하라

함수는 뭔가를 수행하거나 뭔가에 답하거나 둘 중 하나만 해야 한다.

if (set("userName", "unclebob")) {}
		
if (attributeExists("userName")) {
    setAttribute("userName", "unclebob");
}

첫 줄의 코드만 봐서는 유저명이 unclebob인지 확인하는 코드인지, 아니면 유저명을 unclebob으로 설정하는 코드인지 의미를 알 수 없다.
때문에 아래와 같이 명령과 조회를 분리하여 혼란을 뿌리뽑아야 한다.

오류 코드보다 예외를 사용하라

명령 함수에서 오류 코드를 반환하는 방식은 명령/조회 분리 규칙을 미묘하게 위반한다.
오류 코드를 반환하면 호출자는 오류 코드를 곧바로 처리해야 한다는 문제에 부딪히기 때문에 예외를 사용하면 오류 처리 코드가 원래 코드에서 분리되므로 아래와 같이 깔끔해진다.

try {
    deletePage(page);
    registry.deleteReference(page.name);
    configKeys.deleteKey(page.name.makeKey());
} catch (Exception e) {
    logger.log(e.getMessage());
}

조금 더 개선해보자면 try/catch 볼록은 원래 추하다. 코드 구조에 혼란을 일으키며 정상 동작과 오류 처리 동작을 뒤섞는다. 그러므로 별도 함수로 뽑아내는 편이 좋다.

public void delete(Page page) {
    try {
        deletePageAndAllReferences(page)
    } catch (Exception e) {
        logError(e);
    }
}

private void deletePageAndAllReferences(Page page) throws Exception {
    deletePage(page);
    registry.deleteReference(page.name);
    configKeys.deleteKey(page.name.makeKey());
}

private void logError(Exception e) {
    logger.log(e.getmessage());
}

deletePageAndAllReferences 실제로 페이지를 제거하는 함수이며 예외를 처리하지 않는다. 이렇게 정상 동작과 오류 처리 동작을 분리하면 코드를 이해하고 수정하기 쉬워진다.

의존성 자석

public enum Error {
	OK,
	INVALID,
	NO_SUCH,
	LOCKED,
	OUT_OF_RESOURCES,
	WAITING_FOR_EVENT;
}

오류 코드를 반환한다는 것은 클래스든 열거형 변수든, 어디선가 오류 코드를 정의한다는 뜻이다.
이는 Error enum이 변한다면 Error enum을 사용하는 모든 클래스를 컴파일하고 다시 배치해야하므로 Error 클래스 변경이 어렵다.
오류 코드 대신 예외를 사용하면 새 예외는 Exception 클래스에서 파생된다. 따라서 재컴파일 없이 새 예외 클래스를 추가할 수 있다.

결론

모든 시스템은 특정 응용 분야 시스템을 기술할 목적으로 프래그래머가 설계한 도메인 특화 언어로 만들어진다.
작성하는 함수가 분명하고 정확한 언어로 깔끔하게 같이 맞아 떨어져야 시스템이라는 이야기를 풀어가기 쉬워진다는 사실을 기억해야 한다.

[CleanCode]1, 2장 깨끗한 코드 / 의미있는 이름

Gravity___ — Mon, 1 Aug 2022 22:41:35 +0900

CleanCode - 로버트 C.마틴

▷ 1. 깨끗한 코드

코드란?

기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업이 프로그래밍이며 이렇게 명시한 결과가 코드이다.

깨끗한 코드란?

1. 비야네 스트롭스트룹

우아하고 효율적인 코드, 논리가 간단해야 버그가 숨어들지 못하며 의존성을 최대한 줄여야 유지보수가 쉬워진다.
오류는 명백한 전략에 의거해 철저히 처리한다. 성능을 최적으로 유지해야 사람들이 원칙없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다.
깨끗한 코드는 한 가지를 제대로 해야한다.

2. 그래디 부치

단순하고 직접적이다. 잘 쓴 문장처럼 잘 읽힌다.(가독성 강조)
설계자의 의도를 숨기지 않으며 명쾌한 추상화와 단순한 제어문으로 가득하다.

3. 큰 데이브 토마스

작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다.
단위 테스트 케이스와 인수 테스트 케이스가 존재한다. 깨끗한 코드에는 의미 있는 이름이 붙는다.
특정 목적을 달성하는 방법은 하나만 제공한다. 의존성은 최소이며 각 의존성을 명확히 정의한다.
API는 명확하며 최소로 줄인다. 언어에 따라 필요한 모든 정보를 코드만으로 명확히 표기할 수 없기 때문에 문학적으로 표현해야 마땅하다.

4. 마이클 페더스

언제나 누군가 주의 깊게 짰다는 느낌을 준다.
고치려고 살펴봐도 딱히 손 댈 곳이 없다. 작성자가 이미 모든 사항을 고려했으므로.
고칠 궁리를 하다보면 언제나 제자리로 돌아온다. 그리고는 누군가가 남겨준 코드, 누군가 주의 깊게 짜놓은 작품에 감사를 느낀다.

5. 론 제프리스

모든 테스트를 통과해야 하며 중복이 없다.
시스템 내 모든 설계 아이디어를 표현하며 클래스, 메서드, 함수 등을 최대한 줄인다.

6. 워드 커닝햄

코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 할 수 있다.
코드가 그 문제를 풀기 위한 언어처럼 보인다면 아름다운 코드라 불러도 되겠다.

우리는 저자다

javadoc에서 @author필드는 저자를 소개한다. 우리는 저자다. 저자에게는 독자가 있다. 그리고 저자에게는 독자와 잘 소통할 책임도 있다.
코드를 짤 때는 자신이 저자라는 사실을, 여러분의 노력을 보고 판단을 내릴 독자가 있다는 사실을 기억해야 한다.

▷ 2. 의미있는 이름

의미를 분명히 밝혀라

변수나 함수 그리고 클래스 이름은 다음과 같은 굵직한 질문에 모두 답해야 한다. 변수, 함수, 클래스의 존재 이유는? 수행 기능은?
따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.

public List<int[]> getThem() {
    List<int[]> list1 = new ArrayList<int[]>();
    for (int[] x : theList) {
        if (x[0] == 4) {
            list1.add(x);
        }
    }
}

위 코드는 의도를 짐작하기 어렵다. 문제는 코드의 단순성이 아니라 함축성이다. 즉 코드 맥락이 코드 자체에 명시적으로 드러나지 않는다.
목적은 지뢰찾기 게임을 만드는 것이었다고 한다면 아래 코드와 같이 수정할 수 있다.

public List<int[]> getFlaggedCells() {
    List<int[]> flaggedCells = new ArrayList<int[]>();
    for (int[] cell : gameBoard) {
        if (cell[STATUS_VALUE] == FLAGGED) {
            flaggedCells.add(cell);
        }
    }
    return flaggedCells;
}

코드의 단순성, 연산자와 상수의 수, 들여쓰기 단계 또한 동일하나 코드는 더욱 명확해졌다.
더 나아가 int배열을 사용하는 대신 칸을 간단한 클래스로 만들 수 있다. 또한 좀 더 명시적인 함수를 사용해 FLAGGED라는 상수를 감춰도 되겠다.

public List<int[]> getFlaggedCells() {
    List<Cell> flaggedCells = new ArrayList<Cell>();
    for (Cell cell : gameBoard) {
        if (cell.isFlagged()) {
            flaggedCells.add(cell);
        }
    }
    return flaggedCells;
}

단순히 이름만 고쳤는데도 함수가 하는 일을 이해하기 쉬워졌다. 바로 이것이 좋은 이름을 주는 위력이다.

그릇된 정보를 피하라

널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하면 안된다.
서로 흡사한 이름을 사용하지 않도록 주의한다.
여러 계정을 그룹으로 묶을 때 실제 List가 아니라면 accountList로 명명하지 않는다. accountGroup, bunchOfAccounts, Accounts 등으로 칭할 수 있다.

인코딩을 피해라

IDE는 코드를 컴파일하지 않고도 타입 오류를 감지할 정도로 발전했다. 따라서 이제는 헝가리식 표기법이나 기타 인코딩 방식이 방해가 될 뿐이다.
멤버 변수에 m_이라는 접두어를 붙일 필요도 없다.
때로는 인코딩이 필요한 경우도 있다. 다만 인터페이스 이름은 접두어를 붙이지 않는 편이 좋다고 생각한다. 인터페이스가 shapeFactory일 경우 구현체인 클래스는 shapeFactoryImpl 또는 CShapeFactory이라 명명한다.

클래스 이름

클래스명, 객체명 명사, 명사구가 적합하다.
Customer, WikiPage, Account, AddressParser 등이 좋은 예이며 Manager, Processor, Data, Info 등과 같은 단어는 피하고 동사는 사용하지 않는다.

메서드 이름

메서드명은 동사나 동사구가 적합하다.(postPayment, deletePage, save 등이 좋은 예이다.)
접근자, 변경자, 조건자는 javabean 표준에 따라 값 앞에 get, set, is를 붙인다.

String name = employee.getName();
customer.setName('mike');
if (paycheck.isPosted) {}

Customer, WikiPage, Account, AddressParser 등이 좋은 예이며 Manager, Processor, Data, Info 등과 같은 단어는 피하고 동사는 사용하지 않는다.

한 개념에 한 단어만 사용하라

추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다.
똑같은 메서드를 클래스별로 fetch, retrieve, get으로 제각각 부르면 혼란스럽다.

말장난을 하지마라

'한 개념에 한 단어만 사용하라' 규칙을 따르기 위해 같은 맥락이 아닌데도 일관성을 고려해 메서드명은 둘 다 add라고 칭하면 안된다.
새 메서드는 add가 아닌 insert 또는 append라는 이름이 적당하다.
집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표다.

해법 영역에서 가져온 이름을 사용하라

코드를 읽은 이도 프로그래머이기 때문에 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용 해도 괜찮다.
모든 이름을 문제 영역에서 가져오는 정책은 현명하지 못하다.
VISITOR 패턴에 친숙한 프로그래머는 AccountVisitor라는 이름을 금방 이해한다.

문제 영역에서 가져온 이름을 사용하라

적절한 프로그래머 용어가 없다면 문제 영역에서 이름을 가져온다.
코드를 보수하는 프로그래머는 그 분야 전문가에게 의미를 물어 파악할 수 있다.
문제 영역과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다.

한 개념에 한 단어만 사용하라

추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다.
똑같은 메서드를 클래스별로 fetch, retrieve, get으로 제각각 부르면 혼란스럽다.

의미있는 맥락을 추가하라.

firstName, lastName, city, state 등의 변수가 있을 경우 주소라는 사실을 금방 알아챈다. 하지만 메서드에서 state라는 변수 하나만 사용한다면?
addr이라는 접두어를 추가해 addrFirstName, addrLastName, addrCity, addrState라 쓰면 맥락이 좀 더 분명해진다.

[IntelliJ]자주 사용하는 단축키(Mac, Window)

Gravity___ — Sat, 30 Jul 2022 13:15:16 +0900

▷ Mac

Command

- 변수 생성 및 세미 콜론 주입 : 엔터(기존 Option + Enter였으나 커스텀)

- 자동완성 : Command + Space(기존 Ctrl + Space였으나 커스텀)

- 한줄 복사 : Command + 백스페이스

- 한줄 제거 : Command + X

- 현재 탭 닫기 : Command + W

- 소스 자동정렬 : Command + Option + L

- 오른쪽 탭으로 이동 : Command + Shift + ]

- 왼쪽 탭으로 이동 : Command + Shift + [

- 테스트 클래스 생성 : Command + Shift + T

- 생성자, Getter, Setter 자동 완성 : Command + N

- 인터페이스, 추상 클래스의 오버라이드 메소드 자동 완성 : Control + I

- 변수 추출 : Command + Option + V

- 파라미터 추출 : Command + Option + P

- 메소드 추출 : Command + Option + M

- 최근 열었던 파일 조회 : Command + E

- 전체에서 검색 : Command + Shift + F

- 전체에서 교체 : Command + Shift + R

- 현재 파일에서 교체 : Command + R

- 현재 파일에서 검색 : Command + F

- Run : Command + Shift + S(기존 Option + R이었으나 커스텀)

Shift

- 파일 검색 : Shift + Control + N

Option

- 실행 : Option + R - 라인 합치기 : Opition + Shift + J

- 메소드 검색 : Option + Command + O

- 포커스 : Option + 위, 아래

- 멀티 포커스 : Option + Option + 위, 아래

- 라인 이동 : Option + Shift : 위, 아래

Controll

- 스마트 자동완성 : Control + Shift + Space

- 페이지 업, 다운 : Fn + 위 아래

▷ Window

- Alt + Insert

→ 포커스가 로직에 있을 경우 : Generate(Getter, Setter, Constructor, toString 등을 만들어줌)

→ 포커스가 Project Explorer에 있을 경우 : 파일 생성

- 자동 Import : Alt + Shift + Enter

Ctrl

- 한줄 삭제 : Ctrl + Y

- 한줄 추가 : Ctrl + D

- 한줄 라인 이동 : Ctrl + Shift + 위, 아래

- 동일한 단어 동시에 선택 : Ctrl + Alt + Shift + J

- 작업이력 조회 : Ctrl + E

- 테스트 클래스 생성 : Ctrl + Shift + T

- 전체 파일의 특정 단어검색 : Ctrl + Shift + F

- 자바 어플리케이션 실행 : Ctrl + Shift + F10

- 깃 커밋창 : Ctrl + K

- 깃 푸쉬창 : Ctrl + Shift + K

- 문장 끝에 세미 콜론붙이기 : Ctrl + Shift + Enter :

- Ctrl + Alt + N

int resultCount = em.createQuery("update Member m set m.age = m.age + 1" +
                " where m.age >= :age")
        .setParameter("age", age)
        .executeUpdate();

return resultCount;

resultCount에 커서를 두고 Ctrl + Alt + N를 입력하면

return em.createQuery("update Member m set m.age = m.age + 1" +
                " where m.age >= :age")
        .setParameter("age", age)
        .executeUpdate();

- Ctrl + Alt + V

em.createQuery("update Member m set m.age = m.age + 1" +
                " where m.age >= :age")
        .setParameter("age", age)
        .executeUpdate();

CreateQuery에 커서를 두고 Ctrl + Alt + V를 입력하면

int resultCnt = em.createQuery("update Member m set m.age = m.age + 1" +
                " where m.age >= :age")
        .setParameter("age", age)
        .executeUpdate();

Shift

- 파일찾기, 단어가 포함된 파일찾기 :Shift + Shift

- File Rename : Shift + F6

- 에러가 나는 코드로 바로 이동 : F2

[알고리즘 문제]배낭 문제(백준 12865번)

Gravity___ — Thu, 28 Jul 2022 01:03:42 +0900

▷ 문제

이 문제는 아주 평범한 배낭에 관한 문제이다.

한 달 후면 국가의 부름을 받게 되는 준서는 여행을 가려고 한다. 세상과의 단절을 슬퍼하며 최대한 즐기기 위한 여행이기 때문에, 가지고 다닐 배낭 또한 최대한 가치 있게 싸려고 한다.

준서가 여행에 필요하다고 생각하는 N개의 물건이 있다. 각 물건은 무게 W와 가치 V를 가지는데, 해당 물건을 배낭에 넣어서 가면 준서가 V만큼 즐길 수 있다. 아직 행군을 해본 적이 없는 준서는 최대 K만큼의 무게만을 넣을 수 있는 배낭만 들고 다닐 수 있다. 준서가 최대한 즐거운 여행을 하기 위해 배낭에 넣을 수 있는 물건들의 가치의 최댓값을 알려주자.

* 입력

첫 줄에 물품의 수 N(1 ≤ N ≤ 100)과 준서가 버틸 수 있는 무게 K(1 ≤ K ≤ 100,000)가 주어진다. 두 번째 줄부터 N개의 줄에 거쳐 각 물건의 무게 W(1 ≤ W ≤ 100,000)와 해당 물건의 가치 V(0 ≤ V ≤ 1,000)가 주어진다.

입력으로 주어지는 모든 수는 정수이다.

* 출력
한 줄에 배낭에 넣을 수 있는 물건들의 가치합의 최댓값을 출력한다.

▷ 입력 예시

4 7

6 13

4 8

3 6

5 12

▷ 출력 예시

▷ 풀이

알고리즘 문제 중 유명한 예제 중 하나인 배낭 문제는

1) 물건을 쪼갤 수 있는 배낭 문제

2) 물건을 쪼갤 수 없는 배낭 문제로 나뉜다.

1번 같은 경우에는 가치가 큰 물건부터 담고 남는 무게 만큼 물건을 쪼개 넣을 수 있기 때문에

그리디 알고리즘으로 풀 수 있으며 이번 예제와 같은 2번 문제는 동적 계획법(다이나믹 프로그래밍)을 이용한다.

문제에 대한 해설을 잘 풀어놓은 글을 링크로 걸어둔다.

코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.StringTokenizer;

public class Main {
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());
        int n = Integer.parseInt(st.nextToken()); // 물건의 수
        int k = Integer.parseInt(st.nextToken()); // 최대 무게
        int[] w = new int[n+1]; // 무게
        int[] v = new int[n+1]; // 가치
        int[][] dp = new int[n+1][k+1];
        int max = 0;

        for (int i = 1; i <= n ; i++) {
            st = new StringTokenizer(br.readLine());
            w[i] = Integer.parseInt(st.nextToken());
            v[i] = Integer.parseInt(st.nextToken());
        }

        for (int i = 1; i <= n; i++) {
            for (int j = 1; j <= k; j++) {
                if (j >= w[i]) {
                    dp[i][j] = Math.max(dp[i - 1][j], v[i] + dp[i-1][j - w[i]]);
                } else {
                    dp[i][j] = dp[i - 1][j];
                }
                max = Math.max(dp[i][j], max);
            }
        }

        System.out.println(max);
    }
}

[알고리즘 문제]돌다리 건너기

Gravity___ — Mon, 24 Jan 2022 08:14:51 +0900

▷ 문제

철수는 학교에 가는데 개울을 만났습니다. 개울은 N개의 돌로 다리를 만들어 놓았습니다. 철수는 돌 다리를 건널 때 한 번에 한 칸 또는 두 칸씩 건너뛰면서 돌다리를 건널 수 있습니다.
철수가 개울을 건너는 방법은 몇 가지일까요?

* 입력
첫째 줄은 돌의 개수인 자연수 N(3≤N≤35)이 주어집니다.
* 출력설명
첫 번째 줄에 개울을 건너는 방법의 수를 출력합니다.

▷ 입력 예시

▷ 출력 예시

▷ 풀이

import java.util.*;
import java.io.BufferedReader;
import java.io.InputStreamReader;

class Main {
    static int[] dy;
    public int solution(int n){
        dy[1] = 1;
        dy[2] = 2;

        for(int i=3; i<=n+1; i++){
            dy[i] = dy[i-1] + dy[i-2];
        }

        return dy[n+1]; // 돌다리를 거는 방법 = 돌다리를 건넌 시점의 경우의 수
    }

    public static void main(String[] args) throws IOException {
        Main main = new Main();
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        int n = Integer.parseInt(br.readLine());

        dy = new int[n+2];
        System.out.println(main.solution(n));
    }
}

▷ 메모

계단 오르기 문제와 다르게 돌다리 문제는 건넌 시점의 경우의 수를 물어보는 것임에 주의

[알고리즘 문제]계단오르기 - 다이나믹 프로그래밍(Bottom-Up)

Gravity___ — Wed, 29 Dec 2021 07:39:50 +0900

▷ 문제

철수는 계단을 오를 때 한번에 한 계단 또는 두 계단씩 올라간다. 만약 총 4계단을 오른다면 그 방법의 수는

1+1+1+1, 1+1+2, 1+2+1, 2+1+1, 2+2로 5가지이다.

그렇다면 총 N계단일 때 올라갈 수 있는 방법의 수는 몇 가지인가?

* 입력
첫째 줄은 계단의 개수인 자연수 N(3<=N<=35)이 주어집니다.
* 출력
첫 번째 줄에 올라가는 방법의 수를 출력합니다.

▷ 입력 예시

▷ 출력 예시

▷ 풀이

import java.util.*;

class Main {
    static int[] dy;
    public int solution(int n){
        dy[1] = 1;
        dy[2] = 2;

        for(int i=3; i<=n; i++){
            dy[i] = dy[i-2] + dy[i-1];
        }

        return dy[n];
    }
    public static void main(String[] args){
        Main main = new Main();
        Scanner kb = new Scanner(System.in);
        int n = kb.nextInt();
        kb.close();
        dy = new int[n+1];
        System.out.println(main.solution(n));
    }
}

▷ 메모

다이나믹 프로그래밍(동적 계획법)은 일반적으로 바텀업과 탑다운 방식을 사용하여 푼다.
바텀업 방식은 주로 반복문, 탑다운 방식은 재귀함수를 사용하여 문제에 접근한다.
각 계단에 올라가는 방법의 수를 가지는 배열 dy를 선언하여 바텀업 방식으로 문제를 풀 수 있다.