코테 풀다가 SRP 원칙에 맞게 함수를 바꿔봄.

코테 대비용 문제를 풀면서 srp 원칙에 맞게 함수명에 맞는 작업만 하도록 코드를 바꿔보았다.

코딩테스트 연습 - 소수 만들기

기존 방식:
문제를 풀 때 makeCombi 라는 함수에서

1. 소수를 만들기 위한 3개의 숫자를 뽑고,
2. 뽑은 후에는 소수인지 확인
3. 소수인 경우 1을 리턴
   하도록 구현했었다.

이는 객체지향 5원칙 중 단일 책임 원칙에 위배된다.
단일 책임 원칙이 지겨지기 위해서는 클래스는 단 한개의 책임을 가져야한다.

문제 푸는 데에는 어떻게 하든 정답이지만.. 바꾼 결과:

import java.util.*;

class Combination {
    int[] nums;

    public Combination(int[] nums) {
        this.nums = nums;
    }

    void makeCombi(List<Integer> combi, int lv, int idx, List< List<Integer> > combinations) {
        int ret = 0;
        if (idx + (3-lv) > nums.length) {
            return;
        }
        if (lv == 3) {
            combinations.add(combi);
            return;
        }
        List<Integer> newCombi = new ArrayList<>(combi);
        newCombi.add(nums[idx]);
        makeCombi(newCombi, lv+1, idx+1, combinations);

        makeCombi(combi, lv, idx+1, combinations);
    }
}
class Solution {
    int[] nums;
    boolean isPrime(int num) {
        boolean ret = true;
        int number = num/2;
        for (int i=2; i <= number; i++) {
            if (num % i == 0) {
                ret = false;
                break;
            }
        }
        return ret;
    }

    public int solution(int[] nums) {
        int answer = 0;
        this.nums = nums;

        List< List<Integer> > combis = new ArrayList<>();
        new Combination(nums).makeCombi(new ArrayList<>(), 0, 0, combis);
        int list_size = combis.size();
        for (int i=0; i < list_size; i++) {
            int sum = 0;
            for (int num: combis.get(i).stream().mapToInt(n->n).toArray()) {
                sum += num;
            }
            if (isPrime(sum)) answer++;
        }

        return answer;
    }
}

SOLID : 객체지향 5원칙

1. SRP (Single Responsibility Principle) 단일 책임의 원칙

한 클래스는 하나의 책임(기능)만을 가져야한다.

하나의 속성은 하나의 의미를 가져야 하며, 경우에 따라 다르게 쓰이면 안된다. 즉 반대로 srp가 안지켜진다면...

• 변수/메소드가 여러 기능을 함.
• 메소드에 분기처리를 위한 if 문이 많음.
• 수정이 필요할 경우 수정되는 이유는 하나 때문이어야 함.

2. OCP (Open Close Principle)

수정에는 닫히고 확장에는 열 것.

• 기존의 코드는 변경하지 않으면서 기능은 추가가 될 수 있도록 설계되어야 함.

3. LSP (Listov Substitution Principle) 리스코프 치환 원칙

자식 클래스는 부모클래스를 언제나 대체할 수 있어야함.

4. ISP (Inteface Segregation Principle) 인터페이스 분리 원칙

클래스에서 사용하지 않는 인터페이스는 구현하지 말아야함. ⇒ 여러 구체적인 인터페이스를 설계하는 것이 좋음.

5. DIP (Dependency Injection Principle)

의존 관계를 맺을 때 자주 변화하는 것보다 거의 변화가 없는 것에 의존해야함.

⇒ 인터페이스나 추상클래스와 관계가 맺어져야함.