Java에서 객체와 같은 구조

객체와 같은 구조체를 만드는 Java 방식과 완전히 반대입니까?

class SomeData1 {
    public int x;
    public int y;
}

접근 자와 뮤 테이터가 더 많은 클래스가 Java와 비슷하다는 것을 알 수 있습니다.

class SomeData2 {
    int getX();
    void setX(int x);

    int getY();
    void setY(int y);

    private int x;
    private int y;
}

첫 번째 예제의 클래스는 표기법이 편리합니다.

// a function in a class
public int f(SomeData1 d) {
    return (3 * d.x) / d.y;
}

이것은 편리하지 않습니다.

// a function in a class
public int f(SomeData2 d) {
    return (3 * d.getX()) / d.getY();
}

이것은 일반적으로 논의되는 주제입니다. 개체에서 공용 필드를 만드는 단점은 설정된 값을 제어 할 수 없다는 것입니다. 같은 코드를 사용하는 프로그래머가 많은 그룹 프로젝트에서는 부작용을 피하는 것이 중요합니다. 또한 때로는 필드의 객체 사본을 반환하거나 어떻게 든 변환하는 것이 좋습니다. 테스트에서 이러한 메소드를 조롱 할 수 있습니다. 새 클래스를 만들면 가능한 모든 동작이 표시되지 않을 수 있습니다. 방어적인 프로그래밍과 같습니다. 언젠가 getter와 setter가 도움이 될 수 있으며이를 작성 / 사용하는 데 많은 비용이 들지 않습니다. 그래서 그들은 때때로 유용합니다.

실제로 대부분의 필드에는 간단한 getter 및 setter가 있습니다. 가능한 해결책은 다음과 같습니다.

public property String foo;   
a->Foo = b->Foo;

업데이트 : 속성 지원이 Java 7 또는 그 이후에 추가 될 가능성은 거의 없습니다. Groovy, Scala 등과 같은 다른 JVM 언어는 현재이 기능을 지원합니다. -알렉스 밀러

Java가 "struct"를 지원하는 경우 (동작이 없을 때) 클래스가 기본적으로 "구조"인 경우 공용 인스턴스 변수를 사용하는 것이 적절하다고 말하는 많은 Java 사용자가 Sun Java 코딩 지침에 익숙하지 않은 것 같습니다.

사람들은 게터와 세터가 마치 마치 자바의 중심에있는 것처럼 자바 방식이라고 생각하는 경향이 있습니다. 그렇지 않습니다. 적절한 상황에서 퍼블릭 인스턴스 변수를 사용하여 Sun Java 코딩 지침을 따르면 실제로 불필요한 게터와 세터로 코드를 어지럽히는 것보다 더 나은 코드를 작성하는 것입니다.

1999 년 Java 코드 규칙은 변경되지 않았습니다.

10.1 인스턴스 및 클래스 변수에 대한 액세스 제공

정당한 이유없이 인스턴스 나 클래스 변수를 공개하지 마십시오. 종종, 메소드 변수의 부작용으로 발생하는 인스턴스 변수를 명시 적으로 설정하거나 가져올 필요가 없습니다.

적절한 퍼블릭 인스턴스 변수의 한 예는 클래스가 기본적으로 데이터 구조이며 동작이없는 경우입니다. 즉, 클래스 대신 구조체를 사용했을 경우 (Java가 구조체를 지원하는 경우) 클래스의 인스턴스 변수를 public으로 만드는 것이 적절합니다 .

http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-137265.html#177

http://en.wikipedia.org/wiki/Plain_old_data_structure

http://docs.oracle.com/javase/1.3/docs/guide/collections/designfaq.html#28

상식을 실제로 사용하십시오. 다음과 같은 것이 있다면 :

public class ScreenCoord2D{
    public int x;
    public int y;
}

그런 다음 게터와 세터로 감싸는 데 약간의 포인트가 있습니다. 다른 방법으로 x, y 좌표를 전체 픽셀로 저장하지 않습니다. 게터와 세터는 속도를 늦출뿐입니다.

반면에,

public class BankAccount{
    public int balance;
}

나중에 어느 시점에서 잔액이 계산되는 방식을 변경하고 싶을 수도 있습니다. 이것은 실제로 게터와 세터를 사용해야합니다.

