我的位置: 首页 > 校园新闻 > 行业新闻 >
就业喜报更多 >
热点专题更多 >
热门标签更多 >
男生做什么工作有前途
时间:2016-02-16 16:11:22   来源:   点击:
大家都在关注: 东莞软件开发培训
分享到:
[导读]   男生做什么工作有前途?相信许多人都会遇到此类问题,男生做什么工作有前途,学什么技术比较好?女生做什么工作收入高,学什么技术更合

  男生做什么工作有前途?相信许多人都会遇到此类问题,男生做什么工作有前途,学什么技术比较好?女生做什么工作收入高,学什么技术更合适等等。本文是一篇模仿问答的小故事,作者用幽默的风格简单分析了架构师要做的工作:

  我想要成为一名软件架构师。

  这是年轻软件开发者很好的选择。

  我想要带领团队,并在数据库与框架、webserver等方面作出重要的决策。

  噢,那你根本就不想成为软件架构师。

  我当然想了,我想要成为重要决策的制定者。

  那很好,不过你列出的内容中并不包含重要的决策,这些都是不相关的决策。

  什么意思?你是说数据库并不是重要的决策,你知道我们在上面花了多少钱吗?

  也许花的太多了。但是,数据库并不是重要的决策之一。

  你怎么能这样讲?数据库是系统的核心,是进行所有数据系统化、分类、编入索引和存取工作的地方;没有数据库的话,就不会有系统。

  数据库只是一个IO设备,它恰巧为分类、查询与信息报告提供了一些有用的工具,但这些都只是系统架构的辅助功能而已。

  辅助?这太离谱了。

  没错,就是辅助。系统的业务规则也许能够利用其中的一些工具,不过那些工具却并非相应业务规则所固有的。需要的话,可以用不同的工具来替换现有的这些;而业务规则不会改变。

  嗯,没错,不过必须重新进行编码,因为在原本的数据库中这些工具都用到了。

  那是你的问题。

  什么意思?

  你的问题在于,你以为业务规则是依赖数据库工具的,实际上并不是。或者说至少,在提供优秀架构前并不应当是这样的。

  这简直是疯了。如何创建不使用那些工具的业务规则呢?

  我不是说它们没使用数据库的工具,而是说它们并不依赖于此。业务规则无需知道你使用哪个数据库。

  那么如何在不了解使用什么工具的情况下,获得业务规则呢?

  让依赖倒置过来,使得数据库依赖业务规则。确保业务规则不依赖于数据库。

  你在胡言乱语。

  恰恰相反,我在使用软件架构的语言。这是依赖倒置原则:低层准则应当依赖高层准则。

  一派胡言!高层准则(假设指的是业务规则)调用低层准则(假设指的是数据库)。因此高层准则会根据调用方依赖被调用方的原则,而依赖低层准则。这个谁都知道!

  在运行时的确如此。不过在编译时,我们想要的是依赖倒置。高层准则的源代码应当不提及低层准则的源代码。

  得了吧!怎么能在不提及的情况下进行调用呢?

  当然没问题。这就是面向对象的所涉及的内容。

  面向对象是关于真实世界的模型创建,将数据、功能与有凝聚力的对象相结合。是关于将代码组织成直观的结构。

  他们是这么说的?

  大家都知道,这是显而易见的真相。

  没错,确实如此,然而,在使用面向对象准则时,的确可以在不提及的情况下进行调用。

  好吧,那要怎么做?

  在面向对象设计中,各个对象会彼此发送消息。

  没错,这是当然的。

  而sender在发送消息时,并不知道receiver的类型。

  这取决于所使用的语言。在Java中,sender至少知道receiver的基础类型。在Ruby中,sender至少知道receiver能够处理所收到的消息。

  没错。不过在任何情况下,sender都不知道receiver的具体类型。

  是这样,好吧,确实如此。

  因此,sender可以在不提及receiver具体类型的情况下,设计receiver执行某个功能。

  是这样,没错。我了解了。不过sender仍旧依赖于receiver。

  在运行时的确如此。不过编译时则不同。sender的源代码并不会提及或者依赖receiver的源代码。事实上receiver的源代码依赖于sender的源代码。

  不会吧!sender仍依赖于它所发送的类。

  也许从某些源代码来看,会更清楚一些。下面这段是Java写的。首先是sender:

  package sender;

  public class Sender {

  private Receiver receiver;

  public Sender(Receiver r) {

  receiver = r;

  }

  public void doSomething() {

  receiver.receiveThis();

  }

  public interface Receiver {

  void receiveThis();

  }

  }

  下面是receiver:

  package receiver;

  import sender.Sender;

  public class SpecificReceiver implements Sender.Receiver {

  public void receiveThis() {

  //do something interesting.

  }

  }

  注意:receiver依赖于sender,SpecificReceiver依赖于Sender,在sender中并没有receiver相关的信息。

  是啊,不过你在撒谎,你把receiver的接口放在sender类中了。

  你开始懂了。

  懂什么?

  当然是架构的原则。Sender拥有receiver必须实现的接口。

  如果这意味着我必须使用嵌套类,那么……

  嵌套类只是实现目的的手段之一,还有其他办法。

  好吧,等一下。这又跟数据库有什么关系?我们最开始讨论的可是数据库。

  再看一点代码吧。首先是一个简单的业务规则:

  package businessRules;

  import entities.Something;

  public class BusinessRule {

  private BusinessRuleGateway gateway;

  public BusinessRule(BusinessRuleGateway gateway) {

  this.gateway = gateway;

  }

  public void execute(String id) {

  gateway.startTransaction();

  Something thing = gateway.getSomething(id);

  thing.makeChanges();

  gateway.saveSomething(thing);

  gateway.endTransaction();

  }

  }

  业务规则没占多大份量。

  这只是个例子。还能有更多这样的类,实现很多不同的业务规则。

  好的,那么Gateway到底是什么?

  它通过业务规则提供了所有数据存取方法。按以下方式实现:

  package businessRules;

  import entities.Something;

  public interface BusinessRuleGateway {

  Something getSomething(String id);

  void startTransaction();

  void saveSomething(Something thing);

  void endTransaction();

  }

  注意:这是在businessRules之中。

  ok,Something类又是什么?

  它代表着简单的业务对象。我将它放在entities之中。

  package entities;

  public class Something {

  public void makeChanges() {

  //...

  }

  }

  最终BusinessRuleGateway实现,这个类知道真正的数据库:

  package database;

  import businessRules.BusinessRuleGateway;

  import entities.Something;

  public class MySqlBusinessRuleGateway implements BusinessRuleGateway {

  public Something getSomething(String id) {

  // use MySql to get a thing.

  }

  public void startTransaction() {

  // start MySql transaction

  }

  public void saveSomething(Something thing) {

  // save thing in MySql

  }

  public void endTransaction() {

  // end MySql transaction

  }

  }

  另外,注意业务规则在运行时调用数据库;不过在编译时,数据库会涉及并依赖于businessRules。

  好吧,我想我明白了。你只是在利用多态性来隐藏从业务规则实现数据库的事实。不过仍需要一个接口,向业务规则提供所有的数据库工具。

  不,完全不是这样。我们没有尝试向业务规则提供数据库工具。而是通过业务规则,为它们所需要的内容创建接口。实现这些接口就能调用合适的工具。

  是啊,不过如果所有业务规则需要用到每个工具,那么只需把工具放在gateway接口中。

  啊,我看你还是没明白。

  明白什么?这已经很清楚了。

  每个业务规则只为自己所需的数据访问工具定义一个接口。

  等一下,你说什么?

  这就是接口隔离原则(Interface Segregation Principle)。每个业务规则类只用到数据库的某些设施。因此,每个业务规则提供的接口只能访问相应的设施。

  不过,这意味着需要很多接口,以及很多的小型实现类,它们又会调用其他的数据库类。

  很好,你开始理解了。

  不过这太乱了,浪费时间。为什么要这样做呢?

  这样做能够条理分明,节省时间。

  得了吧,为了代码,弄出来一大堆代码。

  恰恰相反,通过重要的架构决策,可以延缓不相关的决策。

  这是什么意思?

  记得最开始,你说想做软件架构师不是吗?你想要作出所有真正重要的决策。

  是啊,我是这样想的。

  你想要决策的是数据库、webserver和框架相关的方面,对吗?

  是啊,你说那些都不重要。只是不相关的内容。

  没错。就是这样。软件架构师所作出的重要决策指的是,让你不对数据库、webserver和框架进行决策。

  不过必须得先决定那些吧!

  不用的。事实上,在开发周期中,这些都可以稍后再决定,在信息更充足的时候再决定。

  如果架构师提前确定框架,却发现框架无法提供所需的性能,或者带来了无法忍受的约束,这就成了灾难。

  只有架构师决定推迟决策,待信息足够时才作出决策;在架构师的决策下,不使用缓慢而过于耗费资源的IO设备和框架的团队,才能创建快速、轻量级的测试环境;只有其架构师关心真正重要的东西,延缓那些不重要的,这样的团队才是幸运的团队。

  胡说,我完全不明白你的意思。

  好吧,还是好好看一下本文,不然只能再等10年你才能明白了。