自己的java知识原本三

Jdo是什么? 

JDO是Java对象持久化的新的规范，为java data object的简称,也是一个用于存取某种数据仓库中的对象的标准化API。JDO提供了透明的对象存储，因此对开发人员来说，存储数据对象完全不需要额外的代码（如JDBC API的使用）。这些繁琐的例行工作已经转移到JDO产品提供商身上，使开发人员解脱出来，从而集中时间和精力在业务逻辑上。另外，JDO很灵活，因为它可以在任何数据底层上运行。JDBC只是面向关系数据库（RDBMS）JDO更通用，提供到任何数据底层的存储功能，比如关系数据库、文件、XML以及对象数据库（ODBMS）等等，使得应用可移植性更强。 

什么是spring的IOC , AOP

简单回答：

控制反转模式（也称作依赖性注入）的基本概念是：不创建对象，但是描述创建它们的方式。在代码中不直接与对象和服务连接，但在配置文件中描述哪一个组件需要哪一项服务。容器 （在 Spring 框架中是 IOC 容器） 负责将这些联系在一起。

在典型的 IOC 场景中，容器创建了所有对象，并设置必要的属性将它们连接在一起，决定什么时间调用方法。下表列出了 IOC 的一个实现模式。

类型 1 服务需要实现专门的接口，通过接口，由对象提供这些服务，可以从对象查询依赖性（例如，需要的附加服务）。 

类型 2 通过 JavaBean 的属性（例如 setter 方法）分配依赖性。 

类型 3 依赖性以构造函数的形式提供，不以 JavaBean 属性的形式公开。

Spring 框架的 IOC 容器采用类型 2 和类型3 实现。

面向方面的编程，即 AOP，是一种编程技术，它允许程序员对横切关注点或横切典型的职责分界线的行为（例如日志和事务管理）进行模块化。AOP 的核心构造是方面，它将那些影响多个类的行为封装到可重用的模块中。

AOP 和 IOC 是补充性的技术，它们都运用模块化方式解决企业应用程序开发中的复杂问题。在典型的面向对象开发方式中，可能要将日志记录语句放在所有方法和 Java 类中才能实现日志功能。在 AOP 方式中，可以反过来将日志服务模块化，并以声明的方式将它们应用到需要日志的组件上。当然，优势就是 Java 类不需要知道日志服务的存在，也不需要考虑相关的代码。所以，用 Spring AOP 编写的应用程序代码是松散耦合的。

AOP 的功能完全集成到了 Spring 事务管理、日志和其他各种特性的上下文中。

详细介绍：

在J2EE的整个发展历程中，现在正是一个非常时刻。从很多方面来说，J2EE都是一个伟大的成功：它成功地在从前没有标准的地方建立了标准；大大提升了企业级软件的开放程度，并且得到了整个行业和开发者的广泛认可。然而，J2EE在一些方面已经开始捉襟见肘。J2EE应用开发的成本通常很高。J2EE应用项目至少和从前的非J2EE项目一样容易失败——如果不是更容易失败的话。这样的失败率高得让人难以接受。在这样的失败率之下，软件开发几乎变成了碰运气。而在J2EE遭遇失败的场景中，EJB通常都扮演着重要的角色。因此，J2EE社群不断地向着更简单的解决方案、更少使用EJB的方向发展[1]。然而，每个应用程序都需要一些基础设施，拒绝使用EJB并不意味着拒绝EJB所采用的基础设施解决方案。那么，如何利用现有的框架来提供这些基础设施服务呢，伴随着这个问题的提出，一个轻量级的J2EE解决方案出现了，这就是Spring Framework。

　　Spring是为简化企业级系统开发而诞生的，Spring框架为J2EE应用常见的问题提供了简单、有效的解决方案，使用Spring，你可以用简单的POJO(Plain Old Java Object)来实现那些以前只有EJB才能实现的功能。这样不只是能简化服务器端开发，任何Java系统开发都能从Spring的简单、可测试和松耦合特征中受益。可以简单的说，Spring是一个轻量级的反向控制（IoC）和面向切面编程（AOP）容器框架[3]。Spring IoC，借助于依赖注入设计模式，使得开发者不用理会对象自身的生命周期及其关系，而且能够改善开发者对J2EE模式的使用；Spring AOP，借助于Spring实现的拦截器，开发者能够实现以声明的方式使用企业级服务，比如安全性服务、事务服务等。Spring IoC和 Spring ; AOP组合，一起形成了Spring，这样一个有机整体，使得构建轻量级的J2EE架构成为可能，而且事实证明，非常有效。没有Spring IoC的Spring AOP是不完善的，没有Spring AOP的Spring IoC是不健壮的。本文是以Spring架构的成功的实际商务系统项目为背景，阐述了反向控制原理和面向切面的编程技术在Spring框架中的应用，同时抽取适量代码示意具体应用，并和传统开发模式进行对比，展示了Spring framework的简单，高效，可维护等优点。

