2010-04-07 3 views
1

그래서 ABC라는 클래스에 Point 개체 목록이 있다고 가정 해 보겠습니다.클래스간에 인수 전달 - 공용 속성을 사용하거나 속성 클래스를 인수로 전달 하시겠습니까?

그 (것)들을 가진 어떤 당기는 논리를 만들어야합니다. 해당 Point 객체 각각에는 ABC 클래스에서 호출 할 Draw() 메서드가 있습니다.

Draw() 메소드 코드에는 ABC 클래스의 정보가 필요합니다. 그 결정을 내릴 무승부()을 허용 할 공공의 일부 속성을

  1. 갖는 ABC 방송 클래스 :

    나는 단지 그들이이 정보를 가지고 있는지 확인하는 방법은 두 가지를 볼 수 있습니다.

  2. Abc 클래스는 속성으로 가득 찬 클래스를 draw()로 전달합니다.

두 경우 모두 속성이 동일 할 것이고, 제 질문은이 경우에 바람직한 것입니다. 아마 두 번째 접근법이 더 유연할까요? 아마? 나는 명확한 승자를 여기에서 보지 못한다. 그러나 그것은 확실히 다른 누구보다 나의 미경험과 관련이있다.

다른 좋은 접근 방법이 있다면 언제든지 공유하십시오. 이 두 가지 접근 방법에 대한 "공식적인"이름이있는 경우

class Abc2 { 
    //here we make take down all properties 

    public void method1(); 
    ... 
    public void methodn(); 
} 

class Abc2MethodArgs { 
    //and we put them here. this class will be passed as argument to 
    //Point's draw() method! 
    public property a; 
    public property b; 
    public property c; 
    ... 
    public property z; 
} 

또한, 내가 알고 싶습니다 : 여기

두 경우 모두 같습니다 접근 방식이 여기

class Abc1 { 
    public property a; 
    public property b; 
    public property c; 
    ... 
    public property z; 

    public void method1(); 
    ... 
    public void methodn(); 
} 

하고있다 따라서 태그/스레드 이름을 더 잘 선택할 수 있으므로 검색 목적으로 더 유용합니다. 그것들을 자유롭게 편집 할 수 있습니다.

+0

예제로 인해 포인트를 잘못 해석 할 수는 있지만 실제로 ABC를 기반으로하는 포인트 그리기 대신 ABC가 포인트를 그려야한다고 생각합니다. – Marc

+0

예, 당신의 요점을 봅니다. 나는 자신을 잘 설명하지는 않았지만, draw() 함수가 실제로 ABC보다 Point에 더 잘 위치한다고 가정하는 것이 안전합니다 (실제로 Point 클래스에서 각각 다른 점을 상속받습니다. 다른 드로잉 논리!). –

답변

2

최상의 방법은 정보의 특성에 따라 다릅니다. ABC Point 인스턴스에 이러한 클래스 간의 관계의 성격과 그 클래스에 대한 "예상 된"미래를 제공해야합니다. 다른 말로하면 질적 요소가 많이 있습니다.

포인트를 ABC 인스턴스로 전달하면 이 아니며, ABC에서 Point가 필요로하는 것이 무엇이든지간에 적절한 추상화를 만들고 인터페이스에 캡슐화하십시오. 정적 용어로 이것은 단순히 정보를 캡슐화하기위한 새로운 클래스를 생성하는 것과 유사하지만 동적으로 매우 다릅니다.

단순히 ABC 인스턴스를 전달하면 안되는 이유는 순환 종속성을 생성하기 때문입니다. 너무 자세하게 설명하지 않으면 일반적으로 매우 나쁜 것으로 간주되어야하며 절대적으로 필요한 경우를 제외하고는 피해야합니다.

더 추상적 인 수준에서 나중에이 명백한 순환 종속성에 대한 이유를 확인하고이를 해결하기 위해 논리적 인 변경을 가능하게 할 것입니다. 즉,이 '데이터 소스 'ABC가 이행해야하는 역할. 이 역할은 'Points for Container'역할과 구별되며 디자인에 반영되어야합니다.

매개 변수를 draw() 메서드에 전달할 수도 있습니다. 다시 요인의 힙에 따라 좋거나 나쁠 수 있습니다. 그 의미에 대해 생각해 본다면 분명히 아주 나쁜 것은 아닙니다.

+0

당신은 몇 가지 매우 흥미로운 점을 만들었습니다. 우선, 순환 의존성이 나쁜 이유를 자세히 설명해 주시겠습니까? 이 경우 ABC가 수행하는 모든 작업은 PointList 객체 (각 인스턴스 객체에 대해 ArrayList에 저장 됨)에 대해 foreach를 수행합니다. 논리 자체는 모두 Point 객체에 있습니다. 또한 정적 용어로는 단순히 정보를 캡슐화하기위한 새로운 클래스를 만드는 것과 유사하지만 동적으로 매우 다른 클래스라고합니다. 왜 이렇게이다? 감사! –

+0

일반 ABC가 아닌 'ABC 인터페이스'를 포인트로 전달할 때 좋은 점. – tucuxi

+0

