2009-02-09 2 views
2

안녕하세요,패키지/모듈 종속성 트리를 올바르게 구성하는 방법은 무엇입니까?

현재 파이썬 라이브러리를 작성 중입니다. 현재 모듈과 클래스는 이유가없는 디자인으로 조직되지 않은 방식으로 배포됩니다. 좀 더 공식적인 버전이 나오면 수업과 모듈을 재구성하여 전반적인 디자인을 개선하고 싶습니다. 가져 오기 종속성에 대한 다이어그램을 그렸으며 클래스 수준을 기준으로 클래스를 집계 할 계획이었습니다. 또한, 이러한 종속성을 줄이기 위해 클래스에 대한 수정을 고려 중이었습니다.

잠재적으로 복잡하고 제작이 많은 파이썬 라이브러리를 전반적으로 잘 디자인하기위한 전략은 무엇입니까? 흥미로운 제안이 있습니까?

감사

업데이트 : 참으로 엄지 손가락의 규칙을 찾고 있었다

. 당신이 bar.b를 가져 d.py과에서는 hello.c를 가져 a.py이 일이 예를 들어,이 경우 발생 가정 (초기화는 명확성을 위해 제거 평)

foo/bar/a.py 
foo/bar/b.py 
foo/hello/c.py 
foo/hello/d.py 

지금, 나는 고려할 것 이것은 나쁜 설정. 또 다른 경우는

foo/bar/a.py 
foo/bar/baz/b.py 
foo/bar/baz/c.py 

이라고 가정합니다. a.py와 b.py 모두 c. 1) b 가져 오기 c, 가져 오기 baz.c 2) foo/bar에서 c를 이동합니다. a.py import c, b.py imports .c 3) c를 다른 곳으로 옮긴 다음 (예 : foo/cpackage/c.py) a와 b 모두 가져 오기 cpackage.c

3) , c.py가 독립 실행 형 모듈로서 아무런 의미가 없다면 (예를 들어 바 패키지에 "private"으로 유지하기를 원하기 때문에) 우선적으로 1)로 갈 것입니다.

다른 많은 유사한 경우가 있습니다. 엄지 손가락의 규칙은 종속성과 교차 횟수를 최소한으로 줄여 고도로 분지되고 고도로 얽힌 설정을 방지하는 것이지만 잘못 될 수 있습니다.

답변

6

"가져 오기 종속성에 대한 다이어그램을 그리고 레이어 수준별로 클래스를 집계 할 계획이었습니다."

파이썬 영어처럼 읽을 수 있어야합니다 (또는 다른 자연 언어.)

반입 진정한 의미가 있어야 일류 문입니다."계층 수준"(모든 것이 무엇이든)을 정리하는 것은 명확하고 의미 있고 명백해야합니다.

클래스의 모듈 및 모듈로의 임의의 기술적 그룹을 패키지로 만들지 마십시오.

모듈 및 패키지를 명확하고 논리적으로 만들어 수입 목록이 명백하고 간단하며 논리적임을 확인하십시오.

"또한 이러한 종속성을 줄이기 위해 클래스 수정을 고려하고있었습니다."

의존성을 줄이는 것은 기술적 인 것과 임의적 인 것입니다. 그것은 그렇지 않을 수도 있지만 그런 식으로 들립니다. 실제 사례가 없다면 말하기가 불가능합니다.

목표는 명확합니다.

또한 모듈과 패키지는 독립 실행 형 재사용 단위입니다. 클래스는 아니지만 클래스 자체는 일반적으로 재사용 할 수 없습니다. 종속성 트리에이를 반영해야합니다. 응용 프로그램에 깔끔하고 깨끗하게 가져올 수있는 모듈을 목표로합니다.

많은 밀접하게 관련된 모듈 (또는 다른 구현)을 사용하는 경우 패키지를 사용할 수는 있지만 아껴서는 안됩니다. 파이썬 라이브러리는 비교적 평평합니다. 거기에는 약간의 지혜가 있습니다.


편집

층 사이의 의존성이 필수적인 기능입니다 편도. 이것은 파이썬에 관한 것보다 적절한 소프트웨어 디자인에 관한 것입니다. (1) 레이어로 디자인해야하며, (2) 레이어간에 종속성이 매우 엄격하도록 디자인 한 다음 (3) Python에서이를 구현해야합니다.

패키지가 레이어링에 꼭 맞는 것은 아닙니다. 패키지는 실제로는 import 명령문을 통해서만 표시되는 종속성을 가진 디렉토리의 편평한 목록 일 수 있습니다.

+0

레이어를 사용하면 클래스/모듈이 해당 패키지의 내용이나 "하위"서비스를 포함하는 다른 패키지에 종속되도록 패키지를 구성해야합니다. 필자는 모든 패키지를 "독립 라이브러리"로 간주 할 것이며, 결국 다른 패키지에 의존하여 원형 종속성을 갖지 않게됩니다. –

0

질문은 매우 모호합니다.

나머지 라이브러리에서 아무것도 가져 오지 않는 기본/핵심 항목과 여기에서 가져 오는 구체적인 구현을 사용하면이 작업을 수행 할 수 있습니다. "가져 오기 시간에 서로로부터 두 개의 모듈을 가져 오지 않아야한다"는 것 외에는 괜찮을 것입니다.

module1.py :

import module2 

module2.py :

import module1 

이 작동하지 않습니다!

+0

실제로, 귀하의 예는 그대로/될 것입니다/작동합니다. 나는 당신의 접근법이 좋은 경험 법칙이기 때문에 downvote하지 않는다. 두 개의 모듈을 서로 가져 오지 않고 디자인을 수정하라. – Yonatan

0

프로젝트에 따라 다르습니까? 예를 들어 모델 뷰 컨트롤러 디자인을 사용하는 경우 패키지는 3 개의 코드 그룹을 독립적으로 만드는 방식으로 구성됩니다.

몇 가지 아이디어가 필요하면 사이트 패키지 디렉토리를 열고 모듈의 코드를 살펴보고 설정 방법을 확인하십시오.

모듈에 대해 더 알지 못하더라도 올바른 방법이 없습니다. 알리가 말했듯이 이것은 막연한 질문이다. 당신은 정말로 당신 앞에서 가지고있는 것을 분석하고 더 잘 될지도 모르는 것이 무엇인지 알아낼 필요가 있습니다.