SOLID 원칙을 사용할 때 개발자의 검색 가능성에 문제가 있습니까?

다른 모든 개발자가 기본 CRUD 앱을 사용하는 데 익숙하거나 예쁘고 기능적인 인터페이스를 만드는 데만 집중하는 LOB (기간 업무) 앱을 운영하고 있으며 다음과 같은 결과를 얻고 있습니다.

"우리가 사용하는 방식으로 직원은 직원과 함께 할 수있는 모든 것을 가질 수 있습니다." 그리고 사실이었다. 한 "클래스"에는 수천 줄의 코드가 있었고 직원과 함께 할 수있는 모든 것이있었습니다. 또는 더 나쁜 것은 직원 데이터 테이블이 있었고 각 개발자는 이벤트 핸들러에서 원하는 작업을 수행하는 방법을 알아 냈습니다.

그 접근법에 대한 모든 나쁜 점은 사실이지만 적어도 직원을 사용하는 개발자는 다른 문서를 보지 않고도 직원을 건강 계획에 등록하고 급여 인상, 해고, 고용, 양도 등을 할 수있는 방법을 알아낼 수 있습니다. 관리자 및 기타 모든 주요 아이디어에 대해 또는 직원이 다른 필요한 데이터 테이블을 사용한 경우 원하는 것을 수행 할 수 있습니다.

예, 중복 된 코드가 많았습니다. 예, 매우 취하기 쉬운 코드였습니다. 예, 테스트는 필요 이상으로 어려웠습니다. 그렇습니다. 기능 변경으로 인한 두려움이 있었으며 복사 붙여 넣기 방식은 자연 스럽습니다.

그러나 그들은 적어도 하나의 클래스를 만들어서 사용 가능한 것을 발견하거나 인터페이스, 추상 클래스, 구체적인 클래스 등의 차이점을 이해하지 않고도 필요한 것을 수행 할 수 있습니다. intellisense에 의해 리턴 된 메소드 또는 데이터가 상주 한 테이블을 알고 있습니다.

나는 googled / binged, 심지어 yahoo! d이지만이 문제에 대한 인정을 찾지 못했습니다.

따라서 문제가 없을 수 있으며 무언가를 놓치고 있습니다. 실제 행동 / 디자인을 수행하지 않는 개발자 (들)가 외부 문서를 참조하거나 다양한 구성 요소에서 클래스 이름을 스캔하지 않고도 무언가를 수행하는 방법을 쉽게 발견 할 수있는 솔루션을 찾으려고 노력했습니다. 작동하는 것처럼 보이는 것을 찾는 프로젝트.

