C# 设计模式学习一 原则
最近着实忙了一阵子，学习了好多东东都没时间整理，呵呵，总算是要放假了，可以好好归纳归纳了。
设计模式的学习是一个任重而道远的过程了，^_^，要好好总结，总结的目的是让自己好好记住，记住的目的是便于理解，而理解的最终目的是应用，O(∩_∩)O~ 而设计模式也往往是应用的一种重构，循环往复，生生不息啊... ...
变化的部分是不易掌握的，容易掌握的是总则，是不变的部分
一，三大原则
1，针对接口编程，而不是实现编程。
客户无需知道所使用的对象的特定类型，只需要知道对象拥有客户所期望的接口。
2，优先使用类与对象的组合，而不是类的继承
继承在某种程度上破坏了封装性，除了很清楚的Is a XX类的关系时用到继承，之外优先使用组合
3，封装变化点
如果未来有变动，尽量只修改一侧代码（不变动的代码是不存在的，少变动才目的）
4，使用重构得到模式，
模式是推演出来的，而不是直接用模式去套用，生搬硬套往往得不到我们的预期。
※设计模式并不是技巧
※设计模式是一个重构的过程
二，具体设计原则
1，单一职责原则
一个类仅有一个引起它变化的原因
2，开放封闭原则
对扩展开放，对更改封闭（不是绝对的不，一再强调任何事都没有绝对的，是尽量扩展，尽量不要修改）
3，替换原则
一个子类必须能替换他们的基类，如果我们的设计发现这样的关系很模糊，就要仔细研究一下了。
4，依赖倒置原则
高层模块不应该依赖于底层模块，二者应依赖于抽象
抽象不应该依赖于实现细节，实现细节应该依赖于抽象
5，接口隔离原则
不应该强迫客户程序依赖于他们不用的方法。
这只是设计模式的整体原则，我想应该是学习过程中要时时体会的东西了。
就C#来说，再说点自己的感想，我们学习模式也好，架构也好，各种framework也好，都有点像那种高深的武功比如乾坤大挪移，九阴真经下卷这种，直接拿来学习有好多艰涩难懂的地方需要反复理解和再学习，如果我们能先把C#中的每一个语法表现都运用自如，再来看这些也许就容易很多，可现实是我们不能像无忌哥那样找个山洞一呆就是几年，所以只能边学九阳神功，边学乾坤大挪移了，^_^，可好就好在我们的世界有了网�
相关文档：
ü ref、out、与params
应该来说这三个关键在一般的编码过程中还是会不时涉及到的，所以不算什么“冷僻”的概念。有关三个参数修饰符的解释如下：
Ref：ref关键字让一个值类型的输入参数按引用传递。实际上，对于引用类型的参数，是否使用ref关键字，差别微乎其微。有一个例外是String类型的参 ......
Eval("")和Bind("") 这两种一个单向绑定，一个双向绑定，bind是双向绑定,但需数据源支持
ASP.NET 2.0改善了模板中的数据绑定操作，把v1.x中的数据绑定语法DataBinder.Eval(Container.DataItem, fieldname)简化为Eval(fieldname)。Eval方法与DataBinder.Eval一样可以接受一个可选的格式化字符串参 ......
又有一段时间没有更新了，缺少学习的热情了。今天贴几个图片处理的小技巧，希望对大家有用：
(1)如何获取.gif图片中的各个帧？
(2)如何获取图片的缩略图？
(3)如何“截取”图片的指定区域？
using System.Drawing;
using System.Drawing.Drawing2D;
using System.Drawing.Imaging;
public class ImageHelp ......
基类的重写：
new:（仅针对派生类用派生实例调用时才起作用，目的是在派生类中用来覆盖基类的方法）
1.派生类构建成的实例，当调用由new 修饰的方法时，覆盖基类new 方法。
2.派生类构建成的实例赋给基类变量时，再调用由new 修饰的方法时，将执行基类中的方法。
virtual、override
1.由派生类构建的实例，不管是用派� ......
//Socket基本编程
//服务端：
using System.Net;
using System.Net.Sockets;
using System.Text;
using System.Threading;
Thread mythread ;
Socket socket;
// 清理所有正在使用的资源。
protected override void Dispose( bool disposing )
{
try
{
socket.Close();//释放资源
......
