사용자 정의 객체를 매개 변수로 사용하지 않아야합니까?

사용자 정의 객체 Student 가 있다고 가정합니다 .

public class Student{
    public int _id;
    public String name;
    public int age;
    public float score;
}

그리고 학생의 정보를 표시하는 데 사용되는 Window 클래스 는 다음과 같습니다.

public class Window{
    public void showInfo(Student student);
}

그것은 정상적인 것처럼 보이지만 Window 는 함수를 호출 하는 실제 Student 객체가 필요하기 때문에 개별적으로 테스트하기가 쉽지 않다는 것을 알았 습니다 . 따라서 학생 객체를 직접 허용하지 않도록 showInfo를 수정하려고합니다 .

public void showInfo(int _id, String name, int age, float score);

Window를 개별적 으로 테스트하는 것이 더 쉽습니다 .

showInfo(123, "abc", 45, 6.7);

그러나 수정 된 버전에 다른 문제가 있음을 발견했습니다.

1. 학생 수정 (예 : 새 속성 추가)은 showInfo의 메소드 서명을 수정해야합니다.

2. 만약 학생이 많은 속성을 가지고 있다면, 학생의 방법 서명은 매우 길 것입니다.

따라서 사용자 정의 객체를 매개 변수로 사용하거나 객체의 각 속성을 매개 변수로 사용하면 어느 것이 더 유지 관리가 용이합니까?

사용자 정의 객체를 사용하여 관련 매개 변수를 그룹화하는 것이 실제로 권장되는 패턴입니다. 리팩토링으로서이를 Introduce Parameter Object 라고 합니다.

당신의 문제는 다른 곳에 있습니다. 먼저, generic Window은 Student에 대해 아무것도 몰라 야합니다. 대신, StudentWindow표시 만하는 것에 대해 알고 있어야합니다 Students. 둘째, Student테스트 StudentWindow를 Student극도로 복잡하게 만드는 복잡한 논리가 포함되어 있지 않으면 테스트 할 인스턴스를 만드는 데 아무런 문제 가 없습니다 StudentWindow. 그 논리가 있다면 Student인터페이스 를 만들고 조롱하는 것이 좋습니다.

당신은 그것이

함수를 호출하려면 실제 Student 객체가 필요하기 때문에 개별적으로 테스트하기가 쉽지 않습니다.

그러나 창에 전달할 학생 개체를 만들 수 있습니다.

showInfo(new Student(123,"abc",45,6.7));

전화하기가 훨씬 더 복잡해 보이지는 않습니다.

평신도의 관점에서 :

• 당신이 부르는 "사용자 정의 개체은" 일반적으로 단순히 객체라고합니다.
• 사소하지 않은 프로그램이나 API를 디자인하거나 사소하지 않은 API 또는 라이브러리를 사용할 때 객체를 매개 변수로 전달하는 것을 피할 수 없습니다.
• 객체를 매개 변수로 전달해도됩니다. Java API를 살펴보면 객체를 매개 변수로받는 많은 인터페이스가 표시됩니다.
• 당신과 나 같은 단순한 필사자들에 의해 쓰여진 곳에서 사용하는 라이브러리의 클래스는 우리가 쓰는 것은 "맞춤형" 이 아닙니다 .

편집하다:

따라 @ Tom.Bowen89이 상태는 훨씬 더 복잡은 showInfo 방법을 테스트하지 않는 것입니다 :

showInfo(new Student(8812372,"Peter Parker",16,8.9));

1. 학생 예제에서 showInfo에 전달할 학생을 만들기 위해 Student 생성자를 호출하는 것이 사소한 것으로 가정합니다. 따라서 문제가 없습니다.
2. 예제 학생이이 질문에 대해 의도적으로 사소한 것으로 가정하고 구성하기가 더 어렵다고 가정하면 테스트 double을 사용할 수 있습니다 . Martin Fowler의 기사에서 선택할 수있는 테스트 복식, 모의 품, 스터브 등에 대한 여러 옵션이 있습니다.
3. showInfo 함수를보다 일반화하려면 공용 변수 또는 전달 된 객체의 공용 접근자를 반복하여 모든 것에 대해 표시 논리를 수행 할 수 있습니다. 그런 다음 해당 계약을 준수하는 오브젝트를 전달하면 예상대로 작동합니다. 인터페이스를 사용하기에 좋은 장소입니다. 예를 들어 Showable 또는 ShowInfoable 객체를 showInfo 함수에 전달하면 학생 정보뿐만 아니라 인터페이스를 구현하는 객체 정보도 표시 할 수 있습니다 (물론 전달할 수있는 객체의 특정 또는 일반에 따라 더 나은 이름이 필요함) 학생의 하위 클래스가 무엇인지).
4. 프리미티브를 전달하는 것이 더 쉽고 때로는 성능에 필요할 수도 있지만 유사한 개념을 더 많이 그룹화할수록 일반적으로 코드를 더 잘 이해할 수 있습니다. 주의해야 할 유일한 것은 그것을 과도하게하지 않고 기업의 fizzbuzz로 끝나는 것 입니다.

