우리가 어떤 상황에서 일을 하든 소비자 요구사항은 항상 바뀐다. 이렇게 시시각각 변하는 사용자 요구사항에 어떻게 대응해야 할까? → 우리의 엔지니어링적인 비용이 가장 최소화될 수 있으면 좋을 것이다. 그뿐만 아니라 새로 추가한 기능은 쉽게 구현할 수 있어야 하며 장기적인 관점에서 유지보수가 쉬워야 한다. 동작파라미터화를 이용하면 자주 바뀌는 요구사항에 효과적으로 대응할 수 있다.
아직은 어떻게 실행할 것인지 결정하지 않은 코드 블록을 의미한다. 이 코드 블록은 나중에 프로그램에서 호출한다. 즉, 코드 블록의 실행은 나중으로 미뤄진다는 것이다. 예를 들어 나중에 실행될메서드의 인수로 코드 블록을 전달할 수 있다. 결과적으로 코드 블록에 따라 메서드의 동작이 파라미터화된다는 것이다. 예를 들어 컬렉션을 처리할 때 다음과 같은 메서드를 구현한다고 가정하자.
동작 파라미터화로 이처럼 다양한 기능을 수행할 수 있다.
색상을 예로 들 때, (Green코드만 구현했고, 다른 색상의 코드를 구현하려고 하는 상황) Green의 코드를 반복 사용하지 않고 Red를 구현할 수 있을까? → 색을 파라미터화할 수 있도록 메서드에 파라미터를 추가하면 변화하는 요구사항에 좀더 유연하게 대응하는 코드를 만들 수 있게된다.
그런데 client가 ‘색 이외에도 가벼운 사과와 무거운 사과(150그램이상)로 구분하고 싶다’고 한다.
이처럼 다양한 무게에 대응할 수 있도록 무게 정보 파라미터도 추가했다. 위 코드도 좋은 해결 책이지만 구현된 코드를 자세히 보면 목록을 검색하고, 각 사과에 필터링을 적용하는 부분의 코드가 색 필터링 코드와 대부분 중복된다. 이는 소프트웨어 공학의 DRY(같은 것을 반복하지 말 것) 원칙을 어기는 것이다. 탐색 과정을 고쳐서 성능을 개선하려면 무슨 일이 일어날까? 한 줄이 아니라 메서드 전체 구현을 고쳐야 한다. → 즉, 엔지니어링적으로 비싼 대가를 치르게 된다. → 어떤 것(목록)을 필터링할지 가리키는 플래그를 추가할 수 있으나, 이 방법을 절대 사용하지 말아야 한다.
다음은 만류에도 불구하고, 모든 속성을 메서드 파라미터로 추가한 모습이다.
형편없는 코드다. 앞으로 요구사항이 바뀌었을 때 유연하게 대응할 수도 없다. true || false는 뭘 의미하는 걸까? 결국 여러 중복된 필터 메서드를 만들어야 한다. 이때문에, 동작 파라미터화를 이용해서 유연성을 얻는 방법이 필요한 것이다.