Java系统分析/架构师欢迎大家关注我的公众号

【专业知识相关】

  1. 谈谈对OOP、IOC、AOP的设计理念的理解;

(1)ioc,意思是Inversion of control,(反转控制),控制反转,就是交换控制权的意思。现在一般不使用这个词,一般使用dependency injection(依赖注入)。依赖注入就是将依赖 注入进去。
(2)这么来说吧,在一个动作或者事件中,比如说,你现在想写字(Action),那么你需要笔,于是乎,你new了一个笔来写字,这里,你用了new笔,你这个动作和笔有了关联,没了笔,你就写不了字,也就是说,你的这个行为依赖于笔了,他们就构成了依赖关系。或者你现在想组装一台电脑(Transaction),那么你就需要显示器、主板、键鼠光驱等对象,这些对象通常是new出来的,new出来的对象和当前(this)对象就有了依赖关系。
spring中对依赖的对象采用注入,这就是常说的依赖注入吧

(3)反转控制嘛
给你个简单的例子:
1、未用IOC:一个人背着一大包炸药去炸敌人的一座碉堡
2、采用IOC:这个人什么都不带跑到敌人碉堡下,然后打电话给总部说,把炸药给我扔过来。

(4)ssh框架,是目前较为流行的框架之一。有时根据项目需要,可能只用到了struts和hibernate。有时可能是spring。
首先理解三个独立框架的功能。struts的目的,主要是请求和相应的分发跳转。页面数据的采集获得。hibernate主要针对于DB层的交互。DB的连接、对持久化对象的操作等。spring核心内容应该是IOC。理解它的控制反转和OOP(面向切面)

(5)所谓IoC,简单理解就是把原本应该我们去new对象这个操作转到spring容器去执行。
而且IoC核心其实就是一个工厂模式,而工厂模式就是制造(new)对象的,工厂模式中,一般都是利用反射来new具体的对象,然后返回实例。
(6)

IOC,控制反转这样理解
举个简单的例子
一个人要去砍柴。那么绝大部分时候,我们会这样设计程序
class Axe
{
   //一些字段或方法
}
class person
{
    private Axe axe = new Axe();        //自己制造斧头
    public void cut(Axe axe)
    {
        axe.cut();
    }
}
即是,我们要去砍柴,我们要自己制造斧头。
而IOC的意思就是我们需要斧头,这时候斧头就已经制造好了,我们去取就可以,不用自己制造.

class person
{
    private Axe axe = springFactory.getBean("axe");
    public void cut(Axe axe)
    {
        axe.cut();
    }
}
这些axe就是在spring的配置文件里声明的bean.

IOC和控制反转是一个意思
(7)<bean id="ss" class="A">
    <property name="dao">
        <ref bean="dbdao" />
    </property
</bean>

个人理解:以上就是ioc的核心,意思是在此创建dbdao的对象,此对象在类A中使用,在类A中使用时候,用地名字是ss。通过getbean(ss)来获取对象。

(8)我来给你个简单明了的解释。
    控制反转又成为依赖注入,主要为了降低类之间的耦合度,类A依赖类B的时候我们按传统写法就需要在类A里面调用类B对象的方法,而用SPRING的话,就相当于提供了一个接口,在类A里面调用这个接口就可以得到类B对象,不用NEW出类B的对象来。利用接口的原理来降低了耦合度(如果你熟习接口的设计和使用就会很清楚)。
    而为了实现上述原理,我们把他写成配置文件,然后在程序运行时用反射的方式来加载这个配置文件(用spring时就是用的反射机制运行时调用),找到要使用的类,并由spring给你生成对象。这样就OK了。
    最后在总结下这两个名词。控制反转,就是交换控制权的意思,比如我类A需要用到类B的时候,具体的实现方式是在类B的某个方法里,也就是说类B控制着这个业务的具体实现。而现在用IOC以后,类B交出控制权,类A来进行控制,类A里只需要调用一个接口的方法,不管你这个方法的具体实现是由类B的对象来实现,还是由其他类的对象来实现,反正类A调用这个接口的这个方法就可以搞定他需要实现的业务内容,这样一来,类A它看上去就得到了实现某个业务的控制权。而依赖注入这个词则体现得更加专业一点,就是讲在我的程序里,我从来不去构造(new HelloWorld()这样的方法)任何对象,只是在需要用到(也就是依赖)某个对象的时候,我就用spring给他注入这个对象。这个注入的方式也就降低了程序的耦合度
