클래스 및 인터페이스 설계(기사 번역)

콘텐츠

1. 소개
2. 인터페이스
3. 인터페이스 마커
4. 기능적 인터페이스, 정적 메서드 및 기본 메서드
5. 추상 수업
6. 불변(영구) 클래스
7. 익명 수업
8. 시계
9. 계승
10. 다중 상속
11. 상속과 구성
12. 캡슐화
13. 최종 클래스 및 메서드
14. 무엇 향후 계획
15. 소스 코드 다운로드

1. 소개

어떤 프로그래밍 언어를 사용하든(Java도 예외는 아님), 깔끔하고 이해하기 쉽고 검증 가능한 코드를 작성하려면 좋은 디자인 원칙을 따르는 것이 중요합니다. 또한 수명이 길고 문제 해결을 쉽게 지원하도록 만듭니다. 튜토리얼의 이 부분에서는 Java 언어가 제공하는 기본 구성 요소에 대해 논의하고 더 나은 디자인 결정을 내리는 데 도움이 되는 몇 가지 디자인 원칙을 소개하겠습니다. 보다 구체적으로 기본 메서드(Java 8의 새로운 기능), 추상 및 최종 클래스, 불변 클래스, 상속, 구성을 사용하는 인터페이스와 인터페이스에 대해 논의하고, 2019년에서 간략하게 다루었던 가시성(또는 접근성) 규칙을 다시 살펴보겠습니다. 1부 레슨 "객체를 생성하고 파괴하는 방법" .

2. 인터페이스

객체 지향 프로그래밍에서 인터페이스 개념은 계약 개발의 기초를 형성합니다 . 간단히 말해서 인터페이스는 일련의 메서드(계약)를 정의하고 해당 특정 인터페이스에 대한 지원이 필요한 각 클래스는 해당 메서드의 구현을 제공해야 합니다. 이는 매우 간단하지만 강력한 아이디어입니다. 많은 프로그래밍 언어에는 어떤 형태로든 인터페이스가 있지만 특히 Java는 이에 대한 언어 지원을 제공합니다. Java의 간단한 인터페이스 정의를 살펴보겠습니다.

package com.javacodegeeks.advanced.design;

public interface SimpleInterface {
void performAction();
}

위의 코드에서 우리가 호출한 인터페이스는 SimpleInterface호출되는 메서드 하나만 선언합니다 performAction. 인터페이스와 클래스의 주요 차이점은 인터페이스는 연락처가 무엇인지 설명하지만(메서드 선언) 구현을 제공하지 않는다는 것입니다. 그러나 Java의 인터페이스는 더 복잡할 수 있습니다. 즉, 중첩된 인터페이스, 클래스, 개수, 주석 및 상수를 포함할 수 있습니다. 예를 들어:

package com.javacodegeeks.advanced.design;

public interface InterfaceWithDefinitions {
    String CONSTANT = "CONSTANT";

    enum InnerEnum {
        E1, E2;
    }

    class InnerClass {
    }

    interface InnerInterface {
        void performInnerAction();
    }

    void performAction();
}

이 보다 복잡한 예에는 인터페이스가 중첩 구문 및 메서드 선언에 무조건 부과하는 몇 가지 제한 사항이 있으며 이러한 제한 사항은 Java 컴파일러에 의해 적용됩니다. 우선, 명시적으로 선언하지 않더라도 인터페이스의 모든 메서드 선언은 공개 됩니다 (공개만 가능함). 따라서 다음 메서드 선언은 동일합니다.

public void performAction();
void performAction();

인터페이스의 모든 단일 메서드는 암시적으로 abstract 로 선언되며 이러한 메서드 선언도 동일하다는 점은 언급할 가치가 있습니다.

public abstract void performAction();
public void performAction();
void performAction();

선언된 상수 필드는 public 일 뿐만 아니라 암시적으로 static 이며 final 로 표시됩니다 . 따라서 다음 선언도 동일합니다.

String CONSTANT = "CONSTANT";
public static final String CONSTANT = "CONSTANT";

