프로그래머 팀이 새로운 유틸리티 클래스에 대해 제안 된 API를 검토하고 있습니다. 일부 토론을 마친 후에 그들은 기능을 잃지 않고 API의 메서드 수를 줄일 수 있다는 것을 알고 있습니다. 그들이 새로운 디자인을 구현한다면, 두 개의 OO 원칙은 이 될 것입니다.scjp 질문에 관한 디자인
A. Looser coupling B. Tighter coupling C. Lower cohesion D. Higher cohesion E. Weaker encapsulation F. Stronger encapsulation
누군가가 대답 무엇인지 말씀해 주시겠습니까?
내 대답은
패자 커플 링 및 높은 응집력
될 것인가? 나는이 기사를 진행하는 데 제안 :
http://blog.sanaulla.info/2008/06/26/cohesion-and-coupling-two-oo-design-principles/
메서드가 기능을 잃지 않고 제거 될 수 있기 때문에 응집력이라고 생각하지 않습니다. 이것은 클래스의 전체 기능이 변경되지 않았 음을 나타냅니다. –
@Robin Green 같은 방법을 여러 용도로 사용하면 기능에 영향을 미치지 않고 제거하는 것이 어려울 것입니다. 응집력에 대한 자세한 내용은 제공된 링크를 확인하십시오. – GuruKulki
귀하의 의견에 동의하지만 질문과 관련이 없습니다! 당신은 * 이전 * 디자인에 대해 모호한 가정을하고 있습니다. (응집력이 있습니다.)하지만, 문제는 * 이전 * 디자인에 대해 묻지 않기 때문에 중요하지 않습니다. * 새로운 * 디자인을 묻습니다! –
나는 첫째, 더 강력한 캡슐화라고 말할 수 있습니다. 더 이상 API에없는 메소드 (즉, 비공개 또는 삭제 된 메소드)가 나머지 "상위 레벨"메소드를 통해 계속 액세스 할 수있는 "저수준"기능을 제공한다고 가정합니다. 나는 그것이 당신이 가정 한 것으로 생각합니다. 이 경우 메소드에 대한 인수의 수와 유형, 메소드의 이름 및 리턴 유형을 자유롭게 변경할 수 있기 때문에 캡슐화 기능을 향상 시키거나 메소드를 완전히 삭제하고 기능을 호출자 (caller)로 접을 수 있기 때문에 캡슐화 기능이 향상되었습니다. API 클라이언트에 영향을 미치지 않습니다.
오 죄송합니다, 어느 두? 클래스와 클라이언트 간의 연결 지점이 적어지고 서로 다른 방식으로 문제를 해결할 기회가 적기 때문에 느슨한 연결을 촉진합니다. 다음 질문이 이유 인 경우
@Suresh 나는 당신의 의견을 이해하지 않습니다. –
이 숙제가 있습니까? 시험 문제 샘플? –
java의 Math 클래스는 유틸리티 API입니다. 그들의 방법을보십시오. –