(9)

AOP面向切面编程 将程序中的交叉业务逻辑(比如安全,日志,事务等),封装成一个切面,然后注入到目标对象(具体业务逻辑)中去。 比如: 很多方法可能会抛异常,你要记录这个异常到日志中去,可以写个拦截器类,在这个类中记录日志,在spring.xml中配置一个对这些要记录日志的方法的aop拦截器 在这个方法执行后调用这个拦截器,记录日志。这样就不用每次抛异常都要手动记录日志。 spring的事务管理用到的就是aop 这样也可以提高程序的内聚性。

(10)

aop叫aspect oriented program,面向切面的编程 ioc是invert of control,反转控制 在spring in action那本书里有详细阐述,简单说一下,ioc就是其实就是依赖注入,即用接口编程,在程序中不出现new关键字,而是用接口来命名引用,然后通过某种方式(多数用spring,不过Google guice也是很好的ioc框架)把接口的某个实现类的实例注入到引用里,从而实现与接口具体实现类的松耦合 aop方式就理解起来就简单了,其方式很类似j2ee中的filter,就是在程序正常的业务流中间像切面一样插入很多其他需要执行的代码,比如登陆时候在进入登录页面前写入日志,登录以后查看cookie等类似的操作,很常用的,尤其是跟数据库有关的,或者跟支付有关的程序肯定会在每一步前面插入日志,还有某些国际化项目会在每次跳转时候都转换字符集之类

(11)我给你来个权威的,你答到这下面就基本不问了。 IOC(反转控制):对成员变量的赋值的控制权从代码中反转到配置文件中。 AOP:Aspect(切面) Oriented(面向) Programming(编程),面向切面编程。

 

  1. 谈谈对主流的J2EE框架(Spring、Struts、Ibatis、Hibernate等);这些框架的局限性在哪儿?在何种情况下会不适合用这些框架?
  2. 关于J2EE方面开发方面,说出前、后端的设计模型;

提示:比如前端的MVC框架,Axis,Ext,JQuery,Flex等,后端的Ejb,Spring,IOC,AOP,JMS,JNDI,RMI,以及负载均衡等

  1. 什么是SOA,ROA?谈谈两种技术的原理及适用场景;

