들어오는 매개 변수를 수정하는 것이 반 패턴입니까? [닫은]

Java로 프로그래밍하고 있으며 항상 다음과 같은 변환기를 만듭니다.

public OtherObject MyObject2OtherObject(MyObject mo){
    ... Do the conversion
    return otherObject;
}

새로운 직장에서 패턴은 다음과 같습니다.

public void MyObject2OtherObject(MyObject mo, OtherObject oo){
    ... Do the conversion
}

들어오는 매개 변수를 변경하지 않는 데 익숙해 져서 약간 냄새가납니다. 이 수신 매개 변수 변경이 반 패턴입니까? 심각한 결점이 있습니까?

반 패턴이 아니며 나쁜 습관입니다.

안티 패턴과 단순한 나쁜 습관의 차이점은 여기에 있습니다 : 안티 패턴 정의 .

Uncle Bob의 Clean Code에 따르면, 새로운 직장 스타일은 나쁜 습관 , 흔적 또는 OOP 이전 시간입니다.

인수는 가장 자연스럽게 함수에 대한 입력으로 해석됩니다.

함수 서명을 강제로 확인하는 것은 이중 테이크와 같습니다. 인지 적 휴식이므로 피해야합니다. 객체 지향 프로그래밍 이전에는 때로는 출력 인수가 필요했습니다. 그러나 OO 언어에서는 출력 인수가 필요하지 않습니다.

Robert C. Martin의 유명한 저서 "Clean Code"인용 :

출력 인수는 피해야합니다

함수는 적은 수의 인수를 가져야합니다

두 번째 패턴은 두 규칙, 특히 "출력 인수"규칙을 모두 위반합니다. 이런 의미에서 첫 번째 패턴보다 나쁩니다.

두 번째 관용구는 더 빠를 수 있습니다. 호출자가 새 인스턴스를 생성 할 때마다 긴 루프 대신 하나의 변수를 재사용 할 수 있기 때문입니다.

나는 일반적으로 사용하지 않지만 예를 들어. 게임 프로그래밍에서 그 자리가 있습니다. 예를 들어 JavaMonkey의 Vector3f 많은 연산을 통해 수정하고 결과로 반환 해야하는 인스턴스를 전달할 수 있습니다.

나는 그것들이 두 개의 동등한 코드 조각이라고 생각하지 않습니다. 첫 번째 경우을 만들어야합니다 otherObject. 두 번째에서 기존 인스턴스를 수정할 수 있습니다. 둘 다 사용하고 있습니다. 코드 냄새가 다른 것을 선호합니다.

언어에 따라 다릅니다.

Java에서 두 번째 형식은 안티 패턴 일 수 있지만 일부 언어는 매개 변수 전달을 다르게 처리합니다. 대신 패스 값 또는 참조하여 예 및 아다 VHDL에서는 파라미터 모드를 가질 수있다 in, out또는 in out.

in매개 변수 를 수정하거나 매개 변수를 읽는 것은 오류 out이지만 매개 변수의 변경 사항 in out은 호출자에게 다시 전달됩니다.

따라서 Ada의 두 가지 형식 (이것은 합법적 인 VHDL입니다)

function MyObject2OtherObject(mo : in MyObject) return OtherObject is
begin
    ... Do the conversion
    return otherObject;
end MyObject2OtherObject;

과

procedure MyObject2OtherObject(mo : in MyObject; oo : out OtherObject) is
begin
    ... Do the conversion
    oo := ... the conversion result;
end MyObject2OtherObject;

둘 다 그들의 용도가있다; 프로시 저는 여러 Out매개 변수 로 여러 값을 리턴 할 수 있지만 함수는 단일 결과 만 리턴 할 수 있습니다. 두 번째 매개 변수의 목적은 프로 시저 선언에 명확하게 명시되어 있으므로이 양식에 반대 할 수 없습니다. 가독성을 선호하는 경향이 있습니다. 그러나 호출자가 이미 객체를 만든 경우와 같이 절차가 더 나은 경우가 있습니다.