　　1、Spring IoC 1.1 反向控制原理

　　反向控制是Spring框架的核心。但是，反向控制是什么意思？到底控制的什么方面被反向了呢？2004年美国专家Martin Fowler发表了一篇论文《Inversion of Control Containers and the Dependency Injection pattern》阐述了这个问题，他总结说是获得依赖对象的方式反向了，根据这个启示，他还为反向控制提出了一个更贴切的名字：Dependency Injection(DI 依赖注入)。

　　通常，应用代码需要告知容器或框架,让它们找到自身所需要的类,然后再由应用代码创建待使用的对象实例。因此，应用代码在使用实例之前，需要创建对象实例。然而，IoC模式中,创建对象实例的任务交给IoC容器或框架(实现了IoC设计模式的框架也被称为IoC容器)，使得应用代码只需要直接使用实例，这就是IoC。相对IoC 而言，“依赖注入”的确更加准确的描述了这种设计理念。所谓依赖注入，即组件之间的依赖关系由容器在运行期决定，形象的来说，即由容器动态的将某种依赖关系注入到组件之中。

　　1.2 IoC在Spring中的实现

　　任何重要的系统都需要至少两个相互合作的类来完成业务逻辑。通常，每个对象都要自己负责得到它的合作（依赖）对象。你会发现，这样会导致代码耦合度高而且难于测试。使用IoC，对象的依赖都是在对象创建时由负责协调系统中各个对象的外部实体提供的，这样使软件组件松散连接成为可能。下面示意了Spring IoC 应用，步骤如下：

　　（1）定义Action接口，并为其定义一个execute方法，以完成目标逻辑。多年前，GoF在《Design Pattern：Elements of Reusable Object-Oriented Software》一书中提出“Programming to an Interface，not an implementation”的原则，这里首先将业务对象抽象成接口，正是为了实施这个原则。

　　（2）类UpperAction实现Action接口，在此类中，定义一个String型的域message，并提供相应的setter和getter方法，实现的execute方法如下：

public String execute (String str) {   　return (getMessage () + str).toUpperCase () ; }

　　（3）编写Spring配置文件（bean.XML）

＜beans＞   ＜bean id="TheAction" class="net.chen.spring.qs.UpperAction"＞ ＜property name="message"＞ ＜value＞HeLLo＜/value＞ ＜/property＞ ＜/bean＞ ＜/beans＞

　　（4）测试代码

public void testQuickStart () {   　ApplicationContext ctx=new 　FileSystemXmlApplicationContext ("bean.xml"); 　Action a= (Action) ctx.getBean ("TheAction"); 　System.out.println (a. execute ("Rod Johnson")); }

　　上面的测试代码中，我们根据"bean.xml"创建了一个ApplicationContext实例，并从此实例中获取我们所需的Action实现，运行测试代码，我们看到控制台输出：

……   HELLO ROD JOHNSON

　　仔细观察一下上面的代码，可以看到：

　　（1）我们的组件并不需要实现框架指定的接口，因此可以轻松的将组件从Spring中脱离，甚至不需要任何修改，这在基于EJB框架实现的应用中是难以想象的。

　　（2）组件间的依赖关系减少，极大改善了代码的可重用性。Spring的依赖注入机制，可以在运行期为组件配置所需资源，而无需在编写组件代码时就加以指定，从而在相当程度上降低了组件之间的耦合。

　　Spring给我们带来了如此这般的好处，那么，反过来，让我们试想一下，如果不使用Spring框架，回到我们传统的编码模式，情况会是怎样呢？

　　首先，我们必须编写一个配置文件读取类，以实现Message属性的可配置化。

　　其次，得有一个Factory模式的实现，并结合配置文件的读写完成Action的动态加载。于是，我们实现了一个ActionFactory来实现这个功能：

