ABAP 클린 코드 - Class 클래스 (생성자) [9-3]

“CREATE OBJECT 대신에 NEW를 사용하라”는 최신 ABAP 문법에서 객체 생성 시 더 간결하고 직관적인 방법인 NEW 키워드를 사용하라는 지침입니다. NEW는 SAP NetWeaver 7.4 이후부터 도입된 구문으로, CREATE OBJECT를 대체하는 역할을 하며, 코드 가독성을 높이고 간결하게 만드는 데 도움이 됩니다.

 

CREATE OBJECT와 NEW의 차이점

 

CREATE OBJECT

• 객체를 생성할 때 사용되는 전통적인 구문입니다. CREATE OBJECT는 명시적으로 객체를 생성하고, 오류 처리(RAISE EXCEPTION)를 통해 객체 생성 시 발생할 수 있는 오류를 처리할 수 있습니다.

* CREATE OBJECT
DATA: lo_object TYPE REF TO lcl_class.
CREATE OBJECT lo_object.

 

NEW

• NEW는 SAP의 최신 구문으로, 객체를 생성하는 간결한 방식입니다. CREATE OBJECT와 달리 별도의 변수를 선언하지 않고, 바로 인스턴스를 생성할 수 있습니다. 또한, 객체 생성 후 바로 해당 객체의 메서드나 속성에 접근할 수 있습니다.

* NEW
DATA(lo_object) = NEW lcl_class( ).

 

NEW를 사용하는 이유

 

1. 간결성

• NEW 구문은 객체 생성을 더 간단하게 만듭니다. CREATE OBJECT는 별도로 객체 참조 변수를 선언하고, 객체 생성 명령을 작성해야 하지만, NEW는 이를 한 줄로 처리할 수 있습니다.

* CREATE OBJECT 사용
DATA: lo_object TYPE REF TO lcl_class.
CREATE OBJECT lo_object.

* NEW 사용
DATA(lo_object) = NEW lcl_class( ).

 

2. 객체 생성 후 즉시 사용 가능

• NEW를 사용하면 객체를 생성하자마자 바로 메서드 호출이나 속성 접근이 가능합니다. 이를 통해 중간 변수를 사용하지 않고 객체를 사용할 수 있어 코드의 가독성을 높입니다.

NEW lcl_class( )->do_something( ).

 

3. 타입 추론

• NEW는 선언 시 자동으로 타입을 추론할 수 있습니다. 예를 들어, 클래스의 타입을 명시하지 않아도 자동으로 참조 타입이 결정됩니다.

DATA(lo_object) = NEW #( ).

 

4. 생성자 인수 전달의 간편함:

• NEW를 사용하면 객체 생성 시 생성자에 인수를 전달하는 것도 더 간단하게 표현할 수 있습니다. 생성자를 호출하면서 초기화 로직을 처리할 수 있습니다.

DATA(lo_object) = NEW lcl_class( iv_param = 'value' ).

 

5. 내부 테이블에서 객체 생성

• NEW를 사용하면 객체를 쉽게 내부 테이블에 추가할 수 있습니다. APPEND NEW 구문을 사용하여 객체를 직접 테이블에 삽입할 수 있습니다.

APPEND NEW lcl_class( iv_param = 'value' ) TO lt_table.

 

CREATE OBJECT를 사용할 때 고려할 사항

 

1. 오류 처리

• CREATE OBJECT는 객체 생성 중에 발생할 수 있는 예외를 명시적으로 처리할 수 있습니다. 따라서 예외 처리(예: RAISE EXCEPTION)가 필요한 경우 CREATE OBJECT를 사용하는 것이 더 적합할 수 있습니다.

CREATE OBJECT lo_object
  EXPORTING iv_param = 'value'
  EXCEPTIONS
    others = 1.

 

2. 특정 기능을 필요로 할 때

