보뇨 다이어리

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

책에서는 해석기라고 되어있어서 뭐지 싶었는데 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()  ..

구조패턴은 쓸내용이 많아서 각각 필요한것대로 정리 개인적인 생각이지만 일부 프록시 패턴과 동일한 구조로 가져가는데 대신에 by 연산자를 통해서 그게 눈에 띄기때문에 나쁘지않아보임.require 메소드 또한 가독성이 의외로 좋아서 (처음에는 어색하지만...ㅠ) 코틀린 철학과 잘맞는 코드형태인거같음. 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263    @Test    fun decoratorTest() {        val defaultStarTrekRepository = DefaultStarTrekRepository()        val v..

싱글턴 패턴- object class 를 선언해서 사용해라 12345678910111213    object StringConstant {        const val HOSTNAME = "user"                fun addPrefix(text: String): String {            return "$text, $HOSTNAME"        }    }        @Test    fun singletonTest() {        println(StringConstant.HOSTNAME) // user        println(StringConstant.addPrefix("hello")) // hello, user    }Colored by Color Scripterc..