Android重构杂感

写了多年C/C++代码,也写了多年java代码,C++为了执行效率,开发效率不断演进,不断推出新的特性,新的标准库。用来开发某一个单独功能时确实很方便快捷,单一旦涉及到UI以及功能复杂点的请况,C++的库就不够用了。java凭借着其简单的语法,以及内存管理,跨平台等优势,赢得了多年稳坐编程语言第一的位置。

在Android开发领域,由于其和C++开放的特点类似,带来了很多的碎片化,对用户来说是百花齐放,对开发者来说就是更多的工作量(更多的就业岗位)。

言归正传,说道重构,涉及到了重构的目标规范等,虽然是java代码重构,以下几大原则适合在很多语言甚至其他很多领域。

下面是搬运过来的

设计模式的六大原则(每一个原则看名字都是这么的高大上)

   1、开闭原则(Open Close Principle)

        一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。

   2、里氏代换原则(Liskov Substitution Principle)

       子类可以扩展父类的功能,但不能改变父类原有的功能。

   3、依赖倒转原则(Dependence Inversion Principle)

       核心思想是面向接口编程,即尽可能通过接口的方式调用函数或传递数据。

   4、接口隔离原则(Interface Segregation Principle)

       建立单一接口,不要建立庞大臃肿的接口,尽量细化接口,接口中的方法尽量少。

   5、迪米特法则(最少知道原则)(Demeter Principle)

      一个类对自己依赖的类知道的越少越好。

   6、单一职责原则(Single Responsiblity Principle)

     一个类只负责一项职责

根据以上设计原则在设计模块或接口时,有以下原则和技巧(有点像在讲做人的道理呢):

1.稳定性

必须相对稳定,若果很小的功能修改导致接口改动很多,这稳定性不够。

2.易用性

提供给外部使用的功能应该清晰易懂,即函数名称,调用参数应该尽可能直观,简单,也就是自描述功能。

3.完备性

模块函数除了完成自身功能外,还应该有容错,异常处理等功能。

4.内聚性

也就是自己的事情自己做,少去依靠别人。

时间: 2024-10-17 01:36:30

Android重构杂感的相关文章

我10年的Android重构之旅:框架篇

在我这几年的学习和成长中,慢慢的意识到搭建一个优秀的 Android 开发框架是一件非常困难以及痛苦的事情,它不仅需要满足不断增长的业务需求,还要保证框架自身的整洁与扩展性,这让事情变得非常有挑战,但我们必须这样做,因为健壮的 Android 开发框架是一款优秀APP的基础.在我们开发的初期往往并不需要什么框架,因为 Android Framework 良好的容错性帮助我们避免了很多问题,甚至你不需要深入的学习就可以写出一个较为完善的 APP,几个简单Material Design 风格界面加上

Android重构与设计之路,从整理提示对话框弹窗开始

封装一个独立弹窗Module,这里的弹窗包括普通的Dialog方式弹框和WindowManager方式弹窗.提供一种管理项目里面弹窗的方案,便于后期修改和维护. 首先描述一个在大项目中普遍存在的一个现象:由于项目的功能多,负责功能的人不同,当功能中需要一个普通的确定取消对话框时,大部分人都选择自己写了一个,自己new一个独立的弹窗出来.这样做的好处有以下几个: 代码逻辑独立,自己写的代码自己能控制 快速方便,便于修改,便于满足各种奇怪的需求 可是这个做法导致项目中存在大量的代码冗余,大量的分散的

数据结构HashMap(Android SparseArray 和ArrayMap)

