아녀 뚱인데요?? 아녀 뚱인데요??

Item 33 : Consider factory functions instead of constructors일반적으로 Kotlin에서 클라이언트에게 클래스 인스턴스를 제공하는 방법은 'primary constructor'를 제공하는 것이다.class MyLinkedList(val head: T, val tail: MyLinkedList?)val list = MyLinkedList(1, MyLinkedList(2, null)) 이 외에도 객체를 인스턴스화시키는 다양한 'creational 패턴'이 존재하며, 이런 패턴 대부분은 객체 생성을 함수가 대신하는 아이디어를 중심으로 돌아간다.fun myLinkedListOf(vararg element: T): MyLinkedList? { if (elemen..

추상화는 프로그래밍 세계에서 매우 중요한 개념이며, OOP에서 추상화가 캡슐화와 상속과 함께 3대 핵심 개념 중 하나로 여겨진다. 함수형 프로그래밍에서는 프로그래밍 작업 전체를 추상화와 구성으로 보는 관점이 일반적이다. 추상화는 일반화 과정이나 결과로써, 특성을 제거하거나 아이디어를 객체로부터 멀어지게 하는 것이다. 즉, 추상화는 복잡성을 숨기는 단순화의 한 형태로, 프로그래밍에서 기본적인 예로 인터페이스를 들 수 있다. 인터페이스는 클래스의 일부 특성만을 나타내기에 클래스의 추상화로 볼 수 있다. 구체적으로는 메서드와 프로퍼티의 집합을 의미한다.Item 26 : Each function should be written in terms of a single level of abstraction잘 분리된 ..

Item 19 : Do not repeat knowledge프로그래밍에서 'knowledge'를 표현하면 다음과 같다.의도적으로 생성된 모든 '정보 조각'을 의미하며, 코드 또는 데이터로 표현된다.코드 또는 데이터가 없는 경우에는, 기본 동작을 사용하고 싶다는 의미로 나타낼 수 있다.e.g : 상속을 받고 메서드를 'override' 하지 않을 때, 해당 메서드가 상위 클래스와 동일하게 동작하기를 원하는것으로 나타낼 수 있다.소프트웨어에서 'knowledge'는 '알고리즘', 'UI 디자인' 등이 될 수 있으며, 다음과 같은 방식으로 표현될 수 있다.코드 : 가장 직접적인 표현 방식, 함수•클래스•변수 등을 통해 구체적인 동작과 로직을 표현구성 : 앱의 동작 환경을 정의하는 방식, 런타임에 프로그램의 행..

Item 11 : Design for readability'디버깅 작업으로 코드를 추적하고 읽는 시간' vs '새로운 API 로직과 구현 방법을 이해하기 위해 코드를 읽는 시간'개발자들은 위 두 가지를 비교해 보면, 프로그래밍은 코드 작성 시간보다 코드를 읽는 시간이 더 길다는 것을 알 수 있다.  따라서 코드 작성 시, 'Readability'를 고려하여 코드를 명확하게 작성하는 것이 중요하다.Reducing cognitive load'Readability'는 개발자마다 다르게 해석될 수 있다. 아래 예시를 보자.// impl Aif (person != null && person.isAdult) { view.showPerson(person)} else { view.showError()}//..

function selection 함수 객체 참조 방식 반환 값 확장 함수인지? let it 람다 블록 결과 Yes run this 람다 블록 결과 Yes run - 람다 블록 결과 No - 컨텍스트 객체 없이 사용한 경우 with this 람다 블록 결과 No - 컨텍스트 객체를 인자로 사용 apply this 객체 자신 Yes also it 객체 자신 Yes 일반적인 사용 가이드라인 let : null이 아닌 객체나 스코프 내에서 로컬 변수를 지정하여 사용할 때 사용합니다. apply : 객체를 설정할 때 사용합니다. run : 객체를 구성하고 그 결과를 계산할 때 사용됩니다. 비확장 run : 표현식 대신 여러 문장을 실행할 때 사용합니다. also : 객체를 그대로 반환하면서 추가적인 작업을 할 ..

Item 1 : Limit mutabilityKotlin은 '불변 객체'와 '가변 객체'를 구분하여 상태를 관리할 수 있다. 이 중 '가변 객체'를 통해 상태를 관리하는 것은 양날의 검과 같다. '가변 객체'는 시간이 지남에 따라 변하는 '상태를 표현하는 것이 간편'하여 유용하다는 장점이 있지만, 다음과 같은 이유로 상태 관리가 어려워진다는 단점이 있다.상태의 변화를 추적해야 하므로 코드를 이해하고 디버그 하는 것이 어려움.상태가 언제든지 변경될 수 있기에 로직의 추론이 어려움.멀티 스레드 환경에서 동기화 메커니즘이 없는 경우, 상태의 변동성은 잠재적인 충돌을 발생함.변경 가능한 모든 상태를 테스트해야 하기에 테스트가 어려움.상태가 변경되면 상태를 사용하고 있던 요소들에게 변경 사항을 반드시 알려야 함...