규칙을 구부릴 수있는시기를 알 수 있도록 유용한 방법을 적용하는 이유 를 아는 것이 항상 바람직합니다 .

변경 가능성 문제를 해결하기 위해 x와 y를 final로 선언 할 수 있습니다. 예를 들면 다음과 같습니다.

class Data {
  public final int x;
  public final int y;
  public Data( int x, int y){
    this.x = x;
    this.y = y;
  }
}

이러한 필드에 쓰려고 시도하는 호출 코드는 "필드 x가 최종 선언되어 할당 할 수 없습니다"라는 컴파일 시간 오류를 발생시킵니다.

그런 다음 클라이언트 코드는 게시물에 설명 된 '짧은'편의를 가질 수 있습니다.

public class DataTest {
    public DataTest() {
        Data data1 = new Data(1, 5);
        Data data2 = new Data(2, 4);
        System.out.println(f(data1));
        System.out.println(f(data2));
    }

    public int f(Data d) {
        return (3 * d.x) / d.y;
    }

    public static void main(String[] args) {
        DataTest dataTest = new DataTest();
    }
}

public필드를 사용하지 마십시오

public클래스의 내부 동작을 실제로 래핑하려는 경우 필드를 사용하지 마십시오 . 가지고 java.io.BufferedReader예를 들어. 다음과 같은 필드가 있습니다.

private boolean skipLF = false; // If the next character is a line feed, skip it

skipLF모든 읽기 방법으로 읽고 씁니다. 별도의 스레드에서 실행되는 외부 클래스 skipLF가 읽기 도중에 상태를 악의적으로 수정 한 경우 어떻게됩니까? BufferedReader확실히 haywire 갈 것입니다.

public필드를 사용하십시오

이 Point수업을 예로 들어 보겠습니다.

class Point {
    private double x;
    private double y;

    public Point(double x, double y) {
        this.x = x;
        this.y = y;
    }

    public double getX() {
        return this.x;
    }

    public double getY() {
        return this.y;
    }

    public void setX(double x) {
        this.x = x;
    }

    public void setY(double y) {
        this.y = y;
    }
}

이로 인해 두 점 사이의 거리를 계산하는 것이 매우 고통 스럽습니다.

Point a = new Point(5.0, 4.0);
Point b = new Point(4.0, 9.0);
double distance = Math.sqrt(Math.pow(b.getX() - a.getX(), 2) + Math.pow(b.getY() - a.getY(), 2));

이 클래스에는 일반 게터 및 세터 이외의 동작이 없습니다. 클래스는 단지 데이터 구조를 나타내며,이없는, 때 공공 필드를 사용하는 것이 허용 하고 행동을 (얇은 getter와 setter가되어주지 않습니다 적이 없습니다 여기에 행동으로 간주). 이 방법으로 더 잘 작성할 수 있습니다.

class Point {
    public double x;
    public double y;

    public Point(double x, double y) {
        this.x = x;
        this.y = y;
    }
}

Point a = new Point(5.0, 4.0);
Point b = new Point(4.0, 9.0);
double distance = Math.sqrt(Math.pow(b.x - a.x, 2) + Math.pow(b.y - a.y, 2));

깨끗한!

그러나 수업에 행동이 없어야 할뿐만 아니라 미래에도 행동을 취할 이유 가 없어야 합니다.

(이 답변 이 정확히 설명하는 내용입니다. "Java 프로그래밍 언어에 대한 코드 규칙 : 10. 프로그래밍 실습" 을 인용 하십시오 .

적절한 퍼블릭 인스턴스 변수의 한 예는 클래스가 기본적으로 데이터 구조이며 동작이없는 경우입니다. 즉, struct클래스 대신 (Java가 지원되는 경우 struct)을 사용했다면 클래스의 인스턴스 변수를 public으로 만드는 것이 적절합니다.

따라서 공식 문서 도이 관행을 받아들입니다.)

또한 위 Point클래스의 멤버를 변경할 수 없다고 확신하는 경우 final키워드를 추가 하여 적용 할 수 있습니다 .

public final double x;
public final double y;

그런데 예제로 제공하는 구조는 이미 Java 기본 클래스 라이브러리에 있습니다 java.awt.Point. 공개 필드로 x와 y가 있으므로 직접 확인하십시오 .

