[언젠가를 위한 복습] 자바 1.8의 학습난이도 최상의 람다식??

2019년의 새해가 밝자 마자 떡국을 드신 분도 있겠지만 오라클은 이제부터 자바의 이용료를 드십니다(...)

--> 단, 기업 한정, 개인 사용자는 2021년부터

​

이게 뭐냐... 오라클은 애초에 데이터베이스로 먹고사는 회사인 만큼... 애초에 ojdbc가 리포지토리 사이트에서 퍼지지 못한 이유 중 하나가 바로 라이선스를 철저하게 강요하기 때문이라 카던데 돈을 내는것 또한 철저하게 잡아낸다는 카더라가 있다. 데이터베이스 상품군 중에서는 Enterprise Edition이 개인, 테스트 목적이라도 7일 이상을 사용할 경우 유료라고 적어놨는데 이걸로 과연 돈을 뜯긴 사용자가 몇명일 지는 알 수 없지만 이렇게 적어놨다는것부터가 범상치가 않다(......)

애초에 정보의 출처가 꺼라위키라서 믿거나 말거나다

​

때문에 다른 회사는 몰라도 1.9로 자바의 업그레이드가 더딘 감이 없지않아 있을까 싶어 올리는 글이기도 하지만, 그래서 1.8에서 추가된 몇가지 새로운 기능에 아직도 눈길이 간다. 그 중 하나가 람다식인데 자바와 자바스크립트는 아예 다른 언어임에도 불구하고 발전하는 과정 중에 몇몇 기능이 대놓고 컨셉이 겹치기도 한다. jQuery 중에는

--> $()객체.each(function() { 곧 치킨튀길 개발자입니다 })

형식의 함수가 있는데 이를 따라한 것이 바로

--> List<T>타입의 객체.forEach(item -> 곧 치킨튀길 개발자입니다 )

라고 보면 될 듯 하다.

새해부터 치킨튀길 생각을 하고 있으니 뒬 성 푸른 떡잎부터 튀김옷냄새가 난다

​

​

​

자바스크립트의 기능을 아예 흉내낸 함수라서 묻지말고 끝까지 순회한다는 함수로써의 역할은 같다. 다만, 순회 중 아이템의 지정은 jquery each에서는 $(this)로 바뀌지만 자바에서는 함수형으로 새로 추가된 패러미터 지정문법을 따른다. item -> 함수본문 형식으로 적혀진 것이 바로 함수형 메소드 축약형이다.

이세상 자바가 아니다!!

​

구글링하지 않고 직접 IDE에서 자습하는 방법은 forEach(new 까지만 치고 Ctrl + Space로 자동완성을 부르면 forEach 패러미터로 넣을 수 있는 유일한 인터페이스가 나온다. 당연히 함수형은 값이 아닌 행위를 넣는 패러다임이기 때문에 패러미터로 인터페이스를 넣고, 직접 그 상태에서 익명함수로 메소드를 구현해야 한다. 애초에 인터페이스를 패러미터에 직접 넣을 수도 없는것이 자바의 엄격한 방침이다. 다행히도 인터페이스 안에는 단 하나의 메소드만 있고, 그것만 구현하면 바로 사용 가능하다. 얼마나 다행인지 모른다.

얼마나 다행인지 모르면 List 인터페이스 를 직접 익명클래스로 구현해보자

​

forEach는 순회하는 동안 하나의 값을 자유자재로 소모할 수 있는 Consumer 메소드를 지정하면 된다. 원래대로라면 forEach(new Consumer<T> { public void accept(아이템) { 곧 치킨튀길 개발자입니다 } }) 형식으로 작성하면 되지만 이걸 완전히 무력으로 찌그러뜨려 간략화시킨 것이 바로 item -> 곧 치킨튀길 개발자입니다 문법이다.

다행인것은 이런거 모르는게 오히려 자바 프로그래밍에 압도적으로 유리하다는 것이다. 물론 사실이다(?!)

​

어째서 이런 말도 못할 이상한 물건이 나오게 되었는가...

​

1) FunctionalInterface 어노테이션으로 생성된 메소드는 해당 인터페이스에서 유일한 메소드이기도 하다.

