代碼是如何越寫越爛的?
你是否經常聽同事自嘲,“開始還想好好寫,不知怎滴,後面越寫越爛”?
代碼越寫越爛,果真是個沒有端倪、無法干預的魔咒玄學嗎?
讓我們來快速瀏覽一下 重構前 項目裡的代碼是怎麼寫的。
<code>protected void initView() {
PagerAdapter pagerAdapter = new PagerAdapter();
viewPagerFix.setOffscreenPageLimit(4);
viewPagerFix.setAdapter(pagerAdapter);
mFragmentBinding.tabLayout.setTabData(pagerAdapter.titles);
mFragmentBinding.tabLayout.setOnTabSelectListener(new OnTabSelectListener() {
@Override
public void onTabSelect(int position) {
viewPagerFix.setCurrentItem(position);
}
@Override
public void onTabReselect(int position) {
}
});
viewPagerFix.addOnPageChangeListener(new ViewPagerFix.OnPageChangeListener() {
@Override
public void onPageScrolled(int position, float positionOffset, int positionOffsetPixels) {
KeyboardUtils.hideSoftInput(getActivity());
}
@Override
public void onPageSelected(int position) {
mFragmentBinding.tabLayout.setCurrentTab(position);
if (mViewModel.getXXXDetailTouchManager().isZZBG()) {
zzbgPageSelected(position);
} else if (mViewModel.getXXXDetailTouchManager().isYBJZ()) {
...
} else {
...
}
}
@Override
public void onPageScrollStateChanged(int state) {
}
});
viewPagerFix.setCurrentItem(0);
mFragmentBinding.headContainer.getTitleView().setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
if (mViewModel.getXXXDetailTouchManager().isZZBG()) {
return;
}
mViewModel.changeWyhcrwMajorState();
EventBus.getDefault().post(new RefreshItemEventBus(
mViewModel.getXXXDetailTouchManager().getCurrentWyhcrw()));
}
});
}
private void zzbgPageSelected(int position) {
if (mScreenNum == 3) {
switch (position) {
case 0:
case 1:
mViewModel.removeAllArrows();
if (mAttachmentFragment != null) {
mAttachmentFragment.hideClickHighLight(ALBUM_ALL);
}
break;
case 2:
mViewModel.showAllArrows();
break;
default:
break;
}
} else {
...
}
;
}
/**
* viewPager適配器
*/
private class PagerAdapter extends FragmentPagerAdapter {
String[] titles;
PagerAdapter() {
super(getChildFragmentManager());
if (mViewModel.getXXXDetailTouchManager().isZZBG()) {
if (mScreenNum == 3) {
titles = getResources().getStringArray(R.array.XXX_detail_tabs_for_no_tbjt);
} else {
titles = getResources().getStringArray(R.array.XXX_detail_tabs_for_zzbg);
}
} else if (mViewModel.getXXXDetailTouchManager().isYBJZ()) {
titles = getResources().getStringArray(R.array.XXX_detail_tabs_for_ybjz);
} else {
titles = getResources().getStringArray(R.array.XXX_detail_tabs);
}
}
@Override
public Fragment getItem(int position) {
if (mViewModel.getXXXDetailTouchManager().isZZBG()) {
return zzbgGetItem(position);
} else if (mViewModel.getXXXDetailTouchManager().isYBJZ()) {
switch (position) {
case 0:
if (mXXXTuBanPicFragment == null) {
mXXXTuBanPicFragment = XXXTuBanPicFragment.newInstance(
mViewModel.getUniqueCode(),
mViewModel.getXXXTouchManger()
);
}
return mXXXTuBanPicFragment;
case 1:
if (mRecordFragment == null) {
mRecordFragment = XXXRecordFragment.newInstance(mViewModel.getXXXDetailTouchManager());
}
return mRecordFragment;
default:
if (mAttachmentFragment == null) {
mAttachmentFragment = XXXAttachmentFragment.newInstance(
mViewModel.getAttachments(),
mViewModel.getOriginalAttachments(),
mViewModel.getUniqueCode(),
mViewModel.getXXXTouchManger(),
XXXDetailFragment.this
);
}
return mAttachmentFragment;
}
} else {
...
}
}
private Fragment zzbgGetItem(int position) {
if (mScreenNum == 3) {
switch (position) {
case 0:
if (mAttributeFragment == null) {
mAttributeFragment = XXXAttributeFragment.newInstance(
mViewModel.getUniqueCode(),
mViewModel.getXXXTouchManger()
);
}
return mAttributeFragment;
case 1:
if (mRecordFragment == null) {
mRecordFragment = XXXRecordFragment.newInstance(
mViewModel.getXXXDetailTouchManager());
}
return mRecordFragment;
default:
if (mAttachmentFragment == null) {
mAttachmentFragment = XXXAttachmentFragment.newInstance(
mViewModel.getAttachments(),
mViewModel.getOriginalAttachments(),
mViewModel.getUniqueCode(),
mViewModel.getXXXTouchManger(),
XXXDetailFragment.this
);
}
return mAttachmentFragment;
}
} else {
....
}
}
@Override
public Object instantiateItem(ViewGroup container, int position) {
Object object = super.instantiateItem(container, position);
if (mViewModel.getXXXDetailTouchManager().isZZBG()) {
if (mScreenNum == 3) {
switch (position) {
case 0:
mAttributeFragment = (XXXAttributeFragment) object;
break;
case 1:
mRecordFragment = (XXXRecordFragment) object;
break;
default:
mAttachmentFragment = (XXXAttachmentFragment) object;
break;
}
} else {
switch (position) {
case 0:
mRecordFragment = (XXXRecordFragment) object;
break;
default:
mAttachmentFragment = (XXXAttachmentFragment) object;
break;
}
}
return object;
} else if (mViewModel.getXXXDetailTouchManager().isYBJZ()) {
...
} else {
switch (position) {
case 0:
mXXXTuBanPicFragment = (XXXTuBanPicFragment) object;
break;
case 1:
mAttributeFragment = (XXXAttributeFragment) object;
break;
case 2:
mRecordFragment = (XXXRecordFragment) object;
break;
default:
mAttachmentFragment = (XXXAttachmentFragment) object;
break;
}
return object;
}
}
@Override
public int getCount() {
if (mViewModel != null) {
if (mViewModel.getXXXDetailTouchManager().isZZBG()) {
if (mScreenNum == 3) {
return 3;
}
return 2;
}
if (mViewModel.getXXXDetailTouchManager().isYBJZ()) {
return 3;
} else {
return 4;
}
}
return 0;
}
}
/<code>
(為保護隱私,模塊類名已替換為“XXX”)
可以看到,該主頁目前服務於 3 個地區,每個地區對子頁面的展示都有定製需求。
if else switch if else switch,只在乎功能實現的碼農就是這麼寫的。
一個地區 50 行,那要是 10 個地區呢?公司領導放話要支持全國 100 個鄉鎮地區!那 100 個地區呢???
抽象,順應的是“開閉原則”
這是一幫對“抽象”無感的碼農。
他們聽到“抽象”,就像不愛鍛鍊的我聽到父母、朋友勸我“健身”一樣被動。(笑)
正如我並不真的理解健身的意義所在,他們也當抽象是“耳邊風”。
“100 個地區”這種,天然的就是用工廠模式來抽象和定製,這原本是一目瞭然、毫無疑問的事。
重構後的代碼,主頁抬頭特意標註了警告。
<code>/
* 友情提示:本類塗有防腐藥品,切勿觸碰,切勿觸碰,切勿觸碰!
*
* 地區定製功能,包括特色的佈局等,請繼承於 AbstractDetailChildFragmentManager 單獨編寫!
*/
public class XXXDetailFragment extends BaseFragment implements IResponse {
protected void initView() {
initViewPagerManager();
PagerAdapter pagerAdapter = new PagerAdapter();
viewPagerFix.setOffscreenPageLimit(4);
viewPagerFix.setAdapter(pagerAdapter);
mFragmentBinding.tabLayout.setTabData(pagerAdapter.titles);
mFragmentBinding.tabLayout.setOnTabSelectListener(new OnTabSelectListener() {
@Override
public void onTabSelect(int position) {
viewPagerFix.setCurrentItem(position);
}
@Override
public void onTabReselect(int position) {
}
});
viewPagerFix.addOnPageChangeListener(new ViewPagerFix.OnPageChangeListener() {
@Override
public void onPageScrolled(int position, float positionOffset, int positionOffsetPixels) {
KeyboardUtils.hideSoftInput(getActivity());
}
@Override
public void onPageSelected(int position) {
mFragmentBinding.tabLayout.setCurrentTab(position);
mDetailChildFragmentManager.onPageSelected(position);
}
@Override
public void onPageScrollStateChanged(int state) {
}
});
}
/**
* viewPager適配器
*/
private class PagerAdapter extends FragmentPagerAdapter {
String[] titles;
PagerAdapter() {
super(getChildFragmentManager());
titles = mDetailChildFragmentManager.getTitles();
}
@Override
public Fragment getItem(int position) {
return mDetailChildFragmentManager.getItem(position);
}
@Override
public Object instantiateItem(ViewGroup container, int position) {
Object object = super.instantiateItem(container, position);
return mDetailChildFragmentManager.instantiateItem(container, position, object);
}
@Override
public int getCount() {
return mDetailChildFragmentManager.getCount();
}
}
}
/<code>
代碼是如何剪不斷理還亂的?
聽說過“代碼耦合”和“解耦”的人很多,但真正理解這是怎麼一回事的,恐怕只有你 ~
因為哪怕你不知,你也即將見證一位帥哥如何手把手帶你解耦 ~
我們先來看下重構前的代碼!
<code>public interface XXXListNavigator {
void updateRecyclerView();
void showProgressDialog();
void dismissProgressDialog();
void updateListView();
void updateLayerWrapperList(List<layerwrapper> list);
boolean isAnimationFinish();
void resetCount();
}
public class XXXListViewModel extends BaseViewModel {
public void multiAddOrRemove(ArrayList<string> bsms, boolean isAdd) {
if (null != mNavigator) {
mNavigator.showProgressDialog();
}
if (null == mMultiAddOrRemoveUseCase) {
mMultiAddOrRemoveUseCase = new MultiAddOrRemoveUseCase();
}
mUseCaseHandler.execute(mMultiAddOrRemoveUseCase, new MultiAddOrRemoveUseCase.RequestValues(isAdd, bsms,
mLayerWrapperObservableField.get()),
new UseCase.UseCaseCallback<multiaddorremoveusecase.responsevalue>() {
@Override
public void onSuccess(MultiAddOrRemoveUseCase.ResponseValue response) {
ToastUtils.showShort(getApplicationContext(), "操作成功");
clearData();
loadData(true, true);
if (null != mNavigator) {
mNavigator.dismissProgressDialog();
}
}
@Override
public void onError() {
ToastUtils.showShort(getApplicationContext(), "操作失敗");
if (null != mNavigator) {
mNavigator.dismissProgressDialog();
}
}
});
}
}
/<multiaddorremoveusecase.responsevalue>/<string>/<layerwrapper>/<code>
可以看到,UI 過度暴露了“處理 UI 邏輯所依賴的過程 API”,並在業務中直接干預了 UI 邏輯,這是典型的 MVP 寫法,這造成了耦合。一旦 UI 的需求有變動,View 和 Presenter 的編寫者都會受到牽連。
而且,職責過多造成了依賴過多,這個 Presenter 會因為過多的依賴,而越寫越臃腫:受“破窗效應”的驅使,別的碼農會因為此處已經有某個依賴,而不假思索的接著往下寫。
到底怎樣才算解耦
所謂解耦,是符合工程設計、符合設計模式原則的編碼。
解耦的本質,我只說一遍:
職責邊界明確,職責邊界明確,職責邊界明確。
viabus_flow_flow.png
符合單一職責原則:
UI 的職責僅限於“展示”,也就是發送請求、處理 UI 邏輯。業務的職責僅限於“提供數據”,也就是接收請求、處理業務邏輯、響應結果數據。
符合依賴倒置原則、最小知識原則:UI 不需要知道數據是經過怎樣的週轉得來的,它只需發送請求,並在拿到結果數據後,自己內部消化 UI 邏輯。業務只需處理數據並響應數據給 UI,它不需要知道 UI 會怎樣使用數據,更無權干預。
綜上,無論是 UI 還是業務,都不應過度暴露內部邏輯 API 而受控於人,它們應只暴露請求 API,來響應外部的請求。過程邏輯應只在自己內部獨立消化。
<code>public class XXXListBusinessProxy extends BaseBusiness<xxxbus> implements IXXXListFragmentRequest {
@Override
public void multiAddOrRemove(final XXXListDTO dto) {
handleRequest((e) -> {
...
if (TextUtils.isEmpty(existBsms)) {
sendMessage(e, new Result(XXXDataResultCode.XXX_LIST_FRAGMENT_MULTI_ADD_OR_REMOVE, false));
} else {
wyhcJgDBManager.insertAllTaskOfMine(existBsms, layersConfig);
sendMessage(e, new Result(XXXDataResultCode.XXX_LIST_FRAGMENT_MULTI_ADD_OR_REMOVE, true));
}
return null;
});
}
@Override
public void refreshPatternOfXXXList(final XXXListDTO dto) {
handleRequest((e) -> {
...
count.setMyXXXCount(wyhcJgDBManager.getMyXXXPatternCount());
return new Result(XXXDataResultCode.XXX_LIST_FRAGMENT_REFRESH_COUNT, count);
});
}
@Override
public void changeXXXPatternOfMine(final XXXListDTO dto) {
handleRequest((e) -> {
if (toMine) {
...
} else {
...
sendMessage(e, new Result(XXXDataResultCode.XXX_LIST_FRAGMENT_GET_ALL_PATTERN_OF_MINE, count));
}
return null;
});
}
}
public class XXXListFragment extends BaseFragment implements IResponse {
XXXBus.XXX().queryList(mDto);
XXXBus.XXX().multiAddOrRemove(mDto);
XXXBus.XXX().queryPattern(mDto);
...
@Override
public void onResult(Result testResult) {
String code = (String) testResult.getResultCode();
switch (code) {
case XXXDataResultCode.XXX_LIST_FRAGMENT_REFRESH_LIST:
updateRecyclerView((List<wyhcrw>) testResult.getResultObject());
if (isNeedUpdateCount()) {
...
} else {
finishLoading();
}
break;
case XXXDataResultCode.XXX_LIST_FRAGMENT_MULTI_ADD_OR_REMOVE:
if ((boolean) testResult.getResultObject()) {
loadData(true, true);
} else {
ToastUtils.showShort(getContext(), "操作失敗");
}
dismissProgressDialog();
break;
case XXXDataResultCode.XXX_LIST_FRAGMENT_REFRESH_PATTERN:
...
break;
default:
}
}
}
/<wyhcrw>/<xxxbus>/<code>
解耦有什麼好處?
解耦的好處,福特最有話語權。
100 多年前,福特發明了世界上第一條流水線,讓工人職責邊界明確,從而得以分工和專注各自領域。
原先裝配一輛車需 700 小時,通過流水線分工後,平均一輛 12.5 小時,這使得生產效率提升了近 60 倍!
軟件工程同理。
由於 UI 和業務職責邊界明確,且相互通過接口通信,使得 UI 和業務的編寫者能夠真正的分工。
寫 UI 的人,不會被業務的編寫打斷,他可以一氣呵成的寫自己的 UI。寫業務的人,同樣不會被打斷,他可以專注於業務邏輯、數據結構和算法的優化。
寫 UI 和寫業務的人,都可以自己實現接口,去獨立的完成單元測試,完全不必依賴和等候對方的實現。
最後,在職責邊界明確的情況下,UI 就算寫 100 個 UI 邏輯,那也是 UI,業務就算寫 100 個業務,那也是業務,純種,所以不會雜亂,何況我們還可以藉助“接口隔離原則”繼續往下分工!
總結
綜上,本文介紹了兩個重構思路:
1.順應開閉原則,對定製化功能進行抽象。
看完這篇文章,如你覺得有所收穫和啟發,請不吝點贊,你的點贊就是對我最大的支持!
本次項目重構用到的,符合設計模式原則的 viabus 架構,已在 GitHub 開源:GitHub:KunMinX/android-viabus-architecture
原文作者:KunMinX,經授權原創發佈,部分真實感受,希望對大家有幫助,在工作寫出更好擴展和可維護的代碼。
歡迎關注我的微信公眾號「碼農突圍」,分享Python、Java、大數據、機器學習、人工智能等技術,關注碼農技術提升•職場突圍•思維躍遷,20萬+碼農成長充電第一站,陪有夢想的你一起成長。