著者|スターシップダック
Zebian |胡威威
制作| CSDNブログ
Androidの開発の伝統的なモデルでは、アクティビティ機能の増加と、そのコードも増加しています。私たちは関数内のアクティビティに追加したい場合は、それを見つけるために可能性があり、この関数は単に要求にあなたが持っているデータベースを読むために持っているのHttp、我々はそう
このような特徴にコードの1000行(誇張)を追加するには、その後、私たちの活動のコードは非常に肥大化になるだろう、あなたはすぐに完了するために、機能コードを変更することはできません。
そのため、MVPのアーキテクチャモデルは、それがこのような状況を解決するための良い方法です
MVPのアーキテクチャモデルとは何ですか
多くのブログでそうMVPを説明しています。
M:特に複雑なロジックを実装するためのモデル、物理層、。
V:ビュー、ビュー層、データ、相互作用を表示します。
P:例えばプレゼンター、ロジック制御層は、モデルとビューを保持しています。
その後頭痛、コードの山を始めました......
だから私はこの記事が鮮やかなのメソッドを使用しようとする書いた、最初のあなたは、このような設定に同意する必要があります。
表示:あなた
プレゼンター:おばさん王
モデル:ツール男
だから助けに設定の代わりおばさん張のおばさん王はなぜ聞かない、理解し、これは単なる仮想のものです。
開始
ストーリー:あなたはいずれかを購入する前に、すべての時間をW音楽のボトルを購入したいが、今現れた王の叔母があります。
彼女は言った:「あなたは私があなたにコーラ、これ以上の電荷を買う、私にお金を与えます!」
あなたを聞いた後、費用対効果の高いものので、そのようにそれをすること。
だから、あなたも彼女の電話番号を与えた、おばさん王にお金を与えました。
しかし、我々はすべての空きランチはありません知っている、おばさん王のために、これはお金を稼ぐための機会です。
>ツールは、彼女はとても安く、彼女が違いを生むことができ、独自の広い音楽を生成することができます - おばさん王は、低コストの広い音楽チャンネルを購入することを知っています。
その後、おばさん王は、彼らがお互いに自分の連絡先情報を与え、ツールを発見しました。
その時から、あなただけのW音楽を飲みたい、あなたは王の叔母の電話番号が彼女に言ったダイヤルすることができます。
しかし、彼女は、ツールの男に電話をかけていること王の叔母のノウハウの後、W音楽のために彼に尋ねます。
ツールが聞いた後、自分たちの生活は、幅広い音楽制作を開始します。
しばらくすると、音楽に従事する広い出てきた、道具、人々は王の叔母を呼んで、おばさん王は、あなたを呼んで知っています。
このように、手持ちのW曲。あなたも知らない幅広い音楽を来る方法ですが、それはあなたの手にありません。
用語が導入され、
这样以故事的形式来解释,我个人感觉会比较好理解。现在我们在故事的基础上将术语引入。
你:View
王大妈:Presenter
工具人:Model
从这种架构模式来看,View想要拿到数据显示,这个流程的逻辑将会变得十分清晰!
Presenter作为一个中间人,需要分两头联系View和Model。
而Model,只管把数据搞出来,再通知Presenter就好了,Presenter会做剩下的工作。
用代码举例
从上文可得知,王大妈和工具人都是十分具体的,但是如果另外一个张大爷也可以帮你完成代购,而且速度很快呢?
相信你一定也有了启发,这个时候 只要能代购到可乐,哪个中间人都行(只是效率问题)。
那有一天你不想喝阔乐了,想喝芬达了呢?
因此我们将这个Presenter(中间人)抽象,抽象成一个接口,只要能帮我们买到可乐,就能做这个中间人。
在中间人接口中,我们需要指定,这个中间人需要帮我们做些什么(代购些啥)。
同理,我们将Model(中间人)也抽象成一个接口,只要能干又苦又累的活都能做工具人。
在工具人接口中,我们需要指定,这个工具人要帮我们搞些什么东西。(生产些啥)
那你呢?你(View)也可以抽象成一个接口,我们需要指定,这个接口要些啥。(需要啥)
所以View需要啥→Presenter代购啥→Model生产啥。随后,Model生产完成→Presenter代购完成→View心愿完成。
这个流程都是十分清晰的,接下来直接上代码了。
上代码,新建3个接口
新建3个包,分别为Model,Presenter和View,在Presenter包中,添加MiddlePeople接口(中间人接口)。
package cn.daccc.mvpdemo.presenter;
/**
* 中间人接口,只要能帮我们买到可乐,能通知我们就行
*/
public interface MiddlePeople{
//买可乐
void buyCola();
//购买成功后调用该方法
void buySucceed();
}
在Model包中,添加ToolPeople接口(工具人接口)。
package cn.daccc.mvpdemo.model;
/**
* 工具人接口,只要能生产可乐就行
*/
public interface ToolPeople{
//生产可乐
void produceCola();
}
在View包中,添加Me这个接口,实现喝可乐的心愿(中间人买回来之后我们就可以喝了)。
package cn.daccc.mvpdemo.view;
/**
* 实际上不一定是你想喝,你同学也想喝呢?就假装他也是“你”
*/
public interface Me {
//喝可乐
void drinkCola();
}
我们添加了上面的3个接口,都是没有具体的实现的,也就是说,也就嘴上说说而已,没有实际行动。
因此我们来建立真真实实的类,去完成上述行为。
上代码,新建2个类
我们指定HanHan(憨憨)作为工具人,让他去帮我们生产可乐。
在Model包中新建一个HanHan类。这里注意了,这个憨憨要符合工具人的特性,因此他要实现ToolPeople接口的所有方法,做工具人做的事。
因此,他要实现接口中的produceCola()方法。
package cn.daccc.mvpdemo.model;
import android.util.Log;
/**
* 工具人憨憨,他要符合工具人的特性才能帮我们做事,因此要实现Tool接口
*/
public class HanHan implements ToolPeople {
@Override
public void produceCola() {
Log.d("ToolPeople","生产可乐好累啊!");
}
}
你会发现,HanHan生产完了,怎么通知呢?
所以,HanHan要知道中间人的联系方式,因此HanHan要在中间人联系他的时候保存好中间人的联系方式,然鹅HanHan并不知道中间人具体是谁,所以要用接口类型来保存中间人。
package cn.daccc.mvpdemo.model;
import android.util.Log;
import cn.daccc.mvpdemo.presenter.MiddlePeople;
/**
* 工具人憨憨,他要符合工具人的特性才能帮我们做事,因此要实现Tool接口
*/
public class HanHan implements ToolPeople {
//保存中间人的联系方式
private MiddlePeople middlePeople;
public HanHan(MiddlePeople middlePeople){
this.middlePeople = middlePeople;
}
@Override
public void produceCola() {
Log.d("ToolPeople","生产可乐好累啊!");
//HanHan生产好了,告诉中间人TA购买成功了
middlePeople.buySucceed();
}
}
在Presenter包中新建WangDaMa类。
现在已经有了一个具体的工具人了,但是我们还差个具体的中间人。
因此我们指定WangDaMa(王大妈)为中间人,这王大妈既要有“我”的联系方式,也要找到一个符合要求的工具人并且保存工具人的联系方式,因此她找到了HanHan。
package cn.daccc.mvpdemo.presenter;
import android.util.Log;
import cn.daccc.mvpdemo.model.ToolPeople;
import cn.daccc.mvpdemo.view.Me;
/**
* 中间人,指定王大妈是中间人,因此她要做所有中间人该做的事情
*/
public class WangDaMa implements MiddlePeople {
private Me me;
private ToolPeople toolPeople;
//保存“我”的联系方式,并指派HanHan为工具人,保存他的联系方式
public WangDaMa(Me me,ToolPeople toolPeople){
this.me=me;
toolPeople = new HanHan(this);
}
@Override
public void buyCola() {
Log.d("MiddlePeople","我来帮你买可乐");
//让工具人去生产可乐
toolPeople.produceCola();
}
@Override
public void buySucceed() {
//买成了,通知“我”可以开始嚯阔乐啦
me.drinkCola();
}
}
在MainActivity中实现Me这个接口,我们找一个中间人做代购,因此我找到了王大妈。
我只要想喝可乐只需要点击一下按钮,就让中间人帮我买可乐,买完之后再告诉我就可以了。
public class MainActivity extends AppCompatActivity implements Me{
private MiddlePeople middlePeople = new WangDaMa(this);
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
Button btn_drink = findViewById(R.id.btn_drink);
btn_drink.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
//点击按钮,就让中间人帮我们买可乐
middlePeople.buyCola();
}
});
}
/**
* 实现Me接口中的drinkCola方法,让喝可乐这件事情有一个更加具体的描述
*/
@Override
public void drinkCola() {
Toast.makeText(this, "这阔乐真他*的好嚯!", Toast.LENGTH_SHORT).show();
}
}
结果展示
诶,就很舒服。
弊端
打住,舒服是暂时的,到底有没有必要为了喝个可乐去搞那么多乱七八糟的什么中间人工具人呢?
答案就是:请使用长远的眼光,来决定在具体Android开发项目中到底需不需要使用MVP架构模式。
文章中这样的设计模式会增加很多的类的接口,这是一个弊端,当然可以优化!
总结
从上边的故事和例子来看,是不是都理解了呢?如果还不理解,你来砍我(顺着网线来)。
哈哈,开个玩笑,我们来总结一下。
ToolPeople:实际上是Model,它做很多又苦又累的工作,因此把业务代码放在这里
MiddlePeopl:实际上是Presenter,它做一个中间人的角色,可以执行少量的业务代码,比如简单判断这件事情能不能干的成
Me:实际上是View,喝可乐这件事情最终体现在View中,但是它无需知道可乐是怎么来的,它只需要委派中间人去实现就可以了
这里的什么憨憨,王大妈,“我”。都是为了帮助理解而已,相信认真看完文章的人,应该都理解了,因此这些类的名称,这些接口的名称,都应该按照规范来命名
编程很少是一个人的工作,所以学习如何架构代码是进阶的必经之路。本文分享了我对MVP架构的一些浅见,希望能够帮助大家理解。
如果文章有误,恳请指出,十分感谢!机会,总是留给有准备的人。共勉。
原文链接:
https://blog.csdn.net/c529283955/article/details/104501002
声明:本文系CSDN博主原创文章,版权归作者所有。
《原力计划【第二季】- 学习力挑战》
正式开始
即日起至 3月21日
千万流量支持原创作者
更有专属【勋章】等你来挑战
推荐阅读
☞近一半程序员单身、年薪低于 15 万,程序员扎心现状大调查!
☞大脑芯片公司Neuralink计划在人脑内植入芯片,他们到底想干什么?
☞深耕技术,与实践赛跑:一文告诉你如何稳妥快速完善区块链技术并有序推动商用?
你点的每一个在看,我认真当成了喜欢