코딩꿈나무

1) 타입 개념관점에서 우리가 인식하는 객체들에 적용하는 개념이나, 아이디어를 가리켜 타입이라고 부른다. 어떤 대상이 타입으로 분류 될 때, 그 대상을 타입의 인스턴스라고 한다. 타입은 3가지 구성요소로 설명 할 수 있다. ● 심볼: 타입에 이름을 붙인것 ex) 침대 ● 내연: 타입에 속하는 객체들이 가지는 공통적인 속성이나 행동의 집합 ex) 물체를 지탱함.. ● 외연: 타입에 속하는 객체들의 집합 ex) 접이식 침대, 스프링 침대, 그물 침대 등등 프로그래밍 관점에서 타입은 연속적인 비트에 의미와 제약을 부여하기 위해 사용된다. ● 타입에 수행될 수 있는 유효한 오퍼레이션 집합을 정의 (연산자 종류 제한) ● 타입에 수행되는 오퍼레이션에 대해 미리 약속된 문맥 제공 (+ 나 new 와 같이 약속된 문..

1) 다형성 다형성은 많은 형태를 가질 수 있는 능력을 의미한다. 프로그래밍에선 여러 타입을 대상으로 동작할 수 있는 코드를 작성할 수 있는 방법으로 얘기할 수 있다. 다형성의 분류 유니버설 매개변수 제네릭 프로그래밍과 관련이 높은데, 인스턴스 변수 혹은 메서드의 매개변수 타입을 임의의 타입으로 선언 후 사용시점에 구체적인 타입으로 지정하는 방식 포함 메시지가 동일하더라도 수신한 객체의 타입에 따라 실제로 수행되는 행동이 달라지는 능력 (서브타입 다형성) 임시 오버로딩 하나의 클래스 안에 동일한 이름의 메서드가 존재하는 경우(시그니처만 다름) 강제 언어가 지원하는 자동적인 타입변환이나 사용자가 직접 구현한 타입 변환을 이용해 동일한 연산자를 다양한 타입에 사용할 수 있는 방식 (단, String + 정수..

1) 상속을 합성으로 변경하기 앞서 상속에서 보아온 문제점들은 다음과 같다. 1. 불필요한 인터페이스 상속 문제 2. 메서드 오버라이딩 오작용 문제 3. 부모 클래스와 자식 클래스의 동시 수정 문제 합성으로 변경하는 방법은 아주 간단하다. 부모 클래스를 자식 클래스의 인스턴수 변수로 변경하면 된다. 만약 부모 클래스의 모든 기능을 자식 클래스에서 구현해야 한다면 자바의 인터페이스를 사용해서 해결 할 수 있다. (단, 부모 클래스 인스턴스 변수를 이용해서 메서드를 호출하는 방식으로 코드를 구현해야한다.) 3번의 경우 합성을 사용하여도 해결되지는 않을 수 있지만 (비즈니스 적인 연관관계) 그래도 합성이 훨씬 좋다. 파급효과를 자식 클래스내로 캡슐화할 수 있기 때문이다. 2) 상속으로 인한 조합의 폭발적인 증..

1) 상속과 중복코드 중복코드는 우리를 주저하게 만들뿐만 아니라 동료들을 의심하게 만든다. 두 코드가 중복인지, 중복을 없애도 괜찮을지 등등 여러가지 사안이 떠오르기 때문이다. DRY 원칙 중복여부를 판단하는 기준은 변경이다. 요구사항이 변경되었을 때 두 코드를 모두 수정해야 한다면 이 코드는 중복이다. 중복코드를 결정하는 기준은 코드의 모양이 아니다. DRY원칙은 Don't Repeat Yourself 간단히 말해 동일한 지식을 중복하지 말라는 것이다. 한번, 단 한번 원칙 혹은 단일 지점 제어 원칙이라고 부른다. 예제로 보여주는 NightlyDiscountPhone, Phone의 상속관계는 새로운 로직을 추가하기 위해 부모, 자식 메서드 모두 수정이 필요했다. 자식 클래스가 부모 클래스에 너무 강하게..

