又到年末，依旧感叹时间的飞逝。隔了大半年，才这里写上一篇文章，而且是年度总结，感觉更是无从下笔。

如果按客观格式写点个人总结：

1）这一年做了什么事情？
2）上一年的总结的计划的事情进展的如何？
3）具体分析完成的事情或目标情况，如完成的百分比，有哪些偏差，有哪些好坏等等？
4）明年的计划和展望是什么？

可是，还是觉得难以表达，难以总结。

这一年，过得还是很「混沌」和「迷茫」，创业团队快两年了，还是处于探索期，在尝试不同的方向，团队成员有疲惫，失去信心的状态。我很是自责，在产品规划、设计和运营这方面经验很不够（我是一个技术能力马马虎虎的coder）。但非常感谢团队的信任！

上一年（2012年的个人总结）计划中，无一实现。但是这年感觉过的很忙很忙，停下来静思，却一点也不充实，无积累。

总之，能力（先产品设计，部门协调，市场营销等能力，这些能力也说得很泛）还很浅很浅，学习再学习，专注再专注。

2014年，2013过去，1314，瞄~

2014年，电子商务又会有一个怎样的发展？阿里双11一天的350亿销售额更说明电商在咄咄逼传统行业。

2014年，移动互联网会进阶到怎样的时代，2013年可以说是移动互联网的创业大潮的青春时代，看过《浪潮之巅》，大家应该就站在移动互联网浪潮之颠吧。所以，骚年们，咱生得逢时啊，但是怎么抓住呢？那个愁啊！

所以，2014年，我的关键字有大家说得老烂的字词 「电子商务」、「移动互联网开发技术」，还有一个非常关键的「爱情->婚姻」。（大伙祝福我吧）

最后，虽然很啰嗦，很负面的呱啦了一段，但马年伊始，祝福大伙想啥「马上」有啥！哈哈…

单例模式被当作职责模式，被用来在应用程序中创建一个单一的功能访问点。比如，在OOP中，一个对象只负责一个特定的任务（一个对象去访问数据库等）。

作用：
1）节约系统资源。单例类仅有一个实例存在。
2）维持应用程序状态的同步

特点（至少以下四个特点）：
1）必须拥有访问级别为private的构造函数。因为单例类不能在其它类中直接实例化，只能被其自身实例化。
2）拥有一个保存类的实例的静态成员变量。
3）拥有一个访问实例的公共的静态方法。
4）必须创建一个空的访问级别为private的__clone()方法。单例类不会创建实例的副本，而是内部存储的实例返回一个引用。

举例：数据库连接职责的集中控制

class Db
{
   private $_db;   // 构建对象时其值被填充
  public static $_instance;   // 静态变量，用于保存类仅有的一个实例

  private function __construct()
  {
    $this->_db = pg_connnect('.....');
  }

  // 私有的__clone方法消除了PHP语言中可以复制对象，防止破坏单一职责
 private __clone() {}

  // 单例模式的实际构造
 public static function getInstance()
 {
    // 检查静态实例变量是否已保存Db类的一个实例
   if (! (self::$_instance instanceof self)) {
     self::$_instance = new self();
   }

   return self::$_instance;
 }

  public functon query($sql)
  {
     // 执行查询的code
  }
}

静态特性应用在变量，类和方法上，带来的好处是无可厚非的：

1）作为静态变量（用static关键字修饰的函数变量，创建时可提供默认的初始化值，其初始化值不能是表达式），在某一函数执行后，其值仍然不会丢失。这可在全局变量作为模拟静态时，消除了变量名称冲突的现象。

2）作为类的静态属性或方法，其变量值或方法对每个类的实例都是有效的，即是所有的实例共享这个成员或方法。这样可以避免创建类的实例，省略实例化的代码，更高效些（因为类的每个实例都会占用一小部分的系统资源）。

