작성
·
462
·
수정됨
1
학습 관련 질문을 남겨주세요. 어떤 부분이 고민인지, 무엇이 문제인지 상세히 작성하면 더 좋아요!
먼저 유사한 질문이 있었는지 검색해 보세요.
서로 예의를 지키며 존중하는 문화를 만들어가요.
안녕하세요!
static 메소드 사용 기준이 궁금합니다!
제가 알기로는 static메소드가 대표적으로 아래 3가지 이유 때문에 최대한 쓰지말라는 말을 들었는데요!
1. 절차지향적이라 캡슐화에 위반된다.
클래스로딩시점에 바로 올라가서 GC가 제거할 수 없는 영역에 있기 때문에 메모리 효율이 떨어진다.
멀티 스레드 환경에서 공유되기 때문에 동시성 이슈가 있다.
16분:17초에 나오는 static의 경우에는 3번에 해당하는건 아니겠지만, 강사님 영상에서 도메인이나 DTO영역에서 비즈니스 로직을 위한 객체 생성용 뿐만 아니라, 테스트 코드에서도 정적메소드로 만드시더라구요!
static 키워드를 사용하는 기준이 언제인지 궁금한데요!
@UtilClass도 내부적으로 static으로 만들어주던데, 비즈니스 로직이 담긴게 아닌 유틸클래스나 객체 생성용이라면 상관이 없는걸까요? 위에서 여쭤봤던 1번과 2번을 고려해야 하는 상황이 언제, 어떤 기준으로 설정 되는건지 궁금합니당..
답변 2
1
안녕하세요, 세진:) 님!
물론 과도한 static 키워드의 사용은 말씀하신 문제들을 야기할 수 있습니다.
굳이 사용하지 않아도 되는 상황에서는 사용하지 않는 것이 좋고, 저는 보통 다음과 같은 상황에 사용합니다.
인스턴스를 생성하는 정적 팩토리 메서드
단순 생성자보다 메서드 이름 등으로 의도를 표현해줄 수가 있어 가독성 등에 도움
유틸 클래스
메모리 효율 측면에서는, 옛날옛적에는(2~30년 전) 하드웨어의 수준을 고려하여 메모리를 극한까지 효율적으로 사용하도록 하는 프로그래밍이 대세였으나, 요즘 하드웨어의 수준은 비약적으로 높아진 수준이기 때문에 오히려 가독성과 유지보수성을 우선적으로 하는 프로그래밍을 추구합니다.
(물론 여전히 메모리 효율을 우선적으로 하는 특정 분야에서는 당연히 메모리 관리가 중요합니다. ex. 임베디드)
남발하는 것이 아니라 위와 같이 기준을 가지고 필요한 경우에 사용할 수 있는 정도는 가능한 것이죠 ㅎㅎ
남발하게 되면 1번과 같은 문제가 발생하는 것도 맞고요.
중요한 것은 3번과 같은 동시성 이슈 때문에, 상태를 가지는 로직에 사용해서는 안 된다는 것입니다.
(그리고 말씀하신 강의 16:17 부분을 찾아보니, 저 부분은 IDE가 메서드를 추출하면서 자동으로 static을 붙여주어서 그런 것 같은데, static일 필요가 없는 부분이라 제거하고 사용해주시면 됩니다 ㅎㅎ)
도움이 되셨기를 바랍니다.
감사합니다 🙂
0
안녕하세요, 인프런 AI 인턴입니다.
static
키워드를 사용하는 기준에 대한 질문에 답변드리겠습니다. 일반적으로 static
키워드는 인스턴스마다 각각 유지될 필요가 없는 공유 데이터나, 인스턴스를 생성하지 않고도 호출할 수 있는 메소드에 사용됩니다. 이와 관련하여 세 가지 주요 측면에서 살펴볼 수 있습니다.
캡슐화와 객체지향적 설계: static
메소드는 객체의 상태에 의존하지 않고, 전역적으로 사용되는 동작을 정의할 때 주로 사용됩니다. 예를 들어, 유틸리티 성격의 함수들(수학 계산, 문자열 처리 등)이 이에 해당합니다. 이러한 경우 객체의 상태를 변경하지 않으므로 캡슐화를 해치지 않습니다.
메모리 효율성: static
필드는 프로그램이 실행될 때 한 번 메모리에 할당되고 프로그램이 종료될 때까지 유지되기 때문에, 불필요한 메모리 사용을 줄이고자 할 때 유용합니다. 다만, 과도한 static
필드 사용은 GC에 의한 메모리 관리를 받지 못해 메모리 누수의 원인이 될 수 있습니다. 따라서 필요한 경우에만 제한적으로 사용하는 것이 좋습니다.
동시성 이슈: static
메소드나 필드는 모든 인스턴스에서 공유되기 때문에, 여러 스레드가 동시에 접근할 때 동기화 문제가 발생할 수 있습니다. 특히 상태를 변경하는 작업을 수행할 경우 주의가 필요합니다. 그러나 static
자체가 항상 동시성 문제를 유발하는 것은 아니며, 동시성 관리를 위한 적절한 동기화(synchronization)를 고려해야 합니다.
테스트 코드에서의 static
사용, 예를 들어 테스트 환경을 구성하는데 사용되는 헬퍼 메소드나 모의 객체(mock objects)를 정의하는 데 static
을 사용하는 것은 일반적으로 문제가 되지 않습니다. 테스트 코드는 어플리케이션 코드와 달리 동시성 이슈나 메모리 효유성이 크게 중요하지 않기 때문에, 테스트의 편의성과 가독성을 높이는 목적으로 static
을 사용할 수 있습니다.
결론적으로, static
키워드의 사용은 그 목적과 사용하는 상황에 따라 달라질 수 있습니다. 유틸리티 클래스나, 상태나 인스턴스에 의존하지 않는 메소드를 구현할 때 static
키워드 사용이 적합할 수 있으멀로, 주어진 상황에서의 필요성과 영향을 고려하여 결정하는 것이 중요합니다.