Java76 [Java] Java는 Call by value? Call by reference? 안녕하세요~ 잭코딩입니다! 이번 내용에서는 Call by value와 Call by reference를 살펴보고 Java는 어떠한 방식인지 예제를 통해 알아볼까요? 자바에서 메서드(함수)를 정의한 후 필요한 변수 or 객체를 인자 값으로 받아온다 이때, 인자 값을 어떤 식으로 받아 올 것인지에 대한 방식이다 Call by value (값에 의한 호출) '값'을 넘겨주는 호출 방식 Call by reference (참조에 의한 호출) '참조값(주소 혹은 포인터)을 넘겨주는 호출 방식' 1. 자바의 기본형(Primitive Type)의 경우는 Call by value이다 (기본형 : boolean, char, byte, short, int, long, float, double) public class Mai.. 2020. 9. 18. [이펙티브자바 3판] ITEM16. public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라 이번장의 핵심은... public 클래스는 절대 가변 필드를 직접 노출해서는 안 된다 불변 필드라면 노출해도 덜 위험하지만 완전히 안심할 수는 없다 하지만, package-private 클래스나 private 중첩 클래스에서는 종종 (불변이든 가변이든) 필드를 노출하는 편이 나을 때도 있다 우선 아래의 퇴보한 클래스를 보자 class Point { public double x; public double y; } 왜 퇴보한 클래스인가? 단순히 인스턴스 필드들을 모아놓는 일 외에는 아무 목적이 없는 퇴보한 클래스이다 데이터 필드에 직접 접근할 수 있으니 캡슐화 이점도 없다 API를 수정하지 않고도 내부 표현을 바꿀 수 있고, 불변식을 보장할 수 없다 외부에서 필드에 접근할 때 부수 작업을 수행할 수도 없다 .. 2020. 9. 18. [이펙티브자바 3판] ITEM15. 클래스와 멤버의 접근 권한을 최소화하라 이번장의 핵심은... 프로그램 요소의 접근성은 가능한 한 최소한으로 하자 꼭 필요한 것만 골라 최소한의 public API를 설계하자 그 외에는 클래스, 인터페이스, 멤버가 의도치 않게 API로 공개되는 일이 없도록 해야 한다 public 클래스는 상수용 public static final 필드 외에는 어떠한 public 필드를 가져서는 안 된다 public static final 필드가 참조하는 객체가 불변인지 확인하자 정보 은닉(캡슐화)의 장점 컴포넌트를 서로 독립시켜서 개발, 테스트, 최적화, 적용, 분석, 수정을 개별적으로 할 수 있게 해 준다 1. 시스템 개발 속도를 높인다 (여러 컴포넌트를 병렬로 개발할 수 있다) 2. 시스템 관리 비용을 낮춘다 각 컴포넌트를 더 빨리 파악하여 디버깅할 수 있.. 2020. 9. 16. [이펙티브자바 3판] ITEM14. Comparable을 구현할지 고려하라 이번장의 핵심은... 순서를 고려해야 하는 값 클래스를 작성한다면 꼭 Comparable 인터페이스를 구현하여, 그 인터페이스들을 쉽게 정렬하고, 검색하고, 비교 기능을 제공하는 컬렉션과 어우러지도록 해야 한다 compareTo() 메서드에서 필드의 값을 비교할 때, ""연산자는 쓰지 말도록 하자 대신 박싱된 기본 타입 클래스가 제공하는 정적 compare() 메서드나 Comparator 인터페이스가 제공하는 비교자 생성 메서드를 사용하자 Comparable 인터페이스 compareTo()는 Object의 메서드가 아니다 성격은 2가지만 빼면 Object의 equals()와 같다 compareTo()는 단순 동치성 비교에 더해 순서까지 비교할 수 있다 Comparable을 구현했다는 것은 해당 클래스의 .. 2020. 9. 14. [이펙티브자바 3판] ITEM13. clone 재정의는 주의해서 진행하라 이번장의 핵심은... 새로운 인터페이스를 만들 때는 절대 Cloneable을 확장해서는 안되며, 새로운 클래스도 이를 구현해서는 안 된다. final 클래스라면 Cloneable을 구현해도 위험이 크지 않지만, 성능 최적화 관점에서 검토한 후 별다른 문제가 없을 때만 드물게 허용해야 한다. 기본 원칙은 '복제 기능은 생성자와 팩토리를 이용하는 게 최고'라는 것이다. 단, 배열만은 clone 메서드 방식이 가장 깔끔하고, 이 규칙의 합당한 예외로 볼 수 있다. Cloneable 인터페이스 클래스에서 clone을 재정의 하기 위해선 해당 클래스에 Cloneable 인터페이스를 상속받아 구현해야 한다 그런데 clone 메소드는 Cloneable 인터페이스가 아닌 Object에 선언되어 있다 Cloneable .. 2020. 9. 13. [이펙티브자바 3판] ITEM12. toString을 항상 재정의하라 이번장의 핵심은... 모든 구체 클래스에서 Object의 toString을 재정의하자 상위 클래스에서 이미 알맞게 재정의한 경우는 예외이다 toString은 해당 객체에 관한 명확하고 유용한 정보를 읽기 좋은 형태로 반환해야 한다 Object의 Default toString 메서드는 작성한 클래스의 적합한 문자열을 반환하는 경우는 거의 없다 1. Object의 Default toString 메서드는 단순히 클래스 이름@16진수 해쉬 코드를 반환한다 ex) 클래스 이름이 Jackcoding이면, Jackcoding@adbbd 2. toString의 일반 규약에 따르면 '간결하고 사람이 읽기 쉬운 형태의 유익한 정보'를 반환해야 한다 3. toString을 잘 구현한 클래스는 사용하기에 즐겁고, 디버깅이 쉽.. 2020. 9. 12. [이펙티브자바 3판] ITEM11. equals를 재정의하려거든 hashCode도 재정의하라 이번장의 핵심은... equals()를 재정의할 때는 hashCode()도 반드시 재정의해야 한다 그렇지 않으면 프로그램이 제대로 동작하지 않을 것이다 재정의한 hashCode는 Object의 API 문서에 기술된 일반 규약을 따라야 하며, 서로 다른 인스턴스라면 되도록 해시코드도 서로 다르게 구현해야 한다 AutoValue 프레임워크를 사용하면 멋진 equals와 hashCode를 자동으로 만들어준다 equals()를 재정의했다면 hashCode도 재정의하자 만약 equals()를 재정의했는데, hashCode를 재정의하지 않았다면, 해당 클래스의 인스턴스를 HashMap이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제를 일으킬 수 있다 Object 명세에서 발췌한 규약은 아래와 같다 1. eq.. 2020. 9. 12. 이전 1 ··· 6 7 8 9 10 11 다음