당신이하고있는 일을 알고 있고 팀의 다른 사람들이 그것에 대해 알고 있다면, 공공 장소를 갖는 것은 괜찮습니다. 그러나 스택 할당 구조체 인 것처럼 객체를 사용하는 개발자와 관련된 버그처럼 두통을 일으킬 수 있기 때문에 의존해서는 안됩니다 (자바 객체는 항상 사본이 아닌 참조로 메서드에 전송 됨).

Re : aku, izb, John Topley ...

가변성 문제를 조심하십시오 ...

게터 / 세터를 생략하는 것이 합리적으로 보일 수 있습니다. 어떤 경우에는 실제로 괜찮을 수도 있습니다. 여기에 제시된 제안 된 패턴의 실제 문제는 변경 가능성입니다.

문제는 최종이 아닌 공개 필드를 포함하는 객체 참조를 전달하는 것입니다. 해당 참조가있는 다른 항목은 해당 필드를 자유롭게 수정할 수 있습니다. 더 이상 해당 객체의 상태를 제어 할 수 없습니다. (문자열이 변경 가능하면 어떻게 될지 생각하십시오.)

해당 객체가 다른 객체의 내부 상태에서 중요한 부분이되면 나빠집니다. 내부 구현을 방금 노출했습니다. 이를 방지하려면 대신 오브젝트 사본을 리턴해야합니다. 이 방법은 효과가 있지만 수많은 일회용 복사본으로 인해 엄청난 GC 압력이 발생할 수 있습니다.

공개 필드가있는 경우 클래스를 읽기 전용으로 설정하십시오. 필드를 생성자에 매개 변수로 추가하고 필드를 final로 표시하십시오. 그렇지 않으면 내부 상태가 노출되지 않도록하고 반환 값에 대해 새 인스턴스를 생성해야하는 경우 지나치게 호출되지 않도록하십시오.

Joshua Bloch의 " 유효한 Java "-항목 # 13 : 선호 불변성 참조.

추신 : 요즘 모든 JVM은 가능한 경우 getMethod를 최적화하여 단일 필드 읽기 명령을 생성합니다.

나는 게터와 세터가 의미 론적으로 의미없는 균열로 코드를 어지럽히고 다른 언어는 규칙 기반의 데이터 숨기기 또는 책임 분할 (예 : 파이썬)로 잘 작동한다고 생각하는 몇 가지 프로젝트에서 이것을 시도했습니다.

다른 사람들이 위에서 언급했듯이 두 가지 문제가 있으며 실제로 해결할 수는 없습니다.

• 자바 세계의 자동화 된 도구는 getter / setter 규칙에 의존합니다. 다른 사람들이 지적한 것처럼 jsp 태그, 스프링 구성, 이클립스 도구 등을위한 Ditto ... 도구가 기대하는 것과 싸우는 것은 Google을 통해 긴 세션을 스크롤하여 비표준 방식을 시작하는 방법을 찾는 방법입니다 봄 콩. 정말 문제가되지 않습니다.
• 수백 개의 공용 변수로 우아하게 코딩 된 응용 프로그램을 만든 후에는 불변성이 절대적으로 필요하거나 변수가 설정되거나 던질 때 이벤트를 트리거 해야하는 상황이 적어도 하나 이상 발견 될 수 있습니다 객체 상태를 불쾌한 것으로 설정하기 때문에 변수 변경에 대한 예외. 그런 다음 변수가 직접 참조되는 모든 곳에서 특정 방법을 사용하여 코드를 어지럽히는 응용 프로그램과 응용 프로그램의 1000 개 변수 중 3 개에 대한 특수 액세스 양식이 있어야합니다.

그리고 이것은 독립적 인 개인 프로젝트에서 전적으로 작업하는 최상의 시나리오입니다. 모든 것을 공개적으로 접근 가능한 라이브러리로 내 보내면 이러한 문제는 더욱 커질 것입니다.

자바는 매우 장황하며, 이것은 유혹적인 일입니다. 하지마

Java 방식이 OO 방식이라면, 예, 공개 필드로 클래스를 만들면 객체가 자체 내부 상태를 관리해야한다는 정보 숨기기에 대한 원칙이 깨집니다. (따라서 전문 용어를 내뱉는 것이 아니라 정보 숨기기의 장점은 클래스의 내부 작업이 인터페이스 뒤에 숨겨져 있다는 것입니다. 아마도 돌아가서 클래스를 사용하는 클래스를 변경해야 할 것입니다 ...)

