하드웨어 장치를 통과하는 일종의 데이터는 특별한 형식을 사용합니다. 첫 번째 부분은 ID이고 마지막 부분은 데이터입니다.
이전 단락은 A, B, C 등 어떤 유형의 데이터인지 나타냅니다.이전 유형에 따르면 뒤에서 특정 숫자를 취합니다. 예를 들어 A 유형의 경우 1~3자리의 데이터가 필요하고, B 유형의 경우 20번째와 22번째 숫자가 필요합니다.
이제 디자인할 때 카테고리 a와 b만 허용하면 됩니다. 하지만 앞으로는 카테고리 c, 카테고리 d 등을 허용하려는 경우 데이터에 대한 작업도 달라집니다. 카테고리 A는 1~3자리를 곱해야 합니다. 2. 카테고리 B의 20번째 자리에 1을 더하면 22번째 자리는 그대로 유지됩니다. z
문제는 향후 확장을 촉진하기 위해 어떻게 설계해야 하느냐는 것입니다. 예를 들어 코드를 다시 작성하지 않고 클래스 d를 지원하고 싶습니다....
三叔2017-06-17 09:17:50
복잡하다면 전략 패턴을 사용하세요. 복잡하지 않다면 직접 OO 상속을 사용하세요. 다양한 유형의 메시지가 다양한 하위 클래스에서 처리됩니다.
某草草2017-06-17 09:17:50
데이터 프로토콜 형식은 잘 정의되어야 합니다. 예를 들어 높은 3자리 숫자는 유형을 나타내고, 중간 2자리 숫자는 프로토콜 버전을 나타내고, 마지막 숫자는 데이터를 나타냅니다.
프로토콜이 규정된 후 템플릿 방식으로 처리되며, 특정 분석은 하위 클래스에, 일반 분석은 상위 클래스에 배치됩니다.
이렇게 하면 확장할 때 원래 코드를 변경할 필요가 없고 새로운 구현만 작성하면 됩니다.
三叔2017-06-17 09:17:50
또한 후속 사용자를 판단해야 합니다. 팩토리 모드, 전략 모드, 에이전트 모드는 모두 확장 요구 사항을 충족할 수 있습니다. 사실 중요한 것은 6가지 원칙에 따라 디자인할 필요가 없습니다. 특정 모드 필요에 따라 코드는 천천히 진화하고 결국에는 자연스럽게 특정 패턴을 따르거나 여러 패턴의 조합이 될 수 있습니다.