本真REST当然是对面向资源架构的一种实现,而并非一种纯粹的技术决策。所以当讨论本真REST时,真正应该讨论的问题是:其基础支撑——面向资源的架构(ROA)——是否真的适合作为你的SOA实现。
为正确评估该问题,让我们首先回想一下SOA的架构风格,它是基于企业业务架构的功能性分解,并且引入了两个高层次的抽象:企业业务服务和业务流程。企业业务服务代表的是现有IT能力(和企业的业务功能相一致)。业务流程编排业务服务,并定义业务的整体功能。
而REST是一组被称之为面向资源架构(ROA)的架构准则。ROA构建在资源这一概念之上;每个资源都是一个能够直接访问的分布式组件,可通过一个标准的、通用的接口来处理。所以,面向资源的架构(ROA)其最根本的还是一种基于资源的分解[3]。
为了评估本真REST是否适用于面向SOA的实现,我们真正需要回答的问题是,“服务和资源之间到底是什么关系?”
服务 vs. 资源
何为服务?
在最简单的情况下,服务可以被定义为一个自包含、独立开发、可部署、可管理和可维护的软件实现,它从整体上为企业提供特定的与业务相关的功能,并且在设计上是“可集成的”。“服务”可以通过动词(verb)来定义(例如,“验证客户信用积分”,这描述了服务实现的业务功能)。
服务并不是某个编程结构或一组APIs,而是一个用于实现企业解决方案的架构(设计单元、实现以及维护)和部署构件。服务接口(尤其对某个给定的服务而言)定义服务功能,并且可由多种方式实现。存在两种基本的定义服务接口的方法——RPC风格和消息(messaging)风格,RPC风格实现使用服务调用语义并且通过服务接口中的一组参数来定义。而消息风格的服务接口被有效地固定(本质上只需要进行“执行”操作)使用XML文档作为输入和输出(这和GoF设计模式非常相似)。在这种情况下,服务语义是由输入和输出消息的语义来确定[4]。
过去,服务通常被定义为一组方法的集合,但正如参考文献[2]中解释的那样,这些方法彼此相互独立[5],但作为整体它们共享同一个命名空间,这样简化了对服务的管理。
何为资源?
在最简单的情况下,资源可以被定义为一个可直接访问的、独立开发的、可部署的、可管理的和可维护的软件构件,它支持特定的数据。资源可以通过名词(noun)来定义,比如“医生的预约”就描述了资源提供的数据。某一资源也可以和其他资源相关联并为它们提供引用(链接)。实际上,一个资源就类似于一个对象[6],不过它是带有预定义(CRUD)接口语义的对象。
REST中的语义基于HTTP操作集,如下所示[5]:
createResource——创建一个新的资源(以及相应的唯一标示)– PUT
getResourceRepresentation——获取资源信息– GET
deleteResource ——删除资源(可选地包括相关联的资源)– DELETE(只是引用的资源),POST(当需要删除相关联的资源时使用)
modifyResource——更改资源— POST
getMetaInforatmion——取得资源元数据信息—HEAD
资源通过两部分定义:资源URL和资源所提供的所有操作上定义的输入/输出参数[7]。这和服务不同,服务的方法之间是完全独立,并且能够以独立端点(endpoints)的方式部署,而资源上的方法遵循OO语义,这意味着所有的方法(除createResource以外)都必须依附于底层的某个资源(同一个URL)。
资源和服务之间的根本差异
基于上述对资源和服务的定义,凭直觉它们显然是不同的。我们先继续深究这些差别,然后再讨论它们是如何对最终架构产生影响的。
正如文献[6]中描述的:
REST不仅不是面向服务的,相反,面向服务和REST风马牛不相及
文献[7]中进一步阐明了二者之间的区别:
如果把WS-*比作是互联网世界的RPC,那么REST就是互联网世界的数据库管理系统(DBMS)……传统的基于SOA的集成表现了不同软件构件之间通过各种过程或方法进行交互。REST有效地将每个软件构件看作一组数据库表,而这些构件之间使用SELECT, INSERT, UPDATE和DELETE来通信。(或如你所想的使用GET, PUT, POST, DELETE)。那业务逻辑放在哪里呢?在存储过程中?不太对,其实在触发器中。
这里我们用J2EE打个稍微不太恰当的比方。我们把服务想象成无状态会话bean,而资源想象成实体bean。
服务(或会话beans)作为控制器控制执行所需的操作,不管底层是哪个资源。打个比方,某个支出账户服务可能会用到账户ID、支出金额和支出所需账户。这样的服务可以支出任何现有账户。
资源(或实体bean)充当数据访问机制,其面对给定数据类型的某一实例。比如,为了从某一账户支出,需要先找到这一账户相关的信息,然后才能更新它,从而向所需账户进行支出。另外提醒一下,与能实现任意所需的方法的实体bean不同的是,一个REST资源只有一个更改资源的方法。这意味着真实的业务操作——支出——只能编码成消息请求的一部分。

  1. 说说JVM原理,内存泄露与溢出的区别,何时产生内存泄露?

 

  1. 谈谈JAVA通信方面相关知识,以及大项目之间通信方案;

【软件架构、服务器、中间件相关】

  1. 谈谈架构师的职责有哪些?
  2. 软件设计领域,有哪些设计模式,你常用的几种设计模式;各个设计模式有哪些优缺点,适应哪些场景;
  3. 谈谈你日常用的几种WEB服务器、中间件的相关特性及优缺点;
  4. 如果要设计一个搜索引擎,像Google那样只有两个页面,要求性能最大化,Web方面应该如何设计?(不需要考虑搜索的逻辑)
  5. 企业级应用有哪些特殊要求?在何种情况下我们不需要考虑这些要求?
  6. 谈谈你现在做技术最大的困惑是什么?
  7. 描述一个你感觉最成功的一次架构案例?
  8. 怎么做到系统整合?