• NEW는 간결하지만, CREATE OBJECT 구문이 필요할 수 있는 특정한 기능, 예를 들어, 팩토리 메서드 패턴이나 별도의 초기화 로직이 필요한 경우에는 CREATE OBJECT를 사용할 수 있습니다.

"CREATE OBJECT 대신에 `NEW`를 사용하라"는 최신 ABAP 문법에서 객체를 생성할 때, 간결하고 가독성 좋은 `NEW` 구문을 사용하는 것이 더 바람직하다는 의미입니다. `NEW`는 코드의 간결성을 높이고, 객체 생성 후 바로 사용할 수 있는 장점을 제공하지만, 오류 처리와 같은 특정한 상황에서는 여전히 `CREATE OBJECT`가 필요할 수 있습니다. 코드의 맥락에 따라 적절한 구문을 선택하는 것이 중요합니다.

 

“전역 클래스가 CREATE PRIVATE라면 생성자를 PUBLIC으로 놔두어라”는 지침은 ABAP에서 전역 클래스를 사용할 때, 클래스 인스턴스화를 제한하고자 CREATE PRIVATE로 설정한 경우에도, 생성자는 PUBLIC으로 설정해야 한다는 의미입니다. 이 지침은 클래스의 설계를 명확히 하고, 특히 팩토리 메서드 패턴과 같은 디자인 패턴을 사용할 때 혼동을 줄이기 위해 중요합니다.

 

CREATE PRIVATE와 생성자의 관계

 

1. CREATE PRIVATE

• 클래스 정의 시 CREATE PRIVATE로 설정하면, 해당 클래스를 외부에서 직접 인스턴스화할 수 없습니다. 즉, CREATE OBJECT 또는 NEW 구문을 통해 외부에서 객체를 생성할 수 없으며, 클래스 내부에서만 객체를 생성할 수 있습니다.
• 이 접근 제한자는 클래스의 인스턴스 생성 방식을 제어할 때 사용됩니다. 주로 팩토리 메서드 패턴을 구현할 때, 클래스 인스턴스화의 통제를 위해 사용됩니다.

2. 생성자(Constructor)

• 생성자는 클래스의 객체가 생성될 때 자동으로 호출되는 메서드로, 객체 초기화를 담당합니다. 생성자는 PUBLIC, PROTECTED, PRIVATE 등 다양한 접근 제어자를 가질 수 있습니다.
• 일반적으로, CREATE PRIVATE로 설정된 클래스에서는 생성자도 PRIVATE이나 PROTECTED로 설정되기 쉽습니다. 그러나 생성자를 PUBLIC으로 설정하는 것이 더 적합한 경우가 많습니다.

생성자를 PUBLIC으로 설정해야 하는 이유

 

1. 팩토리 메서드 패턴과의 호환성

• 팩토리 메서드 패턴은 객체 생성 로직을 캡슐화하고, 특정 조건에 따라 객체 생성 과정을 제어하는 디자인 패턴입니다. 이 패턴에서는 클래스 내부에서 객체를 생성한 후 반환하는 메서드(팩토리 메서드)를 사용합니다.
• CREATE PRIVATE는 클래스 외부에서 객체를 직접 생성할 수 없도록 제한하지만, 클래스 내부에서는 여전히 생성자가 호출될 수 있어야 합니다. 이때, 생성자가 PUBLIC으로 설정되어 있어야 팩토리 메서드 내에서 생성자를 호출할 수 있습니다.

2. 명확한 설계

• CREATE PRIVATE로 클래스의 인스턴스화를 제한한 경우, 생성자는 여전히 객체 초기화 로직을 담당하므로 PUBLIC 접근 제어자가 적합합니다. 이로써 클래스 내부에서 생성자를 호출할 수 있으며, 객체 초기화 로직이 올바르게 수행될 수 있습니다.
• 생성자가 PUBLIC으로 남아 있으면, 클래스 내부 로직에서 객체를 생성하는 코드와의 일관성을 유지할 수 있으며, 외부에서 생성자가 호출되지 않도록 하면서도 내부에서는 자유롭게 사용할 수 있습니다.

