Java (42) 썸네일형 리스트형 동작 파라미터화 코드 전달하기 동작 파라미터화 코드 전달하기 요구사항은 항상 바뀌게 된다. 비용을 최소화 하면서 변화의 대응하는게 좋다. 동작 파라미터화를 이용하면 자주 바뀌는 요구사항에 효과적으로 대응 할 수 있다. 동작 파라미터화란 아직 어떻게 실행할지 결정되지 않은 코드 블록을 의미한다. 즉, 코드 블록의 실행이 나중으로 미뤄진다. 동작 파라미터 책에서의 예제는 Predicate 를 이용해서 설명 하고 있다. Predicate 는 true, false 를 반환하는 함수 전략패턴을 쓰고 있는데 ApplePredicate 인터페이스를 구현한 여러 클래스를 두고 클래스에서는 필터링할 조건들을 return 시키고 있다. filterApples 라는 메소드에서 전략에 맞게 클래스를 구현해서 쓰는 방식이다. 즉 filterApples 의 .. 자바 8,9,10,11 1.1 역사의 흐름은 무엇인가? 자바 8에서는 대대적인 변화가 있었다. 멀티코어 CPU 대중화 같은 하드웨어 변화가 자바 8에 영향을 미쳤다. 자바 8이 등장하기 전에는 코어를 활요하려면 스레드를 사용하는것이 좋았지만, 스레드는 관리하기 어렵고 많은 문제가 생길 수 있다. 자바는 이런 병렬 실행 환결을 쉽게 관리하고 에러가 덜 발생하는 뱡향으로 변경되려 노력했다. 자바1.0 에서는 스레드 와 락, 메모리 모델까지 지원했었는데 이런 저수준 기능들을 활용하긴 어려웠다. 자바 5에서는 스레드 풀, 병렬 실행 컬렉션 등 강력한 도구들이 나왔고 자바 7에서는 병렬에 도움을 줄 수 있는 포크, 조인 등이 나왔지만 여전히 활용하기 어려웠다. 자바 8에서 단순한 방식으로 병렬실행을 할 수 있는 방법을 제공했다. 자바 .. 디자인 패턴 - 데코레이터 패턴 데코레이터 패턴은 객체의 결합으로 기능을 동적으로 추가 시킬 수 있는 패턴이다 여러 기능을 필요에 따라 장착 시킬 수 있다. 코드로 살펴보자 음료와 음료위에 토핑을 올릴 수 있게 2개의 추상 클래스를 생성했다. 음료 클래스를 상속받는 클래스들을 생성 후 음료 토핑 클래스를 상속받는 토핑 클래스들을 생성시켜준다. 중첩시켜 원하는 로직을 장착 할 수 있다. 디자인 패턴 - 팩토리 패턴 객체 생성을 처리하는 클래스 팩토리 패턴을 사용하면 객체 생성 로직이 변경 되었을때 팩토리 객체 한곳에서만 수정하면 된다. 코드로 간단하게 봐보자 여기 커피 머신이 있고 Grinder 를 선택 할 수 있다고 생각해보자 CoffeeGrinder 추상클래스 만들고 상속시켜 여러 종류에 Grinder 를 생성 시켜둔다. 팩토리 클래스를 만들면 type 에 따라 Grinder 를 생성해 대신 만들어 줄 수 있다. 팩토리 메소드 패턴을 사용하지 않으면 여러 곳에서 생성자로 객체를 만들경우 로직의 변경이 발생했을때 모든 곳을 다 변경 해줘야 하는 반면 팩토리 메소드를 사용하면 로직이 변경되도 오직 팩토리 메소드만 변경하면 된다. 디자인 패턴 - 옵저버 패턴 옵저버 패턴은 객체의 상태가 바뀌면 객체를 구독하고 있는 다른 객체들한테 연락이 자동으로 갱신되는 패턴을 말한다. 일대 다 객체 의존 관계를 구성하는 패턴이다. 옵저버 패턴은 결합도를 낮추는게 중요하다. 결합도를 낮춰서 - 옵저버를 언제든지 추가 할 수 있게 만들고 - 새로운 옵저버를 추가할때도 주제(subject)를 변경 할 필요가 없고 - 주제와 옵저버가 서로 독립적으로 재사용될 수 있다. 코드로 살펴보자 옵저버 패턴이 없이 구독을 하면 알람을 보내는 시스템이 있다고 해보자 단순하게 구독을 하면 이메일과 sms 를 보내는 시스템이 있다고 치자. 만약에 여기에 추가로 카카오톡 을 보낸다고 한다면? 생성자가 바뀌게 되고 sendNotification 메소드도 변경이 발생한다. 벌써부터 OCP 법칙에 위반.. 디자인 패턴 - Strategy 패턴 행위를 캡슐화 해 자유롭게 변경 할 수 있게 만든 패턴 전략 을 쉽게 바꿀 수 있게 만들어 준다. 코드로 이해를 해보자 여기 추상 클래스 Bird가 있다. 새는 기본적으로 말하기 기능과 이동 기능이 있다고 하자 그리고 Bird 를 상속받는 Pigeon 과 Chicken 클래스가 있다고 하자. 이 코드에 문제점이 어떤게 있을까? 첫번째로 새로운 객체가 생겼을때 move 메소드 로직이 Chicken 로직과 동일하다고 한다면 중복된 코드가 발생 한다는 문제가 생기고 두번째로 기획이 변경돼서 Chicken 클래스의 move 기능이 변경된다면 기존 move 메소드의 로직을 변경해야 하는데 이건 확장엔 열고 수정엔 닫는 OCP 설계 규칙에 위반되게 된다. 그럼 이제 이 코드를 전략 패턴을 사용해 변경해보자 먼저 전.. 객체지향 설계 - 개방 폐쇄 원칙 엔티티는 확장을 위해 열려 있어야 하지만 수정을 위해 닫혀 있어야 한다. 기존 코드를 변경하지 않고도 새 기능을 추가 할 수있도록 코드를 작성 하라는 메시지다. 클래스 중 하나를 변경하면 모든 종속 클래스가 변경되야 하는 상황을 방지 할 수 있다. 인터페이스를 사용해 사용하는 코드를 변경하지 않고 쉽게 대체 할 수 있게 구현을 허용한다. 수정을 하지 않고도 계속적인 코드 확장이 가능해진다. 예제를 보면서 확인해보자 여기 일반적인 커피머신이 있다. brewCoffee 로 커피를 추출하는 메소드를 가지고 있다. 이 커피 앱에서 자동으로 커피머신에서 커피를 추출할 수 있게 구현을 했다. 근데 만약 여기서 일반적인 커피 머신이 아니라 새로운 기능들이 추가된 새로운 커피머신을 사용해야 한다면? 이제 여기서 개방 .. 객체지향 설계 - 단일 책임 원칙 클래스는 변경해야할 이유가 하나만 있어야 한다. 책임이란 해야 하는것 객체에 책임을 할당해 작업을 시키는데 단 하나의 책임만 가지는게 좋다. 단일 책임 원칙의 이점? 소프트웨어를 구현하기 쉽게 만들고, 향후 변경될때 부작용을 방지 할 수 있다. 요구사항은 시간이 지나면서 변경을 하게 되는데 이런 요구사항이 클래스의 책임을 변경할수있다. 이렇게 책임을 변경하게 되면 클래스를 다시 책임이 하나가 되도록 변경해줘야한다. 변경하지 않으면 더 복잡하고 부작용이 많아질수 있어 더 많은 작업이 필요하게 된다. 또한, 클래스의 책임이 하나라면 이해하기도 쉬워진다. 변경 사례 하나의 책임이 여러 클래스에 분산되어있는 경우 부가 기능을 별개의 클래스로 분리해 책임을 담당하게 한다. 공통 책임을 한 곳으로 모아준다. 이 공.. 이전 1 2 3 4 ··· 6 다음