提示:A、通过代码的整合方式,使用相同的数据库。B、通过SSO方式,可以是异构数据库.

  1. 浅谈一下负载均衡的原理?
  2. 怎么处理权限分配?有几种权限分配模型?(提示:目前流行的三种:

A 自主型访问控制; B、强制型访问控制; C、基于角色的访问控制RBAC

【数据库方面】

  1. 怎么处理日志问题?有那些可行的方案?
  2. 用JAVA如何实现每天1亿条记录的数据存储,数据库方面怎么设计?
  3. 对应大表数据是如何处理;以及数据库性能调优策略;

提示:索引,SQL语句效率(切忌全表扫描),数据迁移,水平切面等

  1. 分布式系统,数据库设计方面,应注意哪些方面?

( 提示:权限设计、图片存储、服务器集群设计等)

  1. 当用户反映,平台访问变的很慢的时候,怎样处理这个问题的?

提示:A、数据库端;B、后端应用平台端;C、前端Web端;D、负载均衡;E、网络设置;F、机器性能的优化;G、考虑是否有病毒、木马等干扰等等

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
第 1 章 系统介绍 4 1.1 系统介绍 4 1.2 系统相关对象介绍 4 1.3 系统设备介绍 4 第 2 章 现有系统分析 4 第 3 章 系统相关人员(系统)愿望列表 4 3.1 部门,人员组织结构图 4 3.2 投资人愿望列表 4 3.3 管理部门愿望列表 5 3.3.1 管理流程 5 3.3.2 质量监控 5 3.3.3 统计与分析 5 3.4 维护部门愿望列表 5 3.5 操作人员与服务人员愿望列表 5 3.5.1 操作人员组一 5 3.5.2 操作人员组二 5 3.6 外界系统愿望列表 6 3.6.1 外界系统一 6 3.6.2 外界系统二 6 第 4 章 系统功能定义 6 4.1 系统功能分类说明 6 4.2 功能分类一功能定义 7 4.2.1 使用者 7 4.2.2 业务流程 7 4.2.3 功能定义 7 4.3 功能分类二功能定义 7 4.3.1 使用者 7 4.3.2 业务流程 7 4.3.3 功能定义 7 第 5 章 系统接口定义 7 5.1 接口规范与标准 7 5.2 第一种类型接口定义 7 5.2.1 适用范围定义 7 5.2.2 功能要求 8 5.2.3 实现方式 8 5.3 第二种类型接口定义 8 5.3.1 适用范围定义 8 5.3.2 功能要求 8 5.3.3 实现方式 8 第1章系统介绍 1.1系统介绍 介绍系统功能和适用范围,系统的使用周期和建设周期。 1.2系统相关对象介绍 介绍和系统有关人,机构,系统。 1.3系统设备介绍 介绍系统内的设备或设备分类,附设备连接图。 第2章现有系统分析 分析现有系统或目前局部使用的软件的功能和缺陷。 第3章系统相关人员(系统)愿望列表 列举和系统有关系的人和系统对本系统的期望和各自要求的功能。对于每个部门和用户群需要给予适当分类,分析不同用户群和同一用户群内不同用户各自的职责和对系统的期望。 3.1部门,人员组织结构图 描述与系统相关的用户群的部门和人员组织,需要标明上下级关系和人员的组织结构。 3.2投资人愿望列表 3.3管理部门愿望列表 3.3.1管理流程 3.3.2质量监控 3.3.3统计与分析 3.4维护部门愿望列表 3.5操作人员与服务人员愿望列表 3.5.1操作人员组一 3.5.1.1工作职责 3.5.1.2愿望列表 3.5.2操作人员组二 3.5.2.1工作职责 3.5.2.2愿望列表 3.6外界系统愿望列表 分析系统之外的其他系统对功能的要求。 3.6.1外界系统一 3.6.1.1系统功能与作用 分析外界系统和本系统间的联系 3.6.1.2系统互操作方式 3.6.2外界系统

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值