普通网友-CSDN博客

转载在Java中实现UDP协议编程的方法[转]

什么是UDP协议　　UDP协议的全称是用户数据报，在网络中它与TCP协议一样用于处理数据包。在OSI模型中，在第四层——传输层，处于IP协议的上一层。UDP有不提供数据报分组、组装和不能对数据包的排序的缺点，也就是说，当报文发送之后，是无法得知其是否安全完整到达的。　　为什么要使用UDP　　在选择使用协议的时候，选择UDP必须要谨慎。在网络质量令人不十分满意的环境下，UDP协议数据包丢失会比较严

2007-07-18 23:38:00 836

转载 How to make your Java applications work across proxies and firewalls?

IntroductionJava provides a rich API for networking and I/O. The initial releases of the JDK did not contain native support for proxies and firewall authentications -- however, as of J2SDK1.4,

2007-07-15 13:42:00 1075

转载 Java/J2EE中文问题终极解决之道[转]

Java中文问题一直困扰着很多初学者，如果了解了Java系统的中文问题原理，我们就可以对中文问题能够采取根本的解决之道。　　最古老的解决方案是使用String的字节码转换，这种方案问题是不方便，我们需要破坏对象封装性，进行字节码转换。　　还有一种方式是对J2EE容器进行编码设置，如果J2EE应用系统脱离该容器，则会发生乱码，而且指定容器配置不符合J2EE应用和容器分离的原则。　

2007-07-12 00:43:00 782

原创代码的坏味道——摘自《重构》

Duplicated Code 如果在一个以上的地点看到相同的程序结构，那么应当可以肯定：设法将它们合而为一，程序会变得更好。Long Method 应该更积极进取地分解函数。我们遵循这样一条原则：每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途（而非实现手法）命名。Large Class 如果想利用单一class做太多事情，其内往往就

2007-05-13 19:13:00 1031

原创重构概述——摘自《重构》

Design Patterns 为 Refactoring 提供了目标。重构：在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。重构是一种有纪律的，经过训练的，有条不紊的程序整理方法，可以将整理过程中不小心引入错误的几率降到最低。本质上说，重构就是“在代码写好之后改进它的设计”。差劲的系统是很难修改的，因为很难找到修改点。如果很难找到修改点，程序员

2007-04-19 21:01:00 983

原创《设计模式解析》摘录（17）

设计模式回顾面向对象原则的总结： 1、对象是具有明确定义的责任的事物； 2、对象对自己负责； 3、封装指的是任何形式的隐藏：（1）数据隐藏（2）实现隐藏（3）类隐藏（4）设计隐藏（5）实例化隐藏 4、使用共性和可变性分析抽象出行为和数据中的变化； 5、按接口设计 6、将继承看成一种将变化概念化的方法，而不是

2007-04-03 22:23:00 863

原创《设计模式解析》摘录（16）

Factory Method 模式关键特征：意图：定义一个用于创建对象的接口，让子类决定实例哪一个类。将实例化推迟到子类。问题：一个类需要实例化另一个类的派生类，但不知道是哪一个。Factory Method 允许派生类进行决策。解决方案：派生类对实例化哪个类和如何实例化做出决策。参与者与协作者：Product 是工厂方法所创建的对象类型的接口

2007-04-02 22:07:00 739

原创《设计模式解析》摘录（15）

Object Pool 模式关键特征：意图：在创建对象比较昂贵，或者对于特定类型能够创建的对象数目有限制时，管理对象的重用。问题：对象的创建和管理必须遵循一组定义明确的规则集。通常这些规则都与如何创建对象、能够创建多少个对象和在已有对象完成当前任务时如何重用它们等等相关。解决方案：在需要一个 Reusable 对象时，Client 调用 ReusablePo

2007-03-27 21:13:00 714

原创《设计模式解析》摘录（14）

Singleton 模式 Singleton 模式和 Double－Checked Locking 模式都可以用于确保某个类只有一个对象实例化。两个模式的区别在于：Singleton 模式用在单线程应用程序中，而 Double－Checked Locking 模式用于多线程应用程序。关键特征：意图：希望对象只有一个实例，但没有控制对象实例化的全局对象。还希望确保所有实例使

2007-03-26 22:45:00 811

原创《设计模式解析》摘录（13）

如果要遵循模式的原则和实践，就暗含着必须将对象的使用与对象的构造和管理分开来，各种工厂模式应运而生。软件开发的大背景：规则：先考虑系统中需要什么，然后再去关注如何创建系统......也就是说，我们应该在确定了对象是什么之后再定义工厂。首先，确定对象是什么，它们如何工作，然后确定如何对其实例化。对象应该要么构造、或管理其他对象，要么使用其他对象，而不应该兼

2007-03-24 22:39:00 892

原创《设计模式解析》摘录（12）

Observer 模式关键特征：意图：在对象之间定义一种一对多的依赖关系，这样当一个对象的状态改变时，所有的依赖者都将得到通知并自动更新。问题：当某个事件发生时，需要向一系列变化着的对象发出通知。解决方案：Observer 将监视某个事件的责任委托给中心对象 Subject。参与者与协作者：Subject 知道自己的 Observer，因为 Ob

2007-03-24 14:25:00 775

原创《设计模式解析》摘录（11）

