이것은 알려진 패턴입니까?

내 수업에서 데이터를 완전히 분리하려고하고 간단한 해결책을 생각해 냈습니다.이것은 알려진 패턴입니까?

class ClassAData 
{ 
    public int Property1; 
    public string Property2; 
    public bool Property3; 
} 

class ClassA : SomeInterface 
{ 
    public ClassAData Data; 

    //behaviour 
    public int CalculateSomething(int value) 
    { 
     ... 
     return result; 
    } 
    public string SomeOtherMethod(){...}   
}

(적절한 캡슐화가 적용됩니다 ...)

이것이 궁금한가요? 무언가에 의해 알려 지거나 공통된 패턴으로 사용됩니까? 또한 어떤 것이 있다면 단점은 무엇입니까?

편집 : 어쩌면 내가 이것을 사용하려고하는 곳을 분명히해야했습니다. 나는 모든 상황에서 모든 반원들에게 이것을 사용하도록 옹호하지 않는다. ClassA는 실제 도메인 개체이고 ClassAData는 서비스 레이어와 프레젠테이션 레이어간에 전송되는 DTO가되는 서비스 지향 응용 프로그램에서이 정보를 사용할 계획입니다. 이 접근법은 속성이 많은 클래스가 많은 경우 특히 코드 중복을 방지합니다.

출처

2009-12-03 Zoman

농담 : 절차 프로그래밍을 재발견하려고합니까? :) – Geo

...기능적 프로그래밍이 당신을 기다리고 있습니다 ;-) – jldupont

ClassAData 회원은 비공개로해서 직접 액세스하지 않아야합니까? –

당신이하고있는 일은 데이터와 동작을 구분하는 것입니다. 그것은 전략 패턴과 유사하지만, 그 차이는 반대입니다. 나는 나쁜 생각이라고 말하지 않을 것이다. (데이터가 다른 저장 기술이지만 동일한 동작을하는 경우 유용 할 수있다.) 일부 지적했듯이, 또한 MVC의 강한 의미가 있습니다. 대신, 그것은 빈혈 방지 반 패턴이라고 말할 수 없습니다. 당신은 행동을 가지고, 당신은 단지 같은 클래스 인스턴스에 데이터를 저장하지 않습니다.

내가 그것을 비난하지 않을 요약하면, 당신은 다음 바이너리 Compability가 유지 또는 공유 데이터를 구현하는 데 유용 할 것이다하는 ClassAData*에 ClassA에 구성원을 변경한다면 그것은 전략과 MVC

출처

2009-12-03 17:01:29

http://stackoverflow.com/questions/9511137/is-the-solution-design-optimal-c-sharp-3-tier에 답변 해 주시겠습니까? – Lijo

의 알려진 안티 - 패턴 - http://martinfowler.com/bliki/AnemicDomainModel.html 및 http://en.wikipedia.org/wiki/Anemic_Domain_Model를 참조 빈혈 도메인 모델은 당신이 데이터에서 동작을 분리 할 이유를 모르겠어요

출처

2009-12-03 16:50:53 mcintyre321

아니요! 다시 보게. ClassA는 실제 도메인 객체입니다 (비헤이비어 포함). 이것은이 반 패턴과 아무 관련이 없습니다. 이러한 방식으로 데이터를 분리하려는 주된 이유는 서비스 레이어와 프리젠 테이션 레이어간에 사용되는 DTO 코드를 복제하지 않기 위해서입니다. – Zoman

발생할 수있는 문제를 확인합니다. 객체 지향 프로그래밍은 특히 데이터와 관련된 동작과 데이터를 조인합니다. 나는 개인적으로 당신이하고있는 방식대로 행동으로부터 완전히 분리 된 데이터를 보지 못했습니다.

출처

2009-12-03 16:51:46

데이터 캐리어와 알고리즘 동작을 분리하는 것이 더 나은 경우가 있습니다. 필터 기반 디자인 (예 : VTK)에서 상당히 많이 볼 수 있습니다. –

전략 패턴 (또는 템플릿 패턴 일 수도 있음). 당신이 Head First Design Patterns 책을 가지고 있다면, 그것은 첫 번째 장에서 전략 패턴을 매우 잘 설명합니다.

출처

2009-12-03 16:51:51 Upperstage

전략 패턴은 전략을 교환 할 수 있음을 의미하지 않습니까 (예 : 전략을 생성자에 전달). 여기는 고정되어있는 반면. –

예; 나는 그가 행동 (전략)을 받아들이도록 그의 코드를 바꿀 것이라는 가정을했다. 물론 Template 패턴을 사용하면 동작이 "고정"됩니다. – Upperstage

그러나 템플릿 패턴의 경우 하위 클래스가 포함되어서는 안됩니다 (하위 클래스에서 템플릿 메서드가 채워지는 방법을 지정하게해야합니까?). 나는 당신이 말하는 것은 단순한 구성이라고 말하고 싶습니다. –

"데이터"부분이 외부 소스에서 생성되는 경우 특수한 방식으로 사용됩니다.

나는 당신이 당신의 컨트롤러, 라 MVC에서 모델을 분리하려는 것처럼이 실제로 종류의 소리를이 방법

출처

2009-12-03 16:51:58 ArielBH

에 대한 부분 클래스를 사용하는 것이 좋습니다 것입니다.

출처

2009-12-03 16:53:30

개체에는 개체에 작용하는 메서드가 없습니다. 그러므로 목적 지향적 인 것으로 목적을 무너 뜨린다. 실제 객체 방향은 객체와 함께 작동하는 속성 및 메서드를 포함합니다. 그렇지 않으면 gets() 및 sets()가있는 클래스를 디자인 할 것입니다.

출처

2009-12-03 16:55:27 JonH

유사하다 객체 간 (예 : refcounts 및 copy-on-write).

코드가 귀하의 질문에 작성 되었기 때문에, 나는 그 코드의 거꾸로도 볼 수 없으며, godd 코드 포맷 및 코멘트로도 제공 될 수 없습니다.

출처

2009-12-11 22:08:26 gnud

이것은 알려진 패턴입니까?

답변

관련 문제