android设计模式 App的设计架构
2017-02-24 14:44
351 查看
自古深情留不住 总是套路得人心为啥说上面这句话呢,因为所谓的设计模式其实就是套路,套路呢还比较受大家喜欢。为啥使用设计模式呢,无非高内聚低耦合。
视图层(View)
一般采用XML文件进行界面的描述,这些XML可以理解为AndroidApp的View。使用的时候可以非常方便的引入。同时便于后期界面的修改。逻辑中与界面对应的id不变化则代码不用修改,大大增强了代码的可维护性。控制层(Controller)
Android的控制层的重任通常落在了众多的Activity的肩上。这句话也就暗含了不要在Activity中写代码,要通过Activity交割Model业务逻辑层处理,这样做的另外一个原因是Android中的Actiivity的响应时间是5s,如果耗时的操作放在这里,程序就很容易被回收掉。模型层(Model)
我们针对业务模型,建立的数据结构和相关的类,就可以理解为AndroidApp的Model,Model是与View无关,而与业务相关的(感谢@Xander的讲解)。对数据库的操作、对网络等的操作都应该在Model里面处理,当然对业务计算等操作也是必须放在的该层的。就是应用程序中二进制的数据。
MVP从更早的MVC框架演变过来,与MVC有一定的相似性:Controller/Presenter负责逻辑的处理,Model提供数据,View负责显示。
MVP框架由3部分组成:View负责显示,Presenter负责逻辑处理,Model提供数据。在MVP模式里通常包含3个要素(加上View interface是4个):View:负责绘制UI元素、与用户进行交互(在Android中体现为Activity)
Model:负责存储、检索、操纵数据(有时也实现一个Model interface用来降低耦合)
Presenter:作为View与Model交互的中间纽带,处理与用户交互的负责逻辑。
*View interface:需要View实现的接口,View通过View interface与Presenter进行交互,降低耦合,方便进行单元测试
两种模式的主要区别:(最主要区别)View与Model并不直接交互,而是通过与Presenter交互来与Model间接交互。而在MVC中View可以与Model直接交互
通常View与Presenter是一对一的,但复杂的View可能绑定多个Presenter来处理逻辑。而Controller是基于行为的,并且可以被多个View共享,Controller可以负责决定显示哪个View
Presenter与View的交互是通过接口来进行的,更有利于添加单元测试。
设计模式文章https://www.cnblogs.com/cr330326/p/5627658.html
(2).对唯一实例的受控访问。
(3).避免全局变量污染命名空间。
(4).允许对操作和表示的精化。
(5).比类操作更灵活。
public class Singleton { private static Singleton instance = null; private Singleton(){} public static synchronized Singleton getInstance() { //也可以这样写:synchronized public static Singleton getInstance() { if (instance == null){ instance = new Singleton(); } return instance; } }
private Context mContext;
private DisplayUtils(Context context) { //这里变化了,把当前Context指向个应用程序的Context
this.mContext = context.getApplicationContext();
}
public static DisplayUtils getInstance(Context context) {
if (instance == null) {
synchronized (DisplayUtils.class) {
if (instance == null) {
instance = new DisplayUtils(context);
}
}
}
return instance;
}弱引用的使用private WeakReference<Context> weakContext;
private DisplayUtils(Context context) { //这里变化了,把当前Context指向个应用程序的Context
weakContext = new WeakReference<Context>(context);
}
public static DisplayUtils getInstance(Context context) {
if (instance == null) {
synchronized (DisplayUtils.class) {
if (instance == null) {
instance = new DisplayUtils(context);
}
}
}
return instance;
}
public int dip2px(float dpValue) {
final float scale = weakContext.get().getResources().getDisplayMetrics().density;
return (int) (dpValue * scale + 0.5f);
}
public Product create();
}
我们再来定义一个产品接口
public interface Product{}
一下是实现了产品接口的产品类
public class Washer implements Product{
public Washer(){
System.out.println("洗衣机被制造了");
}
}
public class Icebox implements Product{
public Icebox(){
System.out.println("冰箱被制造了");
}
}
public class AirCondition implements Product{
public Icebox(){
System.out.println("空调被制造了");
}
}
接下来,就是工厂方法的核心部分,也就是具体创建产品对象的具体工厂类,
//创建洗衣机的工厂
public class CreateWasher implements Factory{
public Product create(){
return new Washer();
}
}
//创建冰箱的工厂
public class CreateIcebox implements Factory{
public Product create(){
return new Icebox();
}
}
//创建空调的工厂
public class CreateAirCondition implements Factory{
public Product create(){
return new AirCondition();
}
}
适配器模式分为类适配器模式和对象适配器模式。
观察者模式里面目标类维护了所有观察者的引用,而回调里面只是维护了一个引用
比如说广播--广播接受者,就是观察者模式,发起广播,所有注册的广播接受者都会收到。 button点击,广播接受者
[java] view plain copyAlertDialog dialog = new AlertDialog.Builder(MainActivity.this).setTitle("提示")
.setMessage("确定退出?").create();
dialog.show();
可以看到dialog是通过Builder创建的,那么Builder是如何同AlertDialog协同工作的呢?其实AlertDialog的创建就是使用Builder模式,废话不多说,直接上代码吧。
[java] view plain copypackage com.umeng.dp.builder;
/**
* @Copyright: Umeng.com, Ltd. Copyright 2011-2015, All rights reserved
* @Title: UmengDialog.java
* @Package com.umeng.dp.builder
* @Description: Builder模式
* @author Honghui He
* @version V1.0
*/
public class UmengDialog {
private String mTitle = "";
private String mMessage = "";
private int mIcon = -1;
/**
* @Title: UmengDialog
* @Description: UmengDialog Constructor
* @param builder 将dialog参数传递给builder,够将好的builder传递给Dialog
*/
private UmengDialog(Builder builder) {
mTitle = builder.getTitle();
mMessage = builder.getMessage();
mIcon = builder.getIcon();
}
/**
* @Title: show
* @Description: show dialog
* @throws
*/
public void show() {
System.out.println("显示窗口 : " + this);
}
/**
* (非 Javadoc)
*
* @Title: toString
* @Description:
* @return
* @see java.lang.Object#toString()
*/
@Override
public String toString() {
return "UmengDialog [mTitle=" + mTitle + ", mMessage=" + mMessage + ", mIcon=" + mIcon
+ "]";
}
/**
* @ClassName: Builder
* @Description: Builder模式, 用于构建复杂的对象
* @author Honghui He
*/
public static class Builder {
private String mDlgTitle = "";
private String mDlgMessage = "";
private int mDlgIcon = -1;
/**
* @Title: Builder
* @Description: Builder Constructor
*/
public Builder() {
}
/**
* 获取 mDlgTitle
*
* @return 返回 mDlgTitle
*/
public String getTitle() {
return mDlgTitle;
}
/**
* 设置 mDlgTitle
*
* @param 对mDlgTitle进行赋值
*/
public Builder setTitle(String title) {
this.mDlgTitle = title;
return this;
}
/**
* 获取 mDlgMessage
*
* @return 返回 mDlgMessage
*/
public String getMessage() {
return mDlgMessage;
}
/**
* 设置 mDlgMessage
*
* @param 对mDlgMessage进行赋值
*/
public Builder setMessage(String msg) {
this.mDlgMessage = msg;
return this;
}
/**
* 获取 mDlgIcon
*
* @return 返回 mDlgIcon
*/
public int getIcon() {
return mDlgIcon;
}
/**
* 设置 mDlgIcon
*
* @param 对mDlgIcon进行赋值
*/
public Builder setIcon(int resId) {
this.mDlgIcon = resId;
return this;
}
/**
* @Title: create
* @Description: 创建窗口
* @throws
*/
public UmengDialog create() {
return new UmengDialog(this);
}
}
}
Android中的MVC
Android中界面部分也采用了当前比较流行的MVC框架,在Android中:视图层(View)
一般采用XML文件进行界面的描述,这些XML可以理解为AndroidApp的View。使用的时候可以非常方便的引入。同时便于后期界面的修改。逻辑中与界面对应的id不变化则代码不用修改,大大增强了代码的可维护性。控制层(Controller)
Android的控制层的重任通常落在了众多的Activity的肩上。这句话也就暗含了不要在Activity中写代码,要通过Activity交割Model业务逻辑层处理,这样做的另外一个原因是Android中的Actiivity的响应时间是5s,如果耗时的操作放在这里,程序就很容易被回收掉。模型层(Model)
我们针对业务模型,建立的数据结构和相关的类,就可以理解为AndroidApp的Model,Model是与View无关,而与业务相关的(感谢@Xander的讲解)。对数据库的操作、对网络等的操作都应该在Model里面处理,当然对业务计算等操作也是必须放在的该层的。就是应用程序中二进制的数据。
MVP从更早的MVC框架演变过来,与MVC有一定的相似性:Controller/Presenter负责逻辑的处理,Model提供数据,View负责显示。
MVP框架由3部分组成:View负责显示,Presenter负责逻辑处理,Model提供数据。在MVP模式里通常包含3个要素(加上View interface是4个):View:负责绘制UI元素、与用户进行交互(在Android中体现为Activity)
Model:负责存储、检索、操纵数据(有时也实现一个Model interface用来降低耦合)
Presenter:作为View与Model交互的中间纽带,处理与用户交互的负责逻辑。
*View interface:需要View实现的接口,View通过View interface与Presenter进行交互,降低耦合,方便进行单元测试
两种模式的主要区别:(最主要区别)View与Model并不直接交互,而是通过与Presenter交互来与Model间接交互。而在MVC中View可以与Model直接交互
通常View与Presenter是一对一的,但复杂的View可能绑定多个Presenter来处理逻辑。而Controller是基于行为的,并且可以被多个View共享,Controller可以负责决定显示哪个View
Presenter与View的交互是通过接口来进行的,更有利于添加单元测试。
设计模式文章https://www.cnblogs.com/cr330326/p/5627658.html
Android设计模式系列-组合模式
将对象View和ViewGroup组合成树形结构以表示"部分-整体"的层次结构(View可以做为ViewGroup的一部分,ViewGroup也可以被用户当做一 个view)。组合模式使得用户对单个对象View和组合对象ViewGroup的使用具有一致性。Android设计模式系列-单例模式
保证一个类仅有一个实例,并提供一个访问它的全局访问点,synchronized关键字,在多线程的环境下,单例模式为了保证自己实例数量的唯一,必然会做并发控制,多线程下的线程安全。(1).创建型模式。(2).对唯一实例的受控访问。
(3).避免全局变量污染命名空间。
(4).允许对操作和表示的精化。
(5).比类操作更灵活。
public class Singleton { private static Singleton instance = null; private Singleton(){} public static synchronized Singleton getInstance() { //也可以这样写:synchronized public static Singleton getInstance() { if (instance == null){ instance = new Singleton(); } return instance; } }
避免单例引起的内存泄漏
private static DisplayUtils instance = null;private Context mContext;
private DisplayUtils(Context context) { //这里变化了,把当前Context指向个应用程序的Context
this.mContext = context.getApplicationContext();
}
public static DisplayUtils getInstance(Context context) {
if (instance == null) {
synchronized (DisplayUtils.class) {
if (instance == null) {
instance = new DisplayUtils(context);
}
}
}
return instance;
}弱引用的使用private WeakReference<Context> weakContext;
private DisplayUtils(Context context) { //这里变化了,把当前Context指向个应用程序的Context
weakContext = new WeakReference<Context>(context);
}
public static DisplayUtils getInstance(Context context) {
if (instance == null) {
synchronized (DisplayUtils.class) {
if (instance == null) {
instance = new DisplayUtils(context);
}
}
}
return instance;
}
public int dip2px(float dpValue) {
final float scale = weakContext.get().getResources().getDisplayMetrics().density;
return (int) (dpValue * scale + 0.5f);
}
Android设计模式系列--工厂方法模式
public interface Factory{public Product create();
}
我们再来定义一个产品接口
public interface Product{}
一下是实现了产品接口的产品类
public class Washer implements Product{
public Washer(){
System.out.println("洗衣机被制造了");
}
}
public class Icebox implements Product{
public Icebox(){
System.out.println("冰箱被制造了");
}
}
public class AirCondition implements Product{
public Icebox(){
System.out.println("空调被制造了");
}
}
接下来,就是工厂方法的核心部分,也就是具体创建产品对象的具体工厂类,
//创建洗衣机的工厂
public class CreateWasher implements Factory{
public Product create(){
return new Washer();
}
}
//创建冰箱的工厂
public class CreateIcebox implements Factory{
public Product create(){
return new Icebox();
}
}
//创建空调的工厂
public class CreateAirCondition implements Factory{
public Product create(){
return new AirCondition();
}
}
Android设计模式系列-适配器模式
适配器模式,把一个类的接口变换成客户端所期待的另一种接口,从而使原本不匹配而无法在一起工作的两个,类能够在一起工作。适配器模式分为类适配器模式和对象适配器模式。
Android设计模式系列--观察者模式
定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。观察者模式里面目标类维护了所有观察者的引用,而回调里面只是维护了一个引用
比如说广播--广播接受者,就是观察者模式,发起广播,所有注册的广播接受者都会收到。 button点击,广播接受者
Android设计模式系列--Builder模式
在Android中经常要使用AlertDialog来显示一些简单的窗口,通常的写法类似下面的代码 :[java] view plain copyAlertDialog dialog = new AlertDialog.Builder(MainActivity.this).setTitle("提示")
.setMessage("确定退出?").create();
dialog.show();
可以看到dialog是通过Builder创建的,那么Builder是如何同AlertDialog协同工作的呢?其实AlertDialog的创建就是使用Builder模式,废话不多说,直接上代码吧。
[java] view plain copypackage com.umeng.dp.builder;
/**
* @Copyright: Umeng.com, Ltd. Copyright 2011-2015, All rights reserved
* @Title: UmengDialog.java
* @Package com.umeng.dp.builder
* @Description: Builder模式
* @author Honghui He
* @version V1.0
*/
public class UmengDialog {
private String mTitle = "";
private String mMessage = "";
private int mIcon = -1;
/**
* @Title: UmengDialog
* @Description: UmengDialog Constructor
* @param builder 将dialog参数传递给builder,够将好的builder传递给Dialog
*/
private UmengDialog(Builder builder) {
mTitle = builder.getTitle();
mMessage = builder.getMessage();
mIcon = builder.getIcon();
}
/**
* @Title: show
* @Description: show dialog
* @throws
*/
public void show() {
System.out.println("显示窗口 : " + this);
}
/**
* (非 Javadoc)
*
* @Title: toString
* @Description:
* @return
* @see java.lang.Object#toString()
*/
@Override
public String toString() {
return "UmengDialog [mTitle=" + mTitle + ", mMessage=" + mMessage + ", mIcon=" + mIcon
+ "]";
}
/**
* @ClassName: Builder
* @Description: Builder模式, 用于构建复杂的对象
* @author Honghui He
*/
public static class Builder {
private String mDlgTitle = "";
private String mDlgMessage = "";
private int mDlgIcon = -1;
/**
* @Title: Builder
* @Description: Builder Constructor
*/
public Builder() {
}
/**
* 获取 mDlgTitle
*
* @return 返回 mDlgTitle
*/
public String getTitle() {
return mDlgTitle;
}
/**
* 设置 mDlgTitle
*
* @param 对mDlgTitle进行赋值
*/
public Builder setTitle(String title) {
this.mDlgTitle = title;
return this;
}
/**
* 获取 mDlgMessage
*
* @return 返回 mDlgMessage
*/
public String getMessage() {
return mDlgMessage;
}
/**
* 设置 mDlgMessage
*
* @param 对mDlgMessage进行赋值
*/
public Builder setMessage(String msg) {
this.mDlgMessage = msg;
return this;
}
/**
* 获取 mDlgIcon
*
* @return 返回 mDlgIcon
*/
public int getIcon() {
return mDlgIcon;
}
/**
* 设置 mDlgIcon
*
* @param 对mDlgIcon进行赋值
*/
public Builder setIcon(int resId) {
this.mDlgIcon = resId;
return this;
}
/**
* @Title: create
* @Description: 创建窗口
* @throws
*/
public UmengDialog create() {
return new UmengDialog(this);
}
}
}
public class PersonThree { //固定不变的对象,一般变量需要声明为 final private final String mName; //必选,final 类型需要在 构造器中初始化,不允许不初始化它的构造器存在 private String mLocation; //可选 private String mJob; //可选 private String mHabit; //可选 /** * 构造方法的参数是它的 静态内部类,使用静态内部类的变量一一赋值 * @param builder */ public PersonThree(Builder builder) { this.mName = builder.mName; this.mLocation = builder.mLocation; this.mJob = builder.mJob; this.mHabit = builder.mHabit; } /** * PersonTree 的静态内部类,成员变量和 PersonTree 的一致 */ public static class Builder{ private final String mName; //必选,final 类型需要在 构造器中初始化,不允许不初始化它的构造器存在 private String mLocation; //可选 private String mJob; //可选 private String mHabit; //可选 /** * 含必选参数的构造方法 * @param name */ public Builder(String name) { mName = name; } public Builder setLocation(String location) { mLocation = location; return this; } public Builder setJob(String job) { mJob = job; return this; } public Builder setHabit(String habit) { mHabit = habit; return this; } /** * 最终构建方法,返回一个 PersonTree 对象,参数是当前 Builder 对象 * @return */ public PersonThree build(){ return new PersonThree(this); } } }调用:
new PersonThree.Builder("shixinzhang") .setLocation("Shanghai") .setJob("Android Develop") .setHabit("LOL") .build();
相关文章推荐
- android app架构设计mvc
- Android App 开发 设计模式第三篇:模板方法模式
- Android App 架构设计
- Android App 开发 设计模式第九篇:桥接模式
- Android App的设计架构:MVC,MVP,MVVM与架构经验谈
- Android App的三种架构模式MVC,MVP和MVVM
- Android App的设计架构:MVC,MVP,MVVM与架构经验谈
- Android App 的设计架构:MVC、MVP、MVVM与架构
- Android App整体架构设计的思考
- Android App的架构设计:从VM、MVC、MVP到MVVM
- Android App的三种架构模式MVC,MVP和MVVM
- Android App的设计架构:MVC,MVP,MVVM与架构经验谈
- Android架构分析&设计模式 课程
- Android App的设计架构:MVC,MVP,MVVM与架构经验谈
- 一个android文本比对APP的实现(三)-设计模式在文件选择模块中的运用
- Android App的设计架构:MVC,MVP,MVVM与架构经验谈
- Android App的设计架构:MVC,MVP,MVVM与架构经验谈
- 设计模式 && android 框架 && app 设计
- Android App整体架构设计的思考
- Android App整体架构设计的思考(一)