[Effective Objective-C] #22 NSCopying 프로토콜을 이해하라. [Effective Objective-C] #22 NSCopying 프로토콜을 이해하라. 출처 : Effective Objective-C -오브젝티브-C 에서는 copy 메서드를 이용하여 객체를 복사할 수 있다.자신이 만든 클래스가 복사될 수 있게 하려면 메서드가 하나뿐인 NSCopying 프로토콜을 구현하면 된다.- (id)copyWithZone:(NSZone*)zone -모든 앱이 단일 존(기본 존)을 가진다.그래서 이 메서드를 구현할 때 zone 파라미터는 무시해도 된다. -copy 메서드는 NSObject 내에서 구현되어 있다.그리고 기본 존을 이용해 copyWithZone: 을 호출한다.그냥 copy 를 재정의하고 싶겠지만 꼭 copyWithZone: 을 대신 구현해야 한다.- (id)copyW.. 2017. 9. 2. [Effective Objective-C] #3 메서드보다는 같은 일을 하는 리터럴 문법을 사용하라 [Effective Objective-C] #3 메서드보다는 같은 일을 하는 리터럴 문법을 사용하라 출처 : Effective Objective-C -NSString, NSNumber, NSArray, NSDictionary 인스턴스 모두 리터럴 문법을 지원한다. -리터럴 문법을 사용하면 소스 코드 크기가 줄고 코드가 읽기 쉬워진다. 리터럴 숫자 -정수, 실수, 불린 값을 Objective-C 로 감쌀(wrapping) 필요가 있다.이는 숫자 타입을 다룰 수 있는 NSNumber 클래스를 이용해 할 수 있다. -리터럴을 쓰지 않으면 다음과 같이 생성한다.NSNumber *number = [NSNumber numberWithInt:1]; 그러나 리터럴을 사용하면 이렇게 간단하다.NSNumber *numbe.. 2017. 7. 20. [Effective Java] 스레드 안전을 문서화 하자. [Effective Java] 스레드 안전을 문서화 하자. - 클래스 행동을 문서화하지 않으면, 프로그래머는 가정에 의존해서 그 클래스를 사용해야 한다. 만일 그런 가정들이 잘못되면, 그로 인한 프로그램은 불충분한 동기화나 과도한 동기화를 하게 될 것이다. 어떤 경우든, 심각한 에러가 유발될 수 있다. - 메소드 선언부의 synchronized 변경자는 메소드의 상세 구현 부분이지 외부로 제공되는 API 가 아니다. 즉 Javadoc 에 synchronized 가 공개되지 않는다. synchronized 변경자가 있다는 것이 스레드 안전을 문서화하기에 충분한 것은 아니다. 동시적 사용을 안전하게 하려면, 해당 클래스가 어떤 수준의 스레드 안전을 지원하는지 명확하게 문서화해야 한다. - 다음은 스레드 안전.. 2017. 3. 14. [Effective Java] 잘 판단해서 최적화하자 [Effective Java] 잘 판단해서 최적화하자 - 최적화에 대한 명언이 있다. 더 많은 컴퓨팅 죄악이 다른 어떤 한 가지 이유(무지로 인한 어리석음을 포함해서)보다는 효율성(달성이 안 되는)의 이름으로 저질러진다. 사소한 효율성은 잊어야 한다. 97%의 시간에 대해 논하자. 성급한 최적화는 모든 죄악의 근원이다. 최적화에 관한 두 가지 규칙을 따르자. 규칙 1. 하지 말자. 규칙 2. (전문가에 한해서). 아직 하지 말자. 정말 최적화되지 않은 솔루션이 있을 때까지는. - 성급한 최적화는 얻는 것보다 잃는 것이 더 많기 쉽다. 최적화를 하면서 빠르지도 않고 제대로 동작하지도 않으며, 문제를 쉽게 해결하기도 어려운 소프트웨어를 만들기도 쉽다. - 성능 때문에 훌륭한 아키텍쳐 원리를 포기하지 말자. .. 2017. 2. 16. [Effective Java] 필요하면 방어 복사본을 만들자. [Effective Java] 필요하면 방어 복사본을 만들자. - 자바는 꽤나 안전한 언어이지만, 우리 클래스의 클라이언트가 불변 규칙을 파괴하기 위해 최선을 다할 거라는 가정하에 방어적으로 프로그램을 작성해야 한다. - 가변 객체인 매개 변수는 각각의 방어복사본(defensive copy)을 만들어서 생성자에 전달해야 한다. 그렇지 않으면 예상치 못한 여러 상황이 발생할 수 있다. - 방어복사본은 매개 변수의 유효성 검사에 앞서 만들어야 하며, 유효성 검사는 원본이 아닌 복사본을 대상으로 해야 한다!! ( TOCTOU 공격 ( 검사시간/사용시간) 이슈 ) - clone 은 위험한 복사방법이므로 가급적이면 다른 방법으로 복제하자. final 이 아닌 Class 는 sub class 가 clone 을 상속.. 2017. 1. 10. [Effective Java] 클래스와 그 멤버의 접근성을 최소화하자. [Effective Java] 클래스와 그 멤버의 접근성을 최소화하자. - 잘 설계된 모듈과 그렇지 않은 것을 구분 짓는 가장 중요한 잣대는, 모듈 자신의 내부 데이터 및 그 외의 상세한 구현 부분을 다른 모듈로부터 어느 정도로 숨기느냐에 달려 있다. - 모듈은 자신의 API 를 통해서만 다른 모듈과 상호작용한다. 정보 은닉(information hiding) 또는 캡슐화(encapsulation)이 그것이다. - 정보 은닉은 시스템을 구성하는 모듈들 간의 결합도를 낮추어(decoupling) 모듈 별로 개발, 테스트, 최적화, 사용 및 수정이 가능하도록 한다. 또한 이렇게 하면 병행 개발 ( parallel development ) 를 할 수 있어 시스템 개발이 빨라진다. 모듈을 더 빨리 파악할 수 있.. 2016. 10. 17. [Effective Java] 불필요한 객체의 생성을 피하자. 불필요한 객체의 생성을 피하자. - 기능적으로 동일한 객체를 필요할 때마다 매번 새로 생성하기보다는 하나의 객체를 재사용하는 것이 좋을 때가 많다. 재사용을 하면 객체 생성에 소요되는 비용(시간과 자원)이 절감되어 실행 속도가 더 빨라지고 코드도 보기 좋게 작성할 수 있다. 불변(immutable) 객체는 항상 재사용이 가능하다. - 불 필요한 객체 생성을 막기 위한 첫번째 좋은 방법은 static 팩토리 메소드를 사용하는 것이다. - 불변객체가 아닌 가변객체더라도 상태가 변경되지 않는 것이 보장되면 재사용 가능하다. - 재사용을 막기 위한 static 팩토리 메소드에서 늦 초기화 ( lazy initialization ) 을 하는 경우가 있는데, 후에 다루겠지만 두드러진 성능 개선이 나타나진 않고, 오.. 2015. 4. 30. 반응형 이전 1 다음