Code Complete의 Steve McConnell은이 문제를 해결하면서 속성을 사용하는 대신 객체를 메서드에 전달할 때의 이점과 단점에 대해 설명했습니다.

세부 사항 중 일부가 잘못되면 저를 용서하십시오. 책에 액세스 한 지 1 년이 지났으므로 메모리에서 작업하고 있습니다.

그는 객체를 사용하지 않고 메소드에 절대적으로 필요한 속성 만 보내는 것이 좋습니다. 메소드는 조작의 일부로 사용할 특성 외부의 오브젝트에 대해 아무것도 알 필요가 없습니다. 또한 시간이 지남에 따라 객체가 변경되면 객체를 사용하는 방법에 의도하지 않은 결과가 발생할 수 있습니다.

또한 그는 당신이 많은 다른 주장을 받아들이는 방법으로 끝내면 아마도 그 방법이 너무 많은 일을하고 더 작은 방법으로 나뉘어 야한다는 신호 일 것이라고 말했습니다.

그러나 때로는 때로는 많은 매개 변수가 필요합니다. 그가 제공하는 예제는 여러 가지 주소 속성을 사용하여 전체 주소를 작성하는 방법입니다 (생각할 때 문자열 배열을 사용하여 해결할 수는 있음).

전체 객체를 전달하면 테스트를 작성하고 읽는 것이 훨씬 쉽습니다.

public class AStudentView {
    @Test 
    public void displays_failing_grade_warning_when_a_student_with_a_failing_grade_is_shown() {
        StudentView view = aStudentView();
        view.show(aStudent().withAFailingGrade().build());
        Assert.that(view, displaysFailingGradeWarning());
    }

    private Matcher<StudentView> displaysFailingGradeWarning() {
        ...
    }
}

비교하려고,

view.show(aStudent().withAFailingGrade().build());

다음과 같이 값을 별도로 전달하면 줄을 쓸 수 있습니다.

showAStudentWithAFailingGrade(view);

실제 메소드 호출은 다음과 같은 곳에 묻혀 있습니다.

private showAStudentWithAFailingGrade(StudentView view) {
    int someId = .....
    String someName = .....
    int someAge = .....
    // why have been I peeking and poking values I don't care about
    decimal aFailingGrade = .....
    view.show(someId, someName, someAge, aFailingGrade);
}

요컨대, 실제 메소드 호출을 테스트에 넣을 수 없다는 것은 API가 잘못되었다는 신호입니다.

이해가되는 내용, 몇 가지 아이디어를 전달해야합니다.

테스트하기가 더 쉽습니다. 객체를 편집해야하는 경우 리팩토링이 가장 필요한 것은 무엇입니까? 다른 목적으로이 기능을 재사용하는 것이 유용합니까? 이 기능을 수행하기 위해 필요한 최소한의 정보는 무엇입니까? (이 코드를 재사용하면이 코드를 재사용 할 수 있습니다.)이 기능을 만드는 디자인 홀을 떨어 뜨린 다음이 객체를 독점적으로 사용하기 위해 모든 것을 병목 현상에주의하십시오.

이러한 모든 프로그래밍 규칙은 올바른 방향으로 생각할 수 있도록 안내하는 것입니다. 코드 짐승을 만들지 마십시오. 확실하지 않고 진행해야하는 경우 방향 / 자신의 제안 또는 제안을 여기에서 선택하십시오. 방법 '-아마도 돌아가서 쉽게 리팩토링 할 수 있습니다. (예를 들어 Teacher 클래스가있는 경우-Student와 동일한 속성 세트 만 필요하고 Person 양식의 객체를 허용하도록 함수를 변경합니다)

코딩하는 방법 때문에이 기능이 수행하는 작업을보다 쉽게 ​​설명 할 수 있기 때문에 주 객체가 계속 전달되는 경향이 있습니다.

이에 대한 한 가지 일반적인 경로는 두 프로세스 사이에 인터페이스를 삽입하는 것입니다.

public class Student {

    public int id;
    public String name;
    public int age;
    public float score;
}

interface HasInfo {
    public String getInfo();
}

public class StudentInfo implements HasInfo {
    final Student student;

