전체 글

HTTPS는 대칭키를 사용할까 비대칭키(공개키)를 사용할까? 정답은 둘 다 사용한다 이다. 대칭키는 알다시피 클라이언트와 서버가 같은 키를 공유하면서 암호화된 메시지를 주고받는 방식이다. 그런데 애초에 이 키를 클라이언트에게 어떻게 전송하느냐! 그것이 중요한 문제이자 한계점이었다. HTTPS는 이 문제점을 비대칭키(공개키)를 사용해서 기가 막히게 해결한다. 그리고 그 과정을 TLS(Transport Layer Security) 또는 SSL(Secure Socket Layer)라고 부르는데 오늘은 TLS 핸드 셰이크에 대해서 자세히 알아볼 것이다. 참고로 TLS와 SSL은 서버와 클라이언트의 핸드셰이크 과정을 나타내는 같은 의미의 용어이다. 현재 시점에서 SSL은 TLS로 대체되었으며 (IEFT에 의해) ..

외판원 순회 문제 (Traveling Salesman Problem)는 조합 최적화 문제의 일종으로, NP-난해 집합에 속하기 때문에 계산 이론에서 해를 구하기 어려운 문제의 대표적인 사례로 많이 다룬다. 문제 외판원 순회 문제는 영어로 Traveling Salesman problem (TSP) 라고 불리는 문제로 computer science 분야에서 가장 중요하게 취급되는 문제 중 하나이다. 여러 가지 변종 문제가 있으나, 여기서는 가장 일반적인 형태의 문제를 살펴보자. 1번부터 N번까지 번호가 매겨져 있는 도시들이 있고, 도시들 사이에는 길이 있다. (길이 없을 수도 있다) 이제 한 외판원이 어느 한 도시에서 출발해 N개의 도시를 모두 거쳐 다시 원래의 도시로 돌아오는 순회 여행 경로를 계획하려고 ..

이전 포스팅에서 우리는 관심 영역을 분리함으로써 기존 코드를 개선했다. 그 과정에서 만들었던 AppConfig를 어떻게 하면 스프링으로 전환할 수 있는지 오늘 글에서 다룰 것이다. https://braindisk.tistory.com/26 객체 지향 설계 원칙을 잘 지키는 법 이전 포스팅에서 좋은 객체 지향 설계란 무엇인가 생각해보았다. https://braindisk.tistory.com/25 좋은 객체 지향 설계란 좋은 객체 지향 설계의 목표는 프로그램이 유연하고 변경이 용이하게 설계하는 braindisk.tistory.com 우리가 만들었던 AppConfig 클래스를 스프링의 설정 파일로 만들 것이다. 스프링의 설정 파일로 만들기 위해서는 클래스 위에 @Configuration 어노테이션을 붙여주고..

제어의 역전 IoC (Inversion of Control) 이전 포스팅에서 작성한 AppConfig는 사용 영역과 구성 영역을 잘 분리해주었다. https://braindisk.tistory.com/26 객체 지향 설계 원칙을 잘 지키는 법 이전 포스팅에서 좋은 객체 지향 설계란 무엇인가 생각해보았다. https://braindisk.tistory.com/25 좋은 객체 지향 설계란 좋은 객체 지향 설계의 목표는 프로그램이 유연하고 변경이 용이하게 설계하는 braindisk.tistory.com 사용 영역에 있는 객체들은 자신의 로직을 실행하는 역할만 담당하고 구성 영역에 있는 AppConfig는 어떤 객체들이 실행될지 직접 제어하는 역할을 담당했다. 기존의 프로그램처럼 객체가 스스로 제어 흐름에 관여..

이전 포스팅에서 좋은 객체 지향 설계란 무엇인가 생각해보았다. https://braindisk.tistory.com/25 좋은 객체 지향 설계란 좋은 객체 지향 설계의 목표는 프로그램이 유연하고 변경이 용이하게 설계하는 것이라고 생각한다. 유연하고 변경에 용이하다는 것은 무슨 소리일까? 우리 실생활을 예로 들어본다면 면허, 자 braindisk.tistory.com 역할과 구현을 잘 분리하면 다형성이 어느 정도 보장됨을 느낄 수 있었지만 분명 부족한 부분이 있었다. 오늘은 그 부족함에 대해서 코드와 함께 살펴볼 것이다. 먼저 전체적인 도메인 설계를 진행하자. 전체 도메인 설계는 개발자가 아니어도 보고 이해할 수 있도록 구성되어 있다. 클래스 다이어그램은 개발자가 보기 편하게 구성되어 있다. 객체 다이어그..