마지막으로 중첩된 클래스, 인터페이스 또는 개수는 public 일 뿐만 아니라 암시적으로 static 으로 선언됩니다 . 예를 들어, 다음 선언은 다음과 동일합니다.

class InnerClass {
}

static class InnerClass {
}

선택하는 스타일은 개인 취향이지만 이러한 간단한 인터페이스 속성을 알면 불필요한 입력을 피할 수 있습니다.

3. 인터페이스 마커

마커 인터페이스는 메서드나 기타 중첩된 구문이 없는 특별한 종류의 인터페이스입니다. Java 라이브러리가 이를 정의하는 방법:

public interface Cloneable {
}

인터페이스 마커는 그 자체로는 계약이 아니지만 특정 특성을 클래스와 "연결"하거나 "연관"하는 데 다소 유용한 기술입니다. 예를 들어 Cloneable 과 관련하여 클래스는 복제 가능으로 표시되지만 이를 구현하거나 구현해야 하는 방식은 인터페이스의 일부가 아닙니다. 매우 유명하고 널리 사용되는 인터페이스 마커의 또 다른 예는 다음과 같습니다 Serializable.

public interface Serializable {
}

이 인터페이스는 클래스를 직렬화 및 역직렬화에 적합한 것으로 표시하며, 이것이 구현될 수 있거나 구현되어야 하는 방법을 지정하지 않습니다. 인터페이스 마커는 계약이라는 인터페이스의 주요 목적을 충족시키지 못하더라도 객체 지향 프로그래밍에서 그 위치를 차지합니다. 

4. 기능적 인터페이스, 기본 메소드 및 정적 메소드

Java 8 출시 이후 인터페이스에는 정적 메서드, 기본 메서드, 람다(기능적 인터페이스)에서 자동 변환 등 매우 흥미로운 새로운 기능이 추가되었습니다. 인터페이스 섹션에서 우리는 Java의 인터페이스가 메소드를 선언할 수만 있을 뿐 구현을 제공하지는 않는다는 사실을 강조했습니다. 기본 메서드를 사용하면 상황이 다릅니다. 인터페이스는 기본 키워드로 메서드를 표시 하고 이에 대한 구현을 제공할 수 있습니다. 예를 들어:

package com.javacodegeeks.advanced.design;

public interface InterfaceWithDefaultMethods {
    void performAction();

    default void performDefaulAction() {
        // Implementation here
    }
}

인스턴스 수준에서 기본 메서드는 각 인터페이스 구현에 의해 재정의될 수 있지만 이제 인터페이스에는 정적 메서드도 포함될 수 있습니다. 예: package com.javacodegeeks.advanced.design;

public interface InterfaceWithDefaultMethods {
    static void createAction() {
        // Implementation here
    }
}

인터페이스에서 구현을 제공하는 것은 계약 프로그래밍의 전체 목적을 무효화한다고 말할 수 있습니다. 그러나 이러한 기능이 Java 언어에 도입된 데에는 여러 가지 이유가 있으며, 그것이 아무리 유용하거나 혼란스럽더라도 귀하와 귀하가 사용할 수 있는 것입니다. 기능적 인터페이스는 완전히 다른 이야기이며 언어에 매우 유용한 추가 기능으로 입증되었습니다. 기본적으로 함수형 인터페이스는 단 하나의 추상 메서드가 선언된 인터페이스입니다. Runnable표준 라이브러리 인터페이스는 이 개념의 아주 좋은 예입니다.

@FunctionalInterface
public interface Runnable {
    void run();
}

Java 컴파일러는 기능적 인터페이스를 다르게 처리하고 람다 함수를 적절한 경우 기능적 인터페이스 구현으로 전환할 수 있습니다. 다음 함수 설명을 고려해 보겠습니다. 

public void runMe( final Runnable r ) {
    r.run();
}

Java 7 이하에서 이 함수를 호출하려면 인터페이스 구현을 제공해야 Runnable하지만(예: 익명 클래스 사용) Java 8에서는 람다 구문을 사용하여 run() 메서드 구현을 제공하는 것으로 충분합니다.

runMe( () -> System.out.println( "Run!" ) );

