보뇨 다이어리

단순히 if 구문으로도 처리할수있지만 코틀린 철학에 맞게 설계한것들이 몇몇개가 있는데require, check 같은것들이 대표적이라고 생각한다. require 는 에러를 IllegalArgumentException 으로 던지지만check 는 IllegalStateException 으로 던지기때문에 새로 wrapping 해서 쓰는것도 나쁘지않을꺼같다.1234567891011121314151617181920212223242526272829303132class Chapter09 {     @Test    fun basic() {        require(isTeenager()) {            "성인이용불가 컨텐츠입니다."        }         check(isBettingMoneyLess()..

항상 머리속으로 외우고 넘어갔던 부분인데 정리좀 할겸...아래와 같이 할경우 Kotlin 프로젝트만 사용할때는 MAX_SIZE_1, MAX_SIZE_2 의 차이점이 느껴지지않는다.단순한 차이인데 MAX_SIZE_1 을 Java 에서 사용할때는 Chapter08.Companion.MAX_SIZE_1 로 접근하게 되고,MAX_SIZE_2 을 Java 에서 사용할때는 Chapter08.MAX_SIZE_1 로 접근하게 된다.그외에 다른 부분이라면 Java 로 변환할때 Companion 바깥쪽에도 getter 가 생긴다는 점이다. 1234567891011121314151617181920class Chapter08 {     companion object {        val MAX_SIZE_1 = 3     ..

책에서는 해석기라고 되어있어서 뭐지 싶었는데 interpreter 패턴을 말하는것이였다.근데 kotlin dsl 관련내용이라 사뭇 다르지만 해당 챕터를 통해서그동안 예를들어 SelelectClause.() -> Unit 이런 형태의 비밀?! 에 대해 알게되었다.즉, SelelectClause 라는 객체가 인자로 들어오는 (SelelectClause) -> Unit 이런형태와 동일하다고한다.apply 를 왜 쓰면 좋은지 간접적으로도 나와있어서 한번 코드를 직접 작성하고 디버깅해보는것도 좋은거같다. 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849class Chapter04Interpreter { ..

내가 가장 좋아하는 책임연쇄패턴인데 이전 글과 동일하게 작가가 typealias 로 만들었길래 재미있어서 기록해봅니다.우선 아래 코드는 interface 로 선언했을때 기준입니다. 123456789101112131415161718192021222324252627282930313233class Chapter04Chain {     @Test    fun sod() {        val chain = BasicValidationHandler(AnswerHandler())         chain.handle(Request("amugae2@naver.com", "question1 -> hello?"))    }     data class Request(val email: String, val question..

책에서 typealias 를 통해 interface 나 class 선언없이 하는 방법을 많이 소개해주는거같은데 지금도 그렇지만 이게 객체지향적인가? 반발감이 있긴하다..(이런식으로 쓰는건 상상도못했기때문에 어색..)근데 어떻게보면 쉬운방법으로 사고전환이 가능해서 해당 언어가 지원해주는 방법을 많이 활용하는게 좋을꺼같다Java 컨벤션대로 짜면 결국 Java 코드이니까 특정 언어를 만든 개발자의 의도를 따라가다보면 이점을 깨닫게 될지도...? 아래 기능에서는 undo 기능이 추가되어야하는데커맨드패턴같은경우 저라면 그냥 interface 구현식으로 할꺼같아서 추가로 기능개발은 하지않았다. 12345678910111213141516171819202122232425262728293031323334353637383..

개인적으로 자바에서 상태패턴 작성할때 고민이 되던 부분이였는데 코틀린 언어적으로 처리가 가능한게 신기해서 기록해봄.무엇보다 switch case 문은 저도 별루지만 그 기능을 만든건 다 이유가 있다고 생각하니... 우선 sealed 키워드없이 abstract 를 쓰거나 아무것도 안적게 되면 Dead 클래스에 따른 requireMoodMessage 처리가 아직 반영되지않았기때문에 에러가 발생한다.12345678910111213141516171819202122class Chapter03Test {     @Test    fun sealedTest() {        println(requireMoodMessage(Still()))        println(requireMoodMessage(Aggressiv..

비교적 짧은 내용들이라서 2개의 패턴을 합쳐서 설명하도록하겠습니다.근데 책을 읽으면서 사실 완전히 공감하는건 아닌데...일단 한번 소스를 보시져! 퍼사드 패턴확장함수를 써서 처리하라고하는데 이게 좀 이해가 안되는게그렇게되면 중구난방으로 분산되기도 하고 특정 유틸성 클래스를 두는게 좋다고 생각합니다.무엇보다 퍼사드는 개인적으로 여러개의 ~Service 클래스를 묶어서 하나의 클래스에서 동작시키게끔하는건데 확장함수를 쓰게되면 성격이 좀 달라진다고 생각하기때문에 참고용으로 기록..!1234567891011121314151617181920class Chapter03Test {     @Test    fun facadeTest() {        val memberService = MemberService()  ..

브릿지 패턴은 이전에도 소개했었지만 간략하게 말하자면 인터페이스 구현을 통해 모든 기능을 만들게되면 인터페이스 한개를 수정할때 구현받은 모든 클래스를 수정해야한다는 문제가 생기지만 각각 기능을 각각의 인터페이스로 쪼개서별도의 구현 클래스로 분리하게된다면 영향도는 비교적 최소화할수있다. 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475typealias PointsOfDamage = Longtypealias Meters = Int // java 일경우 별도의 클래스를 만들어야했는데 별칭지정하여 간단하게 구현..