    public StudentInfo(Student student) {
        this.student = student;
    }

    @Override
    public String getInfo() {
        return student.name;
    }

}

public class Window {

    public void showInfo(HasInfo info) {

    }
}

때로는 약간 지저분하지만 내부 클래스를 사용하면 Java에서 조금 더 깔끔해집니다.

interface HasInfo {
    public String getInfo();
}

public class Student {

    public int id;
    public String name;
    public int age;
    public float score;

    public HasInfo getInfo() {
        return new HasInfo () {
            @Override
            public String getInfo() {
                return name;
            }

        };
    }
}

그런 다음 Window가짜 HasInfo객체를 제공 하여 클래스 를 테스트 할 수 있습니다 .

나는 이것이 Decorator Pattern 의 예라고 생각한다 .

추가

코드의 단순성으로 인해 약간의 혼동이있는 것 같습니다. 이 기술을 더 잘 보여줄 수있는 다른 예가 있습니다.

interface Drawable {

    public void Draw(Pane pane);
}

/**
 * Student knows nothing about Window or Drawable.
 */
public class Student {

    public int id;
    public String name;
    public int age;
    public float score;
}

/**
 * DrawsStudents knows about both Students and Drawable (but not Window)
 */
public class DrawsStudents implements Drawable {

    private final Student subject;

    public DrawsStudents(Student subject) {
        this.subject = subject;
    }

    @Override
    public void Draw(Pane pane) {
        // Draw a Student on a Pane
    }

}

/**
 * Window only knows about Drawables.
 */
public class Window {

    public void showInfo(Drawable info) {

    }
}

이미 좋은 답변이 많이 있지만 다음은 대체 솔루션을 볼 수있는 몇 가지 제안입니다.

• 귀하의 예제는 학생 (명확히 모델 객체)이 Window (겉보기 뷰 수준 객체)로 전달되는 것을 보여줍니다. 중개 컨트롤러 또는 발표자 개체가없는 경우 유리할 수 있으므로 사용자 인터페이스를 모델에서 분리 할 수 ​​있습니다. 컨트롤러 / 프레젠터는 UI 테스트를 위해이를 대체하는 데 사용할 수있는 인터페이스를 제공해야하며 인터페이스를 사용하여 모델 오브젝트를 참조하고 테스트 할 두 오브젝트와 분리 할 수 ​​있도록 오브젝트를 볼 수 있어야합니다. 팩토리 객체, 리포지토리 객체 또는 이와 유사한 객체를 생성하거나로드하는 추상적 인 방법을 제공해야 할 수도 있습니다.

• 모델 객체의 관련 부분을 데이터 전송 객체로 전송하는 것은 모델이 너무 복잡해지면 인터페이스에 유용한 접근 방식입니다.

• 학생이 인터페이스 분리 원칙을 위반 한 것일 수 있습니다. 그렇다면 사용하기 쉬운 여러 인터페이스로 분할하는 것이 좋습니다.

• Lazy Loading을 사용하면 큰 개체 그래프를보다 쉽게 ​​구성 할 수 있습니다.

이것은 실제로 괜찮은 질문입니다. 여기서 실제 문제는 "개체"라는 일반적인 용어를 사용하는 것입니다.

일반적으로 고전적인 OOP 언어에서 "개체"라는 용어는 "클래스 인스턴스"를 의미합니다. 클래스 인스턴스는 공용 및 개인 속성 (및 그 사이의 속성), 메서드, 상속, 종속성 등이 상당히 무거울 수 있습니다. 실제로 일부 속성을 전달하기 위해 이와 같은 것을 사용하고 싶지는 않습니다.

이 경우 객체를 컨테이너로 사용하여 단순히 일부 기본 요소를 보유합니다. C ++에서 이와 같은 객체는 structs(그리고 여전히 C #과 같은 언어로 존재합니다)로 알려져 있습니다. 실제로 Structs는 사용자가 사용하는 용도에 맞게 정확하게 설계되었습니다. 논리적 관계가있을 때 관련 개체와 기본 요소를 함께 그룹화했습니다.

그러나 현대 언어에서는 코드를 작성할 때 구조체와 클래스간에 차이가 없으므로 객체를 사용해도됩니다. (그러나 장면 뒤에는 알아야 할 몇 가지 차이점이 있습니다. 예를 들어 구조체는 참조 유형이 아닌 값 유형입니다.) 기본적으로 객체를 단순하게 유지하는 것이 쉬울 것입니다. 수동으로 테스트합니다. 현대 언어와 도구를 사용하면 인터페이스, 모의 프레임 워크, 의존성 주입 등을 통해 상당히 완화 할 수 있습니다.