또한 @FunctionalInterface 주석 (주석은 튜토리얼의 5부에서 자세히 설명)은 컴파일러가 인터페이스에 추상 메서드가 하나만 포함되어 있는지 확인할 수 있으므로 향후 인터페이스에 대한 변경 사항이 이 가정을 위반하지 않는다는 것을 암시합니다. .

5. 추상 수업

Java 언어가 지원하는 또 다른 흥미로운 개념은 추상 클래스 개념입니다. 추상 클래스는 Java 7의 인터페이스와 다소 유사하며 Java 8의 기본 메소드 인터페이스와 매우 유사합니다. 일반 클래스와 달리 추상 클래스는 인스턴스화할 수 없지만 하위 클래스화할 수 있습니다(자세한 내용은 상속 섹션 참조). 더 중요한 것은 추상 클래스에 추상 메서드, 즉 인터페이스처럼 구현이 없는 특수한 종류의 메서드가 포함될 수 있다는 것입니다. 예를 들어:

package com.javacodegeeks.advanced.design;

public abstract class SimpleAbstractClass {
    public void performAction() {
        // Implementation here
    }

    public abstract void performAnotherAction();
}

이 예제에서 클래스는 abstractSimpleAbstractClass 로 선언되었으며 선언된 추상 메서드 하나를 포함합니다. 추상 클래스는 매우 유용합니다. 구현 세부 사항의 대부분 또는 일부를 여러 하위 클래스에서 공유할 수 있습니다. 그렇더라도 여전히 문을 열어두고 추상 메서드를 사용하여 각 하위 클래스에 내재된 동작을 사용자 정의할 수 있습니다. 공용 선언 만 포함할 수 있는 인터페이스와 달리 추상 클래스는 접근성 규칙의 모든 기능을 사용하여 추상 메서드의 가시성을 제어할 수 있다는 점을 언급할 가치가 있습니다.

6. 즉시 수업

불변성은 오늘날 소프트웨어 개발에서 점점 더 중요해지고 있습니다. 멀티 코어 시스템의 등장으로 데이터 공유 및 병렬 처리와 관련된 많은 문제가 제기되었습니다. 그러나 한 가지 문제는 분명히 발생했습니다. 변경 가능한 상태가 거의 없거나 전혀 없으면 확장성(확장성)이 향상되고 시스템에 대한 추론이 더 쉬워진다는 것입니다. 불행하게도 Java 언어는 클래스 불변성에 대한 적절한 지원을 제공하지 않습니다. 그러나 여러 기술을 조합하여 사용하면 불변 클래스를 설계하는 것이 가능해졌습니다. 우선, 클래스의 모든 필드는 final이어야 합니다( final 로 표시됨 ). 이는 좋은 시작이지만 보장할 수는 없습니다. 

package com.javacodegeeks.advanced.design;

import java.util.Collection;

public class ImmutableClass {
    private final long id;
    private final String[] arrayOfStrings;
    private final Collection<String> collectionOfString;
}

둘째, 적절한 초기화를 확인하세요. 필드가 컬렉션이나 배열에 대한 참조인 경우 해당 필드를 생성자 인수에서 직접 할당하지 말고 대신 복사본을 만드세요. 이렇게 하면 컬렉션이나 배열의 상태가 외부에서 수정되지 않습니다.

public ImmutableClass( final long id, final String[] arrayOfStrings,
        final Collection<String> collectionOfString) {
    this.id = id;
    this.arrayOfStrings = Arrays.copyOf( arrayOfStrings, arrayOfStrings.length );
    this.collectionOfString = new ArrayList<>( collectionOfString );
}

마지막으로 적절한 액세스(getter)를 보장합니다. 컬렉션의 경우 불변성은 래퍼로 제공되어야 합니다  Collections.unmodifiableXxx. 배열의 경우 진정한 불변성을 제공하는 유일한 방법은 배열에 대한 참조를 반환하는 대신 복사본을 제공하는 것입니다. 이는 배열의 크기에 크게 의존하고 가비지 수집기에 막대한 부담을 줄 수 있으므로 실용적인 관점에서는 허용되지 않을 수 있습니다.