3. 객체 생성 로직의 유연성

• 생성자가 PUBLIC으로 설정되어 있으면, 클래스 내부에서 객체 생성 로직을 더 유연하게 설계할 수 있습니다. 예를 들어, 다양한 팩토리 메서드에서 서로 다른 생성자 인수를 사용하여 객체를 생성할 수 있습니다.
• PUBLIC 생성자는 테스트 코드에서 유용할 수 있습니다. 테스트 코드에서는 객체를 쉽게 생성하고 다양한 초기화 조건을 확인할 수 있습니다.

* 잘못된 패턴 - PRIVATE 
CLASS lcl_my_class DEFINITION CREATE PRIVATE.
  PRIVATE SECTION.
    METHODS: constructor IMPORTING iv_param TYPE string.
ENDCLASS.

CLASS lcl_my_class IMPLEMENTATION.
  METHOD constructor.
*     객체 초기화 로직
  ENDMETHOD.

*   객체를 생성할 수 없음 - 생성자가 PRIVATE
ENDCLASS.

 

* 올바른 패턴 - PUBLIC
CLASS lcl_my_class DEFINITION CREATE PRIVATE.
  PUBLIC SECTION.
    METHODS: constructor IMPORTING iv_param TYPE string,
             get_instance RETURNING VALUE(ro_instance) TYPE REF TO lcl_my_class.
ENDCLASS.

CLASS lcl_my_class IMPLEMENTATION.
  METHOD constructor.
*     객체 초기화 로직
  ENDMETHOD.

  METHOD get_instance.
    CREATE OBJECT ro_instance
      EXPORTING iv_param = 'example'.
  ENDMETHOD.
ENDCLASS.

 

“전역 클래스가 CREATE PRIVATE라면 생성자를 PUBLIC으로 놔두어라”는 지침은 클래스의 인스턴스화를 외부에서 제한할 때에도, 생성자를 PUBLIC으로 설정하여 클래스 내부에서 객체를 유연하게 생성할 수 있도록 하라는 의미입니다. 이는 팩토리 메서드 패턴과 같은 디자인 패턴을 올바르게 구현하고, 클래스의 설계를 명확하게 유지하는 데 중요한 역할을 합니다.

 

“선택적 파라미터보다 여러 정적인 생성 메서드를 사용하라”는 객체 생성 시 선택적 파라미터를 통해 다양한 경우를 처리하는 것보다 여러 개의 정적 생성 메서드를 사용해 더 명확하고 의도적으로 객체를 생성하라는 의미입니다. 이 지침은 가독성을 높이고, 코드의 명확성을 유지하며, 다양한 생성 로직을 구분하여 관리하기 위한 객체지향 설계 원칙입니다.

 

선택적 파라미터와 정적 생성 메서드의 차이점

 

선택적 파라미터(Optional Parameters)

• 생성자나 메서드에서 파라미터에 기본값을 제공하여, 호출 시 선택적으로 인수를 전달할 수 있도록 하는 방식입니다.
• 선택적 파라미터를 사용하면 다양한 경우를 하나의 메서드에서 처리할 수 있습니다.

* 선택적 파라미터
CLASS lcl_person DEFINITION.
  PUBLIC SECTION.
    METHODS: constructor IMPORTING iv_name TYPE string DEFAULT 'Unknown'
                              iv_age  TYPE i DEFAULT 0.
  PRIVATE SECTION.
    DATA: name TYPE string,
          age  TYPE i.
ENDCLASS.

CLASS lcl_person IMPLEMENTATION.
  METHOD constructor.
    name = iv_name.
    age = iv_age.
  ENDMETHOD.
ENDCLASS.

DATA(lo_person) = NEW lcl_person( ).
DATA(lo_person_named) = NEW lcl_person( iv_name = 'John' ).

 