또한 JavaBean 네이밍 호환 클래스에 대한 지원을 이용할 수 없으므로 Expression Language를 사용하여 작성된 JavaServer Page에서 클래스를 사용하기로 결정하면 손상 될 수 있습니다.

JavaWorld 기사 Getter 및 Setter 메소드가 악의적 인 기사 인 경우 접근 자 및 변경자 메소드를 구현하지 않을시기에 대해 생각하는 데 관심이있을 수 있습니다.

작은 솔루션을 작성 중이고 관련된 코드의 양을 최소화하려는 경우 Java 방식이 옳지 않을 수 있습니다. 항상 귀하와 해결하려는 문제에 달려 있다고 생각합니다.

저자 가 객체 대신 구조체 (또는 데이터 셔틀) 임을 알고 있다면 해당 유형의 코드에는 아무런 문제가 없습니다 . 많은 Java 개발자는 올바르게 구성된 객체 (java.lang.Object의 서브 클래스가 아니라 특정 도메인 의 실제 객체)와 파인애플 의 차이점을 알 수 없습니다 . Ergo, 객체와 객체가 필요할 때 구조체를 작성합니다.

공개 필드 액세스 사용과 관련된 문제는 팩토리 방법 대신 새 필드를 사용하는 것과 같은 문제입니다. 나중에 마음이 바뀌면 기존의 모든 발신자가 끊어집니다. 따라서 API 진화 관점에서 볼 때 총알을 물고 게터 / 세터를 사용하는 것이 좋습니다.

내가 다른 방향으로가는 곳은 내부 데이터 구조로 사용되는 내부 정적 클래스와 같이 클래스에 대한 액세스를 강력하게 제어하는 ​​것입니다. 이 경우 필드 액세스를 사용하는 것이 훨씬 더 명확 할 수 있습니다.

그런데 e-bartek의 주장에 따르면 Java 7에서 속성 지원이 추가 될 가능성은 거의 없습니다.

코드를 단순화하기 위해 개인 내부 클래스를 만들 때이 패턴을 자주 사용하지만 이러한 객체를 공개 API에 노출하지 않는 것이 좋습니다. 일반적으로 퍼블릭 API의 객체를 변경할 수없는 빈도가 높을수록 'struct-like'객체를 변경할 수 없습니다.

옆으로,이 객체를 개인 내부 클래스로 작성하더라도 객체를 초기화하는 코드를 단순화하는 생성자를 계속 제공합니다. 사용할 수있는 객체를 얻기 위해 3 줄의 코드가 있어야하는 것은 지저분합니다.

아주 오래된 질문이지만 또 다른 짧은 기여를하겠습니다. Java 8에는 람다 식과 메서드 참조가 도입되었습니다. Lambda 표현식은 간단한 메소드 참조 일 수 있으며 "참"본문을 선언하지 않습니다. 그러나 필드를 메소드 참조로 "변환"할 수 없습니다. 그러므로

stream.mapToInt(SomeData1::x)

합법적이지는 않지만

stream.mapToInt(SomeData2::getX)

입니다.

그것이 항상 간단한 구조체가 될 것이고 행동을 결코 붙이고 싶지 않을 것이라는 것을 알고 있다면 해를 보지 않습니다.

이것은 Java 언어가 아닌 객체 지향 디자인에 관한 질문입니다. 일반적으로 클래스 내에서 데이터 유형을 숨기고 클래스 API의 일부인 메소드 만 노출하는 것이 좋습니다. 내부 데이터 형식을 공개하면 나중에 변경할 수 없습니다. 그것들을 숨기면 사용자에게 유일한 의무는 메소드의 반환 및 인수 유형입니다.

여기에서는 5 명의 다른 사람의 이름과 나이를 입력하고 선택 정렬 (연령)을 수행하는 프로그램을 만듭니다. C 프로그래밍 언어와 같은 구조로 작동하는 클래스와 전체 클래스를 수행하기 위해 메인 클래스를 사용했습니다. 아래 코드를 제공하고 있습니다 ...

import java.io.*;

class NameList {
    String name;
    int age;
}

