Go에서 디커플링을 처리하는 가장 좋은 방법은 구조는 비슷하지만 자식이 다른 두 개의 서로 다른 패키지를 사용하는 것입니다. 이 접근 방식은 코드를 효과적으로 분리하여 유지 관리성과 모듈성을 향상시킵니다. 그러나 구조의 하위 항목이 복잡해지면 이러한 분리 접근 방식이 어려워질 수 있습니다. 이 경우 인터페이스와 다형성 개념을 사용하여 문제를 해결하는 것을 고려해 보세요. 공통 인터페이스 유형을 정의함으로써 서로 다른 구조 유형을 균일하게 처리할 수 있어 보다 유연한 디커플링 방법을 구현할 수 있습니다. 이 접근 방식은 코드의 확장성과 재사용성을 높이기 위해 Go에서 널리 사용됩니다.
저는 이 분야에 비교적 익숙하지 않고 의존성 그래프를 최대한 줄이기 위해 대규모 재작성을 해왔습니다. 어디서 구했는지 매우 만족하지만, 한 부분을 어떻게 처리해야 할지 잘 모르겠습니다. 대답이 "둘 사이에 이러한 종속성이 있을 것입니다"라면 그것도 괜찮습니다. 저는 기적을 기대하기보다는 단지 좋은 접근 방식을 찾고 있을 뿐입니다.
아래에는 두 개의 패키지 a
和 b
가 있으며 둘 다 동일한 구조를 가지고 있습니다. 일반적으로 main 에서 하나를 다른 것으로 변환할 수 있지만 각각에는 구조체이기도 한 자식이 있으므로 자식이 동일한 서명을 가지고 있더라도 go가 이를 허용하지 못하게 합니다.
한 가지 방법은 b 구조에서 a.tzconfig를 참조하여 종속성을 갖도록 하는 것이지만, 이것이 제가 제거하고 싶은 것입니다.
또 다른 방법은 인터페이스를 만든 다음 메서드를 통해 loc의 값을 가져오는 것 같아요. 이것이 작동할 것이라고 생각하지만 아직 시도하지 않았습니다. 왜냐하면 이는 단지 데이터 구조인 것에 대한 메서드를 만드는 것을 의미하기 때문입니다( 실제 구조에는 많은 항목이 있는데 여기서는 단순화를 위해 필수 항목으로 줄였습니다. 이는 약간 과잉인 것 같습니다.
tzconfig를 세 번째 모듈로 이동하여 한 모듈이 다른 모듈을 참조하는 대신 둘 다 해당 모듈을 참조하도록 할 수 있습니다. 이것이 제가 생각해낸 것입니다.
제 질문은 실제 경험이 있는 사람이 Go에서 이 상황을 처리하는 가장 좋은 방법이 무엇인지 묻는 것입니다.
그들이 구조체를 복제하는 이유는 단지 그들 사이의 종속성을 깨려고 하기 때문이라는 점을 언급해야 합니다. 원래 코드에는 한 패키지에 구조체가 있고 다른 패키지는 이를 참조합니다.
으아악 으아악package a type cfg struct { addr string loc tzconfig } type tzconfig struct { string string tz *time.location `validate:"nodescent"` } func getcfg() cfg { t, _ := time.loadlocation(`mst`) return cfg{ addr: "abc", host: "a.bc.d", loc: config.tzconfig{ string: "mst", tz: t, }, } }
IMHO @burakserdar가 제공한 조언은 매우 훌륭하고 귀하의 시나리오에 매우 적합합니다. 이런 식으로 코드를 다시 작성했습니다.
package common
자주 사용되는 구조, 함수, 메소드 등은 여기에 배치해야 합니다.
package a
여기에는 a
包相关的特定代码,它继承了 common
包的共享代码,如 import
부분이 나와 있습니다.
common
패키지에 정의된 공유 필드를 가져오기 위해 구조체 임베딩 기능을 사용합니다.
package b
여기서 특별히 언급할 만한 내용은 없습니다.
package main
여기서 코드는 매우 간단해야 합니다. 기능을 활용하기 위해 a
和 b
패키지를 가져왔습니다.
주관적인 주제이므로 마법의 총알 해결책은 없다는 점을 다시 한 번 분명히 말씀드립니다. 제가 보기에는 깔끔하고 깨끗해 보입니다. 나는 확실히 이 접근법을 선택할 것이다. 꼭 알려주시고 감사드립니다!
위 내용은 Go에서 디커플링을 처리하는 가장 좋은 방법은 두 개의 서로 다른 패키지에서 유사한 구조를 사용하는 것입니다. 그러나 구조의 하위 요소로 인해 어렵습니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!