단일 직책 원칙: MVP 모드 로 Activity 디 결합
14005 단어 디자인 모드
단일 직책 원칙 (SRP: Single responsibility principle) 은 단일 기능 원칙 이 라 고도 부 르 는데 그 정 의 는 한 가지 유형 으로 변 화 를 일 으 킬 수 있 는 원인 만 있어 야 한다.개념 만 봐 도 골 치 아 프 니까 제 가 먼저 작은 예 를 들 어 볼 게 요.
2. 단일 직책 원칙 으로 어떤 문 제 를 해결 할 수 있 습 니까?
우리 의 안 드 로 이 드 개발 경험 을 돌 이 켜 보면 많은 사람들 이 Activity 류 의 코드 가 자신 도 모 르 게 많이 변 한 다 는 것 을 알 게 될 것 이 고, 이 는 우리 코드 를 읽 는 사람들 을 매우 고 통 스 럽 게 할 것 이다.이런 상황 을 초래 한 이유 중 하 나 는 Activity 에서 사용자 와 대량의 상호작용 을 해 야 하기 때 문 입 니 다. 사용자 의 조작 은 Activity 가 현재 표시 하 는 인터페이스 요소 / 대응 하 는 정 보 를 바 꿀 수 있 기 때문에 우 리 는 항상 Model, View, 클릭 이벤트 등 을... 조작 을 모두 Activity 에 넣 었 지만 심각 한 문제 가 존재 합 니 다.머리 없 이 Activity 에 코드 를 추가 하면 Activity 를 비대 하고 구조 가 혼 란 스 러 우 며 직책 이 모호 해 질 것 이다. 특히 이전에 이 프로젝트 를 맡 았 던 엔지니어 가 이 직 했 기 때문에 새로 입사 한 엔지니어 가 이 Activity 를 재 구성 해 야 할 때 반드시 죽 고 싶 어 할 것 이다.
그러면 우 리 는 어떻게 Activity 의 결합 을 풀 어야 합 니까?저 는 먼저 작은 Demo 를 통 해 단일 직책 원칙 의 사상 을 Activity 로 결합 시 켰 습 니 다. 상세 한 내용 은 다음 과 같 습 니 다.
public class Data {
private String btn1Str = "btn1 Clicked 1";
private String btn2Str = "btn2 Clicked 1";
private String btn3Str = "btn3 Clicked 1";
private String btn4Str = "btn4 Clicked 1";
public String getData(int index){
if(index == 1)
return btn1Str;
else if(index == 2)
return btn2Str;
else if(index == 3)
return btn3Str;
else
return btn4Str;
}
public void setData(int index,String str){
if(index == 1)
btn1Str = str;
else if(index == 2)
btn2Str = str;
else if(index == 3)
btn3Str = str;
else
btn4Str = str;
}
} import android.app.Activity;
import android.os.Bundle;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.Button;
public class MainActivity extends Activity implements OnClickListener{
private Button btn1;
private Button btn2;
private Button btn3;
private Button btn4;
private Data data = new Data();
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
btn1 = (Button)findViewById(R.id.button1);
btn2 = (Button)findViewById(R.id.button2);
btn3 = (Button)findViewById(R.id.button3);
btn4 = (Button)findViewById(R.id.button4);
btn1.setOnClickListener(this);
btn2.setOnClickListener(this);
btn3.setOnClickListener(this);
btn4.setOnClickListener(this);
}
public void updateData(){
//
}
@Override
public void onClick(View v) {
switch(v.getId()){
case R.id.button1:
btn1.setText(data.getData(1));
break;
case R.id.button2:
btn2.setText(data.getData(2));
break;
case R.id.button3:
btn3.setText(data.getData(3));
break;
case R.id.button4:
btn4.setText(data.getData(4));
break;
}
}
}데모 에서 우 리 는 모든 관련 조작 이 Activity 에서 진행 되 고 있다 는 것 을 알 수 있다. 이것 은 매우 간단 한 페이지 일 뿐 업무 논리 가 전혀 존재 하지 않 는 다 고 할 수 있다.업무 논리 가 복잡 한 페이지 로 바 뀌 었 는데 놀 필요 가 있 습 니까?다음은 사고방식 을 바 꾸 고 MVP 모드 로 결합 을 해제 합 니 다.
public class Presenter {
private Data data;
private IView iView;
public Presenter(IView iView) {
this.iView = iView;
data = new Data();
}
public Data getData(){
return data;
}
public void setData(int index,String str){
//
data.setData(index, str);
updateView();
}
private void updateView(){
iView.updateView(data);
}
} public interface IView {
public void updateView(Data data);
} import android.app.Activity;
import android.os.Bundle;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.Button;
public class MainActivity extends Activity implements IView,OnClickListener{
private Button btn1;
private Button btn2;
private Button btn3;
private Button btn4;
private Presenter presenter;
private Data data = new Data();
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
btn1 = (Button)findViewById(R.id.button1);
btn2 = (Button)findViewById(R.id.button2);
btn3 = (Button)findViewById(R.id.button3);
btn4 = (Button)findViewById(R.id.button4);
btn1.setOnClickListener(this);
btn2.setOnClickListener(this);
btn3.setOnClickListener(this);
btn4.setOnClickListener(this);
presenter = new Presenter(this);
}
@Override
public void updateView(Data data) {
this.data = data;
}
@Override
public void onClick(View v) {
switch(v.getId()){
case R.id.button1:
btn1.setText(data.getData(1));
break;
case R.id.button2:
btn2.setText(data.getData(2));
break;
case R.id.button3:
btn3.setText(data.getData(3));
break;
case R.id.button4:
btn4.setText(data.getData(4));
break;
}
}
}이런 재 구성 을 한 후에 Activity 류 는 어떤 변화 가 생 겼 나 요?우리 먼저 안 드 로 이 드 SDK 가 Activity 에 대한 정 의 를 회상 합 시다.
An activity is a single, focused thing that the user can do. Almost all activities interact with the user, so the Activity class takes care of creating a window for you in which you can place your UI with {@link #setContentView}. While activities are often presented to the user as full-screen windows, they can also be used in other ways: as floating windows (via a theme with {@link android.R.attr#windowIsFloating} set) or embedded inside of another activity (using {@link ActivityGroup}).
간단 한 번역: Activity 는 사용자 가 완성 할 수 있 는 일 을 상징 합 니 다. 대부분의 Activity 는 사용자 와 상호작용 을 하고 그 중에서 우리 의 UI 를 배치 합 니 다.
즉, 구 글 은 공식 적 으로 Activity 의 직책 은 UI 를 보 여주 고 사용자 와 상호작용 하 는 것 이 라 고 주장 한다.
그러면 이전의 코드 는 단일 직책 원칙 을 위반 한 것 이 분명 하 다. 왜냐하면 Activity 에서 데이터 의 요청 과 업 데 이 트 를 해 야 할 뿐만 아니 라 사용자 의 상호작용 / 업 데 이 트 된 데이터 에 따라 View 를 수정 해 야 하기 때문이다.그러면 새로운 코드 가 Activity 에 어떤 변 화 를 일 으 켰 을까요?첫째, 데이터 의 요청 / 업 데 이 트 는 Presenter 에서 처리 하고 Activity 를 통 해 요청 / 업 데 이 트 를 하지 않 아 도 됩 니 다.둘째, View 와 관련 된 논리 (예 를 들 어 수정) 는 IView 인터페이스 에서 제공 되 고 Activity 는 구체 적 인 실현 만 완성 해 야 한다.
3. 단일 직책 원칙 을 따 르 면 어떤 장점 이 있 습 니까?
그렇다면 이런 재 구성 을 하면 어떤 좋 은 점 이 있 을 까?나 는 예 시 를 본 후에 여러분 들 의 마음 속 에 다소 명확 하지 않 고 불분명 한 감동 이 있 을 것 이 라 고 믿 습 니 다. 특히 과거 에 쓴 구조 가 나 쁜 코드 를 회상 할 때 더욱 깊 은 감동 을 받 을 것 이 라 고 믿 습 니 다.실제로 저 는 개인 적 으로 디자인 모델 중의 사상 과 생활 속 의 효율 적 인 조직, 업 무 를 완성 하 는 사상 이 모두 일치 하 다 고 생각 합 니 다. 이른바 디자인 모델 이란 그 자체 가 선인 들 이 코드 를 쓰 는 경험 을 정리 하 는 것 이기 때 문 입 니 다. 그 목적 은 바로 효율 을 향상 시 키 고 유지 하기 편리 하 며 코드 를 읽 기 쉽 고 확장 하기 쉬 운 등 입 니 다.우 리 는 한 팀 / 조직 / 회사 / 기업 을 효율적으로 운영 하려 면 이 단 체 는 실제 부서 에 따라 - > 부서 소통 규범 확립 - > 부서 내 에서 다시 팀 직책 세분 화 (예 를 들 어 UI 부 서 는 시각 디자인, 상호작용 디자인 등 으로 나 뉜 다) - > 부서 구성원 들 이 명확 하 게 분업 하여 전체 단체 구 조 를 모듈 화, 저 결합,높 은 내부 집적, 직책 구분 이 뚜렷 한 구조.
한편, 단일 직책 원칙 은 이런 사상 을 나타 낸다. 한 가지 유형 은 가장 근본 적 인 추상 적 논리 에 만 영향 을 받 아야 한다. 유형 안의 구체 적 인 변 화 는 모두 이 추상 적 논리 에서 비롯 되 어야 한다. 우 리 는 단일 직책 이 라 고 말한다. 나 는 그 의 미 는 한 가지 일 을 하 는 것 이 아니 라 한 가지 유형 이 추상 적 인 단체 이 고 추상 적 인 단 체 는 자신의 속성 과 직책 을 가진다 고 생각한다.그것 의 직책 은 많은 일 을 해 야 할 수도 있 지만, 그것 의 직책 은 시종 유일 하 다.
이러한 재 구성 을 한 후에 우 리 는 유형 내 에 속 하지 않 는 논 리 를 분리 시 켜 추상 적 인 논 리 를 따 르 게 할 수 있 고 다른 직책 에 코드 를 추가 하지 않 아 도 된다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
디자인 모델 의 공장 모델, 단일 모델자바 는 23 가지 디자인 모델 (프로 그래 밍 사상/프로 그래 밍 방식) 이 있 습 니 다. 공장 모드 하나의 공장 류 를 만들어 같은 인 터 페 이 스 를 실현 한 일부 종 류 를 인 스 턴 스 로 만 드 는 것...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.
좋은 웹페이지 즐겨찾기