public String[] getArrayOfStrings() {
    return Arrays.copyOf( arrayOfStrings, arrayOfStrings.length );
}

이 작은 예조차도 불변성은 아직 Java의 일급 시민이 아니라는 좋은 아이디어를 제공합니다. 불변 클래스에 다른 클래스의 객체를 참조하는 필드가 있으면 상황이 복잡해질 수 있습니다. 해당 클래스도 불변이어야 하지만 이를 보장할 수 있는 방법은 없습니다. 코드를 확인하고 일반적인 Java 프로그래밍 결함을 지적함으로써 큰 ​​도움을 줄 수 있는 FindBugs 및 PMD와 같은 몇 가지 괜찮은 Java 소스 코드 분석기가 있습니다. 이러한 도구는 모든 Java 개발자의 좋은 친구입니다.

7. 익명 수업

Java 8 이전 시대에는 익명 클래스가 클래스가 즉시 정의되고 즉시 인스턴스화되도록 보장하는 유일한 방법이었습니다. 익명 클래스의 목적은 상용구를 줄이고 클래스를 레코드로 나타내는 짧고 쉬운 방법을 제공하는 것이었습니다. Java에서 새 스레드를 생성하는 일반적인 구식 방법을 살펴보겠습니다.

package com.javacodegeeks.advanced.design;

public class AnonymousClass {
    public static void main( String[] args ) {
        new Thread(
            // Example of creating anonymous class which implements
            // Runnable interface
            new Runnable() {
                @Override
                public void run() {
                    // Implementation here
                }
            }
        ).start();
    }
}

이 예제에서는 인터페이스 구현이 Runnable익명 클래스로 즉시 제공됩니다. 익명 클래스와 관련된 몇 가지 제한 사항이 있지만 이를 사용하는 데 따른 주요 단점은 Java 언어가 요구하는 매우 장황한 구문 구문입니다. 아무것도 하지 않는 익명 클래스라도 작성할 때마다 최소한 5줄의 코드가 필요합니다.

new Runnable() {
   @Override
   public void run() {
   }
}

다행히도 Java 8, 람다 및 기능적 인터페이스를 사용하면 이러한 모든 고정관념이 곧 사라지고 마침내 Java 코드 작성이 정말 간결해 보일 것입니다.

package com.javacodegeeks.advanced.design;

public class AnonymousClass {
    public static void main( String[] args ) {
        new Thread( () -> { /* Implementation here */ } ).start();
    }
}

8. 가시성

우리는 이미 튜토리얼 1부에서 Java의 가시성 및 접근성 규칙에 대해 조금 이야기했습니다. 이 부분에서는 서브클래싱의 맥락에서 이 주제를 다시 다루겠습니다. 다양한 수준의 가시성은 클래스가 다른 클래스나 인터페이스(예: 서로 다른 패키지에 있거나 서로 중첩된 경우)를 보거나 하위 클래스가 상위 클래스의 메서드, 생성자 및 필드를 보고 액세스하는 것을 허용하거나 방지합니다. 다음 섹션인 상속에서는 이것이 어떻게 작동하는지 살펴보겠습니다.

9. 상속

상속은 객체지향 프로그래밍의 주요 개념 중 하나이며, 관계 클래스를 구성하는 기초 역할을 합니다. 가시성 및 접근성 규칙과 결합된 상속을 통해 클래스를 확장 및 유지 관리할 수 있는 계층 구조로 설계할 수 있습니다. 개념적 수준에서 Java의 상속은 상위 클래스와 함께 서브클래싱 및 확장 키워드를 사용하여 구현됩니다. 하위 클래스는 상위 클래스의 모든 공개 및 보호 요소를 상속합니다. 또한 하위 클래스와 클래스가 모두 동일한 패키지에 있는 경우 하위 클래스는 상위 클래스의 패키지 전용 요소를 상속합니다. 즉, 무엇을 디자인하려고 하든 클래스가 공개적으로 또는 하위 클래스에 노출하는 최소한의 메서드 집합을 고수하는 것이 매우 중요합니다. 예를 들어, 가시성 수준과 그 효과의 차이를 보여주기 위해 클래스 Parent와 해당 하위 클래스를 살펴보겠습니다.Child

