클래스 네이밍 컨벤션

Java나 C++에서 클래스를 생성할 때, 이름을 어떻게 지을지 고민할 때가 있다.

이때, 특정 역할이나 책임을 나타내는 접미사를 쓰면 더욱 이해하기 쉬울 것이다. 접미사에 따른 클래스 네이밍 컨벤션을 알아보자.

 

기본적인 클래스 네이킹 컨벤션

이름	주요 역할	사용 예시
Service	- 비즈니스 로직 - 도메인 로직을 처리하거나 외부 시스템과의 연동 특징 - Controller와 Repository 사이에 동작 - Stateless (상태없이 입력에 따라 출력 반환)	PaymentService
Manager	- 복잡한 작업. 복잡한 라이프 사이클 또는 Orchestration - 여러 서비스/컴포넌트를 조합해 복잡한 작업을 관리 - 객체 생성/삭제, 리소스 풀 관리 등 특징 - 싱글턴 패턴과 함께 자주 사용됨 - 때로는 안티 패턴으로 여겨지기도 함 (넌무 추상적일 수 있어서)	ResourceManager DatabaseConnectionManager
Handler	- 특정 이벤트/요청을 처리하는 클래스 - 이벤트 드리븐 아키텍쳐 (예: 메시지, HTTP 요청, 시스템 이벤트) - 하나의 작업을 전문적으로 처리 특징 - 보통 작은 단위의 작업에 집중 - EventListener, Controller와 유사한 역할	LogoutHandler AuthenticationHandler
Controller	- Handler와 유사 - MVC의 경우 HTTP 요청/응답을 처리 (e.g. Spring의 @Controller)
Repository	- 데이터 저장소 (DB, 캐시)와의 연동	UserRepository
Factory	객체 생성 로직을 캡슐화	PaymentFactory.create()
Delegate	작업을 다른 객체에 위임	PaymentGatewayDelegate

 

 

주의사항

- 프로젝트 컨벤션에 따라 의미가 달라질 수 있다 (e.g. UserManager vs UserService 이 둘은 둘 다 비슷한 역할을 할 수 있다.)

- 과도한 추상화를 피하는게 좋다.

  Manager는 때로 모호한 책임을 의미해 안티 패턴으로 간주되기도 한다.

- 의도 명확성이 가장 중요하다

  이름만 보고도 클래스의 역할을 유추할 수 있어야 한다.

 

 

 

백그라운드 작업을 담당하는 (e.g. 데몬프로세스)의 경우

이름	의미	사용 예시
Daemon	백그라운드에서 무한히 실행되는 프로세스	LogCleanerDaemon
Worker	작업을 지속적으로 처리하는 스레드/프로세스	BackgroundWorker
Listener (혹은 PollingService)	이벤트 또는 메시지를 기다리며 무한 루프로 동작하는 스레드/프로세스 (e.g. 소켓 listener)	MesaageListener
Poller	Poll하는 작업이 들어가는 데몬	NetworkPoller
Scheduler	주기적 작업을 수행하는 데몬	TaskScheduler
BackgroundService	특정 프레임워크에서 제공되는 백그라운드 서비스
Server	(기능에 초점을 맞춤) 특정 상위 프로토콜이나 서비스를 제공하는 서버	HttpServer MQTTServer GameServer
Listener	(위의 Listener와 비슷한 의미로 쓰이며) (프로토콜에 초점을 맞춤) TCP의 경우 특정 포트에서 연결을 기다리는 서버	TcpListener
Broker	메시지/연결 중개 (e.g. 메시지 큐, 채팅 서버)	MessageBroker

 

주의사항

- 프레임워크 컨벤션이 있을 수 있으니 그것을 따르는게 좋다.

e.g. Spring의 @Scheduled,  Go의 goroutine, Python의 Thread

- 리소스 관리를 이름에 반영할 수 있다.

e.g. ResourceMonitorDaemon (리소스 감시용)

- 무한 루프는 명시적 종료 로직이 있어야 한다

e.g. shutdown() 메서드 추가

- 의도가 드러나는 이름을 선택하는게 좋다.

Bad:  LoopClass   Good: HeartbeatChecker (기능이 명확)

 

Server의 경우

- Server 클래스는 네트워크 통신과 비즈니스 로직을 분리하는게 좋다..

e.g. HttpServer는 연결 관리만, ReqeustHandler는 로직 처리

- 동시성 처리 의미를 담는 것도 고려하면 좋다. 즉, 멀티스레드/이벤트 루프 모델을 이름에 반영한다.

e.g. AsyncHttpServer,  ThreadPooledServer