让程序运行的更有效的方法和原则
MVC 是 Model、View、Controller 的缩写(如上图):1.模型(Model):
是应用程序的主体部分，所有的业务逻辑都应该在此体现。
2.视图(View):
是应用程序中负责生成用户界面的部分。
也是在整个 MVC 架构中用户唯一可以看得见的一层，接收用户的输入，显示处理结果。
3.控制器(Control):
根据用户的输入，选择相应的模型，并将用户的输入数据交给相应的模型处理，
最后将模型处理的结果(及数据)交给相应的视图显示。
注：视图和模型与控制器的关系是多对一，视图和模型可以一或多个，而控制器仅且只有一个。
在面对千变万化的业务需求时编写出可重用、可扩展、可维护、灵活性高的代码，需要遵循以下原则:
1."开-闭"原则(Open-Closed principle):
一个软件实体应当对扩展开放，对修改关闭。
这个原则说的是，在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展。
换言之，应当可以在不必修改源代码的情况下改变这个模块的行为。
2.里氏替换原则(Liskov Substitution Principle):
只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或者异常，
我们根本不需要知道是父类还是子类。
需要注意的是：有子类出现的地方，父类未必就能适应。
采用里氏替换原则目的是增强程序的健壮性，版本升级时也可以保持非常好的兼容性，
即使增加新子类，原有的子类还可以继续运行。
3.依赖倒转原则(DIP):
要依赖于抽象，不要依赖于具体。
在实际编程中，我们一般需要做到如下三点：
1)低层模块尽量都要有抽象类或接口，或者两者都有。
2)变量的声明类型尽量是抽象类或接口。
3)使用继承时遵循里氏替换原则。
4.接口隔离原则(Interface Segregation Principle):
使用多个专门的接口比使用单一的总接口要好。
一个类对另外一个类的依赖性应当是建立在最小的接口上的。
即不要强迫一个类使用它不用的方法，如果强迫一个类使用它们不使用的方法，
那么这个类就会面临由于这些不使用的方法的改变所带来的改变。
注：
冗余就是灵活性和健壮性的杀手！
无论软件接口设计还是数据库表设计，一切设计不要冗余！
5.合成/聚合复用原则(Composite/Aggregate Reuse Principle):
又称合成复用原则(CRP)，就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；
新的对象通过向这些对象的委派达到复用已有功能的目的。
要尽量使用合成/聚合，而尽量不使用继承。
应首先使用合成/聚合，合成/聚合则使系统灵活，其次才考虑继承，达到复用的目的。
使用继承时，要严格遵循里氏替换原则。
有效地使用继承会有助于对问题的理解，降低复杂度，
而滥用继承会增加系统构建、维护时的难度及系统的复杂度。
注：
合成：由部分组成整体。
合成表示一种强的拥有关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样。
聚合：分散的聚集到一起。
聚合表示一种弱的拥有关系，体现的是A对象可以包含B对象，但是B对象并不是A对象的一部分。
在设计中，聚合不应该频繁出现，这样会增大设计的耦合度。
耦合度(Coupling)是对模块间关联程度的度量。
耦合的强弱取决与模块间接口的复杂性、调用模块的方式以及通过接口传送数据的多少。
6.迪米特法则(Law of Demeter):
又称最少知识原则(Least Knowledge Principle)，就是说一个对象应当对其他对象尽可能少的了解。
1)每个单元对于其他的单元只能拥有有限的知识：只是与当前单元紧密联系的单元；
2)每个单元只能和它的朋友交谈：不能和陌生单元交谈；
3)只和自己直接的朋友交谈。
信息的隐藏非常重要的原因在于，它可以使各个子系统之间脱耦，从而允许它们独立地被开发、优化、使用、阅读以及修改。
高效快速的编写代码和编写高效率执行的代码很多时候都是对立的死敌，
很多时候，你想快速的开发，代码的执行效率往往就会慢下来；
你想编写高效的代码，开发速度就会慢下来。
不重复发明轮子和发明新的轮子是高效的编写高效的代码的正确是道路。
对于占用资源的系统,有两条基本原则:
1.不要做不必要的事；
2.不要分配不必要的内存；
应该思考的事：
1.分配内存永远都比不分配内存的代价大；
2.在用户界面循环中分配内存，就会引发周期性的内存回收；
3.能用原始的数据就不要用对象，如：能不把字符串转成 string 对象来用，就不要转了，int数组比Integer数组更好。
4.能用 C++ 来实现的就不要用 Java 来实现，能用 C 实现的就不要用 C++ 来实现。
5.调用一个接口的引用会比调用实体类的引用多花费一倍的时间。
6.不需要访问成员变量的成员函数,请声明成静态函数(static)。
7.不需要在多态情况下调用的成员函数，请不要声明成虚函数(virtual)。
8.使用成员函数来避免外部直接访问成员变量是个好习惯，但如 Android 之类的开发在一般的类中，还应该直接访问变量来提高速度。
9.访问成员变量比访问本地变量慢得多，将成员变量缓存到本地。
A.永远不要在 for 的第二个条件中调用任何方法，
如：
unsigned int uiForCounter = 0;
for( uiForCounter = 0;
uiForCounter < this.getCount();
uiForCounter++ )。
B.同 A 如果你要多次访问一个成员变量，也最好先为它建立一个本地变量。
注：另外就是方法的参数与本地变量的效率相同，不是为了将指针常量的参数借来遍历访问的话，不要再建立一个本地变量副本了。
C.能用常量的地方就要用变量，如：
C/C++:
float fPiValue = 3.14159; =变为=> #define PI 3.14159 或 const float PI = 3.14159;
Java:
static int intVal = 42; =变为=> static final int intVal = 42; // 加上 final 关键字
以上不会带来性能的提升，但是会帮助编译器优化代码。
D.嵌入式处理器通常没有支持浮点运算的硬件，一些芯片有对乘法的硬件支持而缺少对除法的支持。
C.能用常量的地方就要用变量，如：
C/C++:
float fPiValue = 3.14159; =变为=> #define PI 3.14159 或 const float PI = 3.14159;
Java:
static int intVal = 42; =变为=> static final int intVal = 42; // 加上 final 关键字
float fPiValue = 3.14159; =变为=> #define PI 3.14159 或 const float PI = 3.14159;
这些没有意义的。 C.能用常量的地方就要用变量，如：
C/C++:
float fPiValue = 3.14159; =变为=> #define PI 3.14159 或 const float PI = 3.14159;
Java:
static int intVal = 42; =变为=> static final int intVal = 42; // 加上 final 关键字
以上不会带来性能的提升，但是会帮助编译器优化代码。 sushe2111 发表于 2014-6-20 18:19
C.能用常量的地方就要用变量，如：
C/C++:
float fPiValue = 3.14159; =变为=> #define PI 3.14159 或...
有测试证据吗？
页:
[1]