저는 수업을 가장 효과적으로 만드는 방법에 대해 끊임없이 토론하고 있습니다.개체가 어떻게 생겼을 까?
이 말은 왜 우리는 항상 InotifyPropertyChanged와 IDataErrorInfo를 구현하는 클래스를 만들지 않으므로 "if"우리가 우리 양식에 직접 바인딩 할 수 있고 왜 우리는 항상 속성을 사용하여 그들을 꾸미지 않습니까? 우리는 WCF에서 클래스를 사용할 수 있기를 원합니까?
나는 명백한 여분의 코드를 제외하고 더 많은 테스트가 더 나은 유연성을 제공하지 않는다는 것을 의미합니까?
나는 항상 '한 번만'만들고 '어디서나'사용할 수 있지만 '야기'와 조화를 이루고 있습니다.
여기 내 질문에 '비즈니스 클래스'라는 생각이 들었다고 생각합니다. 다시 사용할 수 있습니까? 우리는 '지금 가장 효과가있는 것을 만드십시오'라고 말하며, 필요할 때 그것을 기반으로합니다.
R
나는 오히려 다양한 시나리오에서 사용할 수있는 개체를 만드는 것보다, 특정 작업의 작은 세트에 수업이 더 집중하게하는 것이 더 나은 것 같아요. 예를 들어, 모든 데이터 계층의 특성/동작, 모든 표현 계층 항목이있는 표현 계층 객체 및 서비스 계층 객체 등이있는 데이터 계층 객체가있을 수 있습니다.
클래스를 " all-powerful "을 사용하면 여러 레이어에 많은 의존성을 만들어 결국에는 나중에 변경하기가 훨씬 어려워집니다. "Single Responsibility Principle (단일 책임 원칙)"에 대한 Google 검색을 수행하십시오 - OO의 "SOLID"원칙 중 하나입니다.
UI에서 아주 많이 제거 된 많은 클래스를 만듭니다. 매회 이러한 인터페이스를 구현하는 것은 최소한의 보상으로 무거운 부담이 될 것입니다.
우선 프로그래머는 게으르다. 우리의 수정은 지루한 작업을 자동화하는 것이다. (나는 부정적이지 않다.) 우리는 일반적으로 어떤 종류의 여분의 비트가 들어가는지를 명시하는 특별한 목적을 위해 클래스를 작성한다. aspect 지향 프로그래밍이 대답하려고하는 기본적인 질문을하고있다. 내 반은 봉사 요원입니까? 내 수업은 데이터 컨테이너입니까? 수업은 관찰 가능합니까? 이것들은 사용법에 따라 클래스가 이러한 모든 것들이 될 수있는 측면입니다. 아니면 그 중 하나 일 수도 있습니다.
이렇게하면 선을 어디에 그립니다. 언젠가 당신이 어딘가에서 던져 버릴지도 모르기 때문에 모든 수업을 예외로 만들 계획입니까? 그것들을 모두 직렬화 할 예정입니까?
당신이 생각할 수있는 또 다른 방법은 언어 디자이너가 이미 그 결정을 내린 것입니다. 모든 클래스는 "일반"객체에 필요한 모든 것을 포함하는 Object에서 자동으로 상속받습니다.
마지막으로 코드 재사용과 불필요한 코드 작성을 혼동하지 마십시오. 일반적으로 지금 당장 필요한 코드 만 작성하고 나중에 쉽게 사용하고 변경할 수 있도록 설계하십시오.