OOP & Design Pattern

소프트웨어의 세 가지 기능 실행 중에 제대로 동작한다. 간단한 작업만으로도 변경이 용이해야한다. 코드는 쉽게 읽고 이해할 수 있어야 한다. 개발 비용은 점점 증가한다. 릴리즈가 늘어날 때마다 한 줄을 만드는데 드는 비용이 증가한다. 소프트웨어의 가치 : 변화 대응 변하지 않는 것은 오직 변한다는 사실이다. 변화 대응하는 비용을 낮추고, 빠르게 대응하는 ...

협력 어떤 객체가 다른 객체에게 무엇인가를 요청하는 것 한 객체는 어떤 것이 필요할 때 다른 객체에게 전적으로 위임하거나 서로 협력한다. 즉, 두 객체가 상호작용을 통해 더 큰 책임을 수행하는 것이다. 협력이 설계를 위한 문맥을 결정한다. 상태는 객체가 행동하는 데 필요한 정보에 의해 결정되고, 행동은 협력 안에서 객체가 처리할 메시지로 결정된다. 따라서 ...

좋은 설계 좋은 설계란 오늘 요구하는 기능을 온전히 수행하면서, 내일의 변경을 매끄럽게 수용할 수 있는 설계를 가리킨다. 객체 지향 프로그래밍은 객체 사이 의존성을 효율적으로 통제할 수 있는 다양한 방법을 제공하면서 좋은 설계를 도와주는 좋은 도구이다. 객체 사이

캡슐화(ENCAPSULATION) 캡슐화는 내부 구현에 대해 유연함을 제공해 주는 기법이다. 객체가 내부적으로 기능을 어떻게 구현했는지 감추는 것 변경 가능성이 높은 부분은 내부에 숨기고 외부에는 상대적으로 안정적인 부분만 공개함으로써 변경의 여파를 통제한다. 변

