java8의 통과 행위 매개 변수화 전달 코드

실습하는 동안 저는 사용자의 수요가 끊임없이 변화하기 때문에 자신의 코드도 재구성해야 한다는 이치를 깊이 깨달았습니다. 이것은 제가 디자인한 코드가 부족하다는 문제를 설명했습니다.그래서 프로그래머로서 중요한 것은 코드가 변화에 적응할 수 있도록 하는 것이라고 생각합니다.

비헤이비어 매개 변수

행위 매개 변수화는 우리가 빈번하게 변화하는 수요를 처리하는 데 도움을 줄 수 있는 소프트웨어 개발 모델이다. 통속적으로 말하면 코드 블록을 꺼내서 그것을 준비하고 실행하지 않는 것이다.이 코드 블록은 나중에 프로그램의 다른 부분에 호출될 수 있다. 이것은 우리가 이 코드의 집행을 늦출 수 있다는 것을 의미한다.

배경.

농장에 사과가 많으니 우리는 특정한 사과를 선별해서 기록해야 한다.다음으로, 우리는 끊임없이 변화하는 수요를 통해 우리의 코드를 재구성한다.아래의 장면은 모두 내가 가상해 낸 것이어서 이야기의 발전에 편리하다. 하하.

단편 1

처음에 다른 사람들이 우리에게 요구한 것은 모든 색깔이 녹색인 사과를 선별하는 것이다.나는 네가 나를 경멸하는 것이 아니냐고 생각했다. 이렇게 간단하니, 녹색 사과를 새 집합에 두루 두면 되지 않겠니?나는 프로그래머야. 잡일을 하러 온 게 아니라 강요하는 코드를 써야 돼.됐어, 그냥 써.코드는 다음과 같습니다.

 public static List filterGreenApples(List inventory) {
        List result = new ArrayList<>();
        for (Apple apple : inventory) {
            if ("green".equals(apple.getColor())) {
                result.add(apple);
            }
        }
        return result;
    }

나는 코드를 제출한 후에 엉덩방아를 찧으며 다른 일을 했다. 마치 매우 큰 프로젝트를 완성한 것 같다...

부분 2

다음날, 그 사람은 또 나를 찾아와서 빨간색 사과를 선별하는 인터페이스를 실현할 수 있겠느냐고 말했다.나는 마음속으로 혼잣말을 했다. 침대칸. 이 수요의 변화가 그렇게 빨랐는데, 어제는 사과가 푸르고, 오늘은 빨개졌다. 니마, 이 극악무도한 상인, 촉매제는 대단하다.앞으로 사과를 먹을 때는 푸른 것을 먹어라.처음에 나는 위의 코드copy를 내린 다음에'green'을'red'로 바꾸려고 했지만 자세히 생각해 보니 만약에 내일 흑사과 인터페이스를 쓰라고 한다면 나는 또 하나를 쓰지 않을 것이다.그래서 color를 추상화하여 하나의 매개 변수로 가져와서 네가 원하는 색깔을 내가 다 가지게 되었다.갑자기 내가 대단하다는 걸 알게 됐어요. 추상적인 것도 할 줄 알아요...자기 도취 중.코드는 다음과 같습니다.

  public static List filterApplesByColor(List inventory, String color) {
        List result = new ArrayList<>();
        for (Apple apple : inventory) {
            if (color.equals(apple.getColor())) {
                result.add(apple);
            }
        }
        return result;
    }

다 쓴 후에 나는 마음속으로 그 투덜거리는 극악무도한 자본주의에 대해 색깔을 추상화했다. 네가 어떻게 변화하는지 보자.형, 그런데--프로그래머.

세션 3

밤에 돌아가서 편히 자고 다음날 그 사람이 또 왔어요. 맞아요. 그 남자예요.나는 그에게 내가 쓴 인터페이스가 안 되는지 물었다.그 사람이 돌아왔어, 아니야, 이쪽에 또 새로운 수요가 생겼어.갑자기 온몸이 멍청해졌다.그리고 필요, 됐어, 누가 나보고 프로그래머래.이후 그는 나에게 새로운 수요는 큰 사과와 작은 사과를 구분하는 것이고 큰 사과는 무게가 500g보다 크다고 말했다.두말 없이 고개를 돌려 코드를 훑어보았다.코드는 다음과 같습니다.

public static List filterApplesByWeight(List inventory, int weight) {
        List result = new ArrayList<>();
        for (Apple apple : inventory) {
            if (apple.getWeight() > weight) {
                result.add(apple);
            }
        }
        return result;
    }

똑똑한 나는 수요가 바뀔 거라고 생각했는데 이번에는 직접 이 인터페이스를 추상화하여 마음속으로 은근히 기뻐했다.세상에 나 같은 프로그래머가 있다는 것을 생각하면 세상에 희망이 있다는 뜻이다.

단편 4