1) 개방 폐쇄 원칙 개방폐쇄의 원칙의 정의는 다음과 같다. "소프트웨어 개체(클래스, 모듈, 함수,등등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다." 여기서 말하는 수정과 확장에 대한 얘기는 런타임의존성, 컴파일의존성에 대한 이야기이다. 단순히 해당클래스의 메서드명, 필드명등에 대한 이야기가 아니라. 컴파일시점에 추상화 클래스에 의존해서 런타임 의존성에 의해 확장에 대한 유연성을 높이자는 이야기이다. 변하지 않는 부분과, 변하는부분을 나누고 변하는 부분을 추상화하는 것이 개방폐쇄 원칙을 지키는 핵심이 된다. 2) 생성 사용 분리 생성하는 클래스와 사용하는 클래스를 분리하자. 객체를 직접 생성하는 것은 결합도가 높아질 수 있지만, 객체 생성을 피할 수는 없다. 객체 생성을 클라..

1) 의존성 이해하기 어떤 객체가 협력하기 위해 다른 객체를 필요로 할 때 두 객체 사이에 의존성이 존재하게 된다. 의존성은 단방향성으로 되어있다. 의존하고 있는 클래스가 변경된다면 주체도 내부 속성도 같이 변경되어야한다. UML의 의존관계와 의존성은 다르다. UML은 두 요소 사이에 존재할 수 있는 다양한 관계의 하나로 의존 관계를 정의한다. 의존성은 두 요소 사이에 변경에 의해 영향을 주고 받는 힘의 역학관계가 존재한다는 사실에 초점을 맞춘다. 의존성 전이 Movie라는 클래스를 Customer가 의존할 경우, 자연적으로 Movie가 의존하는 대상에 대해서 Customer도 의존한다는 것을 의미한다. 모든 의존성이 전이되지는 않으며, 이는 캡슐화 정도에 따라 달라진다. 런타임과 컴파일 타임 런타임은 ..

1) 프로시저 추상화와 데이터 추상화 프로시저 추상화: 알고리즘, 기능을 중심으로 시스템을 추상화 데이터 추상화: 데이터 중심으로 타입을 추상화 - 추상 데이터 타입 데이터를 중심으로 프로시저를 추상화 - 객체지향 객체지향을 바라보는 일반적인 관점은 데이터 추상화와 프로시저 추상화를 함께 포함한 클래스를 이용해 시스템을 분해하는 것 2) 프로시저 추상화와 기능 분해 기능과 데이터에서 처음은 기능의 우위였다. 기능 분해를 통해 시스템을 분해를 하였으며, 이 프로시저 단위로 분해된 것은 인터페이스를 통해 사용할 수 있었다. (프로시저는 반복적으로 실행 혹은 유사하게 실행되는 작업들을 하나의 장소에 모아놓은 추상화 방법이다.) 전통적으로 기능 분해 방법은 하향식 접근법(최상위 기능 정의 후 작은 단위의 하위 ..

1) 협력과 메시지 협력안에서 메시지를 전송하는 클라이언트, 메시지를 수신하는 객체를 서버라고 표현하는 클라이언트 - 서버 모델이있다. Switch는 클라이언트고 Hitter는 서버이다. Swtich가 Hitter에 온도를 높이라고 요청하면 Hitter는 열에너지를 주게 된다. 이 같은 경우는 우리가 Rest API 통신을 통해 많이 겪게 되는 상황인데, 프론트와 백엔드가 분리된 서버에서 자주 마주칠 수 있는 상황이다. Hitter는 또 다른 객체에게 클라이언트 입장으로 존재할 수 있다. 가령 전기에너지를 얻기 위해 다른 객체를 찾을 수 있을 것이다. 조금 더 깊이 알기 위해 용어 정리를 하자. 메시지: 객체들이 협력하기 위해 사용할 수 있는 의사소통 수단 다른 객체에게 도움 요청하는 것을 메시지 전송 ..