public class ActionFactory {   　public static Action getAction (String actionName) {Properties pro = new Properties (); 　try { 　　pro.load (new FileInputStream ("config.properties")); 　　String actionImplName =(String)pro.get(actionName); 　　String actionMessage =(String) pro.get (actionName+"_msg"); 　　Object obj =Class.forName (actionImplName).newInstance (); 　　BeanUtils.setProperty(obj,"message",actionMessage); 　　return (Action) obj; 　} catch (FileNotFoundException e) { 　　…… 　} }

　　配置文件则采用properties文件形式如下所示：

TheAction=net.chen.spring.qs.UpperAction   TheAction_msg=HeLLo

　　测试代码也作相应修改。现在不论实现的好坏，总之通过上面新增的多行代码，终于实现了类似的功能。如果现在有了一个新的需求，这样这个ActionFactory每次都新建一个类的实例，显然这对系统性能不利，考虑到我们的两个Action都是线程安全的，修改一下ActionFactory，保持系统中只有一个Action实例供其它线程调用。另外Action对象创建后，需要做一些初始化工作。修改一下ActionFactory，使其在创建Action实例之后，随即就调用Action.init方法执行初始化。Action的处理这样就差不多了。下面我们来看看另外一个Factory

　　……

　　往往这些系统开发中最常见的需求，会导致我们的代码迅速膨胀，而Spring IoC的出现，则大大缓解了这样的窘境。通过以上实例，可以看出，Spring IoC为我们提供了如下几方面的优势：

　　（1）应用组件不需要在运行时寻找其协作者，因此更易于开发和编写应用；

　　（2）由于借助于IoC容器管理组件的依赖关系，使得应用的单元测试和集成测试更利于展开；

　　（3）通常，在借助于IoC容器关系业务对象的前提下，很少需要使用具体IoC容器提供的API，这使得集成现有的遗留应用成为可能。

　　因此，通过使用IoC能够降低组件之间的耦合度，最终，能够提高类的重用性，利于测试，而且更利于整个产品或系统集成和配置。

 

2、Spring AOP

　　2.1 面向切面编程基础

　　通常，系统由很多组件组成，每个组件负责一部分功能，然而，这些组件也经常带有一些除了核心功能之外的附带功能 。系统服务如日志、事务管理和安全经常融入到一些其他功能模块中。这些系统服务通常叫做交叉业务，这是因为它们总是分布在系统的很多组件中。通过将这些业务分布在多个组件中，给我们的代码引入了双重复杂性。

　　(1) 实现系统级业务的代码在多个组件中复制。这意味着如果你要改变这些业务逻辑，你就必须到各个模块去修改。就算把这些业务抽象成一个独立模块，其它模块只是调用它的一个方法，但是这个方法调用也还是分布在很多地方。

　　(2) 组件会因为那些与自己核心业务无关的代码变得杂乱。一个向地址录中添加条目的方法应该只关心如何添加地址，而不是关心它是不是安全或支持事务的。

　　此时，我们该怎么办呢？这正是AOP用得着的地方。AOP帮助我们将这些服务模块化，并把它们声明式地应用在需要它们的地方，使得这些组件更加专注于自身业务，完全不知道其它涉及到的系统服务。

　　这里的概念切面，就是我们要实现的交叉功能，是应用系统模块化的一个方面或领域。切面的最常见例子就是日志记录。日志记录在系统中到处需要用到，利用继承来重用日志模块是不合适的，这样，就可以创建一个日志记录切面，并且使用AOP在系统中应用。下图展示了切面应用方式

图表 1 应用切面

　　其中，通知Advice是切面的实际实现。连接点Joinpoint是应用程序执行过程中插入切面的地点，这个地点可以是方法调用，异常抛出，甚至可以是要修改的字段，切面代码在这些地方插入到你的应用流程中，添加新的行为。切入点Pointcut定义了Advice应该应用在那些连接点，通常通过指定类名和方法名，或者匹配类名和方法名式样的正则表达式来指定切入点。

　　2.2 AOP在Spring中的实现

　　基于AOP，业界存在各种各样的AOP实现，比如，JBoss AOP、Spring AOP、ASPectJ、Aspect Werkz等。各自实现的功能也不一样。AOP实现的强弱在很大程度上取决于连接点模型。目前，Spring只支持方法级的连接点。这和一些其他AOP框架不一样，如AspectJ和JBoss，它们还提供了属性接入点，这样可以防止你创建特别细致的通知，如对更新对象属性值进行拦截。然而，由于Spring关注于提供一个实现J2EE服务的框架，所以方法拦截可以满足大部分要求，而且Spring的观点是属性拦截破坏了封装，让Advice触发在属性值改变而不是方法调用上无疑是破坏了这个概念。

　　Spring的AOP框架的关键点如下：

　　（1）Spring实现了AOP联盟接口。在Spring AOP中，存在如下几种通知（Advice）类型

　　Before通知：在目标方法被调用前调用，涉及接口org.springFramework.aop.MethodBeforeAdvice;

　　After通知：在目标方法被调用后调用，涉及接口为org.springframework.aop.AfterReturningAdvice;

　　Throws通知：目标方法抛出异常时调用，涉及接口org.springframework.aop.MethodBeforeAdvice;

　　Around通知：拦截对目标对象方法调用，涉及接口为org.aopalliance.intercept.MethodInterceptor。

　　（2）用Java编写Spring通知，并在Spring的配置文件中，定义在什么地方应用通知的切入点。

　　（3）Spring的运行时通知对象。代理Bean只有在第一次被应用系统需要的时候才被创建。如果你使用的是ApplicationContext，代理对象在BeanFactory载入所有Bean的时候被创建。Spring有两种代理创建方式。如果目标对象实现了一个或多个接口暴露的方法，Spring将使用JDK的java.lang.reflect.Proxy类创建代理。这个类让Spring动态产生一个新的类，它实现所需的接口，织入了通知，并且代理对目标对象的所有请求。如果目标对象没有实现任何接口，Spring使用CGLIB库生成目标对象的子类。在创建这个子类的时候，Spring将通知织入，并且将对目标对象的调用委托给这个子类。此时，需要将Spring发行包lib/cglib目录下的JAR文件发布到应用系统中。

　　2.3 Spring AOP的优势

　　借助于Spring AOP，Spring IoC能够很方便的使用到非常健壮、灵活的企业级服务，是因为Spring AOP能够提供如下几方面的优势：

　　（1）允许开发者使用声明式企业服务，比如事务服务、安全性服务；EJB开发者都知道，EJB组件能够使用J2EE容器提供的声明式服务，但是这些服务要借助于EJB容器，而Spring AOP却不需要EJB容器，借助于Spring的事务抽象框架就可以这些服务。

　　（2）开发者可以开发满足业务需求的自定义切面；

　　（3）开发Spring AOP Advice很方便。因为这些AOP Advice仅是POJO类，借助于Spring提供的ProxyFactoryBean,能够快速的搭建Spring AOP Advice。

　　3、结语

　　本文详细阐述了Spring背后的IoC原理和AOP技术，以实际成功项目为背景，抽取简短片断，展示了Spring架构J2EE应用系统的原理。Spring IoC借助于依赖注入机制，减轻了组件之间的依赖关系，同时也大大提高了组件的可移植性，组件得到了更多的重用机会。借助于Spring AOP，使得开发者能声明式、基于元数据访问企业级服务，AOP合理补充了OOP技术，Spring AOP合理地补充了Spring IoC容器。Spring IoC与Spring AOP组合，使得Spring成为成功的J2EE架构框架，并能与标准的EJB等标准对抗，EJB不再是必需品。Spring已经冲入了J2EE的核心，将引领整个J2EE开发、架构的方向。

STRUTS的工作流程！

Struts是一个“Web应用框架”用来在开发以浏览器为客户端的应用程序时，帮助你进行更深入和更快速的开发；Struts框架是一个基于Model-View-Controller的架构。Model提供了一个内部数据的表示。View显示数据，而不去与大量的业务逻辑打交道。Controller决定执行的过程以及下一步做什么。Web应用如果采用Struts框架，基本执行交互步骤如下：

1 在Web应用程序启动时就会加载并初始化ActionServlet,浏览器所有请求都被提交给ActionServlet处理。

2 此时，当用户把表单提交时，一个配置好的ActionForm对象将被创建，并被填入表单中相应的数据。

3 ActionServlet根据struts-config.xml文件中预先配置好的设置，决定是否需要表单验证，如果需要验证；就调用ActionForm的validate()方法，验证成功后选择应该将请求转发给哪个Action，如果Action对象不存在，ActionServlet会先创建这个对象。然后调用Action的execute()方法。

4 Action的execute()方法中：从ActionForm对象中获取数据，完成业务功能，返回一个ActionForward对象，ActionServlet再把客户请求转发给ActionForward对象指向的JSP组件

5 ActionForward对象指向的JSP组件生成动态网页，返回给客户。

spring 与EJB的区别！！

EJB的优势在分布式，分布式只能用EJB。Spring做不了分布式。

EJB是官方出的。Spring是非官方推出的但做一般web开发更有优势。

很长一段时间内EJB和Spring将共存。

详细：

EJB和Spring全面比较

2009-06-26 14:37 网络 IT专家网 我要评论(0) 字号：T | T

本文介绍EJB和Spring全面比较，包括Java职位列表对Spring技能的需求已经超越了EJB。

AD： 

Rod Johnson将Indeed.com(一个求职网站)职位列表中对EJB和Spring两种技能的需求数量进行了对比，并通过分析这一统计数据得出了一些关于EJB的发展过程及其未来的结论。他围绕着会话Bean和消息Bean对EJB展开了讨论，并承认JPA做为独立的规范是有价值的，JPA“是基于现代技术并已开始体现其价值”。首先，Johnson阐述了职位要求所体现的趋势的重要性：

职位列表是技术真正被采纳的良好指示器。它们表明公司是否把钱花在了“刀刃”上;它们为开发人员指明获取、增强相关技能的重要性(这是技术延续的一个重要因素);它们还为公司稳妥地采用特定技术提供了良好的指导。

随后，Johnson介绍了下面这个EJB和Spring图表。该图表显示，截止到2007年11月，Java职位列表对Spring技能的需求已经超越了EJB。他认为倘若现在基于EJB的应用数量仍相当可观的话，那是很令人惊诧的。

Johnson评论这些趋势的时候有些洋洋自得，因为他2003年以来就预言EJB会因他在J2EE without EJB一书中描述的那些缺点而失去其实用性。甚至在他看来，EJB3.0新的改进也不足以遏制这种趋势：

EJB 3.0改进了一些事情，但还是太少、太迟：依赖注入(DI)的能力不足以满足实际需要;拦截API认识到了需要有一个对横切关注点的解决方案，但我们看到的还是一个最差、最笨重、最容易出错的解决方案(我一直想在博客上发布的一些东西);由于要兼容那些现在已不相关的旧有技术，把它拖累了;沉重的EJB契约(它比“简化的编程模型”多出数百页)需要一个相当复杂的运行时环境，而且开销很大;尽管有语法糖(syntax sugar)，但它还是不能掩盖EJB的大量缺陷，例如启动行为、单例、以及废弃的线程模型。最后，每次改变基础环境的时候，它都要有效地绑定到一个应用服务器环境中去。

接下来，他解释了对整个行业及开发人员个体来说，EJB的衰落意味着什么：

这不是反对标准——而仅仅是有选择性地反对那些无实际意义的标准。正如我长期以来一直指出的那样，Java EE不只是EJB，任何关心这个平台的人都应该真诚地对待其各部分的质量和关联性。

随着越来越先进的技术，业务对象变成了POJOs，对特殊组件模型的依赖在减少，标记也变得不那么重要了。

抛弃EJB后会有更好的架构灵活性来应对需求的变化。随着SOA和其它力量的兴起，公司也越来越多地选择轻量级的部署平台。

Johnson总结到：“由于其绝对数量仍然相当多，EJB不会很快消失。但是趋势曲线清楚地表明它正在逐渐成为过去”。EJB怀疑论者Rick Hightower也相信EJB仍然会存在一段时间。同时，他还表现出对这种对比方式的关注：

然而，EJB被废弃还是比较遥远的事情，难道不是吗?把Spring这样的通用架构(比如Spring MVC、Spring WebFlow、Spring XXX)和EJB这样有侧重点的框架放在一起做比较真的公平吗?正如从Seam，EJB和Spring的比较图中看到的一样，对现有的开发人员来说，这种相对比较的方式是很不公平的。

对于象Seam这样的技术显然有一些疏漏，但Seam结合了EJB 3.0，它也弥补了很多EJB模型原有的缺点，也提供了许多与Spring一样的优点(使用POJOs和IOC等)。依我愚见，它要比Spring更好一些(比如说，它几乎完全基于注释，而不是XML)。我不是想打击Spring，我只是想说结合了Seam和其它技术(像JSF)的EJB3提供了一个非常可行的Spring的替代方法。

假如基于EJB的那些应用中有相当一部分内容是依赖于应用服务器的，而应用服务器恰恰是采用EJB规范专有的实现，那么在一些为它们的核心 Java企业组件模型权衡开源框架的公司中，这些趋势会增加他们的信心。这些对比在表明Spring框架正在走向胜利的同时，不也恰恰表明EJB模型即将开始失去其实用性了吗?查看英文原文：Spring Overtakes EJB as a Skills Requirement?

UML方面 

标准建模语言UML。用例图,静态图(包括类图、对象图和包图),行为图,交互图(顺序图,合作图),实现图。 

j2ee常用的设计模式？说明工厂模式。 

总共23种，分为三大类：创建型，结构型，行为型

我只记得其中常用的6、7种，分别是：

创建型（工厂、工厂方法、抽象工厂、单例）

结构型（包装、适配器，组合，代理）

行为（观察者，模版，策略）

然后再针对你熟悉的模式谈谈你的理解即可。   

Java中的23种设计模式： 

Factory（工厂模式），      Builder（建造模式），       Factory Method（工厂方法模式）， 

Prototype（原始模型模式），Singleton（单例模式），    Facade（门面模式）， 

Adapter（适配器模式），    Bridge（桥梁模式），        Composite（合成模式）， 

Decorator（装饰模式），    Flyweight（享元模式），     Proxy（代理模式）， 

Command（命令模式），      Interpreter（解释器模式）， Visitor（访问者模式）， 

Iterator（迭代子模式），   Mediator（调停者模式），    Memento（备忘录模式）， 

Observer（观察者模式），   State（状态模式），         Strategy（策略模式）， 

Template Method（模板方法模式）， Chain Of Responsibleity（责任链模式） 

工厂模式：工厂模式是一种经常被使用到的模式，根据工厂模式实现的类可以根据提供的数据生成一组类中某一个类的实例，通常这一组类有一个公共的抽象父类并且实现了相同的方法，但是这些方法针对不同的数据进行了不同的操作。首先需要定义一个基类，该类的子类通过不同的方法实现了基类中的方法。然后需要定义一个工厂类，工厂类可以根据条件生成不同的子类实例。当得到子类的实例后，开发人员可以调用基类中的方法而不必考虑到底返回的是哪一个子类的实例。 

开发中都用到了那些设计模式?用在什么场合? 

每个模式都描述了一个在我们的环境中不断出现的问题，然后描述了该问题的解决方案的核心。通过这种方式，你可以无数次地使用那些已有的解决方案，无需在重复相同的工作。主要用到了MVC的设计模式。用来开发JSP/Servlet或者J2EE的相关应用。简单工厂模式等。 

LINUX下线程，GDI类的解释。 

LINUX实现的就是基于核心轻量级进程的"一对一"线程模型，一个线程实体对应一个核心轻量级进程，而线程之间的管理在核外函数库中实现。 

GDI类为图像设备编程接口类库。 

四种会话跟踪技术 

会话作用域ServletsJSP 页面描述 

page否是代表与一个页面相关的对象和属性。一个页面由一个编译好的 Java servlet 类（可以带有任何的 include 指令，但是没有 include 动作）表示。这既包括 servlet 又包括被编译成 servlet 的 JSP 页面 

request是是代表与 Web 客户机发出的一个请求相关的对象和属性。一个请求可能跨越多个页面，涉及多个 Web 组件（由于 forward 指令和 include 动作的关系） 

session是是代表与用于某个 Web 客户机的一个用户体验相关的对象和属性。一个 Web 会话可以也经常会跨越多个客户机请求 

application是是代表与整个 Web 应用程序相关的对象和属性。这实质上是跨越整个 Web 应用程序，包括多个页面、请求和会话的一个全局作用域 

简述逻辑操作(&,|,^)与条件操作(&&,||)的区别。 

区别主要答两点：a.条件操作只能操作布尔型的,而逻辑操作不仅可以操作布尔型,而且可以操作数值型 

b.逻辑操作不会产生短路