package com.javacodegeeks.advanced.design;

public class Parent {
    // Everyone can see it
    public static final String CONSTANT = "Constant";

    // No one can access it
    private String privateField;
    // Only subclasses can access it
    protected String protectedField;

    // No one can see it
    private class PrivateClass {
    }

    // Only visible to subclasses
    protected interface ProtectedInterface {
    }

    // Everyone can call it
    public void publicAction() {
    }

    // Only subclass can call it
    protected void protectedAction() {
    }

    // No one can call it
    private void privateAction() {
    }

    // Only subclasses in the same package can call it
    void packageAction() {
    }
}

package com.javacodegeeks.advanced.design;

// Resides in the same package as parent class
public class Child extends Parent implements Parent.ProtectedInterface {
    @Override
    protected void protectedAction() {
        // Calls parent's method implementation
        super.protectedAction();
    }

    @Override
    void packageAction() {
        // Do nothing, no call to parent's method implementation
    }

    public void childAction() {
        this.protectedField = "value";
    }
}

상속은 그 자체로 매우 큰 주제이며 Java와 관련된 세부적인 내용이 많이 포함되어 있습니다. 그러나 따르기 쉽고 클래스 계층 구조를 간결하게 유지하는 데 큰 도움이 되는 몇 가지 규칙이 있습니다. Java에서 각 하위 클래스는 최종으로 선언되지 않은 한 상위 클래스의 상속된 메서드를 재정의할 수 있습니다. 그러나 메서드를 재정의된 것으로 표시하는 특별한 구문이나 키워드가 없으므로 혼란을 초래할 수 있습니다. 이것이 @Override 주석이 도입된 이유입니다 . 상속된 메서드를 재정의하는 것이 목표일 때마다 @Override 주석을 사용하여 이를 간결하게 표시하세요. Java 개발자가 디자인에서 지속적으로 직면하는 또 다른 딜레마는 클래스 계층 구조(구체적 또는 추상 클래스 포함) 구성과 인터페이스 구현입니다. 가능하면 클래스나 추상 클래스보다 인터페이스를 선호하는 것이 좋습니다. 인터페이스는 더 가볍고 테스트 및 유지 관리가 더 쉬우며 구현 변경으로 인한 부작용도 최소화됩니다. Java 표준 라이브러리에서 프록시 클래스 생성과 같은 많은 고급 프로그래밍 기술은 인터페이스에 크게 의존합니다.

10. 다중 상속

C++ 및 일부 다른 언어와 달리 Java는 다중 상속을 지원하지 않습니다. Java에서 각 클래스는 하나의 직접 상위 클래스만 가질 수 있습니다(클래스가 Object계층 구조의 최상위에 있음). 그러나 클래스는 여러 인터페이스를 구현할 수 있으므로 인터페이스 스태킹은 Java에서 다중 상속을 달성(또는 시뮬레이션)하는 유일한 방법입니다.

package com.javacodegeeks.advanced.design;

public class MultipleInterfaces implements Runnable, AutoCloseable {
    @Override
    public void run() {
        // Some implementation here
    }

    @Override
    public void close() throws Exception {
       // Some implementation here
    }
}

다중 인터페이스 구현은 실제로 매우 강력하지만 구현을 반복해서 사용해야 하는 경우 Java의 다중 상속 지원 부족을 극복하기 위한 방법으로 깊은 클래스 계층 구조가 발생하는 경우가 많습니다. 

public class A implements Runnable {
    @Override
    public void run() {
        // Some implementation here
    }
}

// Class B wants to inherit the implementation of run() method from class A.
public class B extends A implements AutoCloseable {
    @Override
    public void close() throws Exception {
       // Some implementation here
    }
}

// Class C wants to inherit the implementation of run() method from class A
// and the implementation of close() method from class B.
public class C extends B implements Readable {
    @Override
    public int read(java.nio.CharBuffer cb) throws IOException {
       // Some implementation here
    }
}

