2011-07-03 2 views
0

아마존이나 IMDB와 같은 다양한 소스에서 정보를 가져 와서 내가 가지고있는 영화/음악/책에 대한 정보를 유지할 수있는 응용 프로그램을 만들어서 객체 지향 디자인/데이터베이스 디자인으로 놀고 있습니다. ... 영화, 책, 앨범 등과 같은 제품 객체는 1 개 이상의 출처에서 나온 속성으로 구성되며 여러 유형의 객체간에 일부 중복됩니다 (예 : 모든 제품의 제목은 ASIN으로 지정). 또한 다양한 소스에는 동일한 정보 (예 : 릴리스 날짜) 및 일부 다른 정보 (예 : IMDB에는 Amazon에서이 정보를 가져 오지 않지만 내가 사용하고자하는 캐스트 구성원에 대한 정보가 더 많이 들어 있습니다)가있을 수 있습니다. 나는이 중첩 속성을 가져올 소스를 선택할 수 있기를 원합니다. 간단한 예를 들어 링크 된 이미지를 참조하십시오OOD Media Lookup Application

그것은 내가 영화 클래스의 파서 클래스에 정의 된 모든 속성을 재정의하는 것 같다

http://imageshack.us/photo/my-images/194/drawing1r.png/

이 약간 중복, 심지어있는 moreso 내가 다른 사람을 계속 만들 경우 책, 앨범 (ASIN, IMDBId 등등을 재정의)과 같은 수업. 그것은 내가이 잘못에 접근하고있는 것 같습니다.

확장 및 유지 보수가 더 쉬운 더 나은 디자인을위한 제안 사항은 무엇입니까?

답변

0

영화, 도서 및 앨범 사이의 공통 속성을 포함하는 'Product'이라는 수퍼 클래스를 만들 수 있습니다. 그런 다음 이러한 각 특정 객체 유형은 공통 상위 클래스에서 상속됩니다.

Amazon 및 IMDB 파서 은 제품 객체을 생성하지 않아야합니까? 왜 그들은 제품의 특성을 보유하고 있습니까? 각 제품을 개별적으로 구문 분석하는 경우 각 제품이 자체적으로 구문 분석하고 각 특정 제품 클래스 (또는 상위)에 코드를 포함한다고 말할 수 있습니다. 각 객체는 실제로 특정 기능을 갖거나 특정 객체를 나타냅니다. 파서가 객체를 나타내거나 함수 (파싱)를 수행합니까? 은 객체를으로 만듭니다.

각 소스 유형 또는 인터페이스 (IProductSource)에 대해 공통적 인 상위 클래스를 만든 다음 특정 개체가 인터페이스 뒤의 실제 데이터 소스를 알거나 신경 쓰지 않고 해당 인터페이스의 메서드를 호출 할 수도 있습니다.

+0

IMDB/Amazon 구문 분석은 Product가 단일 소스의 정보로만 구성되지 않았기 때문에 Product 객체를 만들지 않습니다. 구문 분석 클래스에 특성을 유지하는 이유는 "제품"클래스의 특정 특성에 사용할 데이터 원본을 선택할 수 있기 때문입니다. IProductSource 인터페이스를 만드는 것은 어렵다. 각 소스가 다른 속성을 가질 수 있기 때문이다. – user623879