정적 생성 메서드(Static Factory Methods)

• 클래스에서 여러 개의 정적 메서드를 정의하여, 각 메서드가 서로 다른 방식으로 객체를 생성하는 방식입니다. 생성 메서드의 이름을 통해 객체 생성의 의도를 명확히 전달할 수 있습니다.

* 정적 생성 메서드
CLASS lcl_person DEFINITION.
  PUBLIC SECTION.
    CLASS-METHODS: create_default RETURNING VALUE(ro_person) TYPE REF TO lcl_person,
                   create_named IMPORTING iv_name TYPE string
                                RETURNING VALUE(ro_person) TYPE REF TO lcl_person.
  PRIVATE SECTION.
    METHODS: constructor IMPORTING iv_name TYPE string DEFAULT 'Unknown'
                                 iv_age  TYPE i DEFAULT 0.
    DATA: name TYPE string,
          age  TYPE i.
ENDCLASS.

CLASS lcl_person IMPLEMENTATION.
  METHOD constructor.
    name = iv_name.
    age = iv_age.
  ENDMETHOD.

  METHOD create_default.
    CREATE OBJECT ro_person
      EXPORTING iv_name = 'Unknown'
                iv_age  = 0.
  ENDMETHOD.

  METHOD create_named.
    CREATE OBJECT ro_person
      EXPORTING iv_name = iv_name.
  ENDMETHOD.
ENDCLASS.

DATA(lo_person_default) = lcl_person=>create_default( ).
DATA(lo_person_named) = lcl_person=>create_named( iv_name = 'John' ).

 

왜 정적 생성 메서드를 사용하는 것이 더 나은가?

 

1. 명확성

• 정적 생성 메서드는 이름을 통해 그 메서드가 어떤 상황에서 객체를 생성하는지 명확하게 전달할 수 있습니다. 각 메서드의 이름은 그 메서드가 어떤 생성 과정을 수행하는지 직관적으로 알려줍니다.
• 선택적 파라미터를 사용하면 생성자가 어떤 의도로 호출되는지 불분명할 수 있습니다. 예를 들어, 선택적 파라미터를 여러 개 사용하면 호출자가 어떤 파라미터를 전달하고 있는지 직관적으로 알기 어렵습니다.

2. 유지보수 용이성

• 정적 생성 메서드를 사용하면, 각 메서드가 특정한 생성 로직만 담당하기 때문에, 코드의 수정 및 유지보수가 쉬워집니다. 새로운 생성 로직이 필요할 때도 기존 메서드에 복잡한 조건문을 추가하는 대신, 새로운 정적 메서드를 추가하면 됩니다.
• 선택적 파라미터를 사용하면, 생성 로직이 점점 더 복잡해질 수 있으며, 조건문이 많아지면서 유지보수가 어려워질 수 있습니다.

3. 오류 방지

• 정적 생성 메서드는 객체 생성 시 필요한 인수를 명확하게 전달받기 때문에, 누락된 필수 인수나 잘못된 조합으로 인해 발생할 수 있는 오류를 줄일 수 있습니다.
• 선택적 파라미터를 사용할 경우, 호출자가 잘못된 인수 조합을 사용해도 코드에서 이를 감지하기 어렵고, 논리적 오류가 발생할 가능성이 높아집니다.

4. 확장성

• 정적 생성 메서드를 사용하면 새로운 생성 로직을 추가하기가 쉽습니다. 새로운 메서드를 정의함으로써 기존 메서드를 건드리지 않고도 기능을 확장할 수 있습니다.
• 선택적 파라미터로 확장하려면 조건문이 늘어나고, 생성자가 복잡해질 수 있습니다.

5. 테스트 용이성

• 정적 생성 메서드를 사용하면, 각 메서드를 독립적으로 테스트할 수 있습니다. 이를 통해 다양한 생성 시나리오를 별도로 검증할 수 있습니다.
• 선택적 파라미터의 경우, 다양한 경우의 조합을 하나의 메서드에서 처리해야 하므로 테스트 케이스가 복잡해질 수 있습니다.

