새 클래스의 이름을 무엇으로 지정해야 할지 고민하면서 머리를 긁적인 적이 있습니까?

우리 모두는 이것과 싸우고 있습니다!

사실, it's one of the two hardest parts of programming!

때로는 명확한 비즈니스 개념을 염두에 두고 있기 때문에 쉽습니다.

다른 경우에는 비즈니스 개념과 반드시 ​​연결되지 않은 클래스를 만들 수도 있습니다.

유지 관리를 위해 클래스를 여러 클래스로 분할하기로 결정할 수 있습니다.

또는 디자인 패턴을 사용해야 할 수도 있습니다.

🤦‍♂️

구조 팁!

코드 작성에는 일반적으로 해결하려는 특정 시나리오가 포함됩니다. 다음은 클래스 이름을 잘 지정하여 이러한 종류의 비즈니스 시나리오를 해결하기 위한 몇 가지 팁입니다.

가능한 한 구체적으로 작성하십시오!

처음에는 장황하게 말하는 것을 두려워하지 마십시오. 나중에 리팩터링할 수 있습니다.

프로그래머가 아닌 사람에게 비즈니스 프로세스를 설명하는 문서의 개요를 작성하는 것처럼 가정해 보십시오. 이것의 용어로 이름을 지정하여 시작하십시오.

예시

팁 #3을 사용하는 샘플은 다음과 같습니다.

Once an order is submitted by the customer, we need to make sure that all the order's items are in stock. If some are not in stock, then we need to send them an email to let them know what items are on back-order.

Next, we will pass the information to the shipping department for further handling.

이 설명을 사용하여 명사에서 일부 클래스를 만들 수 있습니다. 때로는 코드를 어떻게 구성하고 싶은지에 따라 형용사를 사용하는 것도 매우 가치가 있습니다!

Order 또는 SubmittedOrder

Customer 또는 OrderCustomer

OrderItems

OrderItemsOnBackOrderEmail

ShippingDepartmentOrderHandler

명사/용어는 해결하려는 특정 컨텍스트(bounded contexts from DDD 참조)에 모두 적용할 수 있습니다.

우리가 작성하는 코드는 처음에는 다음과 같을 것입니다.

class OrderSubmittedHandler {

    public async handle(order: Order, customer: Customer) {
        const submitted: SubmittedOrder = order.submitOrder();

        if(submitted.hasItemsOnBackOrder()) {
            const mail = new OrderItemsOnBackOrder(submitted);
            mail.sendTo(customer);
            await this._mailer.send(mail);
        }

        const shipping = new ShippingDepartmentOrderHandler(submitted);
        await shipping.sendOrderInfo();
    }

}

가볼만한 곳:

Order에서 SubmittedOrder로의 전환을 명시적으로 모델링합니다. a SubmittedOrder 는 Order 와 동작이 다르기 때문에 Single Responsibility Principle 을 따라 클래스를 더 작고 관리하기 쉽게 유지합니다.

_mailer 변수와 같은 교차 절단 개체를 도입했습니다. 이 예에서 나는 이미 종속성 주입을 사용하여 Mailer 를 제공한다는 것을 알고 있습니다. 그러나 그것은 나중에 리팩토링하기로 결정한 것일 수 있습니다.

전체 시나리오 자체가 새로운 클래스로 의미 있는 명사로 포착!
물론 이것은 나중에 리팩토링될 수 있습니다. 그러나 첫 번째 단계에서 이 기술은 사물의 이름을 지정하고 상호 작용하는 방법을 확고히 하는 데 실제로 도움이 될 수 있습니다.

장황하게 말하는 것이 실제로 잘 작동합니다!

의사 코드 사용에 대한 더 많은 팁은 다음 작성자의 훌륭한 기사를 확인하십시오.

이전 자습서로 이동: 의사 코드

Ali Spittel ・ 2019년 5월 7일 ・ 5분 읽기

#beginners #problemsolving #movingpasttutorials #programming

추가 지침

다음은 비즈니스 시나리오에서 명확하거나 명확하지 않을 수 있는 특정 종류의 클래스를 처리할 때 도움이 될 수 있는 몇 가지 지침입니다.

예를 들어 디자인 패턴을 도입해야 하는 경우가 있습니다. 그럼 클래스 이름은 무엇입니까?


의지
공식
예


권한 부여Can{Entity}{Action}CanAdminViewThisPage , CanManagerUpdateUserInfo
확인Is{Target}{State}{Test}IsAddressUpdateAllowed , IsUserCreationValid
인터페이스ICan{Action}ICanSendMail , ICanBeValidated
구체적인 사업 개념
"무슨 일이야?"(명사 + 형용사)
Student , EmployeeUserProfile , ShippingAddress
사용 사례{Action}{Target}ApproveOrder , SendWelcomeEmail
디자인 패턴{Name}{Pattern}IShippingAddressStrategy , HomeAddressStrategy , TemporaryAddressStrategy

연락 유지

다음에서 나와 연결하는 것을 잊지 마세요.

내 웹 사이트www.jamesmichaelhickey.com에서도 나를 찾을 수 있습니다.

소프트웨어 개발 경력 뉴스레터 탐색

소프트웨어 개발자로서의 경력 수준을 높이는 데 도움이 되는 이메일 뉴스레터! 지금까지 궁금해:

✔ 소프트웨어 개발자의 일반적인 단계는 무엇입니까?
✔ 내가 어느 단계에 있는지 어떻게 알 수 있나요? 다음 단계로 어떻게 가나요?
✔ 기술 리더란 무엇이며 어떻게 될 수 있습니까?
✔ 나와 함께 걸으며 내 질문에 답해 줄 사람이 있습니까?

재미있을 것 같나요? Join the community!