즉, 최종 사용자가 기능을 재사용 할 수 있는지 신경 쓰지 않기 때문에 재사용 성을 위해 소프트웨어를 엔지니어링하지 마십시오. 대신, 설계 이해를 위한 엔지니어 -다른 사람이나 미래의 잊어 버린 자아가 이해하기 쉬운 코드입니까? – 설계 유연성필연적으로 버그를 수정하거나, 기능을 추가하거나, 기능을 수정해야 할 때 내 코드가 변경 사항에 얼마나 영향을 줍니까? 고객이 관심을 갖는 유일한 것은 버그를보고하거나 변경을 요청할 때 얼마나 빨리 응답 할 수 있는지입니다. 우연히 디자인에 대한 이러한 질문을하면 재사용 가능한 코드가 생성되는 경향이 있지만,이 접근 방식을 통해 코드 수명 동안 직면 할 실제 문제를 피하는 데 집중할 수 있으므로, 엄격하고 실용적이지 않고 최종 사용자에게 더 나은 서비스를 제공 할 수 있습니다. 목 수염을 기쁘게하는 “엔지니어링”이상.

제공 한 예제만큼 단순한 것은 초기 구현은 크기가 작기 때문에 훌륭하지만, 이처럼 단순한 디자인은 너무 많은 기능적 유연성 (설계 유연성이 아닌)을 방해하면 이해하기 어렵고 부서지기 쉽습니다. 하나의 절차. 아래는 이해와 유연성을 위해 복잡한 시스템을 설계하는 데 선호되는 접근 방식에 대한 설명입니다. 이 절차는 단일 절차에서 20 줄 미만으로 쓰여질 수있는 것에 대해서는 사용하지 않을 것입니다. 왜냐하면 아주 작은 것이 이미 이해력과 유연성에 대한 나의 기준을 충족시키기 때문입니다.

절차가 아닌 객체

구식 모듈과 같은 클래스를 사용하여 소프트웨어가 수행해야하는 작업을 실행하기 위해 호출하는 많은 루틴을 사용하는 대신, 작업을 수행하기 위해 상호 작용하고 협력하는 객체로 도메인을 모델링하는 것을 고려하십시오. 객체 지향 패러다임의 메소드는 원래 그 때문에 객체 사이의 신호로 만들어진 Object1말할 수있는 Object2그 무엇이든 그 일을 수행하고, 아마도 리턴 신호를받을 수 있습니다. 이는 객체 지향 패러다임이 본질적으로 명령형 패러다임의 동일한 기존 기능과 절차를 구성하는 멋진 방법이 아니라 도메인 객체와 해당 상호 작용을 모델링하는 것이기 때문입니다. 의 경우void destroyBaghdad예를 들어, 바그다드 나 다른 것들 (빠르게 복잡하고 이해하기 어렵고 부서지기 쉬운)의 파괴를 처리하기 위해 문맥이없는 일반적인 방법을 쓰려고 노력하는 대신, 파괴 될 수있는 모든 것은 방법을 이해해야합니다. 스스로를 파괴합니다. 예를 들어, 파괴 할 수있는 것들의 동작을 설명하는 인터페이스가 있습니다.

interface Destroyable {
    void destroy();
}

그런 다음이 인터페이스를 구현하는 도시가 있습니다.

class City implements Destroyable {
    @Override
    public void destroy() {
        ...code that destroys the city
    }
}

인스턴스의 파괴를 요구 City하는 것은 그 일이 어떻게 발생하는지 신경 쓰지 않을 것이므로 코드가 외부 어디에도 존재할 이유가 없으며 City::destroy실제로 City외부 외부의 내부 작업에 대한 친밀한 지식은 긴밀한 결합으로 감소합니다. 의 동작을 수정해야하는 경우 외부 요소를 고려해야하기 때문에 실현 가능성 City. 이것이 캡슐화의 진정한 목적입니다. 모든 객체에는 자체 API가 있으므로 필요한 모든 작업을 수행하여 요청 이행에 대해 걱정할 수 있도록해야합니다.

“제어”가 아닌 위임

지금, 당신의 구현 클래스인지 City또는 Baghdad도시를 파괴하는 과정이 밝혀 방법 일반에 따라 달라집니다. 모든 가능성에서, City도시는 도시의 완전한 파괴를 달성하기 위해 개별적으로 파괴 될 필요가있는 더 작은 조각들로 구성 될 것이고,이 경우, 이들 조각들 각각은 또한 구현 될 것이고 Destroyable, 그들은 각각 City파괴 하도록 지시 될 것이다. 같은 방식으로 외부에서 누군가가 City자신을 파괴 하도록 요청했습니다 .

interface Part extends Destroyable {
    ...part-specific methods
}