HashMap也是我们使用非常多的Collection,它是基于哈希表的 Map 接口的实现,以key-value的形式存在.在HashMap中,key-value总是会当做一个整体来处理,系统会根据hash算法来来计算key-value的存储位置,我们总是可以通过key快速地存.取value. HashMap HashMap.java源码分析:三个构造函数:HashMap():默认初始容量capacity(16),默认加载因子factor(0.75)HashMap(int initialCap

Android弹幕实现:基于B站弹幕开源系统(4)-重构

?? Android弹幕实现:基于B站弹幕开源系统(4)-重构 弹幕在视频播放的APP中比较常见,但是逻辑比较复杂,现在在附录1,2,3的基础上,我再次对弹幕进行抽象和重构,把弹幕从底向上抽象成不同的层,便于复用. 第一步,抽象数据层.通常弹幕的来源是来源于后台的数据接口请求,在实时直播时候,是通过网络的轮询机制获取数据,那么,我把这部分代码抽出来设计成一个MGDanmakuHttpController,该类专注于数据的获取与分发: package zhangphil.danmaku; impo

Android 项目重构之路:实现篇

前两篇文章<Android项目重构之路:架构篇>和<Android项目重构之路:界面篇>已经讲了我的项目开始搭建时的架构设计和界面设计,这篇就讲讲具体怎么实现的,以实现最小化可用产品(MVP)的目标,用最简单的方式来搭建架构和实现代码. IDE采用Android Studio,Demo实现的功能为用户注册.登录和展示一个券列表,数据采用我们现有项目的测试数据,接口也是我们项目中的测试接口. 项目搭建 根据架构篇所讲的,将项目分为了四个层级:模型层.接口层.核心层.界面层.四个层级之

微信Android模块化架构重构实践

微信Android架构历史 微信Android诞生之初,用的是常见的分层结构设计.这种架构简单.清晰并一直沿袭至今.这是微信架构的v1.x时代. 图1-架构演进 到了微信架构的v2.x时代,随着业务的快速发展,消息通知不及时和Android 2.3版本之前webview内存泄露问题开始突显.由于代码.内存.apk大小都在增长,对系统资源的占用越来越多,导致微信进程容易被系统回收.因此微信开始转向多进程架构,独立的通信进程保持长连接的稳定性,独立的webview进程也阻隔了内存泄露导致的问题. 时

Android 项目重构之路:架构篇

去年10月底换到了新公司,做移动研发组的负责人,刚开始接手android项目时,发现该项目真的是一团糟. 首先是其架构,是按功能模块进行划分的,本来按模块划分也挺好的,可是他却分得太细,总共分为了17个模块,而好几个模块也就只有两三个类而已.但应用本身其实比较简单,要按功能模块来分的话,最多五个模块就够了. 另外,有好多模块划分也很模糊,也有很多类按其功能其实可以属于多个模块的,也有些类定义不明确,做了不该做的事.有时候,我要找一个界面的Activity,按照其功能应该属于A模块的,可是在A模块

Android 项目重构之路:界面篇

在前一篇文章<Android项目重构之路:架构篇>中已经简单说明了项目的架构,将项目分为了四个层级:模型层.接口层.核心层.界面层.其中,最上层的界面,是变化最频繁的一个层面,也是最复杂最容易出问题的一个层面,如果规划不好,很容易做着做着,又乱成一团了. 要规划好界面层,至少应该遵循几条基本的原则: 保持规范性:定义好开发规范,包括书写规范.命名规范.注释规范等,并按照规范严格执行: 保持单一性:布局就只做布局,内容就只做内容,各自分离好:每个方法.每个类,也只做一件事情: 保持简洁性:保持代

Android基础工具类重构系列一Toast

前言: 一直在考虑写一下Android实际项目中的一些总结,翻看CSDN博客,上一篇已经是一年多曾经. 本系列定位Android基础工具类重构.旨在记录实际项目中经经常使用到的一些工具类,比方Toast.Dialog.动画类,ImageLoader类等等.正在梳理,但发现梳理完再写预计黄花菜都凉了.所以改变策略,边写边梳理. 首先要写的就是这个Toast. 一.说明 作为Android系统提供的基类,Toast是最简单的提示消息类.特点悬浮.跨界面(Activity)特定时间内自己主动销毁. 二