然后，静态类会对特定类型的测试产生影响。因为静态特性的使用会导致类之间通过名称绑定一起，使得单独的测试某个组件变得更加困难。因为类的名称是硬编码的，这样测试时，这个类不容易被模拟。

有 这么个设计原则，叫IoC（控制反转），它试图在OOP中去掉所以相互依赖的现象。相互依赖现象少了，越容易单独测试某个组件。也使对象具有更好的多态性和封装性。这是对于复杂的系统来说，是非常重要的。显然，使用静态特性，IoC就受到限制。

在PHP的应用中，静态特性还是很受欢迎的。现在，自己只能等着瞧它如何“走”～

来个简单的滑动显示评价等级星标识。即是假如有个星标识，当鼠标移到到第三个星标识时，前三个星“满色”（充满颜色），后二个没有颜色。看了一些例子，有写得很棒的，很玄的。下边给个很简单的：

function stars(num)
{
	var items = document.getElementById('rating_stars').getElementsByTagName('a');

	if (items.length) {
		for (var i=0; i < items.length; i++) {
			items[i].className = i <= num ? '' : 'disabled';
		}
	}
}

对a标签的className定义下，就可以看到效果。 很简单也很不美观，但效率还是过得去吧，不过有时候觉得，想法简单点，可能会有好的局面和收获。

Ecshop类的模板类（includes/cls_template.php)，简化的着实好用。但可否注意到这个bug：

简单举例说：

在模板里面的某一个smarty标签有：{foreach from=$goods_list item=goods} ， 还有 {$goods.goods_name}等

在PHP文件注册变量有：$smarty->assign(‘goods_list’, $goods_list);  $smarty->assign(‘goods’, $goods);

注意到smarty语法foreach语句中的item的名字是goods，而又有一个goods标签名被注册；其模板类有考虑防止注册相同标签的变量（即$this->_val[var_name]中的var_name防止重复），所以它在处理var_name的时候，在_compile_foreach_start(tag_args)处理，利用$this->_patchstack成员（array类型）暂存储foreach中的处理后的item名字（即对goods后面再加入随机数字，以防重复）。然后再注册变量的时候，判断下标为item的名字的$this->_patchstack变量是否存在，然后再以其值作为$this->_val数组的下标，而进行赋值。

然而，它在处理$this->_patchstack中，有一个必要的任务，存储一个变量的时候，用完它的时候，必须废了它。它在这个关节上，有bug（从make_val方法入手查起就了然）。所以导致在多个foreach在item的名字，如果和单独一个变量名相同时候（上边提到的goods），就会导致生成编译文件的时候，对单独变量名的：eg：编译后的本应该是$this->_val[‘goods’][‘goods_name’]， 却是 $this->_var[‘goods_0_95615500_1302147485’][‘goods_name’]，这样$smarty->assign(‘goods’, goods)注册的变量，就不可赋值到对应的变量中，从而显示不出数据。

罗嗦了那么多，就是该废它的时候，没废到。在select($tag)方法中，当tag{0} == ‘/’和substr($tag, 1) == ‘foreach’的时候，在$this->_foreachmark == ‘foreachelse’的时候，没有array_pop($this->_patchstack)。允许它，问题解决。

还有，模板类它一开始并为声明_patchstack其成员变量，这本身埋下不稳定的因素。

还是记下来，方便使用：

1 等差数列
1）公差d：d = a_n-a_n-1
2）通项公式：a_n = a₁ + (n-1) d = S₁ = S_n – S_n-1 (n >= 2)
3）等差中项：A = (a+b) / 2
4）前n项和：
S_n = n(a₁ + a_n) / 2 = na₁ + n(n-1) * d / 2
5）a₁ + a_n = a₂ + a_n-1 = ….

2 等比数列
1）公比q： q = a_n / a_n-1
2）通项公式：a_n = a₁q^n-1
3）等比中项：b² = ac
4）前n项和：S_n = a₁(1-qⁿ) / (1-q) (q != 1)
5）a₁a_n = a₂a_n-1 = …..