Abstract model class 에 대한 논의

[anohk]

1. 추상 모델의 이름에 Abstract, Base를 붙이지 않는 것을 제안합니다.

추상 모델명에 prefix를 붙이는 컨벤션이 Django에서 일반적으로 사용되지 않는 것으로 보입니다. (예: TimeStampedModel, UUIDModel 등)
기본적으로 추상 모델은 충분히 일반화된 이름을 붙이고, 이를 상속하는 구체 모델에서는 구체적인 이름을 붙여 관리하는 것이 어떨까요?

# Don't

class AbstractPayment:
    class Meta:
        abstract = True

class BasePayment:
    class Meta:
        abstract = True

# Do

class Payment:
    class Meta:
        abstract = True

단, prefix를 사용하지 않으면 네이밍이 어려워 질 수도 있습니다.
중첩된 추상화의 경우에는 prefix를 붙이는 것을 고려해 볼 수 있습니다.
아래는 apps.payments.abstract_models 의 사례입니다.

class BasePayment:
    class Meta:
        abstract = True

class AbstractPayment(BasePayment):
    class Meta:
        abstract = True

class AbstractInvestmentPayment(BasePayment):
    class Meta:
        abstract = True

# 상위 추상모델에만 prefix 적용

class BasePayment:
    class Meta:
        abstract = True

class Payment(BasePayment):
    class Meta:
        abstract = True

class InvestmentPayment(BasePayment):
    class Meta:
        abstract = True

2. 추상 모델 모듈의 위치는 어디가 적절할까요?

추상모델의 모듈은 어떤 곳에서 관리되는 것이 좋을지, 의견을 주시면 좋겠습니다.

대체로 아래와 같이 app level에서 abstract_models.py 모듈이 정의되어 있습니다.
app이 세분화되고 모델이 증가함에 따라 abstract_models 단일 모듈의 복잡도가 높아질 가능성이 있습니다.

investments
|__ abstract_models.py
|__ models.py

investments
|__ abstract_models.py
|__ models.py
|__ reservations
    |__ __init__.py
    |__ models.py

investments
|__ abstract_models.py
|__ reservations
    |__ __init__.py
    |__ models
        |__ __init__.py
        |__ corporation.py
        |__ individual.py 

아래와 같이 의도가 동일한 영역 내에서 abstract_models를 분리해 볼 수 있습니다.

investments
|__ abstract_models.py
|__ models.py
|__ reservations
    |__ __init__.py
    |__ models
        |__ __init__.py
        |__ abstract_models.py
        |__ corporation.py
        |__ individual.py 

[kyungjunleeme]

저는 개인적으로 abstract_models.py 라는 모듈내에서 별도로 abstract model를 관리하는 것이 보기 좋은 것 같지는 않습니다.
그 근거는 장고에서 CustomUser model을 만들기 위해서 자주 사용하는

from django.contrib.auth.models import AbstractBaseUser

역시 별도의 모듈에서 관리되고 있지 않기때문입니다.

[leehosung]

위치에 대해서는 저도 models.py 에 함께 두는것이 좋다고 생각해요.
만일 모듈이 너무 커지는 상황이 발생한다고 하면, 오히려 django app 을 나누어야 하는 상황은 아닐까 싶습니다.

[leehosung]

이름에 대해서는 Base, Abstract 의 사용에 대한 규칙 또는 패턴을 만들지 않는것이 좋다고 생각합니다.
꼭 필요하거나 그 이름이 적합한 경우가 있을수는 있겠습니다. (Abstract 는 없을것 같아요)

하지만 보다 좋은 방향은 sub class 의 이름을 보다 명확하게 작성하는것 입니다.
super class가 접두사가 없는 보다 일반적인 이름을 취함으로 오히려 sub class 의 이름을 명확하게 하는 효과가 있습니다.
그리고 이름을 짓는 과정에서 해당 class 의 범위를 함께 고민하게 되지 않을까요.

ex) BasePayment 를 상속받았으니 그냥 Payment 라고 이름 짓자
vs
Payment 를 상속받아야 한데 Payment라고 할 수는 없으니 WorkoutPayment 라고 명확하게 이름을 정하자.

중첩된 구조에 대해서도 중첩(여러 단계 두기)을 해야만 하는 이유가 있을겁니다. 그렇다면 그 이유를 설명할 수 있는 적절한 이름을 정할 수 있겠습니다.

예전에 이 논의를 한번 한적이 있습니다.

from apps.post_management.rehabs.models import Payment
from apps.post_management.workout.models import Payment 

이 부분이 논의의 결과로 남아 있는 대표적인 예입니다.

from apps.post_management.rehabs.models import RehabPayment
from apps.post_management.workout.models import WorkoutPayment

과 같은식으로 유사한 역할을 하는 class 들의 이름을 모두 다르게 할 필요가 있는가? 에 대한 논의 였던것으로 기억합니다.
모듈 패스에 이미 "rehab", "workout" 이라는 정보가 포함되어 있기도 하구요. 그래서 두가지를 모두 동시에 써야 하는 경우에는

from apps.post_management.rehabs.models import Payment as RehabPayment
from apps.post_management.workout.models import Payment as WorkoutPayment

로 구분해서 쓰자로 결론 내렸던것 같습니다.

유사한 일을 하는 각 Class의 이름을 동일하게 맞춰서 접근을 쉽게 만드는것도 가치가 있는 일이지만 지금은 프로젝트 내의 Class 이름을 유니크하게
만드는것이 더 가치 있지 않을까요.

(네. 의견이 바뀌었어요.)

[cbscsm]

추상모델의 위치에 관해서 각각의 추상모델이 커버하는 계층에 존재하는 것도 좋을 것 같습니다.
하위 구체 모델이 모두 한 모듈에 있는 경우에는 같은 모듈에 있어도 될것 같고,
구체 모델이 모두 존재하는 패키지 레벨이 있다면 그 레벨에 두는 방법이 있을 것 같습니다.
한 모듈에 있던 모델들이 종류가 많아지거나 크기가 커지면서 여러 모듈로 분리된다면 그 때 추상 모델도 함께 다른 모듈로 분리가 되는 방식일 것 같습니다.