Decorator 模式 Decorator 模式的工作原理：可以创建始于 Decorator 对象（复杂新功能的对象）终于原对象的一个对象“链”。每条链都始于一个 Component（ConcreteComponent 或 Decorator）。每个 Decorator 对象后面都跟着另一个 Decorator 对象或原 ConcreteComponent 对象。对象链总是

2007-03-23 23:38:00 696

原创《设计模式解析》摘录（10）

开闭原则：模块、方法和类应该对扩展开放，对修改封闭。也就是说，应该将软件设计得不对其修改就能扩展功能。开闭原则本质上意味着将软件设计成为新功能能够作为单独的模块加入系统，这样就尽量降低了集成成本。完全遵守开闭原则几乎是不可能的，但是它可以作为一个目标，指引正确的方向。代码越遵守这一原则，以后适应新（而且可能是无法预测的）需求就越轻松。依赖倒置原则： 1、

2007-03-23 23:15:00 834

原创《设计模式解析》摘录（9）

设计常常被认为是一种合成过程，一种将事物放在一起的过程，一种组合过程。按照这种观点，整体是由部分组合而成的。先有部分，然后才有整体的形式。但是，只是把预先形成的部分加起来，不可能形成有自然特征的任何东西，从部分构造整体，不可能得到优美的设计。优秀的设计要求胸中始终有丘壑。每个部分都因其存在与更大整体的背景中而被赋予了特定的形式。这是一个分化的

2007-03-23 00:41:00 713

原创《设计模式解析》摘录（8）

Abstract Factory 模式 switch 语句本身常常说明： 1、需要多态行为； 2、存在职责错放。应该考虑用一种更通用的解决方案，比如抽象代替 switch 语句，或者将职责赋予其他对象；工厂是有一定职责的......而且是内聚的。 Abstract Factory 模式的3各关键的概念步骤： 1、找到变化并封装之；

2007-03-23 00:04:00 710

原创《设计模式解析》摘录（7）

当人们开始学习设计模式时，他们经常把注意力放在模式提供的解决方案上。这看起来似乎很合理，因为设计模式被广为宣传的一点就是能够为实际问题提供优秀的解决方案。但是，这从方向上来说就是错误的。在尝试将某个解决方案应用到一个问题之前，应该先理解问题。这种只是寻找在何处应用模式的方法，只能告诉你要做什么，但是不能告诉你什么时候或者为什么使用。将注意力放在模式的上下文——模式

2007-03-21 22:08:00 735

原创《设计模式解析》摘录（6）

Strategy 模式定义一系列的算法，把它们一个个封装起来，并且使它们可互相替换。Strategy 模式使算法可独立于使用它的客户而变化。基础原则： 1、对象都具有职责； 2、这些职责不同的具体实现是通过多态的使用完成的； 3、概念上相同的算法具有多个不同的实现，需要进行管理。将问题域中的各个行为互相分离开来——也就是说将它们解耦

2007-03-20 23:41:00 629

原创《设计模式解析》摘录（5）

短期的抄近路，可能会在长期导致问题严重复杂化。灾难往往是由短期未臻最优的决策，长期积累而引起的。许多项目只关心处理眼前的紧迫需求，却不顾将来的维护。 1、针对接口进行编程，而不要针对实现编程； 2、优先使用对象组合，而不是类继承； 3、考虑设计中什么应该是可以变化的。这种方法与关注引起重新设计的原因刚好相反。它不是考虑什么会迫使设计发生改变，而是考虑什么能够在

2007-03-19 23:53:00 784

原创《设计模式解析》摘录（4）

对象传统看法：具有方法的数据（从实现的视角来看待对象，太简单，太肤浅了）；新看法：具有责任的实体。这些责任定义了对象的行为（从概念视角出发）。关注动机而非实现，使设计模式中反复出现的主题，因为将实现隐藏在接口之后，实际上是将对象的实现与使用它们的对象解耦了。封装封装不仅仅是数据隐藏；封装应该被视为“任何形式的隐藏”，可以是隐藏数据，但还可以隐藏实

2007-03-17 16:33:00 802

原创《设计模式解析》摘录（3）

Adapter 模式将一个类的接口转换成为客户希望的另一个接口。Adapter 模式使原本由于接口不兼容而不能一起工作的类可以一起工作。关键特征：意图：使控制范围之外的一个原有对象与某个接口匹配。问题：系统的数据和行为都正确，但接口不符。通常用于必须从抽象类派生时。解决方案：Adapter 模式提供了具有所需接口的包装类。参与者与协作

2007-03-17 16:32:00 739

原创《设计模式解析》摘录（2）

Facade 模式为子系统中的一组接口提供一个统一接口，Facade 模式定义了一个更高层的接口，使子系统更加容易使用。关键特征：意图：希望简化原有系统的使用方式，需要定义自己的接口。问题：只需要使用某个复杂系统的子集，或者，需要以一阵特殊的方式与系统交互。解决方案：Facade 为原有系统的客户提供了一个新的接口。参与者与协作者：为

2007-03-17 16:29:00 754

原创《设计模式解析》摘录（1）

对象真正的威力并不在于继承，而是来自封装行为。不能将模式作为一个单独的东西使用，应该把它们结合起来。模式应该相互配合，共同解决问题。功能分解方法的挑战：能者多责；难题：应对变化。对于阻止变化，我们无计可施。但是我们对变化本身却并非无能为力。虽然无法预测会发生什么变化，但是通常可以预期哪里会发生变化。面向对象的巨大优点之一，就是可以

2007-03-14 22:40:00 693

悠悠的专栏