본문으로 건너뛰기

#ocp

7
FundamentalOOP

오브젝트; 추상화에 의존하는 상속

부모 클래스의 변경에 의해 자식 클래스가 영향을 받는 현상을 취약한 기반 클래스 문제 라고 부른다. 이제 결합도의 개념을 상속에 적용해보자. 구현을 상속한 경우(extends) 파생 클래스는 기반 클래스에 강하게 결합되며, 이 둘 사이의 밀접한 연결은 바람직하지 않다. 설계자들은 이런 현상에 대해 "취약한 기반 클래스 문제"라는 명칭을 붙였다. 겉으로 보기에는 안전한 방식으로 클래스를 수정한 것 처럼 보이더라도 이 새로운 행동이 파생 클래스에게 상속될 경우 파생 클래스의 잘못된 동작을 초래할 수 있기 때문에 기반 클래스는 "취약하다
FundamentalOOP

오브젝트; 개방-폐쇄 원칙

개방 폐쇄 원칙 Open-Closed Principle : 소프트웨어 개체 (클래스, 모듈, 함수) 는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다. 이는 다음의 관점을 반영한다. 확장 -> 동작 확장에 대해 열려 있다 : 어플리케이션의 요구사항이 변경될 때 이 변경에 맞게 새로운 동작을 추가해서 어플리케이션의 기능을 확장할 수 있다. 수정 -> 코드 수정에 대해 닫혀 있다 : 기존의 코드를 수정하지 않고도 어플리케이션의 동작을 추가하거나 변경할 수 있다. 인터페이스, 추상화는 컴파일타임 의존성을 고정기키게 한
FundamentalOOP

오브젝트; 절차 추상화와 타입 추상화

타입 : 변수에 저장할 수 있는 내용물의 종류와 변수에 적용될 수 있는 연산의 가짓수를 의미. 안타깝게도 프로시저만으로는 충분히 풍부한 추상화의 어휘집을 제공할 수 없다. 이것은 언어 설계에서 가장 중요한 추상 데이터 타입의 개념으로 우리를 인도한다. 추상 데이터 타입은 추상 객체의 클래스를 정의한 것으로 추상 객체에 사용할 수 있는 오퍼레이션을 이용해 규정된다. 이것은 오퍼레이션을 이용해 추상 데이터 타입을 정의할 수 있음을 의미한다. 추상 데이터 객체를 사용할 때 프로그래머는 오직 객체가 외부에 제공하는 행위에만 관심을 가지며
FundamentalTILDesign pattern

Command pattern

Command패턴은 이벤트가 발생했을 때 실행될 기능이 다양하면서도 변경이 필요한 경우에 이벤트를 발생시키는 클래스를 변경하지 않고도 재사용을 가능하게 할때 유용하다. 실행될 기능을 캡슐화함으로써 기능의 실행을 요구하는 Invoker 클래스와 실제 기능을 실행하는 Receiver클래스 사이의 의존성을 제거한다. 따라서 실행될 기능의 변경에도 Invoker 클래스를 수정없이 그대로 사용할 수 있도록 해준다. 램프를 켜는 버튼을 만들어보자 Button클래스의 생성자를 이용해 불을 켤 Lamp객체를 전달한다. Button클래스의 pres
FundamentalTILDesign pattern

Strategy pattern

전략패턴이라고도 불리는 스트래티지 패턴은 가튼 문제를 해결하는 여러 코드가 클래스별로 캡슐화 되어있고 이들이 필요할 때 교체할 수 있도록 함으로써 동일한 문제를 다른 코드로 해결할 수 이쎅 하는 디자인 패턴이다. 우선 다음 구조의 클래스가 있다고 보자 아래는 Guitar를 상속(extends) 받는 두 클래스다. 아래는 간단한 기타 플레이어에 대한 테스트다. 아래는 실행결과다 별로 중요한 이야기는 아니지만 스트랫이라고 모두 '디리링'이 아니고 슈퍼트스트랫이라고 '좌좌좡' 소리가 나는게 아니다 모든것은 다 이펙터와 앰프의 채널 상태가
Java EcoTILSpring Framework

스프링의 IoC/DI, AOP의 개념

본격적으로 스프링에서 사용되는 코드 패턴과 개념에 대해서 파고 들어간다. 제어의 역전 객체를 직접 생성하지 않고 외부에서 구현체를 넣어줌으로써 제어권을 거꾸로 가지고 가는 현상 IoC는 즉, 설계의 패턴이다. 실체에 의존할 것인가 추상화에 의존할 것인가 의존성 주입 외부에서 의존성을 받는 행동. 즉, 외부에서 new로 생성된 객체를 받는다. DI는 즉, 동작 그 자체다. 의존성을 어떻게 가질 것인가? 관계를 짧고 쉽게 정리하자면 → DI를 하면 IoC가 일어난다. 객체의 생성, 소멸, 작동의 주도권(즉, 제어권)이 객체 자신에게 있
FundamentalTILOOP

SOLID; 객체지향 설계의 5원칙

이 부분은 1회차 지만 신경써서 머릿속에 넣어본다. 실제로 설계하거나 구현 할 때 적절한 모델링(추상화)와 인터페이스의 분리에 신경쓸 필요가 있겠다. 그러나 SRP-ISP와 OCP-DIP 관계의 뉘앙스 차이는 아직 잘 모르겠다. SRP; 단일 책임 원칙 OCP; 개방 폐쇄 원칙 LSP; 리스코프 치환 원칙 ISP; 인터페이스 분리 원칙 DIP; 의존 역전 원칙 모델링, 즉 적절한 추상화와 상속을 통해 구현이 바뀌어도 인터페이스를 통해 사용에 영향을 주지 않는다. 상속의 원칙에 만족하는가? → LSP를 만족한다. is a kind o