
用户框架构思
最初构造的时候,这个框架整体上来说是很混乱的。混乱到了User类可以做一切事情。混乱到了,觉得总结出所有User的功能整个程序的所有功能。
但是后来觉得这太混乱了,以我的能力无法组织在一个类中完成这相关的所有任务。所以也就分成了user和usermanger。user负责存放数据。而UserManager负责处理动作。这样做无非是使得系统的更加复杂。因为本质上来说,这个和上面没有任何区别。仍然是想通过用户系统完成所有的工作。结果就是写代码写得越来越复杂。
在写了代码之后,慢慢的觉得,整个系统应该只是做两件事情——封装内部的逻辑和向外部User以及其身份信息。所以以后所有的设想,都是围绕着这亮点展开。
User,userUtils和UserFactory
User:
这个类现在只提供信息了。没有任何实际性的操作。在我的设想中,User类好像是一个身份识别牌的作用。所以我只在里面封装了ID,Name和password这3个东西。其余的都都封装到了UserInfo,Rolemap中。
构思中,这个User类有两种。一种是只包含简单信息的,UserInfo为空的User,这里称之为简短的User,一种则是UserInfo为不为空的User。这里称之为完整的User。考虑到这两种User要相互装换,并且转换也是很方便的。所以通过一个isBrief()这个方法来进行区分。
这个类为了安全考虑,构造函数都设置成了default
UserFactory:
这个类处理的是User的组装操作。把user,UserInfo何Role这几个类有机的合成一个完整的User,预计希望成为与外部系统沟通的主要类。
所以,这个类的方法,除了获得User的之外。还有给User装填Role和UserInfo的方法。这些方法都是以User为参数。因为希望把这个类写成User,Role和UserInfo的装配工厂
Role
其实这个类是最让我头疼的一个类。因为最初的设想是这是一个接口。比方说一个User,它有一般用户和管理员的功能,我就把这个类设计成,继承抽象的User类,然后实现管理员和用户的接口,谁都知道这个很麻烦。
后来呢,有了Rolemap这个概念之后,我就希望把Role设置成了抽象的。然后各个不同的觉得继承它,把其装入Rolemap。产生这种想法的根源是我希望把各种动作封装到Role中。
后来把整个系统定位成一个身份的提供者之后,现在就统一成了Role类。很简单的一个类,他有一个标示,一个获得标示的方法。外加一个Authoritymap。由于Authority类还在构思之中。所以这里不便继续说了。
UserInfo
这个类很简单。现在位置就碰到一个麻烦。那就是怎么标示其为空。
由于在数据库中,他的ID我设置为从0递增。所以现在我是判断它的id是否为-1.
但是接下来,打算把他的ID设置为UUID,可能需要一个专门的属性来判断了。
各种Uitls类:
这些类的作用我定义的是做为数据库和整个系统的缓冲区。所以和数据库的操作都封装在这些类中。日后加上Hibernate时,我会把这些类大幅度简化。