커머스 발제와 달리기반 내용 정리 중 오늘은 달리기반 내용을 전체 훍어보고 람다와 스트림에 대해 알아보고 내일부터 커머스 발제를 풀어 볼려고 합니다.
제일 이해가 어려웠던 부분
step4
😫 Phase 1: "녹색 사과만 골라줘!"
농장 주인이 첫 번째 요구를 합니다.
"창고에서 녹색 사과만 다 꺼내주게."
우리는 단순하게 코드를 짭니다.
public static List<Apple> filterGreenApples(List<Apple> inventory) {
List<Apple> result = new ArrayList<>();
for (Apple apple : inventory) {
if (Color.GREEN.equals(apple.getColor())) { // 녹색만 딱 집어서!
result.add(apple);
}
}
return result;
}😡 Phase 2: "빨간 사과도 골라달라니까?"
다음 날, 농장 주인이 화를 냅니다.
"아니, 왜 빨간 사과는 안 골라줘? 다시 만들어!"
우리는 고민합니다. filterRedApples를 또 만들까요?
아니죠, 색깔을 파라미터로 받으면 해결됩니다.
// 색깔(Color)을 파라미터로 받아서 유연해졌다! (값 파라미터화)
public static List<Apple> filterApplesByColor(List<Apple> inventory, Color color) {
...
if (apple.getColor().equals(color)) { ... }
...
}🤯 Phase 3: "무거운 사과도 고르고 싶은데?"
일주일 뒤, 농장 주인이 또 찾아옵니다.
"색깔 말고, 이번엔 150g 넘는 무거운 사과만 골라줘. 아, 그리고 빨간색인데 무거운 사과도 골라주고..."
이젠 단순히 값을 파라미터로 받는 걸로는 부족합니다. 조건이 계속 바뀌니까요.
이때 천재적인 아이디어가 떠오릅니다.
"조건(검사하는 방법) 자체를 파라미터로 받으면 어떨까?"
이것이 바로 동작 파라미터화입니다.
우리는 ApplePredicate라는 전략(Strategy)을 만듭니다.
// "사과를 검사하는 방법"을 추상화
public interface ApplePredicate {
boolean test(Apple apple);
}
// 메인 메서드는 이제 '검사 방법(p)'을 받아서 실행만 합니다.
public static List<Apple> filterApples(List<Apple> inventory, ApplePredicate p) {
...
if (p.test(apple)) { // "이 사과 합격인가요?"라고 물어봄
result.add(apple);
}
...
}🌈 Phase 4: "사과 말고 바나나는?" (제네릭)
// T: 무엇이든 들어올 수 있다!
public static <T> List<T> filter(List<T> list, GenericPredicate<T> p) { ... }// 숫자 중 짝수만 골라줘!
filter(numbers, (Integer i) -> i % 2 == 0);- 하드코딩: 변화에 대응 불가능 (Phase 1)
- 값 파라미터화: 조건이 바뀌면 대처 불가능 (Phase 2)
- 동작 파라미터화: 어떤 조건이든 대응 가능! (Phase 3)
- 제네릭: 어떤 객체든 적용 가능 (Phase 4)
단순히 Ctrl + C, V 가 아니라 코드를 읽으면서 Ctrl + 좌 클릭을 통해 흐름을 파악하려고 노력했습니다. 또한 구조체? 같은 것도 보면서 열심히 익혔습니다.
솔직히 아침부터 시작해서 봤는데 못 끝냈네요. 대충 보고 넘어가야 하나 싶은데 앞으로 람다, 스트림 발제에서 사용할 거 생각하면 더 열심히 봐야 하나 싶기도 하고...발제도 얼른 시작 해야 하는데... 결론은 그냥 열심히 더 하자 아자아자!!
오늘 홍순구 튜터님이 상담을 오셨다. 상담을 해주시는데 따뜻한 이 느낌...따스한 햇살 아... 미스터 선샤인... 하는 말씀 잘 듣고 잘 따라가봐야겠다!!