“선택적 파라미터보다 여러 정적인 생성 메서드를 사용하라”는 선택적 파라미터를 사용하여 객체 생성 로직을 처리하는 것보다, 명확한 의도를 가진 여러 개의 정적 생성 메서드를 사용하여 객체 생성을 처리하라는 의미입니다. 이를 통해 코드의 명확성, 가독성, 유지보수성, 테스트 용이성을 높일 수 있습니다. 선택적 파라미터는 간단한 경우에 유용할 수 있지만, 객체 생성 로직이 복잡해질 때는 정적 생성 메서드를 사용하는 것이 더 적합합니다.

 

“여러 생성 메서드를 만들 때는 서술적인 이름을 사용하라”는 객체 지향 설계에서 생성 메서드(Factory Methods)를 정의할 때, 메서드의 이름이 해당 메서드가 객체를 어떻게 생성하는지 또는 어떤 상황에서 사용해야 하는지 명확히 나타내도록 서술적인 이름을 사용하라는 의미입니다. 서술적인 이름을 사용하면 코드의 가독성과 유지보수성이 크게 향상됩니다.

 

1. 가독성 향상

• 메서드 이름만으로도 해당 메서드가 어떤 역할을 수행하는지 쉽게 이해할 수 있습니다. 서술적인 이름은 코드를 읽는 사람이 추가적인 설명 없이도 메서드의 목적을 파악하는 데 도움을 줍니다.
• 예를 들어, create_default_car()와 같은 이름은 기본 차량을 생성한다는 의도를 명확히 전달합니다. 반면에, create()와 같은 일반적인 이름은 메서드가 어떤 역할을 하는지 파악하기 어렵습니다.

2. 명확한 의도 전달

• 서술적인 이름은 메서드의 의도를 명확히 전달합니다. 예를 들어, create_admin_user()라는 이름은 이 메서드가 관리자 사용자 객체를 생성한다는 것을 분명히 알려줍니다. 이는 코드의 목적을 명확하게 전달할 수 있기 때문에, 개발자들이 코드를 이해하고 사용하는 데 큰 도움이 됩니다.

3. 유지보수 용이성

• 서술적인 이름은 코드가 변경되거나 유지보수될 때, 코드의 역할을 쉽게 이해할 수 있게 합니다. 이를 통해 새로운 기능을 추가하거나 기존 기능을 수정할 때 혼란을 줄일 수 있습니다.
• 메서드 이름만 보고도 수정이 필요한 부분을 쉽게 파악할 수 있기 때문에, 개발자는 더 효율적으로 작업할 수 있습니다.

4. 오류 방지

• 서술적인 이름은 잘못된 메서드를 호출하는 오류를 방지하는 데 도움이 됩니다. 이름이 구체적일수록 어떤 메서드를 호출해야 할지 명확히 알 수 있기 때문에, 잘못된 객체 생성을 방지할 수 있습니다.

* 잘못된 패턴
CLASS lcl_vehicle DEFINITION.
  PUBLIC SECTION.
    CLASS-METHODS: create_car,
                   create_truck.
ENDCLASS.

 

* 올바른 패턴
CLASS lcl_vehicle DEFINITION.
  PUBLIC SECTION.
    CLASS-METHODS: create_standard_car,  " 표준 자동차 생성
                   create_electric_car, " 전기 자동차 생성
                   create_large_truck,  " 대형 트럭 생성
                   create_small_truck.  " 소형 트럭 생성
ENDCLASS.

 

서술적인 이름을 만들 때 고려해야 할 사항

 

1. 구체적인 역할 설명

• 메서드 이름은 해당 메서드가 구체적으로 무엇을 하는지를 설명해야 합니다. 이름에서 메서드의 목적을 파악할 수 있어야 하며, 가능하면 동사와 명사를 조합해 구체적인 행동과 결과를 나타내는 것이 좋습니다.
• 예시: create_guest_user_with_trial_period (체험 기간이 있는 게스트 사용자 생성)