내가 생각해 낼 수 있었던 유일한 것은 더 나은 이름이 없기 때문에 실제 클래스를 반환하는 더 이상 아무것도하지 않는 "목차 클래스"가 없다는 것입니다 (실제로 대부분은 인터페이스이지만 다른 개발자가 원하는 실제 작업을 수행하는 데 사용할 수있는 차이점이나주의 사항을 알고 있어야합니다. 여전히 큰 수업으로 끝나지 만 거의 행동이 없습니다.

실제 SOLID 구현이 수행되는 중간 계층에 대한 친밀한 지식이 필요하지 않은 더 좋은 방법이 있습니까?

기본적으로 CRUD 유형 개발자가 매우 복잡한 시스템에서 CRUD 개발자가 될 수있는 방법이 있습니다.

당신이 설명 한 것 (즉, 직원과 함께 할 수있는 모든 가능한 코드를 가진 직원 클래스)은 개인적으로 꽤 많이 본 매우 일반적인 패턴 인 것 같습니다. 그 코드 중 일부는 내가 더 잘 알기 전에 직접 작성했습니다.

관리 가능한 메소드 세트를 가진 단일 엔티티를 나타내는 클래스로 시작하는 것은 각 기능과 각 릴리스가 계속 동일한 클래스에 점점 더 추가되기 때문에 유지해야 할 악몽으로 변모합니다. 이것은 클래스를 한 번 작성하고 반복해서 수정하려는 충동에 저항해야한다는 SOLID 원칙에 위배됩니다.

얼마 전 (다른 사람들이 홍보 한대로 디자인 패턴이나 SOLID를 발견하기 전에) 다음 프로젝트를 진행하기로 결정했습니다. 나는 두 개의 매우 큰 플랫폼 사이의 인터페이스 역할을하는 서버에서 일하고있었습니다. 처음에는 구성 동기화 만 필요했지만 이것이 다른 많은 기능의 논리적 장소라는 것을 알 수있었습니다.

따라서 메소드를 노출하는 클래스를 작성하는 대신 메소드를 나타내는 클래스를 작성했습니다 (GoF의 "명령"패턴으로 밝혀 짐). 클라이언트 작업을 수행하는 대신 모든 주요 응용 프로그램 클래스는 영구적 인 상태 유지자가되어 길이가 훨씬 짧아졌습니다. 서비스 자체에 새 인터페이스 메서드를 추가해야 할 때마다 모든 것을 시작한 Execute () 메서드가있는 새 클래스를 만들었습니다. 여러 명령에 공통점이 있으면 공통 기본 클래스에서 파생됩니다. 결국 70 개 이상의 서로 다른 명령 클래스가 있었으며 전체 프로젝트는 여전히 매우 관리가 용이했으며 실제로 작업하기가 즐거웠습니다.

당신의 "TOC 수업"은 내가 한 일에서 그리 멀지 않습니다. 명령 인스턴스화를 담당하는 추상 팩토리 (GoF)가있었습니다. 팩토리 클래스 내에서 기본 클래스와 ATL 스타일 매크로 뒤에 대부분의 세부 사항을 숨겼으므로 프로그래머가 요청을 추가하거나 조회해야 할 때 거기에 들어갔습니다.

BEGIN_COMMAND_MAP()
    COMMAND_ENTRY( CChangeDeviceState )
    COMMAND_ENTRY( CSetConfiguration )
    ....
END_COMMAND_MAP()

또는 모든 실제 명령 클래스를 별도의 네임 스페이스에 넣을 수 있으므로 사람들이 코딩하고 무언가를 실행해야 할 때 네임 스페이스 이름 만 입력하면 Intellisense는 사용자가 정의한 모든 명령을 나열합니다. 그런 다음 각 명령에는 입력 및 출력 매개 변수를 정확하게 결정하는 모든 get get / set 메소드가 포함됩니다.

Facade (GoF) 패턴 사용을 탐색 할 수도 있습니다. CRUD 엔지니어에게 1000 개 이상의 클래스를 공개하는 대신 필요한 것만 노출시키는 단일 클래스 뒤에 모든 것을 숨 깁니다. 나는 여전히 각 "조치"를 자체 클래스로 유지하려고 노력하지만 Facade 클래스는 각 조치를 인스턴스화하는 메소드를 가질 수 있으며 Intellisense를 사용하면 즉시 사용 가능한 항목을 볼 수 있습니다. 또는 Facade에 실제 메서드가 있지만 내부적으로 명령을 인스턴스화하고 대기열에 넣고 응답을 기다립니다. 그런 다음 일반 메소드 호출이 이루어진 것처럼 리턴하십시오.

(*) 너무 많은 세부 정보를 얻고 싶지는 않지만 실제로 "Command"및 "CommandHandler"클래스 세트가 있습니다. 이로 인해 실제로 해당 명령을 "처리"한 클래스와 매개 변수 관리 / 큐잉 / 직렬화에 대한 책임이 분리되었습니다.

문제가 될 수 있습니다. 특히 이름을 잘못 지정하면 그러나 복잡한 수업에 의지하지 않고 여러 가지 해결책이 있습니다. 너무 많은 메소드를 가진 클래스는 Intellisense로 탐색하기가 똑같이 어려울 수 있습니다.

네임 스페이스 (C #) 또는 패키지 (Java) 또는 이와 유사한 언어 개념 (모든 네임 스페이스라고 함)을 사용하여 문제를 단순화하십시오.

회사 이름으로 시작하십시오. 이는 Intellisense가 스스로 작성한 네임 스페이스로만 제한합니다. 그런 다음 여러 응용 프로그램이있는 경우 네임 스페이스의 두 번째 부분을 사용하여 분할하십시오. 여러 응용 프로그램에 존재하는 것들에 대한 핵심 네임 스페이스를 포함시킵니다. 다음으로 기능을 유형별로 분류하십시오. 등등.

이 작업을 올바르게 수행하면 검색 가능한 항목이 생깁니다.

예를 들어, 사용자 유효성 검사를 원하면 "MyCo"를 입력하십시오. 응용 프로그램 네임 스페이스 목록을 제공합니다. 사용자 데이터베이스가 모든 앱에서 사용되는 것을 알고 있으므로 "Core"를 입력합니다. 그런 다음 기능 유형 목록을 얻습니다. 그중 하나는 "유효성 검증"이므로 분명한 선택처럼 보입니다. 그리고 Validation에는 모든 기능을 갖춘 "UserValidator"가 있습니다.

그것이 일어날 때, 내가 많이 사용하는 것들에 대해, 나는 이름이나 최소한 관습을 빨리 기억할 것입니다. 유효성 검사 규칙을 많이 변경했기 때문에 모든 유효성 검사 클래스를 FooValidator라고합니다. 여기서 Foo는 테이블 이름입니다. 따라서 실제로 네임 스페이스를 탐색 할 필요가 없습니다. UserValidator를 입력하고 IDE가 나머지 작업을 수행하도록하겠습니다.

그러나 내가 기억할 수없는 것들을 찾기는 여전히 쉽습니다. 그리고 내가 할 때 네임 스페이스 접두사를 제거 할 수 있습니다.

기본적으로 "CRUD"개발자라고 언급하기 때문에 우리는 그들이 매우 좋다고 생각하지 않는다고 가정합니다. 이것이 귀하의 비즈니스 도메인도 이해하지 못한다는 것을 알 수 없습니다. 그들이 도메인을 이해한다면, 클래스는 그들에게 의미가 있어야합니다. 여러 클래스가 구축되었음을 알면 먼저 살펴보고 두 번째로 물어보고 처음부터 세 번째 옵션으로 건물을 고려하십시오.

클래스를 보면서 클래스를 사용 / 재사용하는 방법을 자동으로 아는 방법을 아는 한 처음으로 기 대해서는 안됩니다. 교육을 통해 또는 코드 검토 중에 추가 설명을 문서화하고 제공해야 할 수 있습니다.

많은 API 및 오픈 소스 프로젝트는 문서, 코드 예제 및 기타 설명을 제공합니다. 당신은 사용자 친화적 일 필요는 없지만 해결할 수는 없습니다. 잘 가르칩니다.