openwares.net

Freedom & Beauty

0%

Posted on Edited on In

Mybatis Generator配置文件中
generatorConfiguration元素有一个子元素properties，可以用来指定一个java属性文件,从而配置文件内可以通过${property}来引用属性对应的值。可以将一些通用的属性放到共享的属性文件中减少一些冗余。

properties子元素有两个互斥的属性resource和url,resource用来指定类路径下的属性文件,url用来指定文件系统路径指示的属性文件。
二者只能使用一个,resource总是不成功,Mybatis Generator的类路径就没整明白,jdbc驱动类还是用的绝对路径:(

样例属性文件generatorConfig.properties
[xml]
classPath=/path/to/WEB-INF/lib/postgresql-9.3-1100.jdbc41.jar
driverClass=org.postgresql.Driver
dbURL=jdbc:postgresql://localhost/reis
userId=general
passwd=general
project=projectname/src/main
[/xml]

更新(12/30/2013):

将资源文件放入eclipse已经存在的classpath中,或者将资源文件所在的文件夹添加到eclipse类路径里就可以用resource属性来引用资源文件了。
比如资源文件放在WEB-INF/conf文件夹里面,WEB-INF/conf不在eclipse的类路径下,所以需要设置eclipse添加该文件夹,如下：
project -> properties -> java build path -> libraries -> add class folder,选择WEB-INF/conf确定就可以了。
这样工程根目录下的.classpath文件内会添加一行:
[xml]

[/xml]

Posted on Edited on In

Mybatis Generator默认设置会生成一大堆罗哩罗嗦的Example类,主要是用各种不同的条件来操作数据库,大部分是用不到的,用到的时候手工修改mapper和接口文件就行了。

[sql]

\[/sql\]

这样生成的mapper和dao接口就清爽多了。

Posted on Edited on In

因为要引用schema base中的一张表tb_user,所以在sql文件中使用如下语句授权:
[sql]
\c reis base
GRANT REFERENCES ON tb_user TO general;
\c reis general
[/sql]

但仍然无法引用base.tb_user表,提示:

ERROR: permission denied for schema base

这里虽然对schema base下的对象tb_user有了参考的权限,但对schema本身却没有授予权限,所以出现这个错误提示。

所以先授权角色general有使用schema的权限就可以了。

[sql]
\c reis base
GRANT USAGE ON SCHEMA base TO general;
GRANT REFERENCES ON tb_user TO general;
\c reis general
[/sql]

对于schema对象,有两种权限可以授权其他角色。一个是CREATE,允许被授权的角色在当前schema内创建和修改对象。另一个权限是USAGE,允许被授权角色使用schema内的对象。

参考:
GRANT的详细语法

Posted on Edited on In

complete和finish的区别: When you marry the right girl, you are completed. When you marry the wrong girl, you are finished. When the right girl catches you with the wrong girl, you are completely finished. 太经典了！

Posted on Edited on In

Florence是一款不错的GNOME屏幕虚拟键盘，如果不使用GNOME,可以使用另一款屏幕虚拟键盘xvkbd,xvkbd只依赖于X11。有了屏幕虚拟键盘，触摸本用起来更爽了。

Posted on Edited on In

概括总结

设计模式千变万化，但万变不离其宗

设计模式可以使用以下几个简单的词汇进行总结:

  • 间接(indirection)

    通过引入间接层来解耦。

  • **高内聚(cohesion)，低耦合(decoupling)**。

  • 隔离变化

    将变化的部分和不变的部分隔离开来，使经常变化的部分发生变化时，不变的部分不受影响。 这叫做”以不变应万变”。

基本原则

软件设计实践中有几个比较重要的原则,是各种设计模式的指导性原则。简述如下:

  • 开闭原则(Open Closed Principle,OCP)

    开闭原则认为一个软件实体应当对扩展开放，而对修改关闭。在设计一个模块时，应使这个模块在未来不修改的前提下扩展其功能。 也就是可以在不修改源代码的情况下，改变这个模块的行为。 遵循OCP原则,可以通过扩展已有软件系统，提供新的行为，以满足对软件的新的需求，使变化中的软件有一定的适应性和灵活性。 已有软件模块，特别是最重要的抽象层模块不能再修改，这使变化中的软件系统有一定的稳定性和延续性。

  • 接口隔离原则(Interface Segregation Principle,ISP)

    客户不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。使用多个专门的接口比使用单一的总接口总要好。 过于臃肿的接口是对接口的污染，不应该强迫客户依赖于它们用不到的方法。

  • 里氏替换原则(Liskov Substitution Principle,LSP)

    子类型(subtype)必须能够替换他们的基类型,也就是，所有父类可以出现的地方，子类也必须可以出现。

  • 依赖倒置原则(Dependency Inversion Principle,DIP)

    DIP的两大原则：

    1. 高层模块不应该依赖于低层模块,二者都应该依赖于抽象。

    2. 抽象不应该依赖于细节,细节应该依赖于抽象。

      具体来讲，依赖倒置的核心思想是针对接口而不是实现编程。 应用DIP可以降低模块之间的耦合度，只要接口保持稳定，模块可以独立演化而互不影响。

  • 单一职责原则(Single Responsibility Principle,SRP)

    There should never be more than one reason for a class to change。 一个类应该只有一个引起它变化的原因。一个类应该只有一个职责。如果类有一个以上的职责，这些职责就耦合在了一起。这会导致脆弱的设计。 当一个职责发生变化时，可能会影响其它的职责。另外，多个职责耦合在一起，会影响复用性。

  • 迪米特法则(Law of Demeter,LoD）或者叫最少知识原则(Least Knowledge Principle,LKP)

    一个对象应该尽可能少的了解其他对象。类之间的关系越密切，耦合度越大，当其中一个发生变化时，必定会对另一个产生影响， 应该把这种影响降到最低。

  • 组合/聚合复用原则(Composite/Aggregate Reuse Principle,CARP)

    优先使用合成/聚合而不是继承。

    继承作为面向对象三大特性之一，在给程序设计带来巨大便利的同时，也带来了弊端。 比如使用继承会给程序带来侵入性，程序的可移植性降低，增加了对象间的耦合性， 如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类， 并且父类修改后，所有涉及到子类的功能都有可能会产生故障。

    合成/聚合复用

    优点： 新对象存取成分对象的唯一方法是通过成分对象的接口； 这种复用是黑箱复用，因为成分对象的内部细节是新对象所看不见的； 这种复用支持包装； 这种复用所需的依赖较少； 每一个新的类可以将焦点集中在一个任务上； 这种复用可以在运行时动态进行，新对象可以使用合成/聚合关系将新的责任委派到合适的对象。

    缺点： 通过这种方式复用建造的系统会有较多的对象需要管理。

    继承复用

    优点： 新的实现较为容易，因为基类的大部分功能可以通过继承关系自动进入派生类； 修改或扩展继承而来的实现较为容易。

    缺点： 继承复用破坏包装，因为继承将基类的实现细节暴露给派生类，这种复用也称为白箱复用； 如果基类的实现发生改变，那么派生类的实现也不得不发生改变； 从基类继承而来的实现是静态的，不可能在运行时发生改变，不够灵活。

  • 机制与策略分离原则

    机制是要做什么,而策略是要怎么做。或者说,”机制是需要提供什么功能,而策略则是怎样实现这些功能”。更简单明了一些,接口就是机制，而实现则是策略。

    机制与策略分离是UNIX的一大设计哲学,也是UNIX设计的如此灵活的重要基石。

    本质上,机制与策略分离原则仍然讲的是将不变的和经常变化的部分进行隔离的原则。机制是稳定不变的,而策略通常可以是千变万化的。

  • DRY原则

Don’t repeat yourself!

  • Less is more

延伸

GoF(Gang of Four)的Design Pattern列举了23种经典设计模式,除此之外,还有其他许许多多的设计模式。设计模式无论如何变化，纷繁复杂，其本质仍然符合上面的概括和列举的设计原则。 理解了设计模式的本质，才不会被各种设计模式晃花了眼睛。

注:这一篇post是用markdown写，使用pandoc转换为html，然后贴过来的。markdown果然好用。

===
[erq]