2. 일관성 유지

• 메서드 이름은 클래스 내에서 일관성을 유지해야 합니다. 동일한 클래스 내에서 메서드 이름의 패턴을 유지하면, 코드의 일관성과 가독성이 높아집니다.
• 예시: create_standard_user, create_admin_user, create_guest_user와 같이, 사용자 생성 메서드들은 동일한 패턴을 따릅니다.

3. 불필요한 축약 피하기

• 축약된 이름보다는 명확한 이름을 사용해야 합니다. 축약어는 처음에는 편리할 수 있지만, 나중에 코드의 의미를 이해하는 데 어려움을 줄 수 있습니다. 가능한 한 축약 없이 메서드의 목적을 명확히 표현하는 것이 좋습니다.
• 잘못된 예시: crt_std_usr (이해하기 어려움)
• 올바른 예시: create_standard_user (이해하기 쉬움)

4. 도메인 언어 사용

• 도메인과 관련된 용어를 사용하여 메서드의 역할을 설명하면, 해당 도메인에 익숙한 개발자들이 코드를 쉽게 이해할 수 있습니다. 도메인 용어를 적절히 사용하면 메서드의 역할을 더 명확히 전달할 수 있습니다.
• 예시: create_vip_member (VIP 회원 생성)

“여러 생성 메서드를 만들 때는 서술적인 이름을 사용하라”는 각 메서드가 객체를 생성하는 방식이나 상황을 명확히 설명할 수 있는 이름을 사용하여, 코드의 가독성, 유지보수성, 그리고 의도를 쉽게 전달할 수 있도록 하라는 의미입니다. 서술적인 이름은 메서드가 어떤 역할을 하는지 명확하게 전달함으로써 코드 작성자뿐만 아니라 코드 사용자도 더 쉽게 이해하고 사용할 수 있게 합니다.

 

“여러 인스턴스가 있는 곳에서만 싱글톤을 만드는 것은 말이 되지 않는다”는 싱글톤 패턴의 본질에 대한 지침입니다. 이 말은 싱글톤(Singleton) 패턴의 목적이 하나의 클래스에 대해 오직 하나의 인스턴스만 존재하도록 보장하는 것인데, 여러 인스턴스가 생성될 수 있는 상황에서는 싱글톤 패턴을 사용하는 것이 적합하지 않다는 의미입니다.

 

싱글톤 패턴의 목적

 

싱글톤 패턴은 특정 클래스의 인스턴스가 애플리케이션 전체에서 단 하나만 존재해야 할 때 사용됩니다. 이 패턴을 사용하면 해당 클래스의 인스턴스를 전역적으로 접근할 수 있으며, 동일한 인스턴스를 여러 곳에서 사용할 수 있습니다. 싱글톤 패턴의 주요 목적은 하나의 객체만 생성하고, 그 객체를 공유하여 사용하는 것입니다.

 

싱글톤 패턴의 특징

1. 단일 인스턴스: 클래스의 인스턴스가 하나만 존재하도록 보장합니다.
2. 글로벌 접근: 애플리케이션 내 어디에서든지 동일한 인스턴스에 접근할 수 있습니다.
3. 객체 공유: 동일한 객체를 여러 곳에서 사용함으로써 자원을 절약하고, 상태를 일관되게 유지할 수 있습니다.

왜 여러 인스턴스가 있는 곳에서 싱글톤을 사용하면 안 되는가?

 

1. 싱글톤의 본질을 위배

• 싱글톤 패턴의 핵심은 하나의 인스턴스를 공유하는 것입니다. 만약 여러 인스턴스가 생성될 수 있는 환경에서 싱글톤 패턴을 적용하면, 패턴의 목적이 손상됩니다. 여러 인스턴스가 생성될 수 있다면 더 이상 그것은 싱글톤이 아니며, 단일 인스턴스라는 싱글톤 패턴의 이점을 누릴 수 없습니다.