등등... Java 8의 최근 릴리스에서는 기본 메소드 삽입 문제를 어느 정도 해결했습니다. 기본 메서드 때문에 인터페이스는 실제로 계약뿐 아니라 구현도 제공합니다. 따라서 이러한 인터페이스를 구현하는 클래스는 구현된 메서드도 자동으로 상속합니다. 예를 들어:

package com.javacodegeeks.advanced.design;

public interface DefaultMethods extends Runnable, AutoCloseable {
    @Override
    default void run() {
        // Some implementation here
    }

    @Override
    default void close() throws Exception {
       // Some implementation here
    }
}

// Class C inherits the implementation of run() and close() methods from the
// DefaultMethods interface.
public class C implements DefaultMethods, Readable {
    @Override
    public int read(java.nio.CharBuffer cb) throws IOException {
       // Some implementation here
    }
}

다중 상속은 매우 강력하지만 동시에 위험한 도구라는 점을 명심하세요. 잘 알려진 죽음의 다이아몬드 문제는 다중 상속 구현의 주요 결함으로 종종 인용되므로 개발자는 클래스 계층 구조를 매우 신중하게 설계해야 합니다. 불행하게도 기본 메소드를 사용하는 Java 8 인터페이스도 이러한 결함의 희생양이 됩니다.

interface A {
    default void performAction() {
    }
}

interface B extends A {
    @Override
    default void performAction() {
    }
}

interface C extends A {
    @Override
    default void performAction() {
    }
}

예를 들어 다음 코드 조각은 컴파일에 실패합니다.

// E is not compilable unless it overrides performAction() as well
interface E extends B, C {
}

현 시점에서 언어로서의 Java는 항상 객체 지향 프로그래밍의 특수한 경우를 피하려고 노력해 왔다고 말하는 것이 타당합니다. 그러나 언어가 발전함에 따라 이러한 경우 중 일부가 갑자기 나타나기 시작했습니다. 

11. 상속 및 구성

다행히 상속이 클래스를 디자인하는 유일한 방법은 아닙니다. 많은 개발자들이 상속보다 훨씬 낫다고 믿는 또 다른 대안은 구성입니다. 아이디어는 매우 간단합니다. 클래스의 계층 구조를 만드는 대신 다른 클래스로 구성해야 합니다. 이 예를 살펴보겠습니다.

// E is not compilable unless it overrides performAction() as well
interface E extends B, C {
}

클래스는 Vehicle엔진과 바퀴(단순화를 위해 남겨둔 다른 많은 부품 포함)로 구성됩니다. 그러나 클래스 Vehicle도 엔진이므로 상속을 사용하여 설계할 수 있습니다. 

public class Vehicle extends Engine {
    private Wheels[] wheels;
    // ...
}

어떤 디자인 솔루션이 맞을까요? 일반적인 핵심 지침은 IS-A(is) 및 HAS-A(포함) 원칙으로 알려져 있습니다. IS-A는 상속 관계입니다. 하위 클래스는 상위 클래스의 클래스 사양과 상위 클래스의 변형도 충족합니다. 하위 클래스)는 상위 클래스를 확장합니다. 한 엔터티가 다른 엔터티를 확장하는지 알고 싶다면 일치 테스트를 수행하세요 - IS -A(is).") 따라서 HAS-A는 구성 관계입니다. 클래스는 대부분의 경우 다음과 같은 여러 가지 이유로 HAS-A 원칙이 IS-A보다 더 잘 작동하는 객체를 소유(또는 포함)합니다. 

• 디자인이 더욱 유연해졌습니다.
• 변경 사항이 클래스 계층 구조를 통해 전파되지 않기 때문에 모델이 더 안정적입니다.
• 클래스와 해당 컴포지션은 상위 클래스와 해당 하위 클래스를 긴밀하게 연결하는 컴포지션에 비해 느슨하게 연결됩니다.
• 클래스의 논리적 사고 방식은 모든 종속성이 한 곳에 포함되어 있기 때문에 더 간단합니다. 

그럼에도 불구하고 상속은 그 자리를 차지하고 다양한 방식으로 기존의 여러 디자인 문제를 해결하므로 무시되어서는 안 됩니다. 객체 지향 모델을 설계할 때 이 두 가지 대안을 염두에 두십시오.

