'10.03.29 story

여러분은 오직 상호작용할 필요가 있는 클래스만 고객에게 노출시켜야 한다

고객 코드가 상호작용하지 않는 클래스는 고객 코드에 최소한의 영향만 주고 변경될 수 있다.

 

Subway

stations : Station[*] connections : Connection[*]

addStation(Station) hasStation(String) : boolean addConnection(Connection)

이렇게 만드는 것이 더 객체지향적이지 않느냐~

하지만 그렇게 되면 Application의 내부를 밖으로 노출하게 된다

위의 코드를 보면 지하철을 만드는데 Station이나 Connection객체를 사용할 필요가 없다

단지 새로운 Subway클래스만이 필요할 뿐이다

Subway클래스를 사용하는 콛가 Station과 Connection클래스들을 직접사용하기 때문에, 그 코드는 우리가 Station과 Connection클래스를 어떻게 구현하느냐에 의존하게 된다

Subway

stations : Station[*] connections : Connection[*]

addStation(String) hasStation(String) : boolean addConnection(String, String, String)

이 Application에서, 우리가 Station과 Connection이 동작하는 방식을 변경하더라도 , 오직 Subway객체만 사용하는 코드에는 영향을 주지 않을 것이다. 그들은 우리의 구현상의 변경으로부터 보호받고 있다.

 

디자인결정은 좋은 객체지향원리뿐만 아니라 여러분의 시스템이 어떻게 사용될 것인가에 근거하고 있다.

 

우리는 항상 가능한 한 읽기 쉽게 코드를 작성하도록 노력해야한다.

 

AutoMobile에 클래스에 대한 SRP분석

AutoMobile이 자신을 start한다

AutoMobile이 자신을 stop한다

AutoMobile이 자신을 drive한다

AutoMobile이 자신을 changesTires한다

AutoMobile이 자신을 getOil한다

AutoMobile이 자신을 checkOil한다

 

Class_name이 자신을 메소드한다

추상 메소드 공식

A = NA/NC

 

A : 추상적 메트릭(abstractness metric)

NA : 특정 패키지나 모듈내에서 추상 클래스의 개수(인터페이스도 포함)

NC : 같은 패키지나 모듈내에서 클래스 전체의 개수

 

추상화가 많이 된 패키지는 A값이 크고, 적게 사용된 패키지는 A값이 작다. 일반적으로 우리는 각 패키지가 A값이 큰 패키지에만 의존하게 하고 싶을 것이다. 즉, 우리의 패키지가 항상 보다 추상적인 패키지에 의존하게 된다. 결과는 변화에 쉽게 대응하는 소프트웨어일 것이다.

 

시퀀스 다이어그램

액터와 시스템 사이에 일어나는 상호작용

 

상태 다이어그램(STATE DIAGRAM)

이 다이어그램은 시스템의 다양한 상태와 상태르르 변화시키는 액션을 나타냄으로써, 시스템의 일부를 설명한다. 이 다이어그램은 복잡한 행동을 그림으로 설명하는데 좋다.

 

단위 테스팅

입력 데이터의 집합이나 일련의 메소드 호출을 통해 각 클래스를 테스트한다.

다행스럽게도 기능의 매우 작은 조각뿐만 아니라 커다란 조각들까지 자동적으로 테스트할 수 있는 테스팅 프레임웍이 있다.

 

코딩 규칙과 읽기 쉬운 코드

읽기 쉬운 코드를 작성하면 개발들이 그 코드를 더 쉽게 유지보수하고 재사용할 수 있다.

 

리팩토링

리팩토링은 코드의 기능은 바꾸지 않으면서 코드의 구조를 변경하는 프로세스이다. 리팩토링은 코드를 잘 정돈하고, 유연성과 확장성을 높이기 위해 사용되며, 디자인의 향상과 관련되어 있다.

EFFECTIVE JAVA

 

serializable 인터페이스를 분별력 있게 구현하자

 

만일 기본 직렬화 형태를 사용하고 나중에 그 클래스의 내부 구현을 변경한다면, 변경으로 인해 직렬화 형태가 호환되지 않을 수 있다. 그러므로 긴 기간 동안 사용할 수 있는 고품질의 직렬화 형태를 신중하게 설계해야 한다. 그렇게 하면 개발 초기 비용은 더 들어 가겠지만, 그런 노력을 할 만한 가치는 있다. 잘 설계된 직렬화 형태에서 조차 클래스의 진화에 제약을 주는데, 하물며 잘못 설계된 직렬화 형태는 오죽하겠는가? 심각한 타격을 줄 수 있다.

 

직렬화를 수반하면서 클래스 진화를 제약하는 간단한 예로, 직렬화 버전 UID라고 더 많이 알려진 스트림 고유 식별자가 있다. 직렬화가 가능한 모든 클래스는 고유 식별 번호를 갖는다. static final long 필드인 serialVersionID를 명시적으로 선언하여 지정하지 않으면 시스템이 복잡한 절찰ㄹ 사용하여 지정해준다.

 

Serializable을 구현하는데 들어가는 두 번째 비용은 결함과 보안상의 허점을 증대시키기 때문에 발생한다.

Serializable을 구현하는데 들어가는 세 번째 비용은 새 버전의 클래스 배포와 관련해서 부담을 증대시키기 때문에 발생한다.Serializable 인터페이스의 구현은 쉽게 결정할 일이 아니다. 직렬화는 실질적인 이점을 제공하며,객체의 전송이나 영속성을 직렬화에 의존하는 프레임워크와 관계되는 클래스라면 필수적이다. 또한 Serializable을 반드시 구현해야 하는 다른 클래스의 컴포넌트로써 클래스를 굉장히 쉽게 사용할 수 있다. 그러나 비용이 만만치 않다.

 

상속을 위해 설계된 클래스들은 Serializable을 구현할 필요 없으며, 그런 목적의 인터페이스 역시 Serializable을 확장할 필요가 없다.

 

내부 클래스에서는 Serializable을 구현하면 안된다. 내부 클래스는 컴파일러가 생성한 대용 필드를 사용하는데, 이 필드에는 외곽 인스턴스에 대한 참조와 외곽 인스턴스의 유효범위에 있는 지역 변수들의 값을 저장한다. 그러므로 내부클래스의 기본 직렬화 형태는 정의가 불분명하다. 그러나 static 멤버 클래스는 Serializable을 구현할 수 있다.

 

요약하면, Serialzable 인터페이스의 구현이 쉽다는 것은 허울에 지나지 않는다. 클래스를 잠깐만 쓰고 버릴 거라면 몰라도, 그렇지 않다면 Serializable의 구현은 신중하게 해야한다. 상속을 위해 설계된 클래스는 특별한 주의가 필요하다. 그런 클래스의 경우는 서브 클래스에서 Serializable을 구현할 수 있게 하는 것과 구현을 막는 것을 절충하는 설계 관점이 필요한데, 그것은 매개 변수가 없고 접근 가능한 생성자를 제공하는 것이다. 그리고 그렇게 함으로써 서브 클래스에서 Serializable을 구현할 수 있다.