类似邮箱功能的应用,望OO

12-11-06 wyz191
要整一个类似邮箱的短信发送应用,要求:
收信箱:查看上行短信
发信箱:查看已下发短信
垃圾箱:查看已删除短信
草稿箱:查看保存的草稿

现在我的想法是:
信箱[收信箱、发信箱、垃圾箱、草稿箱]
短信
具体实现时,将短信中加一个标志位,加以区分此短信属于[收信箱、发信箱、垃圾箱还是草稿箱],但是现在有一个问题是,当发信时,即可以将此短信归属到草稿箱中,同时还可以归属到发信箱中;针对这种情况,我想将短信的标志位设置为一个整型,将归属[发信箱、草稿箱]的短信标志位设置为大于或小于指定数值的整形,不知道这样是否可行

如果用OO的思想如何来整理?


[该贴被wyz191于2012-11-07 08:25修改过]

3
banq
2012-11-07 10:43
业务用oo基本采取DDD,信息和信箱是两个主要实体,信箱可以看成是信息的距合体,作为根实体,下份几个继承子类:收信箱,发信箱等。

alexwoo
2012-11-07 16:16
我认为不应该为了OO而OO,
应该深入分析需求,找到事物之间的客观联系。

以你的这个问题为例子,一封信件可以同时存在多个信箱,我的理解对吗?

如果是这样的话, 对每个信箱编号1,2,4,8,16, 信件的标志位直接使用信箱编号的或操作就行。比如 1|2代表同时存在于1信箱和2信箱。

以上

[该贴被alexwoo于2012-11-07 16:17修改过]

wyz191
2012-11-07 18:58
现在有三种用户:
1、部门用户[收发维护本部门短信]
2、个人用户[收发维护私人短信]
3、部门领导[兼有1、2用户的功能]

针对上面提到的信箱,有一点尚不确定,信箱是用户获取短信的窗口,那么针对信箱是应该让用户去取短信呢[信箱不与用户关联,将信箱当做一个仓库,给信箱单号,信息给你拿货]?还是让信箱给用户短信[直接标明信息是某个用户的信箱]?

banq
2012-11-08 08:53
2012-11-07 18:58 "@wyz191"的内容
直接标明信息是某个用户的信箱 ...


不妥,信箱是信息的聚合体,信箱可直接和所有者用户关联,信息可通过所在信箱导航得到关联信箱的所有者用户。

wyz191
2012-11-08 09:53
针对短信的情况:
短信分为:
1、上行短信
2、下行短信
a、立即发送短信
b、定时发送短信
------------------
a1、点对点发送:发给一指定号码,号码主人未在系统中注册
b1、群发:所有接收方均在系统中注册

针对这种情况,用OO应该设置一个根类SMSInfo,然后再细分为:
根:SMSInfo
子一:UpSMSInfo DownSMSInfo
子二: DownImmeSMSInfo DownNotImmeSMSInfo
是否应该细分到子二,还是分到子一然后在下行中设置一下行时间?
在收取短信时,所有的短信如果都同下行短信号码来匹配,a1、b1的情况应该可以忽略,这块是不是可以忽略过去,不做过多考虑?


针对信箱:
在根[信箱]下细分为[收信箱、发信箱、草稿箱、垃圾箱]
根:SMSBOX[数据:短信 行为一:存信 行为二:取信]
子一:SMSDraftBox SMSDustBox SMSReceiveBox SMSSendBox
然后,在实际操作中,在外面包裹上一层信息过滤,这样是否可行?


[该贴被wyz191于2012-11-08 10:06修改过]

banq
2012-11-09 10:38
2012-11-08 09:53 "@wyz191"的内容
短信分为:
a、立即发送短信
b、定时发送短信
------------------
a1、点对点发送:发给一指定号码,号码主人未在系统中注册
b1、群发:所有接收方均在系统中注册 ...



以上这些属于用户对短信的操作行为,以购物车为案例,用户增加 修改购物车中的商品,都属于用户操作行为。

“用户操作短信的行为”可以解释为:用户 + 发出操作指令命令 + 短信的相应行为被激活。

分析首先从名词和动词两个方面入手,也就是区分静态结构和动态行为两个方面入手:

至于上行短信和下行短信可能不属于动态行为,而是属于和动态行为有关的状态,如果这个短信被上行行为操作了,那属于上行短信,本质还是属于短信,只是短信在特定场景实施了动态行为,可以将上行短信看成是短信扮演的上行角色。

静态结构和动态行为两天线路可以很清晰落地,常见下图:



图中,领域--聚合--实体 属于静态结构;场景 事件和状态属于动态行为,当然状态特殊一点,属于静态和动态结合点,这点经常被混淆,要么和实体固有属性混淆,要么和事件行为混淆,比如上行短信和下行短信。

建议楼主多了解一下DDD,聚合根是需要的,比如SMSInfo。


clonalman
2012-11-10 03:59
邮箱、短信讨论了半天,实质就是邮箱、短信的一个分配问题!


2012-11-08 08:53 "@banq"的内容
不妥,信箱是信息的聚合体,信箱可直接和所有者用户关联,信息可通过所在信箱导航得到关联信箱的所有者用户。 ...


信箱、短信与用户最好分开设计,不需要进行任何偶合,他们分属不同的场景,否则信箱使用范围就会被“用户”限定死了,针对信箱的多用户使用与一个用户同时使用多个信箱的问题,本质上是用户的一个信箱地址的分配问题。

当然还要解决一个来信短信提醒的问题,可以在邮箱接受信件事出发一个来信事件,过程可以这样设计:
Hr模块场景订阅来信事件。
邮箱接受信件事->邮箱上下文处理事件(比如:完善时间内容、技术上ServiceBus进行发送等)->事件订阅场景处理来电事件,产生短信发送事件(hr根据邮箱地址找到该地址的所有使用者,获取电话号码发送短信提醒)->短信处理场景处理短信发送事件



如果hr行政部门对邮件有写特殊的控制,邮件字串地址做成一个MailAddress对象,加上MailAddress的邮件控制属性、短信控制属性等

2012-11-08 09:53 "@wyz191"的内容

针对短信的情况:短信分为:1、上行短信2、下行短信 a、立即发送短信 b、定时发送短信 ...



这个发短信问题看是一个短信问题实质也个业务控制问题,主要是考虑相关的控制属性应该放在哪些类上
对短信发送事件做一个EventScheduler来执行。对短信模块而言只要收、发,
既于是部门收发还是个人收发放到业务模块,否则信箱、短信就太死了,过程与油箱来信一样,可以写一个短信到达的事件一样处理。

如果进一步抽象的话,MailAddress、MessageAddress继承一个共同的Address基类,拓展性就话好一点了,
DDD设计不怕聚合根或对象方法没找到或找错了,最担心的没有看到潜在的对象把一些系统不相关(可能业务相关)的对象硬塞到系统,这样太容易迷失方向。(个人观点,DCI设计最大毛病就在于此,因为它太接近业务描述了)


不好意思,文字描述没什么条理,想到哪写到哪,将就着看吧 .....

[该贴被clonalman于2012-11-10 04:48修改过]

猜你喜欢