12. 캡슐화.

객체 지향 프로그래밍에서 캡슐화의 개념은 모든 구현 세부 사항(예: 작동 모드, 내부 메서드 등)을 외부 세계로부터 숨기는 것입니다. 캡슐화의 장점은 유지 관리성과 변경 용이성입니다. 클래스의 내부 구현은 숨겨져 있으며, 클래스 데이터 작업은 클래스의 공개 메서드를 통해서만 발생합니다(많은 사람들이 사용하는 라이브러리나 프레임워크를 개발하는 경우 실제 문제). Java의 캡슐화는 가시성 및 접근성 규칙을 통해 달성됩니다. Java에서는 필드가 최종으로 표시되지 않는 한 getter 및 setter를 통해서만 필드를 직접 노출하지 않는 것이 모범 사례로 간주됩니다. 예를 들어:

package com.javacodegeeks.advanced.design;

public class Encapsulation {
    private final String email;
    private String address;

    public Encapsulation( final String email ) {
        this.email = email;
    }

    public String getAddress() {
        return address;
    }

    public void setAddress(String address) {
        this.address = address;
    }

    public String getEmail() {
        return email;
    }
}

이 예는 Java 언어에서 JavaBeans 라고 불리는 것을 연상시킵니다 . 표준 Java 클래스는 일련의 규칙에 따라 작성되며, 그 중 하나는 getter 및 setter 메소드를 통해서만 필드에 액세스할 수 있도록 허용합니다. 상속 부분에서 이미 강조한 것처럼, 클래스 내에서는 항상 캡슐화 원칙을 활용하여 최소한의 홍보 계약을 준수하시기 바랍니다. 공개되어서는 안 되는 모든 항목은 비공개(또는 해결 중인 문제에 따라 보호/패키지 비공개)가 되어야 합니다. 이는 장기적으로 큰 변화 없이(또는 최소한 최소화하여) 디자인할 수 있는 자유를 제공함으로써 성과를 거둘 것입니다. 

13. 최종 수업 및 방법

Java에는 클래스가 다른 클래스의 하위 클래스가 되는 것을 방지하는 방법이 있습니다. 즉, 다른 클래스를 final로 선언해야 합니다. 

package com.javacodegeeks.advanced.design;

public final class FinalClass {
}

메서드 선언의  동일한 final 키워드는 하위 클래스가 메서드를 재정의하는 것을 방지합니다.

package com.javacodegeeks.advanced.design;

public class FinalMethod {
    public final void performAction() {
    }
}

클래스나 메서드가 최종이어야 하는지 여부를 결정하는 일반적인 규칙은 없습니다. 최종 클래스와 메서드는 확장성을 제한하므로 클래스를 상속해야 할지, 상속하지 말아야 할지, 또는 메서드를 나중에 재정의해야 할지 말아야 할지 미리 생각하기가 매우 어렵습니다. 이와 같은 설계 결정으로 인해 라이브러리의 적용 가능성이 크게 제한될 수 있으므로 이는 라이브러리 개발자에게 특히 중요합니다. Java 표준 라이브러리에는 최종 클래스의 여러 예가 있으며, 가장 유명한 것은 String 클래스입니다. 초기 단계에서 이 결정은 개발자가 문자열 구현에 대한 "더 나은" 솔루션을 고안하려는 시도를 방지하기 위해 내려졌습니다. 

14. 다음은 무엇입니까

이 단원에서는 Java의 객체 지향 프로그래밍 개념을 다루었습니다. 또한 계약 프로그래밍을 간략하게 살펴보고 몇 가지 기능적 개념을 살펴보고 시간이 지남에 따라 언어가 어떻게 발전했는지 살펴보았습니다. 강의의 다음 부분에서는 제네릭에 대해 알아보고 프로그래밍에서 유형 안전성에 접근하는 방식이 어떻게 바뀌는지 살펴보겠습니다. 

15. 소스 코드 다운로드

여기에서 소스를 다운로드할 수 있습니다 - Advanced-java-part-3 소스: 클래스를 디자인하는 방법