仓酷云

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 514|回复: 10
打印 上一主题 下一主题

[学习教程] JAVA教程之精晓J2EE使用程序开辟之交织剖析J2EE

[复制链接]
飘灵儿 该用户已被删除
跳转到指定楼层
楼主
发表于 2015-1-18 11:15:44 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
还有就是总有人问我到底该学习什么语言,什么语言有前途,那么我的回答是不论是C,C++,java,.net,ruby,asp或是其他语言都可以学,编程的关键不是语言,而是思想。j2ee|程序  在不久前的一段工夫内,Java开辟职员在筹办一个新的企业Java开辟项目时,事前就晓得将要利用的工具。事先,统统都很复杂:J2EE是新的,HTML扫瞄器是公认的用户界面尺度,而庞大性(最少从推想的角度而言)已成为已往的事变。而现在,事变变得云云庞大。

  “开辟职员面临的选择使人头昏眼花。”

  开辟职员面临的选择使人头昏眼花,从“轻型容器”(如Spring、NanoContainer或HiveMind)到“web框架”(如WebWork、Tapestry(一个基于JSF的UI,相似于Oracle的新使用程序开辟框架(OracleADF))或Velocity)。这些选择还增添了一系列新的J2EE标准,大概说是经由过程JAXM、SAAJ、JAX-RPC或JAX对“Web服务”和响应的新手艺术语“面向服务的系统布局”付与了新的代价(更不必提“WS-*”标准、工具和库了),Java开辟职员能够完成一切事情,这真是一个事业。
  NoFluffJustStuff软件论文系列的演讲者BenGalbraith将此征象称作“Java框架不断定性准绳”:“您方才选择了一个框架,某个其他框架的新版本便公布了,从而迫使您对选择框架从头剖析。”并且这类情形的庞大水平也无以复加了:只需将中心J2EE和J2SE类夹杂在一同利用。究竟,我们原告知EJB是J2EE的“中心”,而且思索一个没有EJB的企业Java项目将是一个愚昧的设法,这只是今天的事。事实泛型怎样改动您的J2EE编码体验?而且究竟是谁让一切Java办理扩大成了路障?

  究竟是怎样了?最后明白专注于创立一个由单项上风工具和库组成的平台的行业何故在云云短的工夫内变得云云庞杂?我们什么时候必要在传统的“J2EE”工具(如EJB)与新型“Web服务”(如JAXRPC和WS-Security)工具之间举行选择?更主要的是,我们如今怎样做才干制止Ben的Java框架不断定性准绳而又不违反Java起首应遵守的供给商有关准绳?

  此成绩次要在于懂得最能满意必要的手艺,而最好的办法是起首懂得使用程序的必要。懂得使用程序的必要后,便可分明地界定应选用的响应手艺。

  本文将扼要概述开始进的J2EE、与其相干的手艺和Java开辟职员现今面对的某些系统布局应战。

  我们现在要走向那边?

  良多分歧范例的Java程序在“企业Java”的名义下趋于变得痴肥,在深切会商前,这大概有助于将它们与其他范例的Java使用程序辨别开。假如我们从传统的“3层”办法入手下手(行将暗示、营业逻辑和数据会见分别为三个分歧的计划条理),则我们实践上能够断定五种“企业”Java使用程序:烟囱、宝石、聚合器、集成器和企业使用程序。

  “我们实践上能够断定五种“企业”Java使用程序:烟囱、宝石、聚合器、集成器和企业使用程序”。

  烟囱烟囱使用程序(也称作“竖井”)多是开辟职员最简单承受的使用程序,这是由于它是一种我们几回再三开辟的使用程序:它是传统的“双数据库、单UI”使用程序,就相对数目而言,它是以后构建最广的一种IT使用程序。它一般是依据某个部门司理或副司理的必要(即寻觅某个特定工具或使用程序来搜集、操纵和显现某种以后未搜集、操纵和显现的数据)而入手下手创立的,为此将组建一个团队(范围一般不凌驾三到四团体,常常只要一团体)来搜集需求、创建用例、构建数据库、对营业逻辑举行编码、将其部署到选择作为此使用程序的临盆服务器的呆板其实不断地监督它。
  固然,此称号得自您在白板上绘制的三个框(暗示体系的逻辑层―暗示层、营业逻辑层和数据会见层)所构成的图象―它们组成了一条垂直线,不由令人想起将熄灭木头的火炉中发生的烟排挤到房间表面的新式“烟囱”。(特地说一下,关于将该术语用作褒义术语的用户而言,请记着,您在平生中将利用的很多最主要的体系(如ATM机、次要船运公司园地上的包裹定位器等)都是烟囱体系。
  有一点大概对照使人受惊的是,J2EE软件套件其实不能完整满意构建复杂烟囱体系的开辟职员的必要。当只必要一个暗示层,且只要一个资本用于存储和检索数据时,J2EE套件(特别是EJB)就显得“碍事”了。更诱人的办法是思索轻型框架,由于它们其实不那末专注于部署形貌符,而且就JNDI、JMS之类而言也没甚么方便的。它只是经由过程web扫瞄器举行的基础哀求/呼应通讯,一般构建在相似Struts或类似的MVC款式web框架中,并与一组中心的传统Java对象(偶然与单个呆板上运转的暗示层和营业逻辑层(而非数据库自己))举行通讯。(您大概奇异此处为何没有利用术语“数据库”。缘故原由很复杂,固然年夜多半项目利用数据库(并且仍是干系数据库)存储数据,但数据存储一般是原有体系、贸易软件程序包或形如CICS年夜型机、SAP或BizTalk的“中介”手艺。利用更一样平常的术语“资本”有助于夸大如许一个意见:后端完成的确与本会商有关。)

  烟囱使用程序的另外一个上风是它们一般是“自力的”―也就是说不触及其他使用程序。几近不必要恪守任何已创建的平安、牢靠性或办理尺度,这是由于此使用程序所建立的一切内容都将成为尺度(最少对此使用程序而言是如许,这恰是此局限的关头地点)。开辟职员常常使用此现实来构建恰好合适于此使用程序的基本架构,从而打消了一般针对企业Java使用程序的求全谴责:它们太庞大了,以致于没法利用和保护。

  只管人们但愿云云,但J2EE的计划并不是是针对烟囱使用程序的―固然,一个基于J2EE的使用程序能够构建此类使用程序(而且有上千个示例能够作为此现实的证据),现实上有点像用牛刀杀鸡。基于J2EE的使用程序实行了必定水平的层分别,但偶然这类分别关于办理手头的成绩显得有些过犹不及,如传统的“10用户”烟囱体系。固然,成绩是10用户烟囱体系一般有一种另人不悦的趋向,即变化为其他四个版本中的某个版本,如许将使事变变得很糟。就像某位哲学家说的那样“没有哪一个人是伶仃的”,我们也能够很轻松和正确地说“没有哪一个体系是伶仃的”。最少在短时间内是如许。(固然,假如体系没法完成其预期的方针,那它就没法与任何其他体系集成,而且大概停产,但我们将假定那不是预期的方针。)

  珠宝我们并非说这是IT情况的乐成和自满或五种使用程序款式中“最好”的一个,但珠宝款式的使用程序是分离了多个暗示层的使用程序(因而,它的称号--“珠宝”暗示有良多面可供检察)。但请注重,给定暗示层大概基本不是供用户检察的;公司以后常常切磋的一个层是其基于Web服务的使用程序前端,它并不是为人利用而设。只管云云,该Web服务仍暗示一个暗示层,这是由于它从基本上实行统一操纵:猎取输出并从其上面的中心营业逻辑层中供应输入。

  因为一度曾存在的某些假定俄然间不复存在了,珠宝使用程序对传统编程模子举行了一些风趣的变化。比方,当思索一个Web服务前端时,俄然必需以某种平台和言语有关的体例(对此,XML形式是以后能够选择的工具)界说范例,而幻想情形下,“一次且仅此一次”划定规矩(也称作“不反复本身”准绳)将同意我们间接经由过程基于HTML的暗示层用来与营业逻辑层通讯的统一范例构建此范例。这就是某些JAX*标准的用武之地--比方,JavaAPIforXMLBinding有助于界说一个以十分含混的体例举行“对象到XML和XML到对象”转换的尺度办法,而JavaAPIforXMLRPC(JAX-RPC)界说一种利用WSDL、SOAP和XML构建可互操纵的哀求-呼应远程通讯层的办法。

  只管任何事物都不克不及制止开辟职员从其最爱的轻型容器中使JAX*标准,而J2EE1.4标准间接将JAXRPC和JAXB整合到它的整体手艺套件中,从而使您能够将EJB无形态会话bean供应为WSL1.1/SOAP1.1RPC/encodedWeb服务。(请注重,依据WS-InteroperabilityBasicProfile标准,RPC/编码的服务正式不撑持文档/笔墨服务;人们广泛希冀此不同在JAX*和J2EE标准的下个版本中失掉办理,详细的完成应也许在开辟职员实践指出RPC/编码的服务和文档/笔墨服务之间的不同时推出。)别的,贸易使用服务器供给商正不遗余力确保其产物不但完整与J2EE尺度兼容,并且还与Web服务尺度兼容。不言而喻,这类情形下用“兼容且具合作力”来描述供给商的念头(包含J2EE的次要合作敌手,来自东南宁靖洋的那家不出名的软件公司的念头)再得当不外。

  特地说的是,盘算构建Web服务暗示facet时,值得一提的是,最好利用JAXB或Oracle的开辟职员工具包将体系的模子对象间接供应为XML范例,并将全部Web服务前端代码天生为年夜型WSDL文档。只管这后来仿佛是某个用户的营业逻辑层的优秀考证(究竟,假如暗示层中真的没有甚么营业划定规矩,那末接纳此办法实在其实不坚苦),但Web服务手艺套件中的限定很快便使这个希冀变得很难完成。

  比方,思索基于援用的对象与XML的干系:应怎样最好地暗示一个在XML中值为空的java.util.Date援用?特别是在.NET中,Date基本不是基于援用的对象,而是“值范例”,这意味着它的感化相似于int在Java中的感化吗?当实验暗示XML对象的庞大轮回图时,事变将变得十分辣手,这就是为何本来否决RPC/编码的服务的缘故原由之一。这是WS-*套件面前所要做的一切事情,但即便某个团队决意“走本人的路”并构建他们本人的XML-over-HTTP体系,他们也要面临统一中心成绩。正在实验将对象-XML映照整合到中心产物(如OracleToplink)中,但到今朝为止,它们仍处于初始阶段。

  同时,我们不克不及疏忽那些旨在弥补传统的基于扫瞄器使用程序中的年夜毛病以完成“更年夜的呼应性”的新潮暗示层办法(“智能”客户端或“富”客户端”)。HTML只管有良多长处,但也存在一些基本性的弱点,很简单地就想到了两个:

  最小公分母角度。HTML最后用于尽量晚地推延暗示决议,尺度HTML中实践上只要十分少的元素包管在任何给定体系上的出现表面。为页面熟成器供应更年夜把持(如CSS)的实验已获得了多方面的乐成,特别是在跨分歧扫瞄器方面。

  暗示代码必需与内容一同发送。因为扫瞄器自己不懂得使用程序,因而必需在每一个收集往复中向服务器发送暗示代码和内容。此办法有两个负面影响,一个是带宽较低(每一个客户真个损耗越高,统一硬件的客户端数越少),另外一个是可用性遭到损坏(假如服务器或参与的任何拓扑呈现妨碍,则使用程序将不存在)。

  为完成此目标,企业使用程序供给商正主动思索将暗示层代码置于终极用户的呆板中,以便完整或部分打消HTML的两个次要弱点。这制造了一些风趣的部署表示,但很多商铺正追求同时创立瘦客户端和富客户端暗示层―富客户端用于公司防火墙的外部,而瘦客户端用于公司的内部(再次证实您不克不及太富或太瘦)。此办法招致了必需处置两个分歧框架的贫苦,但最少我们乐意具有一种将数据从用户输出传送到后端存储库的一致办法,并且最好可以针对“富”客户端和“瘦”客户端将这类传送举行某种情势的尺度化―由此便发生了JSR227,一个通用的数据绑定框架。

  “我们乐意具有一个将数据从用户输出传送到后端存储库的一致办法;因而,便发生了JSR227。”

  聚合器正如体系能够供应多个“出口点”一样,假如您乐意,体系还能够创建在多个后真个基本上,从而从分歧的资本搜集数据并按分歧和成心义的体例显现它。(既然显现和操纵的数据是多个资本/数据库的聚合,因而也就有了术语“聚合器”。)而且,在入手下手创立此聚合数据的操纵和存储用例的30秒以后,不言而喻的是,必需利用某品种型的原子性以便两个数据库所做的修正坚持同步。这恰是Java事件API(和它之前的X/A标准)的用处,而事件处置和营业逻辑的交织部分则是EJB发生的缘故原由。

  但它不单单是事件。多个资本所带来的不单单是两个分歧的数据库―偶然,体系必要的牢靠性要高于单个数据库呆板所能供应的牢靠性。究竟,体系中任何地位的单个呆板只暗示单个妨碍点,并且一般情形下(除一切“热互换”妨碍切换情形之外),我们只需封闭数据库以对其实行某些预定的保护―大概包含新的形式变动以满意代码变更。Java定名和目次接口(JNDI)用作一切“查找”操纵的单个API,从实践底层物理数据库呆板中供应一个直接层,这意味着假如不缓存JNDI查找了局,则办理员能够变动JNDI出口,以从一台呆板指向分歧的呆板,同时J2EE使用程序将复杂地举行响应的调剂,从而将创立一个无缝和通明的指向新数据库的“开关”,这在没有直接层的情形下是没法完成的。
  集成器

  当必要毗连两个独自保护的营业逻辑汇合时,集成器体系将发扬感化,而且必需入手下手思索烟囱体系从不必要的互操纵性。比方,假如必需实行传统的哀求-呼应服务,那末怎样实行哀求和呼应?开辟职员一般立即乞助于WS-*服务,但如上所述,WS-*标准偶然太多(而且在以后完成中太不成熟),以致于没法牢靠地满意集成/互操纵性的必要。而J2EE标准经由过程请求每一个EJB容器切合CORBA挪用(意味着任何CORBA客户端能够与EJB容器中封装的营业逻辑交互)再次满意了此必要。

  但并不是一切集成均以哀求-呼应的体例举行。为制止RPC和哀求-呼应通讯的异步实质中潜伏的瓶颈,很多体系选择利用基于动静的办法互相集成。基于动静的办法是Java动静服务标准(和联系关系的完成,如Oracle的初级行列)和/或JavaAPIforXMLMessaging(JAXM)及其联系关系的SOAPAPIforAttachmentsinJava(SAAJ)(用于实行“利用尖括号的动静传送”)的用武之地。

  数据库自己还用作集成层,但与传统RPC或动静驱动体系其实不不异。良多情形下,集成和互操纵性仅仅表现在将程序“A”中的数据传送到程序“B”,而数据库(和其他资本)一般用作分歧平台(特别是J2EE和.NET)的有效(和了解充实)的中介言语。只管它其实不满意一切互操纵性的必要,但关于很多体系而言,此办法恰好满意必要―它具有本身的优点,特别是当营业逻辑(经由过程存储历程)嵌进到数据库中时。别的,.NET无需懂得怎样挪用驻留在EJB服务器中的Java代码,Java也无需懂得怎样挪用驻留在COM+ServicedComponent中的.NET代码,或怎样在二者之间共享单个散布式事件ID,等等。特别是思索到如许一个现实:Oracle同意您在Java而非PL/SQL中编写存储历程,从而简化了存储历程的编写。

  企业使用程序最初,我们懂得一下“真实的”企业使用程序,它是以下三个层的多个facet的交融:暗示层、逻辑层和数据会见层。传统的企业体系必要利用遍及多个使用程序、言语或平台的营业划定规矩汇合以各类格局显现多个资本中的数据。企业使用程序最具庞大性,而这恰是J2EE的刚强。别的,因为陪伴庞大性而来的是壮大的功效(和天真性),因而外表上“过于庞大的”J2EE标准及其联系关系手艺变得更加符合。

  比方,流派一般就属于此种别,这是由于它们一般必要在一切三个层完成多重性―关于暗示层,表现在流派一般组合了公司各个部分(或部门,或分歧的公司,乃至多是分歧的挪动家庭)的分歧web使用程序,关于营业逻辑层,表现在特定“portlet”偶然将必要挪用由分歧的portlet的后端供应的功效,关于数据会见层,表现在年夜多半portlet具有本身的用于交互的数据库(或数据库集,目标是使事物更成心义),但更风趣的是,给定用户的会话一般必要跟踪历程中的信息,即便用户在各类portlet之间往返挪动。在很多方面,流派及其联系关系portlet是企业使用程序的典型。

  “在很多方面,流派及其联系关系portlet是企业使用程序的典型。”
  它将我们至于那边?

  此类分类自己就充足杰出了,因而会让手艺愚人们沉醉好一段工夫,但这事实与构建现在的企业Java使用程序有多年夜干系呢?

  起首也是最主要的是,企业Java开辟职员必需尽快断定他们被请求构建的使用程序属于以上五种使用程序的哪种。假如是传统的烟囱体系,则选择哪一种手艺其实不像其他四个使用程序那样主要。当呈现Web服务成绩时,将其看做是其他暗示层(意味着您如今在检察珠宝使用程序)而不单单看做是Struts代码与营业逻辑之间利用的模子对象扩大。实践上,在良多方面,模子视图把持器形式是暗示层自己的一部分,而并非延长到营业逻辑层的甚么工具,这是由于实行无效的“分歧”暗示层一般将请求我们针对怎样与后端交互举行分歧的选择,如(关于Web服务)将体系的“面向对象”的实质抛在前面。

  当呈现多个数据库或其他后端成绩时,请思索妨碍可分性和利用散布式事件完成可分性的必要,和具有一个优秀的直接可热互换层来会见资本的妨碍切换倡议。当现有体系之间的集成成为成绩时,请记着除Web服务之外另有良多选择(只管Web服务办法对照有用而且一般被看做是尺度),并记着动静驱动的体系和是不是能够将营业逻辑置于数据库自己中以便其他必要与该体系交互的平台更简单地会见此数据库。

  请记着,J2EE只是用于完成某个方针的办法,关于任何手艺的果断意见一般将得到手艺作为整体的意义。比方,不要试图在烟囱体系上利用EJB,这是由于EJB次要合用于事件处置(特别是两个阶段的提交事件处置,此种事件处置对照占用资本而且必需在作为统一事件一部分的两个或更多资本中猎取可分性),但当聚合器使用程序依托您实行操纵时不要疏忽它的利用。当JMS(和动静驱动bean,当必要事件处置时)的异步实质更合适于此目标时,不要实验将一切内容编写为会话bean。等等。

  其次,必定要一直切实地切记使用程序的功能和可伸缩性方针(拜见我的《高效企业Java》一书)。只管这关于以任何言语编写的任何使用程序一般都很主要,但在企业Java范畴中更主要,这是由于企业Java开辟职员有那末多的手艺能够选择。您的体系必要为每一个用户操纵供应亚秒级呼应?基于扫瞄器的使用程序(特别是跨广域网使用程序)很难完成此方针,这是由于HTML扫瞄器一般必要约莫一秒的工夫来处置乃至是中等庞大的HTML页;也许一个更好的办法是思索经由过程JavaWebStart提交的“富客户端”前端,以便使跨收集传送的数据数目尽量得小,和吸收数据的工夫尽量得短(以免剖析暗示元素)。

  是不是必要在全部互联网上具有展望的100万个用户?用户界面一定必要改动,而Java在一般用户的PC上的低提高率使WebStart其实不符合实践,也许applet或传统的HTML更加符合。但扩大到此用户数量意味着开辟职员必要出格寄望在岑岭负载下每一个哀求的呼应工夫,也许以分歧的体例构建用户界面能够制止频仍的服务器回程。等等。

  第三,请记着,Java开辟职员的工具套件在不休的改善,已往五年中的年夜部合作作一向在野J2EE范畴的偏向举行,千方百计使界说J2EE组件更复杂、更简单。年夜型贸易供给商在该范畴的上风凌驾开源项目,这是由于供给商能够环绕他们的贸易服务创立完全的端到端开辟履历,个中开放源项目只是浅尝辄止。比方,将OracleADF中供应的某些新功效与实验在Eclipse中构建JSF使用程序举行对照。大概,将在JDeveloper中界说Web服务与在Axis编写.wsdd文件举行对照。工具愈来愈完美,我们只能希冀此趋向得以持续,由于这要看供给商有无乐趣使其持续了。“工具愈来愈完美,我们只能希冀此趋向得以持续,由于这要看供给商有无乐趣使其持续了。”

  最初但并不是不主要的,在本系列的后续文章中寄望此手艺范畴,这些后续文章将先容从建模和计划到调试以优化/监督代码(这将比您如今界说的功能和可伸缩性方针复杂良多)等主题。

  最主要的是要抓紧。性命太长久了。

  结论

  只管企业Java范畴偶然像一组使人头昏眼花的标准、完成,而实践上仿佛投合长久盛行作风的各类尺度和框架已做好充实的筹办并意想到,关于五品种型的使用程序的任何一种而言,任何可用的Java/J2EE手艺都能够事情(并杰出地事情)。

前些天,在CSDN上看到了一个消息,说是ASP.NETAJAX成功在Linux上运行,这一点对我触动很大,而且引发了我许多感叹,所以想写出来分享一下。
小女巫 该用户已被删除
沙发
发表于 2015-1-20 18:48:45 来自手机 | 只看该作者
是一种语言,用以产生「小应用程序(Applet(s))
分手快乐 该用户已被删除
板凳
发表于 2015-1-29 14:48:14 | 只看该作者
Jive的资料在很多网站上都有,大家可以找来研究一下。相信你读完代码后,会有脱胎换骨的感觉。遗憾的是Jive从2.5以后就不再无条件的开放源代码,同时有licence限制。不过幸好还有中国一流的Java程序员关注它,外国人不开源了,中国人就不能开源吗?这里向大家推荐一个汉化的Jive版本—J道。Jive(J道版)是由中国Java界大名 鼎鼎的banq在Jive 2.1版本基础上改编而成, 全中文,增加了一些实用功能,如贴图,用户头像和用户资料查询等,而且有一个开发团队在不断升级。你可以访问banq的网站
爱飞 该用户已被删除
地板
发表于 2015-2-5 02:04:29 | 只看该作者
是一种由美国SUN计算机公司(Sun Microsystems, Inc.)所研究而成的语言
兰色精灵 该用户已被删除
5#
发表于 2015-2-6 15:58:49 | 只看该作者
多重继承(以接口取代)等特性,增加了垃圾回收器功能用于回收不再被引用的对象所占据的内存空间,使得程序员不用再为内存管理而担忧。在 Java 1.5 版本中,Java 又引入了泛型编程(Generic Programming)、类型安全的枚举、不定长参数和自动装/拆箱等语言特性。
不帅 该用户已被删除
6#
发表于 2015-2-7 19:33:11 | 只看该作者
Sun公司看见Oak在互联网上应用的前景,于是改造了Oak,于1995年5月以Java的名称正式发布。Java伴随着互联网的迅猛发展而发展,逐渐成为重要的网络编程语言。
海妖 该用户已被删除
7#
发表于 2015-2-13 04:31:27 | 只看该作者
关于设计模式的资料,还是向大家推荐banq的网站 [url]http://www.jdon.com/[/url],他把GOF的23种模式以通俗易懂的方式诠释出来,纯Java描述,真是经典中的经典。
只想知道 该用户已被删除
8#
发表于 2015-3-3 13:23:13 | 只看该作者
一直感觉JAVA很大,很杂,找不到学习方向,前两天在网上找到了这篇文章,感觉不错,给没有方向的我指了一个方向,先不管对不对,做下来再说。
再见西城 该用户已被删除
9#
发表于 2015-3-6 16:13:03 | 只看该作者
关于设计模式的资料,还是向大家推荐banq的网站 [url]http://www.jdon.com/[/url],他把GOF的23种模式以通俗易懂的方式诠释出来,纯Java描述,真是经典中的经典。
活着的死人 该用户已被删除
10#
发表于 2015-3-17 02:10:25 | 只看该作者
应用在电视机、电话、闹钟、烤面包机等家用电器的控制和通信。由于这些智能化家电的市场需求没有预期的高,Sun公司放弃了该项计划。随着1990年代互联网的发展
深爱那片海 该用户已被删除
11#
发表于 2015-3-23 15:20:24 | 只看该作者
设计模式是高级程序员真正掌握面向对象核心思想的必修课。设计模式并不是一种具体"技术",它讲述的是思想,它不仅仅展示了接口或抽象类在实际案例中的灵活应用和智慧
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|Archiver|手机版|仓酷云 鄂ICP备14007578号-2

GMT+8, 2024-12-23 21:12

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表