다음날 그가 또 왔다. 나는 또 일을 해야 한다는 것을 안다.새로운 수요는 빨간색에 무게가 500g 이상인 사과를 거르는 것이다.코드는 다음과 같습니다.

 public static List filterApples(List inventory, String color, int weight) {
        List result = new ArrayList<>();
        for (Apple apple : inventory) {
            if (color.equals(apple.getColor()) && apple.getWeight() > weight) {
                result.add(apple);
            }
        }
        return result;
    }

얼마 지나지 않아 내가 설계를 다 했지만 이전의 즐거움이 없어졌다. 내일 또 무슨 새로운 수요가 있을지 아기의 마음이 매우 괴롭다.

단편 5

이후에 나를 놀라게 한 것은 새로운 수요가 제기되지 않았다는 것이다. 나는 은근히 기뻐하며 한 가지 문제를 생각하고 있었다.왜, 수요가 변하면, 나의 코드가 그렇게 크게 변해야 합니까?수요는 모두 애플을 선택하는 것과 관련이 있다. 어떤 애플을 선택할 때 파라미터를 통해 전달되는지 핑계를 대고 서로 다른 파라미터를 전달하는 방법이 없을까?디자인 모델에 익숙한 당신이라면 전략 모델을 생각해 낼 수 있을 것이다.인터페이스가 일치하여 필요에 따라 이 인터페이스에 대응하는 실례를 전달한다.인터페이스 프로그래밍을 위한 일종의 구현이기도 하다.먼저 애플 선택의 논리를 탑재할 인터페이스를 설계했는데 코드는 다음과 같다.

public interface ApplePredicate {
    boolean test(Apple apple);
}

이제 우리는 서로 다른 실현으로 서로 다른 논리를 전달할 수 있다. 다음과 같다.

//    
public class GreenApplePredicate implements ApplePredicate {
    @Override
    public boolean test(Apple apple) {
        return apple.getColor().equals("green");
    }
}

//   
public class BigApplePredicate implements ApplePredicate {
    @Override
    public boolean test(Apple apple) {
        return apple.getWeight() > 500;
    }
}

//    
public static List filterApples(List inventory, ApplePredicate p) {
        List result = new ArrayList<>();
        for (Apple apple : inventory) {
            if (p.test(apple)) {
                result.add(apple);
            }
        }
        return result;
    }

이를 통해 알 수 있듯이 코드 주체는 앞으로 우리가 변하지 않을 것이다. 서로 다른 행위(필터 논리)를 전달하면 된다. 그리고 여기는 하나의 매개 변수만 전달하고 다양한 행위, 다양한 행위, 하나의 매개 변수를 전달할 수 있으니 매우 nice가 아니냐.나는 또 득의양양하게 뽐내기 시작했다.자신이 또 심해진 것 같아서 저녁에 돌아가서 제멋대로 잔다.

토막 6

다음날에도 새로운 수요가 없었다. 우리는 프로그래머가 할 일이 없으면 이 귀중한 자원을 헛되이 낭비하고 다른 사람이 아까워하지 않아도 나는 아까워한다.그래서 자기는 또 어제의 그 코드를 만지작거리러 갔다.처음에는 사용하기에 편했지만 오래 걸려서 매번 새로운 논리가 이 인터페이스를 실현해야 한다는 것을 발견했다. 너무 괴로웠다. 갑자기 자바에 익명 클래스가 있다는 생각이 들었다. 그래서 그 다음에 바로 익명 클래스로 이 논리를 실현했다.코드는 다음과 같습니다.

 List greenApples = filterApples(inventory, new ApplePredicate() {
            @Override
            public boolean test(Apple apple) {
                return apple.getColor().equals("green");
            }
        });

이렇게 보면 확실히 이전보다 훨씬 간결하다. 인터페이스를 현저하게 실현하지 마라.그러나 자세히 살펴보니 이 안에 진정으로 유용한 코드는 이 줄에 있다.

return apple.getColor().equals("green");

그렇다면 Filter Apples 방법에만 이런 진정한 논리적 코드만 전달하는 방법은 없을까?다행히 자바8은 행위 매개 변수화 지원을 제공합니다.그래, 지원했으니 뭘 더 기다려, 해, 다음 코드가 해결될 거야.

List greenApples = filterApples(inventory, (Apple apple) -> apple.getColor().equals("green"));

뭐야, 내가 잘못 본 거 아니지, 이렇게 신기해?잘못 보지 않았습니다. 전달된 매개 변수를 lambda 표현식이라고 합니다. 만약 간결하지 않다고 생각한다면 유형을 제거할 수 있습니다. 이렇게:

List greenApples = filterApples(inventory, apple -> apple.getColor().equals("green"));

상기 몇 단계를 거쳐 우리는 여러 차례의 코드를 재구성하여 인터페이스가 수요의 변화에 적응할 수 있도록 했다. 한편, 우리는 불필요한 코드를 작성하고 싶지 않다. lambda 표현식을 통해 핵심 코드를 전달하고 프로그래머가 불필요한 작업을 하지 않아서 정말 다행이다.