2. 설계의 혼란

• 여러 인스턴스가 존재하는 클래스에서 싱글톤 패턴을 사용하는 것은 설계상의 혼란을 초래할 수 있습니다. 다른 개발자들이 해당 클래스가 싱글톤으로 설계되었음을 예상하고 사용할 수 있으며, 이로 인해 예상하지 못한 동작이나 버그가 발생할 수 있습니다.

3. 상태 공유 문제

• 싱글톤 패턴을 사용하면 하나의 인스턴스가 애플리케이션 전체에서 상태를 공유하게 됩니다. 만약 여러 인스턴스가 존재한다면 각 인스턴스는 서로 다른 상태를 가질 수 있으므로, 이를 싱글톤으로 처리하면 상태 관리에 혼란이 발생할 수 있습니다.
• 설정이나 캐시 관리와 같은 글로벌 상태를 유지하려면 싱글톤이 적합하지만, 각기 다른 상태를 유지해야 하는 개별적인 객체들에 대해 싱글톤을 적용하면 문제가 생길 수 있습니다.

4. 유지보수의 어려움

• 싱글톤 패턴을 남용하면 유지보수가 어려워질 수 있습니다. 만약 특정 클래스가 싱글톤으로 설계되었는데, 실제로는 여러 인스턴스를 생성해야 하는 경우라면, 코드를 수정하는 데 많은 노력이 필요할 수 있습니다.
• 여러 인스턴스를 생성할 필요가 있는 클래스는 싱글톤으로 설계하기보다는, 적절한 객체 생성 패턴(예: 팩토리 패턴)을 사용하여 관리하는 것이 좋습니다.

* 잘못된 패턴
CLASS lcl_config DEFINITION.
  PUBLIC SECTION.
    CLASS-METHODS: get_instance RETURNING VALUE(ro_instance) TYPE REF TO lcl_config.
    METHODS: get_value RETURNING VALUE(rv_value) TYPE string.
  PRIVATE SECTION.
    DATA: config_value TYPE string.
    CLASS-DATA: instance TYPE REF TO lcl_config.
ENDCLASS.

CLASS lcl_config IMPLEMENTATION.
  METHOD get_instance.
    IF instance IS INITIAL.
      CREATE OBJECT instance.
      instance->config_value = 'Default Config'.
    ENDIF.
    ro_instance = instance.
  ENDMETHOD.

  METHOD get_value.
    rv_value = config_value.
  ENDMETHOD.
ENDCLASS.

 

* 올바른 패턴
CLASS lcl_config_factory DEFINITION.
  PUBLIC SECTION.
    CLASS-METHODS: create_config IMPORTING iv_type TYPE string
                                 RETURNING VALUE(ro_config) TYPE REF TO lcl_config.
ENDCLASS.

CLASS lcl_config_factory IMPLEMENTATION.
  METHOD create_config.
    CREATE OBJECT ro_config.
    IF iv_type = 'Default'.
      ro_config->set_value( 'Default Config' ).
    ELSEIF iv_type = 'Custom'.
      ro_config->set_value( 'Custom Config' ).
    ENDIF.
  ENDMETHOD.
ENDCLASS.

 

“여러 인스턴스가 있는 곳에서만 싱글톤을 만드는 것은 말이 되지 않는다”는 싱글톤 패턴의 목적을 잘못 이해하고 사용하지 말라는 의미입니다. 싱글톤은 특정 클래스의 인스턴스를 하나만 유지해야 할 때 적합하며, 여러 인스턴스가 필요할 경우에는 다른 패턴을 사용해야 합니다. 설계 시 클래스의 역할과 인스턴스 관리 방식을 명확히 정의하고, 싱글톤 패턴이 적합한지 신중히 고려하는 것이 중요합니다.