--> 따라서 인터페이스를 패러미터로 넣는것만으로도 어떤 메소드를 사용할 것인지 지정이 가능하다

--> 더불어 함수형 메소드를 사용하기 위해서는 인터페이스에 단 하나의 메소드만 있어야 한다.

--> 축약형에서 메소드명을 기재하지 않는다. 따라서, 2개 이상이 들어가면 어떤 메소드를 호출하는지 알 수 없다.

​

2) 자바의 엄격한 문법 덕분에 패러미터의 타입을 추론할 수 있다.

--> 인터페이스 메소드를 만들 때 정해진 패러미터의 타입이 익명함수에서도 그대로 적용된다.

--> 패러미터의 이름만 정의한다. 이미 메소드 원형에서 정해진 타입을 그대로 사용할 것이기 때문.

--> 타입만 다르고 함수가 같다 하더라도 함수형 인터페이스의 특성상 인터페이스를 아예 새로 만들어야 한다.

​

-> 라는 표현식은 함수형 프로그래밍을 위해 어쩔 수 없이 도입한 듯 하다. 저 표식을 브릿지로 왼쪽을 패러미터, 오른쪽을 메소드 바디로 판단하는 것 같은데 맞는지는 모르겠다. 보통 메소드 바디에 1줄의 작업만 들어간다면 {} 또한 필요 없지만 아닐 경우에는 반드시 {} 으로 감싸야 한다. 리턴 타입이 있을 경우 return의 기재 또한 필요하지만 시작부터 바로 리턴값을 던질 경우 {}와 함께 return 마저도 생략한다.

회사생활 수명도 생략될 수 있다 쓸꺼면 진짜로 잘 쓰던가 아니면 쓰지 말자

​

forEach에서는 consumer만 사용했지만 기타 함수형 함수(......)에서는 다른 인터페이스가 요구되는 경우도 있다. 무작정 List객체.forEach만 사용하지 말고 함수형 프로그래밍의 깊은 패러다임을 이해하기 위해 stream() 함수도 같이 파볼 필요가 있다.

​

list객체.stream().filter(i -> 남기고자 하는 조건으로 true 반환)

--> 순회를 하는 동안 조건에 맞는 엘리먼트 아이템만 남긴다.

​

list객체.stream().map(i -> 값을 변화시킬 패턴 또는 함수)

--> 순회를 하면서 해당 아이템을 변환, 일괄수정 등. 조건? true액션:false액션 등으로 구체적으로 지정할 수 있는지는 안해봐서 모르겠다 시간 얼마 안걸리니 해볼 사람들은 해보자

​

list객체.stream().reduce((i1, i2) -> 연속된 2개의 아이템을 어떻게 1개의 아이템으로 합병할 것인지의 함수)

--> 모든 아이템을 순회하여 익명으로 구현된 메소드의 내용에 따라 합병처리된다. 단순히 모든 엘리먼트의 합을 원할 경우 i1, i2 -> i1 + i2 등으로 지정하는 것도 가능. 단, 3개의 엘리먼트 액션은 지원하지 않는 듯 하다. 주의점으로는 reduce 메소드는 1개의 아이템만을 Optional 타입으로 반환하기 때문에 결과값에 대한 액션은 Optional 객체의 메소드인 ifPresent 에서 정의해야한다.

이제 다 읽었으니 우리 모두 다함께 치킨을 튀기는 방법을 배우도록 하자

​

​

​

더 볼 글 (자바를 벗어나 의사함수로 적혀있어 여기보다 훨씬 이해하기 쉽다!!)

https://jdm.kr/blog/181