v***n
发帖数: 562 | 1 2. customers want to buy some products but the products are out of stock,
design a system to notify them when those products are again available.
3.design, display a customer's friends list who also bought the product he
is curently looking at. |
p*****2
发帖数: 21240 | 2 第一题each product stores a customer list who registered notification
第二题each product has a hashtable to store customers who purchased already
行不行呀。 |
i*******6
发帖数: 107 | 3 2.用observer pattern
3.用mediator pattern |
v***n
发帖数: 562 | 4 I think it is okay for the first one to use a hash table in which key is the
product id and value is an array of customer ids.
For the second one, is there any more efficient way?
already
【在 p*****2 的大作中提到】
: 第一题each product stores a customer list who registered notification
: 第二题each product has a hashtable to store customers who purchased already
: 行不行呀。
|
p*****2
发帖数: 21240 | 5
is
the
if we have two classes User and Product
question1:
class Product
{
List notificationlist; // to notify all users in the list once
the
product is available
}
question2:
class User
{
List friends;
}
class Product
{
HashSet purchaseduser;
List GenerateList(User user)
{
foreach(friend in user.list)
{
if(purchaseduser.Contains(frind))
add it to output list
}
}
}
【在 v***n 的大作中提到】
: I think it is okay for the first one to use a hash table in which key is the
: product id and value is an array of customer ids.
: For the second one, is there any more efficient way?
:
: already
|
A**u
发帖数: 2458 | 6 大牛
能不详细解释一下3的mediator pattern,
我专门学习了一下mediator,
请问这里，用什么做mediator呢
【在 i*******6 的大作中提到】
: 2.用observer pattern
: 3.用mediator pattern
|
i*******6
发帖数: 107 | 7 先说5楼的设计的不好的地方：
1.每个product中都必须维护一个消费者list，开销过大（想想amazon上几百万的东西
，每个东西对应一个product类...）
2.每个用户的责任里面有记录他自己的朋友们（也是用户），造成宏观的交互模式是多
对多，非常难以维护和复用。比如需求突然改为要分老用户和新用户，每种用户有特定
的行为。那么user代码必须改成：
olduser extends user{
list;
list;
}
newuser extends user{
list;
list;
}
如果再次扩展用户类型，问题会更严重。
3.user和product类紧耦合，造成的后果是如果需要改动user类（比如扩充新用户种类
），product类必须随之更改。 product类本身低内聚,它必须要负责本来不属于它的责
任：维护购买了它的用户，而且这种维护违背了一致性封装原则。
Mediator模式本身实现并不复杂，只需要有一个中介负责处理用户间交互即可，具有很
强的灵活性。
设计如下(代码从简)：
class user{
private Mediator m;
public user(Mediator m){
this.m = m;
}
public open(product){
m.showfirends(this,product);
}
public boolean isbuy(product){
return if user brought product;
}
public list getallfriends(){
}
public showUserFriendsBuyProduct(list FriendsBuyProduct){
// show list in correct place
}
}
class mediator{
private user;
private product;
public showfriends(user,product){
this.user = user;
this.product = product;
list friendsbuyproduct;
list friends = user.getallfriends();
foreach friend in friends
if frind.isbuy(product) friendsbuyproduct.add(friend);
user.show(friendsbuyproduct)
}
}
好处：
1.高内聚：每个类只负责它自己的职责（为了简化代码起见，我把不应属于user的最后
一个方法放在user里面了，其实它应该在别的比如webpage类里面show出来）
2.宏观来看user之间的联系变为一对多
3.无论扩展多少新用户种类，只需要修改mediator一个类
【在 A**u 的大作中提到】
: 大牛
: 能不详细解释一下3的mediator pattern,
: 我专门学习了一下mediator,
: 请问这里，用什么做mediator呢
|
p*****2
发帖数: 21240 | 8
多谢大牛。这些是design pattern的东西吗？
【在 i*******6 的大作中提到】
: 先说5楼的设计的不好的地方：
: 1.每个product中都必须维护一个消费者list，开销过大（想想amazon上几百万的东西
: ，每个东西对应一个product类...）
: 2.每个用户的责任里面有记录他自己的朋友们（也是用户），造成宏观的交互模式是多
: 对多，非常难以维护和复用。比如需求突然改为要分老用户和新用户，每种用户有特定
: 的行为。那么user代码必须改成：
: olduser extends user{
: list;
: list;
: }
|
i*******6
发帖数: 107 | |
A**u
发帖数: 2458 | 10 多谢irvine666大牛
下午才仔细看看，太感谢了，码这多字 |
|
|
w*******t
发帖数: 62 | 11 mediator的用法明白了。
还有一些不明白的，想问一下，可能有点儿偏。
mediator调用user的isbuy和getallfriends，想知道buy和product的信息存在哪儿，如
果user没有friend列表和buyProduct列表？是用product-user hash table 和 user-us
er hash table吗？
谢谢先！
【在 i*******6 的大作中提到】
: 先说5楼的设计的不好的地方：
: 1.每个product中都必须维护一个消费者list，开销过大（想想amazon上几百万的东西
: ，每个东西对应一个product类...）
: 2.每个用户的责任里面有记录他自己的朋友们（也是用户），造成宏观的交互模式是多
: 对多，非常难以维护和复用。比如需求突然改为要分老用户和新用户，每种用户有特定
: 的行为。那么user代码必须改成：
: olduser extends user{
: list;
: list;
: }
|
i*******6
发帖数: 107 | 12 product就是一个实体类，负责它自己的责任，比如库存，价格，折扣等等。
isbuy可以通过hibernate技术和database直接交互检索信息，比如SQL语句
Select * from usebuy(this is a table) where userid=user.id and productid=
product.id
检索结果为空说明没有，不为空说明有
get_all_friend也是一样的,用SQL在数据库里面查，返回一个列表
当然不能每次查询都从数据库里面读取，否则性能会下降的很厉害。
常用的优化方法包括：
设计良好的缓存系统增加hit数
读取出来的数据储存到临时文件（一般是XML）或者数据结构（hashtable）里面
multi-thread 并发
但是这些优化并不算在我们的OOP设计当中，这个属于设计良好的MVC架构中control层和persistent层的交互, OOP主要关注的是model.
每个层面分开专注于自己的事情和优化方式，这也是MVC架构的优势
us
【在 w*******t 的大作中提到】
: mediator的用法明白了。
: 还有一些不明白的，想问一下，可能有点儿偏。
: mediator调用user的isbuy和getallfriends，想知道buy和product的信息存在哪儿，如
: 果user没有friend列表和buyProduct列表？是用product-user hash table 和 user-us
: er hash table吗？
: 谢谢先！
|
v***n
发帖数: 562 | |
A**u
发帖数: 2458 | 14 大牛，
我又仔细看了看你的mediator 设计，有点不对啊
你的mediator只指向一个user?
难道mediator 不应该像个中转站，被多个user共享吗?
【在 i*******6 的大作中提到】
: 先说5楼的设计的不好的地方：
: 1.每个product中都必须维护一个消费者list，开销过大（想想amazon上几百万的东西
: ，每个东西对应一个product类...）
: 2.每个用户的责任里面有记录他自己的朋友们（也是用户），造成宏观的交互模式是多
: 对多，非常难以维护和复用。比如需求突然改为要分老用户和新用户，每种用户有特定
: 的行为。那么user代码必须改成：
: olduser extends user{
: list;
: list;
: }
|
i*******6
发帖数: 107 | 15 那我写个client你就懂了：
class client{
public static void main(String args){
mediator m = new mediator;
//假设有3个用户：amazon, google, facebook， 相互为好友， amazon买过
book，facebook买过kindle
user google = new user(m);
user amazon = new user(m);
user facebook = new user(m);
product book = new product();
product kindle = new product();
google.open(book); //amazon will be showed
// 现在google打开新的一页了！
google.open(kindle); //amazon will not be showed, facebook will be
showed
}
}
mediator确实是被多个user的 《实例》 共享，并不是指被若干个user类共享。
【在 A**u 的大作中提到】
: 大牛，
: 我又仔细看了看你的mediator 设计，有点不对啊
: 你的mediator只指向一个user?
: 难道mediator 不应该像个中转站，被多个user共享吗?
|
A**u
发帖数: 2458 | 16 太感谢了，明白了。
你这个mediator里指向的user是变化的。。。
我想的是在mediator里建个 map.
非常感谢.
【在 i*******6 的大作中提到】
: 那我写个client你就懂了：
: class client{
: public static void main(String args){
: mediator m = new mediator;
: //假设有3个用户：amazon, google, facebook， 相互为好友， amazon买过
: book，facebook买过kindle
: user google = new user(m);
: user amazon = new user(m);
: user facebook = new user(m);
: product book = new product();
|
w*******t
发帖数: 62 | 17 多谢～～
对这方面不是很了解，现在明白了。
【在 i*******6 的大作中提到】
: product就是一个实体类，负责它自己的责任，比如库存，价格，折扣等等。
: isbuy可以通过hibernate技术和database直接交互检索信息，比如SQL语句
: Select * from usebuy(this is a table) where userid=user.id and productid=
: product.id
: 检索结果为空说明没有，不为空说明有
: get_all_friend也是一样的,用SQL在数据库里面查，返回一个列表
: 当然不能每次查询都从数据库里面读取，否则性能会下降的很厉害。
: 常用的优化方法包括：
: 设计良好的缓存系统增加hit数
: 读取出来的数据储存到临时文件（一般是XML）或者数据结构（hashtable）里面
|
b******g
发帖数: 1721 | 18 For the second one, can we just use a parametrized stored procedure in the
database side? At the same time, each user can have a method shown below:
List allFriends(){
return sb_allfriend(thisUser, this.user.product).
}
where sb_allfriend() is a stored procedure.
he
【在 v***n 的大作中提到】
: 2. customers want to buy some products but the products are out of stock,
: design a system to notify them when those products are again available.
: 3.design, display a customer's friends list who also bought the product he
: is curently looking at.
|
