오늘은 코딩테스트 입문 단계 중 그나마 난이도가 있어보이는 문제를 골라서 풀어보았다. 문제 문제 설명만 읽어봐서는 배열을 회전시킨다는 의미를 이해하지 못했는데 direction과 입출력 예시를 보고 의미를 파악했다. direction이 left이면 배열을 그대로 한 칸 왼쪽으로 밀면 되고, right이면 오른쪽으로 밀면 되는 것이었다. 풀이 가장 먼저 리턴될 배열의 크기를 정해주었다. 다른 문제를 풀 때도 배열의 크기를 정하는 게 은근 귀찮은 부분이었는데 위의 입출력 예를 보니 direction이 right이면 리턴될 배열의 첫 칸이 주어진 배열의 마지막 원소였다. 반대로 direction이 left일 때, 리턴될 배열의 마지막 칸이 주어진 배열의 첫 원소였다. 그래서 각 상황마다 처음 혹은 마지막 원소..
오늘은 또 새로 나온 것같은 문제를 하나 풀어보았다. 근데 계속 코딩테스트 입문 단계의 문제가 추가되면 이거 언제 다 풀고 넘어가지?ㅋㅋ 문제 문제는 간단하다. 소문자를 대문자로, 대문자를 소문자로 바꾼 String를 리턴해주면 된다. 전에 문제를 풀면서 썼던 메소드가 기억났다. 전에 toUpperCase(), toLowerCase()를 사용하려 했는데 Deprecated됐던 기억이 있다. 다시 찾아보니 그냥 uppercase(), lowercase() 메소드를 사용하면 됐다. 그런데 무작정 두 메소드를 쓰면 안되니 조건문을 통해 대소문자를 구분해주었다. 있을법한 이름으로 코틀린 공식 사이트에 검색하니.. 역시 나의 기대를 저버리지 않았다 ㅋㅋ isUpperCase()는 Char가 대문자이면 true를 ..
이번 문제는 시작 값에 계속 2를 곱하면 되는 문제였다. 문제 풀이 주어진 n을 answer에 대입해두고 그 값을 t까지 2씩 곱했다. 실행 결과
이번에는 간단한 수학 문제(?)를 하나 풀어보았다. (물론 내가 계산 안 함) 문제 주어진 수의 제곱근이 자연수이면 1, 아니면 2를 리턴하는 문제였다. 나는 제곱근이 자연수인지 판단하는 방식으로 제곱근을 Double형으로 받아와 1로 나눈 나머지가 0일 때를 사용했다. 풀이 다른 문제들과 다르게 import 문이 들어있는데 이를 명시해주지 않으면 프로그래머스에서 sqrt가 어떤 메소드인지 모른다. 그리고, sqrt의 인자는 double형 또는 float형을 주어야 했기에 가장 자주 쓰는 double형으로 변환해 주었다. 실행 결과를 보고 '역시 컴퓨터는 연산을 하기 위한 장치였지?' 라는 생각을 다시금 하게 되었다.
이번에도 간단한 문제 풀이이다. 나는 최근 코틀린에서 제공되는 편리한 함수의 소스 코드를 보면 언제나 적응이 되질 않고 무슨 의미인지 해석할 수가 없다. 문제 배열의 원소를 내림차순으로 정렬하고 0번과 1번 인덱스 값을 곱해 리턴해야 겠다! 는 생각을 했다. 그리고 그런 기능을 하는 메소드를 찾아보았다. 역시, 제공되는 메소드가 있었다. 그런데 예~~전에 쓴 글에서 나는 분명 MutableList에게 sort와 reverse 메소드를 사용해 내림차순 정렬을 했었다. 왜 그랬을까 뭐 암튼 이유는 모르겠지만 이번엔 sortDescending이라는 메소드를 사용했다. 그런데 여기서 궁금한 점이 생겼다. sortDescending이라는 메소드가 있으면 sort와 reverse 메소드를 두 번 부를 필요가 없는데..
이번 문제는 제목 그대로 배열을 자르는 문제이다. 요즘 코틀린에 너무 익숙해져서 자바로는 어떻게 풀어볼지 고민이다. 문제 풀이들 풀이 1) 문제에서 기본적으로 answer 변수를 IntArray형으로 주었기 때문에 이에 맞춰 생각하다 보니 배열의 사이즈를 정해 빈 배열을 만들고 반복문을 통해 하나씩 값을 넣어주기로 했다. - 이 경우, for문을 통해 주어진 numbers의 값을 answer 배열에 하나씩 넣어준다. 실행 결과는 이렇다. 보면 기가 막히게 실행 속도가 빠르다. 풀이 2) 찾아보니 Array의 메소드 중 copyOfRange()라는 메소드를 사용하면 원본 배열을 변경하지 않고 지정한 범위의 배열을 리턴해준다고 한다. answer 변수의 타입도 선언하지 않고 작성해보았다. 실행 결과는 이렇다..
오늘은 정말 오랜만에 프로그래머스에 들렀다. 새로운 문제가 나와서 풀어보았다. 문제 한 문장으로 문제를 표현하면 좌표가 어느 사분면에 있는지 숫자로 리턴하는 문제이다. 조건문을 어떻게 하면 짧게 쓸 수 있을까 고민해보았다. 사분면마다 x와 y값의 양수 음수 여부를 판단해 리턴하는 것은 코드가 매우 길어질 것 같았다. 그래서 일단 x와 y값을 곱한 값이 양수인지 판단해 크게 1, 3분면과 2, 4분면으로 나눴다. 그 다음, x좌표의 부호(양수인지 음수인지)에 따라 사분면을 구분했다. 풀이
캡슐화는 객체의 필드에 직접 접근을 막는 방법이다. 우리가 객체를 캡슐화할 때 private인 내부 필드를 수정할 수 있도록 public 메소드들을 제공해야 한다. 캡슐화를 사용하면 다른 클래스가 이 내부 필드를 어떻게 조작할지 제어할 수 있다. 현재, 우리가 수정한 코드에서 viewModel.score.value를 사용하듯 모든 외부 클래스에서 score와 word 변수를 수정할 수 있다. 우리가 지금 만드는 이 앱에서는 문제가 없을 수 있지만, 출시용 앱에서는 ViewModel 객체의 데이터를 조작해야한다. 오직 ViewModel이 앱의 데이터를 수정해야한다. 하지만, UI controller가 데이터를 읽을 필요가 있고, 그래서 데이터 필드는 완벽한 private이 될 수 없다. 앱의 데이터를 캡슐..
저번 단계에서는 score와 word의 데이터를 LiveData 객체로 바꿔줬다. 이번 단계에서는 Observer 객체를 작업한 LiveData 객체에 붙일 것이다. 우리는 fragment의 뷰(viewLifecycleOwner)를 LifecycleOwner로써 사용할 것이다. 왜 viewLifecycleOwner를 사용할까? 프래그먼트의 뷰는 프래그먼트 자체가 부서지지 않더라도 사용자가 다른 곳으로 이동하면 부서진다. 이것은 필연적으로 프래그먼트의 lifecycle과 프래그먼트 뷰의 lifecycle 두 lifecycle을 만든다. 프래그먼트의 뷰 대신 프래그먼트의 lifecycle을 참조하면 뷰를 업데이트할 때 사소한 버그가 생길 수 있다. 그래서, 프래그먼트의 뷰에 영향을 미치는 observer를 ..
첫 번째로 ViewModel에 LiveData를 적용해 볼 것이다. LiveData는 생명 주기를 인지하는 관찰 가능한 데이터 홀더 클래스이다. 예를 들어, 우리는 이 앱에서 현재 점수를 LiveData로 감쌀 수 있다. 이번 코드랩에서는 LiveData의 여러 특성을 배울 것이다. - LiveData는 관찰 가능하다. 이 뜻은 LiveData 객체가 가지고 있는 데이터가 변경될 때 observer에게 감지된다는 의미이다. - LiveData는 데이터를 가지고 있다. LiveData는 wrapper이고 모든 데이터와 같이 사용될 수 있다. - LiveData는 생명 주기를 인식한다. LiveData에 observer를 붙일 때, observer는 LifecycleOwner와 연계되어 있다. (Lifecy..
