Kotlin의 Scope 함수는 객체의 컨텍스트 내에서 코드 블록을 실행할 수 있게 해주는 강력한 기능입니다. Scope 함수에는 let(), run(), also(), apply(), with() 이렇게 5개가 있는데요. 얘네들이 비슷한 것 같으면서도 미묘하게 달려서 잘 정리해두지 않으면 언제 어떤 녀석을 써야 하는지 은근히 헷갈릴 수 있습니다. 이번 포스팅에서는 Kotlin의 Scope 함수 5종의 사용법을 정리해드리도록 하겠습니다. 예제 클래스 다음과 같이 간단한 클래스를 가지고 간단한 예제 코드를 작성하면서 각 Scope 함
파이썬으로 데이터를 다루다 보면 여러 리스트를 하나로 이어 붙이거나, 조건을 만족할 때까지만 순회하거나, 모든 조합을 구해야 하는 상황이 생기곤 하는데요. 그럴 때마다 for 루프와 임시 리스트를 조합해 작성하다 보면 코드가 생각보다 길어집니다. 😅 이럴 때 파이썬 표준 라이브러리의 itertools 모듈이 큰 도움이 됩니다. 이터레이터를 효율적으로 만들고 조합하는 함수를 모아놓은 모듈인데요. 내장 함수인 map()이나 filter()와 마찬가지로 결과를 한꺼번에 메모리에 올리지 않고 필요할 때마다 하나씩 생성하기 때문에 대용량
파이썬 코드를 읽다 보면 대괄호 안에 for가 들어간 독특한 문법을 자주 만나게 됩니다. 처음 보면 낯설지만, 한 번 손에 익으면 도저히 안 쓸 수가 없는 파이썬의 꽃 🌼이라고 할 수 있는데요. 바로 컴프리헨션(comprehension)입니다. 컴프리헨션은 기존 데이터를 기반으로 새로운 리스트, 딕셔너리, 세트를 간결하게 만들어내는 파이썬만의 문법입니다. 반복문을 여러 줄에 걸쳐 쓰는 대신 한 줄로 표현할 수 있어서 코드가 훨씬 깔끔해지거든요. 이번 포스팅에서는 리스트 컴프리헨션부터 시작해서 딕셔너리, 세트 컴프리헨션, 그리고 제
reduce 함수 파이썬의 functools 내장 모듈의 reduce() 함수는 여러 개의 데이터를 대상으로 주로 누적 집계를 내기 위해서 사용합니다. 기본 문법은 다음과 같은데요. 기본적으로 초기값을 기준으로 데이터를 루프 돌면서 집계 함수를 계속해서 적용하면서 데이터를 누적하는 방식으로 작동합니다. 여기서, 집계 함수는 두개의 인자를 받아야 하는데요. 첫번째 인자는 누적자(accumulator), 두번째 인자는 현재값(current value)가 넘어오게 됩니다. 누적자는 함수 실행의 시작부터 끝까지 계속해서 재사용되는 값이고,
함수형 프로그래밍에서 데이터 필터링(filtering) 작업을 할 때 반복문 대신에 함수 호출로 처리하는 경우가 많은데요. 이번 포스팅에서는 파이썬의 filter() 함수를 사용하여 특정 조건을 충족하는 요소만 추출하는 방법에 대해서 알아보겠습니다. filter 내장 함수 파이썬의 내장 함수인 filter()는 여러 개의 데이터로 부터 일부의 데이터만 추려낼 때 사용하는데요. 따라서, 여러 개의 데이터를 담고 있는 리스트(list)나 튜플(tuple)을 대상으로 주로 사용하는 함수입니다. 사용 방법은 매우 간단한데요. 기본 문법은
함수형 프로그래밍에서 데이터 맵핑(mapping) 작업을 할 때 반복문 대신에 함수 호출로 처리하는 경우가 많은데요. 이번 포스팅에서는 파이썬의 map() 함수를 사용하여 여러 데이터를 한 번에 변환하는 방법에 대해서 알아보겠습니다. map 내장 함수 파이썬의 내장 함수인 map()는 여러 개의 데이터를 한 번에 다른 형태로 변환하기 위해서 사용하는데요. 따라서, 여러 개의 데이터를 담고 있는 리스트(list)나 튜플(tuple)을 대상으로 주로 사용하는 함수입니다. 사용 방법은 매우 간단한데요. 기본 문법은 다음과 같습니다. ma
Java9에서는 기존 Java8 때 부터 있었던 Stream 클래스의 iterate() 메서드를 오버로드(overload)한 신규 메서드가 추가되었습니다. 이번 포스팅에서는 Stream 클래스의 정적 메서드인 iterate()에 대해서 얘기해보고자 합니다. 메서드 이름이 암시하듯 iterate()는 어떤 연산을 반복적으로 수행할 때 사용되는 메서드이며, 명령형 프로그래밍(imperative programming)에서 for나 while과 같은 루프문으로 해결하던 코드를 함수형 프로그래밍(functional programming) 방
Optional을 좀 더 Java8 API 설계자의 의도에 맞게 쓰는 방법에 대해서 알아봅시다. 이전 포스팅를 통해서 Optional에 대해서 소개드렸습니다. 또한 Optional을 Optional답지 않게 사용할 경우, 어떤 부작용이 발생하는지도 살펴보았는데요. 이 번 포스팅에서는 어떻게 코드를 작성해야 Optional을 Optional답게 쓸 수 있는지 알아보도록 하겠습니다. Stream처럼 사용하기 Optional을 제대로 사용하려면, Optional을 최대 1개의 원소를 가지고 있는 특별한 Stream이라고 생각하시면 좋습니
Java8의 Optional API를 통해 어떻게 null 처리를 할 수 있는지 알아봅시다. 이전 포스팅를 통해 Java8 이 전에는 얼마나 null 처리가 고통스러웠는지 살펴보았습니다. 그리고 문제의 본질이 null 참조를 통해 "값의 부재"를 표현하는 자바 언어의 초기 설계에 기인한다라는 것도 말미에 언급하였습니다. null 관련 문제 돌아보기 이 전 포스팅의 예제 코드를 통해 살펴본 null과 관련된 문제들을 크게 2가지로 요약됩니다. 런타임에 NPE(NullPointerException)라는 예외를 발생시킬 수 있습니다. N
Java8이 나오기 이 전에는 얼마나 힘들게 null 처리를 했었는지 살펴봅시다. null 창시자가 스스로 인정한 null 탄생의 실수 우선 null이라는 개념은 언제 누구에 의해 만들어졌을까요? null 참조는 1965년에 Tony Hoare라는 영국의 컴퓨터 과학자에 의해서 처음으로 고안되었습니다. 당시 그는 "존재하지 않는 값"을 표현할 수 있는 가장 편리한 방법이 null 참조라고 생각했다고 합니다. 하지만 나중에 그는 그 당시 자신의 생각이 "10억불 짜리 큰 실수"였고, null 참조를 만든 것을 후회한다고 토로하였습니다
본 포스팅는 Dead Code Rising의 Java 8: No more loops를 번역하였습니다. 이전 포스팅통해 자바의 판도를 바꿀 자바8의 새로운 함수형 기능들에 대해서 살펴보았습니다. 자바 개발자들에게는 새로운 세상이 열렸으며, 이제 우리가 그 새로운 세상에 적응해야 할 때 입니다. 이번 포스팅에서는 전통적인 반복문에 대한 몇가지 대안들에 대해서 알아보겠습니다. 자바8의 새로운 함수형 기능의 훌륭한 점은 어떻게 실행하는지 대신에 무엇이 실행되야 할지를 명시할 수 있다는 것입니다. 이런 측면에서 반복문이 탈락되게 됩니다. 물
본 포스팅는 오라클 웹사이트에 Ted Neward가 기고한 Java 8: Lambdas, Part 1를 번역하였습니다. 메소드 참조 (Method Reference) 지금까지 다룬 모든 람다는 사용 시점에 람다를 정의하는 익명 리터럴이였습니다. 이는 1회성 행위를 위해서는 훌륭하지만, 이 행위가 여러 곳에서 사용되어야 하는 상황에서는 별로입니다. 예를 들어 다음 Person 클래스를 생각해봅시다. (지금은 부적절한 캡슐화에 대해서는 무시하시죠.) Person 객체를 SortedSet에 저정하거나 어떤 형태로든 리스트 내에서 정렬될
본 포스팅는 오라클 웹사이트에 Ted Neward가 기고한 Java 8: Lambdas, Part 1를 번역하였습니다. 자바8은 그런한 코드 블록을 쉽게 작성하게 하기위해 설계된 몇몇 새로운 언어 기능들을 도입합니다. 그 중에서 가장 중요한 기능은 구어체로 클로저또는 익명 함수라고 일켣는 람다식입니다. (클로저라고 불리는 이유는 잠시 후 논의할 것입니다.) 이것들에 하나 씩 다뤄봅시다. 람다식 람다식은 기본적으로 나중에 실행하는 메서드의 구현을 간결하게 기술하는 방법에 불과합니다. 예를 들어 그러므로 일람 2와 같이 Runnable
본 포스팅는 오라클 웹사이트에 Ted Neward가 기고한 Java 8: Lambdas, Part 1를 번역하였습니다. 자바8의 람다 표현식 알아보기 자신이 선택한 프로그래밍 언어나 플랫폼의 새로운 출시 소식보다 소프트웨어 개발자를 흥분시키는 일이 있을까? 자바 개발자들도 예외는 아니다. 사실, 오히려 자바 개발지들 더욱 새로운 출시에 대해 간절했을지도 모릅니다. 왜냐하면 자바를 만들었던 Sun이 그랬던 것 처럼 자바도 쇠퇴의 길을 걷지 않을까 생각했던 게 그리 오래 전 일이 아니기 때문이죠. 죽을 고비를 겪고 나면 다시 주어진 삶