Open/Closed Principle The Open/Closed principle states a class must be open and closed where: open means a class has the ability to be extended. closed means a class is closed for modifications other than extension. The idea is once a class has been approved for use having gone through code reviews, unit tests, and other qualifying procedures, you don't want to change the class very much, just extend it. The Open/Closed principle is a pitch for stability. A system is extended by adding new code not by changing already working code. Programmers often don't feel comfortable changing old code because it works! This principle just gives you an academic sounding justification for your fears :-)
In practice the Open/Closed principle simply means making good use of our old friends abstraction and polymorphism. Abstraction to factor out common processes and ideas. Inheritance to create an interface that must be adhered to by derived classes.
Design by Contract The idea of design by contract is strongly related to . A contract is a formal statement of what to expect from another party. In this case the contract is between pieces of code. An object and/or method states that it does X and you are supposed to believe it. For example, when you ask an object for its volume that's what you should get. And because volume is a verifiable attribute of a thing you could run a series of checks to verify volume is correct, that is, it satisfies its contract.
The contract is enforced in languages like Eiffel by pre and post condition statements that are actually part of the language. In other languages a bit of faith is needed.
Design by contract when coupled with language based verification mechanisms is a very powerful idea. It makes programming more like assembling spec'd parts.
其他杂项这一部分包含着各种各样的该做的和不该做的。
在需要用到离散的数值使，不要使用浮点数变量。采用浮点数来做循环计数器无异于向自己的脚
开枪。测试浮点数时总要使用 <= 或 => ，永远不要用 = 或 => 。
不要使用程序自动美化器，得益于好的程序样式的主要的人就是程序员自己，特别是刚开着手代
码、算法设计的程序员，使用程序自动美化器仅仅能根据语法来更正程序，因此当对空白和缩进
的注意有很大需要时，它是不可能做到的。正常的细心注意细节的程序员们能很好的用清晰直观
的样式来完成一个函数或文件（换句话来说，一些直观的样式是意向的规定而不是程序自动美化
器能读懂的智慧）。马虎的程序员应该学习细致的程序员，不要依赖程序自动美化器来增加程序
的可读性。最初的美化器是必须分析源代码的程序，复杂的美化器不值得通过这样获得好处，美
化器最好用于生成总的机器建立（machine-generated）格式代码。
对逻辑表达式第二个 = 不小心的忽略是一个问题，以下显得混乱而且更像是错误： if ($abool= $bbool) { ... }
程序员在这里真的是要赋值么？一般常常是，但通常又不是这样。这样避免引起这样的混乱呢？解
决方案就是不要这样做，利用显式和隐式的判断测试，推荐的方法是在做测试前先做赋值：
$abool= $bbool;
if ($abool) { ... }
使用if (0)来注释外部代码块 有时需要注释大段的测试代码，最简单的方法就是使用if (0)块： function example()
{
great looking code
if (0) {
lots of code
}
more code
}
你不能使用/**/，因为注释内部不能包含注释，而大段的程序中可以包含注释，不是么？ Different Accessor Styles Why Accessors? Access methods provide access to the physical or logical attributes of an object. We disallow direct access to attributes to break dependencies, the reason we do most things. Directly accessing an attribute exposes implementation details about the object.
To see why ask yourself:
What if the object decided to provide the attribute in a way other than physical containment?
What if it had to do a database lookup for the attribute?
What if a different object now contained the attribute? If any of the above changed code would break. An object makes a contract with the user to provide access to a particular attribute; it should not promise how it gets those attributes. Accessing a physical attribute makes such a promise.
Implementing Accessors There are three major idioms for creating accessors.
Get/Set class X
{
function GetAge() { return $this->mAge; }
function SetAge($age) { $mAge= $age; }
var $mAge;
}
One Method Name class X
{
function Age() { return $mAge; }
function Age($age) { $mAge= $age; }
var $mAge;
}
Similar to Get/Set but cleaner. Use this approach when not using the Attributes as Objects approach.
Attributes as Objects class X
{
function Age() { return $mAge; }
function rAge() { return &$mAge; }
function Name() { return mName; }
function rName() { return &$mName; }
var $mAge;
var $mName;
}
X $x;
$x->rName()= "test";
The above two attribute examples shows the strength and weakness of the Attributes as Objects approach.