인터페이스 설계 사상
6274 단어 이음매
인터페이스를 이해하기 전에 반드시 대상을 대상으로 하는 것을 이해해야 한다. 왜냐하면 인터페이스를 대상으로 하는 것은 대상을 대상으로 하는 역사의 경험에 따라 파생된 사상이기 때문이다.대상을 대상으로 하는 과정에서 모든 것이 대상이고 대상은 독립성을 가진다. 대상은 반드시 내부 상태를 유지하고 모든 외부의 방해를 피해야 한다.따라서 대상을 대상으로 대부분의 필드는 개인적이어야 하며, 제한된 공개 인터페이스를 제공하여 이 필드에 접근해야 한다.예:
class {
private string ;
public string get (){
return this. ;
}
}초보자들은 왜 이 필드를 직접 공개하지 않고 get 이름의 함수를 써야 책의 이름을 얻을 수 있느냐고 자주 묻는다.대상을 대상으로 하는 전문가들은 이런 종류의 봉인성(즉 독립성)을 위해서라고 대답한다.이름이라는 필드는 외부에 있어서는 읽기만 하고 쓸 수 없는 것이다.
대상을 대상으로 대상의 독립성을 강조함으로써 높은 코드 중용률을 확보하고 유형의 학습 원가를 낮춘다(내부 세부 사항에 신경 쓸 필요가 없다).그러나 세계 만물은 모두 관련이 있다는 사실을 잊어버렸다.그래서 두 대상이 연락을 하기 시작했을 때 번거로운 문제가 생겼다.예를 들어 현재 한 사람이 추가된 유형:
class {
public void ( a){
( a.get () )
}
}사람은 책을 읽을 수 있지만 책도 읽을 수 있다.그렇다면 독서라는 조작이 사람에 속하는지 책에 속하는지 대상을 대상으로 하는 것에는 구분이 없다.책 자체가 하나의 독립된 대상이지만 사람은 책을 읽을 때 책의 봉인성을 깨뜨릴 수밖에 없다. 사람은 책의 내용과 더 많은 세부 사항을 읽어야 한다.봉인 사상을 붙잡고 놓지 않으면 책에 API를 늘려야만 책이 진정으로 읽힐 수 있다. 한 대상이 어떤 API를 제공하는지는 수요에 따라 결정된다.만약 수요가 많다면 책의 API가 매우 많을 것이다. 다른 사람들이 이 원본을 읽을 때 원래 매우 간단한 대상이지만 왜 쓰는지 모르는 API가 많다.많은 API는 특정한 수요를 위해 작성된 것으로, 저자는 단지 개인 필드에 접근하기 편리하도록 이 대상에 끼워 넣었다.이런 코드 디자인은 사실상 대상을 향한 초지에서 벗어났지만 작가에게 프로젝트를 완성하는 것이 중점이다.그래서 그들은 이런 절충 방식을 선택했다. API는 마음대로 추가한다. 어차피 방문 목표에 도달하면 되고 봉인을 깨면 어때?그래서 전문가가 있어야만 처음부터 어떤 대상과 API를 설계할 수 있고 진정으로 대상을 대상으로 하는 코드를 쓸 수 있다는 의견도 있다. 이런 전문가들은 소프트웨어 구조사라고 불린다.대상을 향해 거절하고 대상 간의 관계를 말하지 않기 때문에 처음에 좋은 코드가 마지막에는 서로 인용하기 어려운 유지보수하기 어려운 코드가 된다.
대상을 향한 더 많은 결함에 관해서는 다른 문장을 볼 수 있다. 객체 중심 설계 트랩
다음은 인터페이스를 향한 소개입니다.인터페이스를 향해 똑같은 모든 것이 대상이지만 대상을 두 종류로 나눈다. 생물과 비생물이다.비생물은 생명이 없는 대상이다. 예를 들면 책 한 권, 컴퓨터 한 권.프로그램에서 비생물은 항상 수동적이다. 예를 들어 공 자체는 날 수 없고, 그것은 차서 날아갈 수밖에 없다.생물은 능력의 소유자를 대표한다. 비생물을 처리할 수 있고 기억할 수 있으며 다른 생물과 소통할 수 있다.
예를 들어 현실 장면: 샤오밍의 컴퓨터가 고장난 후에 샤오강이 수리하러 간다.여기에는 사실 세 가지 대상이 있는데 그것이 바로 샤오밍, 샤오강, 컴퓨터다.샤오밍과 샤오강은 생물이고 컴퓨터는 비생물이라는 것은 누구나 다 안다.샤오밍은 이런 일을 해야 한다.그가 컴퓨터 한 대를 가지고 있다는 것을 기억해라. 이것은 그의 사유재산이다.2. 샤오강에게 컴퓨터를 고치러 가라고 통지하고 그의 사유재산을 샤오강에게 전달한다.샤오강은 컴퓨터 수리(누구의 컴퓨터든)를 해야 한다.컴퓨터는 비생물이기 때문에 어떤 일도 할 수 없다.그렇다면 인터페이스를 향해 어떻게 이 현실 문제를 코드 표시로 바꿉니까?
원칙1: 모든 비생물은 어떠한 봉인성도 갖추지 못한다.
컴퓨터를 예로 들면, 비록 우리는 항상 컴퓨터를 하나의 독립된 전체로 간주하지만, 확실히 일부 시간이 존재하고, 그것의 부품은 흩어진 것이다.컴퓨터 자체는 사고 능력이 없어서 자신이 반드시 완전하고 쓸 수 있는 상태에 있다는 것을 보장할 수 없다.따라서 비생물에 대해 말하자면 내부에서 하나의 상태를 유지할 필요가 없다.그러나 한가한 사람들이 망가지지 않도록 보호할 필요가 있지만 강제적인 조치는 아니다.마치 네가 컴퓨터를 망가뜨린 것 같다. 네가 잘못한 것은 컴퓨터의 질이 나빠서가 아니다. (물론 좋은 컴퓨터는 함부로 망가지지 않는다.)
원칙2: 모든 생물은 봉인성을 가지고 있다.
예를 들어 샤오밍이 가지고 있는 컴퓨터는 그의 사유재산이다. 그가 원하지 않으면 아무도 그의 컴퓨터를 사용할 수 없다.만약 샤오밍이 자발적으로 그가 컴퓨터를 가지고 있다는 것을 잊어버린다면, 이 컴퓨터와 샤오밍은 어떠한 연락도 잃게 될 것이다.
원칙3: 옳고 그름.
예를 들어 샤오밍의 컴퓨터가 고장났다고 해서 그가 반드시 샤오강에게 맡겨야 하는 것은 아니다. 그는 컴퓨터를 수리할 줄 아는 사람에게 맡기면 된다. 단지 샤오강이 요구에 부합했을 뿐이다.
위의 원칙과 같이 상술한 현실 문제를 코드로 묘사하면 다음과 같아야 한다.
class {
public bool ;
}
class {
private a;
public void ( b){
b. (a);
}
}
class : {
public void ( a) {
a. = true;
}
}위 코드와 객체 지향 코드의 차이점:
1. 컴퓨터는 공공 필드를 가지고 있다. 컴퓨터는 비생물이기 때문에 봉인할 필요가 없다.
2. 컴퓨터를 고치러 가는 파라미터는 샤오강이가 아니라 컴퓨터를 고칠 줄 아는 사람이다.
원칙4: 능력은 언제든지 확장할 수 있다.
상기 세 가지 원칙은 사실 인터페이스를 향한 장점을 나타내지 않고 진정한 장점은 원칙 4에 있다.현실에서 너는 여전히 너지만, 너의 능력은 끊임없이 성장하고 있다.대상을 대상으로 하는 데는 대상이 독립적으로 봉인되어 있기 때문에 대상이 선천적으로 어떤 능력을 가지고 있는지 결정한다.그러나 인터페이스를 향한 능력은 후기에 확장될 수 있다.
예를 들어 원래 컴퓨터를 수리할 줄 아는 사람은 샤오강일 뿐이다. 뒤에 샤오밍도 스스로 컴퓨터를 수리할 줄 알게 되면 심지어 스스로 컴퓨터를 수리할 수 있다.이 수정은 원본 코드에서 진행할 필요가 없다.원본 코드는 이러한 현실 논리를 잘 구현했기 때문에 샤오밍이 스스로 고치든 말든 원래의 디자인은 변하지 않는다.한 대상이 여러 가지 능력을 가질 수 있고 다방면으로 사용될 수 있으며 능력은 선천적일 수도 있고 후기에 확장될 수도 있다.상례 코드에 대해 현재 다음과 같은 코드를 통해 소명에게 컴퓨터를 수리하는 능력을 증가시킬 수 있다.
extend : {
public void ( a){
//
}
}지금까지 인터페이스라는 두 글자를 언급하지 않은 것 같다.인터페이스는 사실 하나의 증서이다. 한 생물이 어떤 능력을 가지고 있는지 약속하는 데 쓰인다.상례에서'컴퓨터를 수리할 줄 아는 사람'은 바로 능력의 약속이다. 즉, 그것은 하나의 인터페이스이다.이론적으로 모든 능력은 인터페이스로 묘사할 수 있지만 이것은 분명히 현실적이지 않다. (생활 속에서 어떤 능력에 대해서도 증서를 제공할 수 없다. 밥을 지을 줄 아는 증서? 글씨를 쓸 줄 아는 증서?)따라서 우리는 같은 종류의 생물을 사용하여 대여를 한다. 예를 들어 샤오강은 컴퓨터를 수리할 줄 아는 사람이면 샤오강으로 컴퓨터를 수리할 줄 아는 모든 사람을 대여한다(평소 말했듯이 이웃집 아이가 각종 능력을 가진 아이를 대여한다).
인터페이스를 향해 우리는 모든 생물이 처음에는 아무런 능력이 없고 모든 능력은 후기에 필요에 따라 제공된다고 가정한다.그러나 이런 능력은 이 생물 자체의 자산과 관계가 없다.
좋은 웹페이지 즐겨찾기
