ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • EmailField & CharField Difference
    Django/OZ 2024. 3. 18. 20:02

    EmailField vs CharField

    일단 EmailField는 CharField를 상속하기 때문에 적절한 곳에 사용시 손실되는 것이 없기 때문에 validate_email로 기본 검증을 한다. 

    올바른 형식으로 example@example.com 이메일을 작성하는지 확인할 수 있다.

    그렇지 않을 경우 오류메세지를 반환하는데 이 때 정보의 손실이 발생할 수도 있다.

    사전에 정의된 변수(description)도 사용할 수 있다.

    백엔드에서는 이미 최대 길이를 75자로 제한한다. (물론 설정값을 변경할 수도 있다.)

     

    EmailField에서는 유효성 검사 기능(validate_email)을 제공하기 때문에 이메일 형식의 입력만 허용되며 입력된 값이 유효한 이메일 주소인지 자동으로 확인하고, 잘못된 형식의 값이 입력되면 오류를 발생하여 중복된 이메일 주소가 저장되는 것을 방지한다.

    이는 이메일 주소의 유효성 검사 로직을 여러곳에 반복작성하는 것보다 EmailField를 사용하여 반복을 줄이고 코드를 간결하게 유지시키기 때문에 CharField와 비교했을 때 DRY principle을 준수하고 있다. 유효성 검사 로직이 한 곳에만 존재하기 때문에 유지보수에도 용이하다.

    class EmailField(CharField):
        default_validators = [validators.validate_email]
        description = _("Email address")
    
        def __init__(self, *args, **kwargs):
            # max_length=254 to be compliant with RFCs 3696 and 5321
            kwargs.setdefault("max_length", 254)
            super().__init__(*args, **kwargs)
    
        def deconstruct(self):
            name, path, args, kwargs = super().deconstruct()
            # We do not exclude max_length if it matches default as we want to change
            # the default in future.
            return name, path, args, kwargs
    
        def formfield(self, **kwargs):
            # As with CharField, this will cause email validation to be performed
            # twice.
            return super().formfield(
                **{
                    "form_class": forms.EmailField,
                    **kwargs,
                }
            )

     

    CharField 에서는 유효성 검증이 진행되지 않기때문에 형식에 맞는 않는 데이터가 손실될 일이 없다.

     

     

     

     


     

    그렇다면 DRY 원칙이 무엇일까?

     

    DRY principle - Don't Repeat Yourself.

    • 중복된 코드 작성을 지양하자는 원칙
    • 중복을 피하고 반복되는 코드는 메서드로 묶어 재사용을 용이하게 하여 유지 보수성을 높여야한다
    • DRY principle을 따르면 코드의 의도를 명확히하고 효율적인 유지가 가능하며 코드의 복잡성을 줄여준다

     

    이 원칙을 지키며 코드를 짤 때 생각해야 할 것. 

     
    1. 항상 코드를 서로 작동할 수 있는 작은 모듈들의 시리즈로 생각합니다.
    2. 재사용 가능한 코드를 생각하고 유틸리티 클래스를 형성하려고 노력합니다.
    3. 로직을 분할하고 간단하고 짧은 코드 시퀀스로 잠그세요.
    4. 객체 지향적으로 코드를 작성하려면 클래스로 분류할 수 있는 동작을 생각합니다.
    5. 기억하세요. 적은 코드는 유지보수성이 더 높습니다.

     

    WET principle. - Write Every Time

    • DRY principle을 따르지 않을 때 발생
    • 중복된 코드 작성을 허용하고 장려하는 원칙
    • Waste Everyone's Time 이라고 이해하면 쉽다. 모든 코드에 주석을 다는 것과 같은 행동이 대표적인 WET 원칙을 따르는 행동이다.
    • 빠른 개발에 도움을 줄 수는 있지만 코드의 품질향상과 재사용성을 높이기 위해서는 지양

     

    프로그래머들은 DRY 원칙을 적용하여 간결한 코드를 달성하려고 노력해야한다!

     

    'Django > OZ' 카테고리의 다른 글

    Django 3일차 - Rest framework  (0) 2024.03.09
    ORM  (0) 2024.03.08
    Django 2일차 - Admin Panel  (0) 2024.03.07
    Django 2일차  (1) 2024.03.07
    URL, VIEW 개념  (0) 2024.03.06
Designed by Tistory.