전체 글

코틀린을 처음 시작하면 프로퍼티라는 용어가 굉장히 헷갈릴 수 있다. 그래서 프로퍼티에 대한 용어 정리를 한 번 해보려고 한다. 프로퍼티 Kotlin In Action의 말을 빌리자면 코틀린 프로퍼티는 자바의 필드와 접근자 메서드(getter, setter)를 완전히 대신한다. 오해하지 말자. 이 말은 필드와 접근자 메서드를 모두 합친게 프로퍼티라는 말이 아니다. 프로퍼티는 필드의 역할도, 접근자 메서드의 역할도 할 수 있구나! 라고 받아들이면 된다. + 코틀린에선 자바의 필드를 뒷받침하는 필드(backing field) 라고 부른다. 코틀린을 처음 배울 때 가장 먼저 접하는 프로퍼티는 아래와 같은 형태일 것이다. val name: String = "빅스" 위 name 프로퍼티는 뒷받침하는 필드와 접근자 ..

코틀린에서의 인터페이스와 추상클래스의 차이에 대해 알아보자 구현적 관점에서의 차이 개념적 관점에서의 차이 구현적인 관점에서의 차이 프로퍼티 선언 다중, 단일 상속 구현적인 관점에서 (코틀린의) 인터페이스와 추상클래스의 큰 차이는 없다고 생각한다. 프로퍼티 선언 인터페이스와 추상클래스 모두 자체로는 생성이 불가능하며 구현부(함수 바디)가 있는 함수가 존재할 수 있다. 뿐만 아니라 프로퍼티 또한 둘다 선언할 수 있는데 여기서 조금의 차이가 발생한다. 코틀린 인 액션 (이하 코인액)에서는 이렇게 말한다. (말이 어렵다면 넘어가도 좋다) 인터페이스에는 추상 프로퍼티뿐 아니라 게터와 세터가 있는 프로퍼티를 선언할 수도 있다. 물론 그런 게터와 세터는 뒷받침하는 필드를 참조할 수 없다. (뒷받침하는 필드가 있다면 ..

하루 종일 오목 미션을 수정하고 MVC패턴에 대해 고민했다. 오목 미션은 정말 내 가슴을 답답하게 했다. 뭔가 하고싶은 구조는 있는데 자꾸 디테일이 안 잡혔다. 그래서 썼다 지웠다를 굉장히 반복했다. 아, 그리고 오늘은 제임스의 수업도 있었다. 뭔가 레벨2의 내용을 미션에 필요한 부분만 미리 맛보기로 보여주는 느낌이었는데, 맛만 보다보니 이해가 안되는 부분이 꽤 생겨서 궁금증 투성이였다. (SQLite 부분은 사용법만 익히는 느낌이라 괜찮았다. Log와 디버그 모드 릴리즈 모드... 요부분이 어려웠다..) 또 제이슨과의 면담도 있었다. 처음 면담을 신청할때는 '알고리즘을 해야할까요?'라는 질문을 하려고했었다. 그러나 4기 분들과 대화도 해보고 혼자 생각도 해보니 제이슨이 나에게 답해줄 수 있는 문제가 아..

우테코 2주차. 몸풀기였던 온보딩 미션이 끝나고 이제 진짜배기 미션이 시작되었다. 프리코스에서 날 가장 괴롭혔던 로또.. 다시 돌아와서 날 괴롭혔다. 새로운 미션은 화요일에 새로 진행되는데 이때 모두가 보는 앞에서 랜덤으로 페어를 정한다. 이번에 내 페어가 된 사람은.. 두구두구 바로 반달이었다~! 온보딩에서 함께했던 산군은 이미 친한사이였기 때문에 이번이 진짜 제대로된 페어프로그래밍이었다고 생각한다. 반달은 굉장히 신중한 사람이다. 내가 무언가 의견을 제시하면 반달은 한참동안 열심히 고민하고 대답해주었다. 신중한 성격의 반달 덕분에 고민할 거리도 많아지고 질문거리도 많아졌던 것 같다. 아 질문하니까 생각났다. 내 로또 미션 리뷰어님은 바로! 우테코 안드로이드 과정 코치님인 레아다!! 레아로 말하자면 잠..

다음 주에 결과로 돌아온다는 우테코 최종 코테 후기를 쓰고... 결국 결과를 적지 않았었다,, 그리고 두 달이 지난 이제서야 적게 되었다,, 정말 감사하고 운 좋게도 합격하게 되었다..!! 서류 쓰는 내내 다시쓰고 고쳐쓰고를 반복하며 깎고 깎았고 프리코스 4주 동안은 프리코스 미션 외에는 아무것도 하지 못했었다. 너무나 우테코가 하고싶었던 나머지 서류 지원과 프리코스 기간 동안 적잖은 스트레스도 받았었다. 프리코스가 끝나고 꽤나 기진맥진하여 최종 코딩테스트 전까지 딱히 공부하지 못했다. 그래서 직전에 한 두 문제밖에 풀어보지 못하고 최종 코딩테스트를 봤었다. 최종 코딩테스트 준비는 거의 못 했지만 프리코스 때 고생한 보람이 있었는지 예상보다는 수월하게 볼 수 있었다. 정말 내 모든걸 걸고 준비했던 선발과..

코틀린의 인터페이스를 알아보도록 하자 코틀린의 인터페이스는 자바의 인터페이스와는 차이가 있다. 코틀린의 인터페이스에서는 프로퍼티 선언이 가능하지만 자바는 불가능하다. 자바에는 implements를 통해 인터페이스를 구현하지만 코틀린은 콜론(:)을 사용한다. 코틀린의 인터페이스 안에는 추상 메서드뿐 아니라 구현이 있는 메서드도 정의할 수 있다. (이는 자바 8의 디폴트 메서드와 비슷하다고 한다) 그럼 지금부터 코틀린 인터페이스의 예시들을 보며 알아가보도록 하자. 자바 코드는 이해를 돕기 위해 참고용으로 매 코드마다 넣어놨다. override 키워드와 인터페이스 우선 간단하게 인터페이스를 선언해보자 interface Soccer { fun kick() } 자바 코드 // java도 큰 차이는 없다 publi..

Java와 비교해서 Kotlin 맛보기 먼저 Kotlin을 잠시 맛보고 가도록 하자 클래스(Class)라는 개념의 목적은 데이터를 캡슐화하고 캡슐화한 데이터를 다루는 코드를 한 주체 아래 가두는 것이다. // java code 1-1 public class Person { private final String name; public Person(String name) { this.name = name; } public String getName() { return name; } } java code 1-1을 코틀린으로 변환해보자 // kotlin code 1-1 class Person(val name: String) 11줄을 차지하던 Person 클래스의 코드가 단 1줄로 변환되었다. 이와 같이 코틀린은..

객체지향은 실제 세상의 모방이 아니다. 우리는 보통 객체지향을 처음 마주할 때 실제 세상의 모방이라는 말을 많이 듣는다. 즉 객체지향 소프트웨어가 실세계의 투영이며, 객체란 현실 세계에 존재하는 사물에 대한 추상화라는 뜻이다. 하지만 이 것은 틀렸다. 애플리케이션을 개발하면서 객체에 직접적으로 대응되는 실제 세상의 사물을 발견할 확률은 그다지 높지 않다. (책을 읽으면서 놀란 부분.. 생각해보니 정말 그렇다! ㅋㅋ) 방화벽이 화재의 확산이 아닌 네트워크 침입을 막는다고 문제가 될까? 실제 세상의 방화벽이 건물과 연관돼 있다고 해서, 네트워크 방화벽이 건물과 연관될 필요가 있을까? 소프트웨어 방화벽과 건물의 방화벽 사이의 의미적 거리만큼이나 소프트웨어 객체와 실제 사물 사이에 존재하는 연관성은 희미하다. ..