다음은 순환 종속성에 대한 예의 토론입니다. http://stackoverflow.com/questions/1356304/are-circular-class-dependencies-bad-from-a-coding-style-point-of-view 정적 동적 구분 - Point가 요구하는 ABC의 정보에 대한 액세스를 캡슐화하는 인터페이스는 정적으로 (즉, 클래스 다이어그램을 생각하면) 앞서 언급 한 MethodArgs 클래스와 매우 유사하지만 동적 동작 (상호 작용 다이어그램을 생각하십시오)은 매우 다릅니다. 특히 정보는 ABC 인스턴스에서 MethodArgs 인스턴스로 복사되지 않습니다. –

1

접근법 # 2로 이동하지만 개체가 없습니다. 매개 변수를 Draw에 직접 전달하십시오.

+0

매개 변수를 직접 전달하는 것이 이상하게 보입니다. 나중에 더 많은 매개 변수를 추가하고 싶다면 큰 문제가 있습니다. –

+0

그렇게하면 투표 수가 줄어 듭니다. 다시는 당신을 도우려고하지 마십시오. –

+0

귀하의 글은 쓸모 없거나 잘못되었습니다. 메서드에서 속성을 직접 전달하는 것은 제대로 작동하는 OO 프로그래밍에서는 바람직하지 않습니다. 그렇기 때문에 직접 값을 전달하는 대신 양식 이벤트 프로그래밍 EventArgs에 있어야합니다. –

1
Point 클래스 이후

ABC는 인수로 실제 ABC 객체를 전달 Pointdraw() 메소드를 호출하지 왜, 무엇을 그려야할지에 스스로 중재해야 할 것으로 보인다. ABC 객체는 접근 자 메서드를 제공 할 수 있습니다 (해당 속성을 노출하지 마십시오!) 그리고 포인트 클래스 (또는 하위 클래스 구현)는 ABC에서 다시 호출 할 대상을 결정할 수 있습니다.

+0

접근 자 메서드 및 노출 속성을 제공하는 것의 차이점은 무엇입니까? 단지 클래스의 클라이언트가 데이터를 읽도록하는 대신 데이터를 읽도록하는 것입니다. 아니면 클라이언트가 실제 데이터 대신 "인터페이스"를 얻는 것과 같은 것을 의미합니까? –

+0

이 인터페이스를 사용하면 동일한 인터페이스를 유지하면서 액세스를 기록 및/또는 달리 이러한 속성에 대한 액세스를 관리하면서 클래스를 리팩토링 할 수 있습니다. –

2

ABCpoint 사이에 상태를 전달하는 별도의 클래스를 생성하고 유지하기 위해 더 많은 작업이 될 것입니다,하지만 당신은 ABC에서 point을 분리 할 경우는 일을 가치가있다.

중요한 질문은 문제가되는 경우 문제가되는 것이 얼마나 중요합니까? 도메인 인스턴스에서 abc 인스턴스에 대해 알아야 할 점이 있다면 매개 변수 클래스를 만들 가치가 없으므로 옵션 1 만 사용해야합니다.

+0

동의합니다. Point가 ABC의 속성에 대해 알고 있으면 해당 속성을 별도의 클래스에 배치하여 디커플링을 거의 수행 할 수 없습니다. – tucuxi

+0

지금 포인트는 ABCs 속성에 대해 알지 못합니다. 나는 ABC의 공공 재산이나 AbcMethodArg의 공공 재산 중 하나를 가지고있을 것입니다. 둘 다 (또는 나는 당신이 그 의미를 이해하지 못했습니다). –

1

종속성을 취소하는 것이 좋습니다. ABC의 속성에 액세스하는 Point 대신 ABC가 각 점에 "draw()"를 호출 할 때 (또는 직전에) 점에 대한 속성을 설정하게하십시오. Swing의 JTables (javadoc 참조)에서 셀을 렌더링 할 때 Flyweight pattern과 비슷한 것을 사용합니다. Point (데이터 모델)을 PointDrawer (재사용 가능한 렌더링 코드)에서 분리하는 것도 고려해 볼 수 있습니다. 그렇게하면 포인트가 모든 속성에 의존하지 않고 PointDrawers 만됩니다.

그렇습니다. 그리기 시간에 각 Point에 모든 매개 변수를 명시 적으로 전달하더라도 OO 프로그래밍입니다. 즉, Point는 ABC 또는 ABC의 "매개 변수 전달 클래스"에 전혀 의존하지 않습니다. .

+0

의존성을 뒤집는 것에 관해서는, 그것은 매우 흥미로운 아이디어 중 첫 번째 것으로 보인다 (나는 그것에 대해 생각하지 않았다!). 하지만 이제는 ABCMethodArgs 클래스를 사용하는 것과 같지 않습니다. 이점은 무엇입니까? 포인트는 이미 PointDrawers라고 부릅니다. –

+1

일반적으로 클래스를 서로 의존하게 만드는 것은 좋지 않습니다 (재사용하거나 서로 독립적으로 변경하기가 어렵 기 때문에). 인수를 Draw로 변경하려는 경우 Steven Mackenzie가 제안한 접근 방법이이 방법보다 낫습니다. 나는 여전히 Properties 객체가 정당하다고 의심한다. Steven이 제안한 인터페이스와 동등하고 더 복잡하기 때문이다. – tucuxi