class StructNameAge {
    public static void main(String [] args) throws IOException {

        NameList nl[]=new NameList[5]; // Create new radix of the structure NameList into 'nl' object
        NameList temp=new NameList(); // Create a temporary object of the structure

        BufferedReader br=new BufferedReader(new InputStreamReader(System.in));

        /* Enter data into each radix of 'nl' object */

        for(int i=0; i<5; i++) {
            nl[i]=new NameList(); // Assign the structure into each radix

            System.out.print("Name: ");
            nl[i].name=br.readLine();

            System.out.print("Age: ");
            nl[i].age=Integer.parseInt(br.readLine());

            System.out.println();
        }

        /* Perform the sort (Selection Sort Method) */

        for(int i=0; i<4; i++) {
            for(int j=i+1; j<5; j++) {
                if(nl[i].age>nl[j].age) {
                    temp=nl[i];
                    nl[i]=nl[j];
                    nl[j]=temp;
                }
            }
        }

        /* Print each radix stored in 'nl' object */

        for(int i=0; i<5; i++)
            System.out.println(nl[i].name+" ("+nl[i].age+")");
    }
}

위의 코드는 오류가 없으며 테스트되었습니다 ... 그냥 복사하여 IDE에 붙여 넣으십시오 ... 알고 있습니다. :)

Java에서 메소드를 사용하지 않고 공용 필드를 사용하여 간단한 클래스를 작성할 수 있지만 클래스는 여전히 클래스이며 구문처럼 클래스처럼 메모리 할당 측면에서 처리됩니다. Java에서 구조체를 실제로 재현하는 방법은 없습니다.

때로는 메서드에서 여러 값을 반환해야 할 때 이러한 클래스를 사용합니다. 물론 그러한 개체는 수명이 짧고 가시성이 매우 제한적이므로 괜찮습니다.

대부분의 경우와 마찬가지로 일반적인 규칙이 있으며 특정 상황이 있습니다. 주어진 객체가 어떻게 사용 될지 알 수 있도록 닫힌 캡처 응용 프로그램을 수행하는 경우 가시성과 효율성을 높이기 위해 더 많은 자유를 행사할 수 있습니다. 당신이 통제 할 수없는 다른 사람들이 공개적으로 사용할 클래스를 개발하고 있다면, getter / setter 모델에 의존하십시오. 모든 것과 마찬가지로 상식 만 사용하십시오. 대중과의 첫 라운드를 한 다음 나중에 게터 / 세터로 변경하는 것이 좋습니다.

Aspect 지향 프로그래밍을 사용하면 할당이나 가져 오기를 포착하고 가로 채기 논리를 첨부 할 수 있습니다. 문제를 해결하는 올바른 방법입니다. (공개 또는 보호되어야하는지 또는 패키지로 보호되어야하는지의 문제는 직교입니다.)

따라서 올바른 액세스 규정자가있는 인터셉트되지 않은 필드부터 시작하십시오. 프로그램 요구 사항이 증가함에 따라 논리를 연결하여 유효성을 검사하고 반환되는 객체의 복사본 등을 만듭니다.

게터 / 세터 철학은 필요하지 않은 수많은 간단한 경우에 비용을 부과합니다.

애스펙트 스타일이 더 깨끗한 지 아닌지는 다소 질적입니다. 클래스의 변수 만보 고 논리를 개별적으로 보는 것이 쉽다는 것을 알았습니다. 사실, Apect 지향 프로그래밍의 요점은 많은 관심사가 크로스 커팅되고 클래스 본문 자체에서 구획화하는 것이 이상적이지 않다는 것입니다 (로그 기록의 예-모든 로그를 원하면 Java가 원합니다) 전체 게터를 작성하고 동기화를 유지하지만 AspectJ는 하나의 라이너를 허용합니다).

IDE의 문제는 청각입니다. 입력 / 설정에서 발생하는 읽기 및 시각적 오염만큼 타이핑이 아닙니다.

어노테이션은 언뜻보기에는 어 스펙트 지향 프로그래밍과 비슷해 보이지만 AspectJ의 간결한 와일드 카드와 같은 포인트 컷 스펙과 달리 어노테이션을 첨부하여 포인트 컷을 철저하게 열거해야합니다.

AspectJ에 대한 인식으로 사람들이 동적 언어에 조기에 정착하지 못하게되기를 바랍니다.