그것은 실제로 냄새가 나는 것처럼 보이며 더 많은 맥락을 보지 않으면 확실히 말할 수 없습니다. 두 가지 방법이 있지만 두 가지 이유가있을 수 있습니다.

첫째, 부분 변환을 구현하거나 변환이 실패 할 경우 결과를 기본값으로 유지하는 간결한 방법입니다. 즉, 당신은 이것을 가질 수 있습니다 :

public void ConvertFoo(Foo from, Foo to) {
    if (can't convert) {
        return;
    }
    ...
}

Foo a;
Foo b = DefaultFoo();
ConvertFoo(a, b);
// If conversion fails, b is unchanged

물론 일반적으로 예외를 사용하여 처리됩니다. 그러나 어떤 이유로 든 예외를 피해야하는 경우에도 TryParse 패턴 이 하나의 옵션 인 더 좋은 방법이 있습니다.

또 다른 이유는 순전히 일관성있는 이유 일 수 있기 때문입니다. 예를 들어이 메소드는 어떤 이유로 든 모든 변환 함수 (예 : 다중 출력을 갖는 다른 변환 함수)에 사용되는 공용 API의 일부입니다.

Java는 여러 출력을 처리하는 데별로 좋지 않습니다. 일부 언어와 같은 출력 전용 매개 변수를 사용하거나 다른 언어와 같은 여러 반환 값을 가질 수는 없지만 여전히 반환 객체를 사용할 수 있습니다.

일관성 이유는 다소 절충 적이지만 슬프게도 가장 일반적 일 수 있습니다.

• 직장 또는 코드베이스의 스타일 경찰은 Java 이외의 배경에서 왔으며 변경하기를 꺼려했습니다.
• 귀하의 코드는이 스타일이 더 관용적 인 언어의 포트 일 수 있습니다.
• 조직은 여러 언어에 걸쳐 API 일관성을 유지해야 할 수 있으며 이는 가장 낮은 공통 분모 스타일입니다 (불분명하지만 Google에서도 발생합니다 ).
• 또는 스타일이 먼 과거에 더 의미가 있었고 현재 형식으로 변형되었습니다 (예 : TryParse 패턴 일 수는 있지만 의도가 좋은 전임자는 아무도 그것을 확인하지 않은 것을 발견 한 후 반환 값을 제거했습니다).

두 번째 패턴의 장점은 호출자가 생성 된 객체에 대한 소유권과 책임을지게한다는 것입니다. 메소드가 오브젝트를 작성했는지 또는 재사용 가능한 풀에서 가져 왔는지 여부는 의문의 여지가 없습니다. 호출자는 새 객체의 수명과 폐기에 대한 책임이 있음을 알고 있습니다.

이 방법의 단점은 다음과 같습니다.

1. 팩토리 메소드로 사용할 수 없으므로 호출자는 OtherObject필요한 서브 타입을 정확히 알고 미리 구성해야합니다.
2. 해당 매개 변수가 생성 된 경우 생성자에 매개 변수가 필요한 개체와 함께 사용할 수 없습니다 MyObject. OtherObject에 대해 몰라도 구성 할 수 있어야합니다 MyObject.

대답은 C #에서의 경험을 기반으로하며, 논리가 Java로 변환되기를 바랍니다.

의미가 느슨 하면 첫 번째 개체에서 두 번째 개체 myObjectToOtherObject로 일부 데이터 를 이동 하거나 완전히 새로 변환한다는 의미 일 수 있습니다. 두 번째 방법이 더 적합 해 보입니다.

그러나 메소드 이름이 Convert( "... 변환을 수행하십시오"부분을 보면) 두 번째 메소드가 의미가 없다고 말할 수 있습니다. 값을 이미 존재하는 다른 값인 IMO로 변환하지 않습니다.