DeFacto-Standard IT

피터 코드의 상속 규칙 상속의 오용을 막기 위해 상속의 사용을 제한하는 5가지 규칙. 어느 하나라도 만족하지 않는다면 상속을 사용해서는 안된다. - 자식 클래스와 부모 클래스 사이는 '역할 수행(is role played by)'관계가 아니어야 한다. - 한 클래스의 인스턴스는 다른 서브 클래스의 객체로 변환할 필요가 절대 없어야 한다. - 자식 클래스가 부모 클래스의 책임을 무시하거나 재정의하지 않고 확장만 수행해야 한다. - 자식 클래스가 단지 일부 기능을 재사용할 목적으로 유틸리티 역할을 수행하는 클래스를 상속하지 않아야 한다. - 자식 클래스가 '역할', '트랜잭션', '디바이스' 등을 특수화해야 한다. 상속으로 표현한 역할 수행 관계 위 그림을 바탕으로 피터 코드의 5가지 규칙을 살펴본다. 1번..

일반화 관계 일반화는 또 다른 캡슐화 객체지향 개념에서 가장 많이 오해하고 오용되는 것이 일반화 관계다. 일반화 관계는 객체지향 프로그래밍 광점에서는 상속 관계라 한다. 따라서 속성이나 기능의 재사용만 강조해서 사용하는 경우가 많다. 이는 일반화 관계를 극히 한정되게 바라보는 시각이다. 일반화를 하면 각각의 종류에 신경쓰지않고 전체를 다룰 수 있는 수단을 얻을 수 있다. 장바구니에 있는 과일 가격의 총합을 구하는 함수는 다음과 같이 작성할 수 있으며, 이미 추상화 개념에서 본 적이 있다.가격 총합 = 0 while(장바구니에 과일이 있다) { switch(과일 종류) case 사과: 가격 총합 = 가격 총합 + 사과 가격 case 배: 가격 총합 = 가격 총합 + 배 가격 case 바나나: 가격 총합 =..

추상화 사람의 속성이나 행동을 생각해보면, 사람이라고 판단할 수 있는 속성이나 사람이 할 수 있는 행동은 너무 많으므로 사람의 모든 속성과 행동을 기술할 수는 없을 것이다. 또한 사람이라고 판단되는 속성이나 행동은 필요에 따라 선별해서 사용할 수 있다. 추상화란 어떤 영역에서 필요로 하는 속성이나 행동을 추출하는 작업을 의미한다. 추상화 덕에 관심이 쏠리는 부분에 더욱 집중할 수 있다. 구체적인 사물들의 공통적인 특징을 파악해서 이를 하나의 개념으로 다루는 수단이 추상화다. 추상화가 없다면 각각의 개체를 구분해야 할 것이다. 자동차 종류마다 엔진 오일을 교환하는 방식이 다르다고 한다면 다음과 같은 코드가 작성될 수 있다.switch(자동차 종류) case 아우디: //아우디 엔진 오일을 교환하는 과정을 ..

인터페이스와 실체화 관계 인터페이스란 책임(기능, 메서드) 이다. 어떤 객체의 책임이란 객체가 해야 하는 일로서 해석할 수 있고 어떤 경우에는 객체가 할 수 있는 일로도 해석할 수 있다. 즉, 객체가 외부에 제공하는 서비스나 기능은 객체가 수행하는 책임으로 보는 것이다. 인터페이스를 어떤 공통되는 능력이 있는 것들을 대표하는 관점으로 볼 수 있다. 비행기와 새는 공통적으로 날 수 있는 능력이 있다. 이런 공통 능력이라는 관점에서 다음과 같이 비행기와 새를 그룹화할 수 있는 메커니즘이 인터페이스다. 인터페이스 자체는 실제로 책임을 수행하는 객체가 아니며 TV 리모컨이나 형광등 스위치가 이와 같은 책임들을 실제로 수행하는 객체다. 따라서 책임과 이를 실제로 실현한 클래스의 관계는 분리해서 보여줄 필요가 있다..

의존 관계 일반적으로 한 클래스가 다른 클래스를 사용하는 경우는 다음과 같다. - 클래스의 속성에서 참조할 때 - 연산의 인자로 사용될 때 - 메서드 내부의 지역 객체로 참조될 때 (결합도가 높다. 사용 빈도가 낮을때만 사용함) 한 클래스의 객체를 다른 클래스 객체의 속성에서 참조하는 경우에는 참조하는 객체가 변경되지 않는 한 두 클래스의 객체들이 오랜 기간 동안 협력 관계를 통해 기능을 수행한다. 예를 들면 자동차(Car 클래스)를 소유한 사람(Person 클래스)이 자동차를 이용해 출근한다고 할 경우 한 번 출근한 후 다음날 출근할 때도 어제 사용한 자동차를 타고 출근할 것이다. 매번 출근할 때마다 다른 자동차를 사용하는 경우는 거의 없을 것이다. 이런 경우 사람과 자동차의 관계는 연관 관계며 Per..

집합 관계 UML 연관 관계의 특별 경우로 전체와 부분의 관계를 명확하게 명시하고자 할 때 사용. 집약과 합성 두 종류의 집합 관계가 존재. has a 관계 집약 관계는 한 객체가 다른 객체를 포함하는 것을 나타낸다. '전체', '부분'과의 관계며 '전체'를 가리키는 클래스 방향에 빈 마름모로 표시한다. 특히 부분을 나타내는 객체를 다른 객체와 공유할 수 있는 경우에 집약 관계로 나타낸다. 이때 전체 객체의 라이프타임과 부분 객체의 라이프타임은 독립적이다. 즉, 전체 객체가 메모리에서 사라진다 해도 부분 객체는 사라지지 않는다. 합성 관계는 전체를 가리키는 클래스 방향에 채워진 마름모로 표시되며 부분 객체가 전체 객체에 속하는 관계다. 따라서 전체 객체가 사라지면 부분 객체도 사라진다. 공유할 수 있는 ..

일반화 관계 한 클래스가 다른 클래스를 포함하는 상위 개념일 때 두 클래스 사이에는 일반화 관계가 존재한다. 일반화 관계가 존재할 때 자식(또는 서브)이라 불리는 클래스는 부모(또는 슈퍼)라 불리는 클래스로부터 속성과 연산을 물려받을 수 있다. "is a kind of 관계' - '세탁기' is a kind of '가전 제품' - 'TV' is a kind of '가전 제품' - '식기세척기' is a kind of '가전 제품' 가전 제품을 부모 클래스라 하며 세탁기, TV, 식기세척기를 자식 클래스라 한다. UML에서 일반화 관계는 다음과 같이 두 클래스를 연결하는 화살표의 끝에 빈삼각형 표시를 해 표현한다. 삼각형 표시가 있는 쪽은 부모 클래스, 반대쪽은 자식 클래스. 가전 제품은 세탁기, TV, ..

연관 관계 연관된 클래스 사이에 실선을 그어 표시. '교수(Professor 클래스)가 학생(Student 클래스)을 상담한다'라는 사실은 다음과 같이 나타낸다. 두 클래스 사이의 연관 관계가 명확한 경우에는 연관 관계 이름('상담한다')을 사용하지 않아도 된다. 한 클래스가 다른 클래스와 연관 관계를 가지면 각 클래스의 객체는 해당 연관 관계에서 어떤 역할을 수행한다. 이러한 역할은 클래스 바로 옆 연관 관계를 나타내는 선 가까이에 적을 수 있다. Professor 객체들은 조언자(advisor 속성)의 역할을, Strudent 객체들은 피조언자(student 속성)의 역할을 '상담한다' 라는 연관 관계에서 담당한다. 역할 이름은 실제 프로그램을 구현할 때 연관된 클래스의 객체들이 서로를 참조할 수 있..

분류 Diagram 유형 목적 구조 다이어그램 (Structure Diagram) - 정적 클래스 다이어그램 (Class Diagram) 시스템을 구성하는 클래스들 사이의 관계를 표현 객체 다이어그램 (Object Diagram) 객체 정보를 보여줌 복합체 구조 다이어그램 (Composite Structure Diagram) 복합구조의 클래스와 컴포넌트 내부 구조를 표현 배치 다이어그램 (Deployment Diagram) SW, HW, 네트워크를 포함한 실행 시스템의 물리 구조를 표현 컴포넌트 다이어그램 (Component Diagram) 컴포넌트 구조 사이의 관계를 표현 패키지 다이어그램 (Package Diagram) Class나 UseCase 등을 포함한 여러 모델 요소들을 그룹화하여 패키지를 구..