2009-08-06 5 views
15

동일한 개념을 나타내는 외부 소스 (수정 불가능)에서 오는 여러 클래스가 있습니다. 예 : Address. 나는이 com.namespace2.Addressnamespace3.com.CoolAddress (필드 house_num, street, city과), (필드 h, s, c과), (필드 houseNum, street, city와) com.namespace1.Address.객체 변환 패턴

내가 사용하는 특정 웹 서비스는 namespace3.com.CoolAddress이라는 com.namespace1.Address을 생성해야하므로 특정 주소 개체 유형이 필요하다는 점이 문제입니다. 필드는 쉽게 맵핑 할 수 있지만 패턴을 찾는 방법을 찾고 있습니다.

실례로 인스턴스 객체 AddressConverter은 상태가 없으므로 의미가 없으며 클래스에만 동작이있을 때 유틸리티 클래스의 정적 메소드로 귀결됩니다. 장기간에 걸쳐 새로운 객체를 서로 매핑해야 할 때마다 메소드를 추가/수정/제거 할 수있는 곳이 한 곳 있습니다. 어떻게 완료 될지는 모르지만 코드가 어디에 배치되는지 (한 번에) 알고 필요할 때 매핑을 변경할 수 있습니다.

생각하십니까?

답변

8

당신이 찾고있는 것은 팩토리 클래스입니다. 팩토리 패턴은 여러 관련 클래스 중 하나를 인스턴스화 할 수 있어야하고 개발자가 아니라 공장에서 결정해야 할 때 사용됩니다.

당신은 ClassOne.toClassTwo(), ClassOne.toClassThree을()하고 대신 한 곳에서 모든 비즈니스 로직을 유지하려고 할 맞아 http://en.wikipedia.org/wiki/Factory_method_pattern

, ... 참조

가장 유연한에게 방법을 생각해 볼 수 있습니다 (그러나 지금까지는 가장 쉬운 방법은 아닙니다). 기본적인 클래스만으로 공장을 시작하고, Hashtable이나 다른 컨테이너에 핸들러를 추가하는 방법이 있습니다. 그렇게하면 모든 가능한 조합의 기능을 구체적으로 구현할 필요가 없습니다.

물론 각 가능한 주소 변형에 대해 구체적인 구현을하는 것이 더 빠를 것이지만 상당량의 중복 코드가있을 것이고 새로운 주소 클래스 유형을 추가하는 것이 조금 더 어려울 것입니다.

+1

핸들러 테이블 제안에 +1 - 나는 그 패턴을 꽤 사용합니다. 그러나'Hashtable'보다는'Map'을 사용하십시오. :) –

+1

공장은 창조적 인 패턴입니다. 문제는 새로운 객체를 생성하는 대신 기존 객체를 관리하는 것입니다. – SomeWittyUsername

+0

@icepack 나는 OP가 하나의 객체를 다른 객체에 매핑 할 때 새로운 인스턴스를 생성하려고한다고 생각합니다. 나는 "외부 소스 (수정 불가능한)로부터 오는 여러 다른 객체"라는 문장으로 객체의 클래스가 변경 불가능하다는 것을 의미한다고 생각합니다. 나는 다음 문장에 기초를 둔다 : "나는 ** ** namespace3.com.CoolAddress가 주어진 com.namespace1.Address를 생성해야한다.". 나는 그 문장을 편집 할 것이다. –

1

클래스 자체를 수정할 수 없기 때문에 각 방향에 대해 Adapter 패턴 구현을 제안합니다. 앞에서 말했듯이 어댑터 메서드 자체는 정적 일 수 있지만 논리가 모두 한 위치에 있도록 단일 클래스 내에 두 방향을 그룹화 할 수 있습니다.

하루가 끝나면 전화를 걸거나 코드를 넣는 위치에 상관없이 동일한 작업을 수행하게 될 것입니다. 두 방향 모두 동일한 파일에 존재하는 것이 좋습니다. 양쪽 방향이 바뀌면 업데이트가 필요하기 때문입니다.

0

항상 동일한 클래스로 변환하는 경우 간단하게 유지하고 해당 클래스에 모든 전환 코드를 넣고 공장 등을 걱정하지 않아도됩니다. 특히 다른 클래스를 두 개만 다루는 경우 특히 그렇습니다. 왜 항상 이런 것들에 대해 복잡한 패턴이 있어야합니까?!

public class A { 

    ... 

    public static A convertB(B b) { 

    ... 

    } 
} 
+0

질문에 원본 개체는 수정할 수 없다고합니다. –

+0

@BrianYarger 그는 클래스 정의가 변경 가능하다는 것을 의미한다고 생각합니다. 나는 다음 문장에 기초를 둔다 : "나는 namespace3.com.CoolAddress가 주어지면 ** ** com.namespace1.Address를 생성해야한다." –

+0

클래스에 변환 논리를 삽입하면 코드가 밀접하게 결합됩니다. 디자인 패턴 중 하나는 서로 독립적으로 존재할 수있는 클래스의 결합을 피하는 것입니다. 나는이 답변에서 충고에 반대 할 것을 권합니다. – Chaos

0

출력 할 클래스가 final입니까? 그렇지 않다면 하위 클래스를 사용하여 적절한 Adapters을 만들 수 있습니다. 그렇지 않으면 dj_segfault가 제공하는 Handler 테이블을 가진 Factory에 대해 제안 할 것입니다.

또는 잠깐 - 대화 할 필요가있는 웹 서비스입니까? 그렇다면 데이터 유형의 구현이 입력 데이터 유형을 래핑하는 어댑터 또는 자신의 중간 객체 일 수는 없습니다.

관련 문제