협력과 메시지 객체가 독립적으로 수행할 수 있는 것보다 더 큰 책임을 수행하기 위해서는 다른 객체와 협력해야 한다. 두 객체의 협력을 가능하게 해주는 매개체가 바로 메시지이다. 메시지와 메서드를 분리하는 것이 커다란 차이를 만든다. 메시지 : 호출하는 시점 메서드 : 실행되는 시점 (동적으로 바인딩 되기 때문에 다형성이 적용되면서 큰 효과가 있다...

의존성 어떤 객체가 예정된 작업을 정상적으로 수행하기 위해 다른 객체를 필요로 하는 경우 두 객체 사이에 의존성이 존재한다고 말한다. 의존성을 다른 말로하면 의존되는 요소가 변경될 때 의존하는 요소도 함께 변경될 수 있다는 것을 의미한다. 따라서 의존성은 변경에 의한

상속 DRY(Don't Repeat Yourself) 원칙 상속을 사용하면 중복되는 내용을 상당수 제거할 수 있다. 상속을 이용해 코드를 재사용하기 위해서는 부모 클래스의 구현 방법에 대한 정확한 지식을 가져야 한다. 이는 부모 객체의 캡슐화를 약화시키는 문제를 가져온다. 결과적으로 상속은 부모 클래스와 자식 클래스 간의 결합도를 높이고 이 높은 결합도는 ...

객체 지향에서의 다형성 객체 지향 프로그래밍에서 사용되는 다형성은 유니버셜(universal) 다형성과 임시(Ad Hoc)다형성으로 분류할 수 있다. 유니버셜 다형성 : 매개변수(Parametric) 다형성 + 포함(Inclusion) 다형성 임시 다형성 : 오버로딩(Overloading) 다형성 + 강제(Coercion) 다형성 일반적으로 가...

1. 단일 책임 원칙(SRP) Single Responsiblity Principle 클래스는 단 한 개의 책임을 가져야 한다. 클래스가 여러 책임을 갖게 된다면 그 클래스는 각 책임마다 변경되는 이유가 발생하기 때문에 클래스가 한 개의 이유로만 변경되려면 클래스는 한 개의 책임만을 가져야 한다. 다른 말로 클래스를 변경하는 이유는 단 한 개여야 한다.고도...

SOLID 연습 예제 변경과 확장이 용이한 SOLID 원칙의 효과를 보려면 극단의 사례를 비교하는게 좋을 것 같다. 절차지향으로 구현한 프로그램을 SOLID 원칙을 적용하면서 객체지향 코드로 만들어보자. 이러한 과정을 통해 객체 지향의 장점을 확실히 느낄 수 있을 것이다. 프로그램 설명 아메리카노, 라떼를 판매하는 간단한 커피 머신이 있다. 커피는 아이스...

우리는 프로그래밍을 하면서 수많은 메서드들을 작성한다. 그렇다면 우리가 작성하는 프로그래밍에서의 메서드란 무엇일까? 객체 지향 프로그래밍에서 메서드는 객체간의 협력하는 구조를 설계하고 구현하기 위해서 반드시 필요한 객체의 행동에 해당한다. 하지만 구현해야하는 요구사항이

전략 패턴은 정책에 따라 유연하게 동작하는 메서드(알고리즘)를 캡슐화하여 다형성을 구현하는 디자인 패턴이다.만약 패턴을 사용하지 않으면, 모든 정책에 대한 로직이 if-else 문으로 분기 되어야 하고 이는 결과적으로 코드 분석과 유지보수를 어렵게 만든다. 정책을 사용

템플릿 메서드 패턴 템플릿 메서드 패턴은 실행 과정이 동일한 절차를 가진 코드를 작성할 때 일부 과정의 구현만 다형성으로 다르게 대입하는 디자인 패턴이다. 실행 과정을 구현한 상위 클래스와 실행 과정의 일부 단계를 구현한 하위 클래스로 구성된다. 상위 클래스는 실행 과

상태 패턴 동일한 동작을 수행될 때마다 상황(객체 상태)에 따라서 다른 동작을 하도록 하는 디자인 패턴 변하는 부분을 캡슐화해야 한다. 변하는 것은 상태(State)이므로 상태를 인터페이스로 분리시키고 각 상태에 따른 구현 클래스를 만든다. 전략 패턴과 다른 점은 객체

싱글톤 패턴 애플리케이션 구동 중 클래스의 인스턴스를 단 한 개만 생성하고 사용하는 디자인 패턴 객체에 메모리를 최초 한번만 할당한다. 싱글톤 인스턴스는 전역 변수 처럼 사용할 수 있다. 모든 생성자는 private이어야 한다. 싱글톤 패턴 장단점 장점 객체를 여러번 생성할 필요가 없고, 기존에 생성된 것을 가져다 쓰기 때문에 메모리와 성능 측면에서 효...

프록시 패턴 프록시 패턴이란 실제 기능을 수행하는 객체 대신 가상의 객체를 사용해 로직의 흐름을 제어하는 디자인 패턴이다. 프록시란 대역이라는 뜻 비용이 많이드는 연산이나 객체 생성등을 프록시 객체로 임시로 만들어놓고 실제 필요한 시점에 수행하도록 할 수 있다. 이미지 로딩, JPA 지연로딩, Spring AOP 등 필요한 순간에 실제 객체를 생성해 주...

어댑터 패턴 어댑터 패턴은 클라이언트와 서버의 인터페이스가 서로 맞지 않을 경우 이를 연결하기 위해 어댑터 클래스를 구현하는 디자인 패턴이다. 클라이언트가 사용하고 있는 기존의 인터페이스와 서버가 제공하는 인터페이스를 변경하지 않고 둘을 연결할 수 있다는 장점이 있다. 예시 Tolr 검색 서버가 제공하는 인터페이스와 클라이언트가 요구하는 인터페이스가 일치...