class Building implements Part {
    ...part-specific methods
    @Override
    public void destroy() {
       ...code to destroy a building
    }
}

class Street implements Part {
    ...part-specific methods
    @Override
    public void destroy() {
        ...code to destroy a building
    }
}

class City implements Destroyable {
    public List<Part> parts() {...}

    @Override
    public void destroy() {
        parts().forEach(Destroyable::destroy);
    }
}

정말 미치게 만들고 Bomb특정 위치에 놓이고 특정 반경 내의 모든 것을 파괴 하는 아이디어를 구현하려는 경우 다음과 같이 보일 수 있습니다.

class Bomb {
    private final Integer radius;

    public Bomb(final Integer radius) {
        this.radius = radius;
    }

    public void drop(final Grid grid, final Coordinate target) {
        new ObjectsByRadius(
            grid,
            target,
            this.radius
        ).forEach(Destroyable::destroy);
    }
}

ObjectsByRadius는 Bomb입력에 대해 계산되는 개체 집합을 나타내며 개체에 대해 Bomb작업 할 수있는 한 계산 방법을 신경 쓰지 않기 때문 입니다. 이것은 우연히 재사용 가능하지만 주요 목표는 Bomb객체 를 떨어 뜨리고 파괴 하는 프로세스에서 계산을 분리하여 각 조각을 이해하고 전체 알고리즘을 재구성하지 않고도 개별 조각의 동작을 변경하고 개별 조각의 동작을 변경하는 것입니다. .

알고리즘이 아닌 상호 작용

복잡한 알고리즘에 대해 적절한 수의 매개 변수를 추측하는 대신 프로세스를 복잡한 역할을하는 일련의 상호 작용 객체로 모델링하는 것이 더 합리적입니다. 잘 정의되고 이해하기 쉽고 거의 변하지 않는 객체 간의 상호 작용을 통해 프로세스를 수행합니다. 올바르게 수행하면 인터페이스를 구현하거나 main()메소드 에서 인스턴스화 된 객체를 재 작업하는 것처럼 사소한 수정처럼 가장 복잡한 수정도 가능합니다 .

나는 당신에게 당신의 원래 예제에 무언가를 줄 것이지만, 솔직히 “인쇄 ​​… Day Light Savings”라는 것이 무엇을 의미하는지 이해할 수 없습니다. 그 범주의 문제에 대해 말할 수있는 것은 계산을 수행 할 때마다 여러 가지 형식으로 결과를 형식화 할 수 있다는 것입니다.

interface Result {
    String print();
}

class Caclulation {
    private final Parameter paramater1;

    private final Parameter parameter2;

    public Calculation(final Parameter parameter1, final Parameter parameter2) {
        this.parameter1 = parameter1;
        this.parameter2 = parameter2;
    }

    public Result calculate() {
        ...calculate the result
    }
}

class FormattedResult {
    private final Result result;

    public FormattedResult(final Result result) {
        this.result = result;
    }

    @Override
    public String print() {
        ...interact with this.result to format it and return the formatted String
    }
}

이 예제에서는이 디자인을 지원하지 않는 Java 라이브러리의 클래스를 사용하므로 ZonedDateTime직접 API를 사용할 수 있습니다. 여기서의 아이디어는 각 계산이 자체 객체 내에 캡슐화된다는 것입니다. 실행 횟수 나 결과 형식화 방법에 대해서는 가정하지 않습니다. 가장 간단한 형태의 계산 수행에만 관심이 있습니다. 따라서 이해하기 쉽고 유연하게 변경할 수 있습니다. 마찬가지로,는 Result계산 결과를 캡슐화하는 FormattedResult것과 관련이 있으며, Result정의한 규칙에 따라 형식을 지정하기 위해 와 상호 작용하는 것만 관련됩니다. 이런 식으로,우리는 각각의 메소드가 잘 정의 된 작업을 가지고 있기 때문에 각 메소드에 대해 완벽한 인수를 찾을 수 있습니다 . 또한 인터페이스가 변경되지 않는 한 (객체의 책임을 올바르게 최소화 한 경우에는 수행 할 수없는) 앞으로 수정하는 것이 훨씬 간단합니다. 우리의main()방법은 다음과 같습니다.

class App {
    public static void main(String[] args) {
        final List<Set<Paramater>> parameters = ...instantiated from args
        parameters.forEach(set -> {
            System.out.println(
                new FormattedResult(
                    new Calculation(
                        set.get(0),
                        set.get(1)
                    ).calculate()
                ).print()
            );
        });
    }
}

실제로 객체 지향 프로그래밍은 명령 방식의 복잡성 / 유연성 문제에 대한 해결책으로 특별히 고안되었습니다. 관용구 내에 명령 기능 및 절차를 지정하십시오.

답변