좋은 객체 지향 설계의 목표는 프로그램이 유연하고 변경이 용이하게 설계하는 것이라고 생각한다. 유연하고 변경에 용이하다는 것은 무슨 소리일까? 우리 실생활을 예로 들어본다면 면허, 자동차, 그리고 특정 자동차를 예로 들 수 있다. 우리가 차를 몰기 위해서 면허를 땄다고 하자. 그럼 면허 종류에 맞는 모든 자동차를 운전할 수 있다. 자동차가 바뀐다고 해서 면허를 다시 따야 하는가? 그렇지 않다.. 내 자동차가 특정 자동차로 바뀌어도 문제가 없어야 한다. 즉 면허는 자동차라는 추상화에 의존하고 특정 자동차에 의존하지 않는다는 소리이다. 객체 지향 설계의 목표도 이와 유사하다. 클라이언트 코드는 추상화된 코드에 의존해야 하고 구현체에는 의존하지 않아야 한다는 중요한 원칙을 가지고 있다. 그리고 이 원칙을 다형..

유명한 패턴들은 프로그래머들이 당연하게 사용하는 코딩 스타일들이 관습화 된 것일 뿐, 특별하거나 엄청난 개념이 아니다. 어댑터 패턴 또한 그렇다. 다음 그림처럼 콘센트에 코드를 꽂는 경우, 별다른 어댑터가 필요하지 않다. 하지만 외국에 나가게 되면 이런 어댑터가 필요한 경우가 있다. 어댑터 패턴이란.. 바로 이 어댑터를 만드는 행위를 말한다. 프로그래머가 코딩을 하다가 어댑터가 필요한 경우가 뭐가 있을까? 자바 프로그래밍을 예로 들자면, 기존 코드와 다른 인터페이스를 구현하는 클래스를 사용해야 하는 경우 인터페이스가 다르기 때문에 어댑터가 필요하다. (인터페이스가 다른데 막 가져와서 쓸 수는 없지 않은가) 말도 안되는 예를 한 번 들어보겠다. 위에 그림을 보면 K2는 gun 인터페이스를 구현하고 있고 K..

많은 클래스가 하나 이상의 자원에 의존한다. 가령 맞춤법 검사기는 사전(dictionary)에 의존하는데, 이런 클래스를 정적 유틸리티 클래스로 구현한 모습을 드물지 않게 볼 수 있다. // 정적 유틸리티를 잘못 사용한 예 - 유연하지 않고 테스트하기 어렵다 public class SpellChecker { private static final Lexicon dictionary = ...; // 인스턴스화 방지 private SpellChecker() {} public static boolean isValid(String word) {...} public static List suggestions(String typo) {...} } // 비슷하게 싱글턴을 잘못 사용한 예 public class Spel..

인스턴스화를 막으려거든 private 생성자를 사용하라. 이따금 단순히 정적 메서드와 정적 필드만을 담은 클래스가 필요할 때가 있다. 예를 들어 java.lang.Math와 java.util.Arrays 처럼 기본 타입 값이나 배열 관련 메서드들을 모아놓거나 java.util.Collections 처럼 특정 인터페이스를 구현하는 객체를 생성해주는 정적 메서드(혹은 팩터리)를 모아놓을 수도 있다. 또한 final 클래스를 상속해서 하위 클래스에 메서드를 넣는 건 불가능하기 때문이다. 정적 멤버만 담은 유틸리티 클래스는 인스턴스로 만들어 쓰려고 설계한게 아니기 때문에 기본 생성자가 자동으로 생성되지 않도록 해야 한다. 해당 클래스를 추상 클래스로 만드는 것으로는 인스턴스화를 만들 수 없다. 하위 클래스를 만..