比方一个人，他在家就是家长,在单位就是工人。
interface parent{
bringup();
}
interface work{
doWork();
}
class person implements parent ,work{
}
class atHome{
parent p = new person();
p.bringup();
}
class atFactory{
work w = new person();
w.doWork();
}
这样合适吗？ 怎么比较好呢？
原来是这么个场景。
这样设计关键还是看需求。现实情况很可能是一个人即不会bringup也不用work，另外一个人家庭主妇只要bringup，她老公则只要work……这种情况，用装饰模式可能更好。
除非某些特殊应用，比如六一儿童节，单位工会讨论所有有小孩的职工结合他们在单位work技能以及在家里bringup技能组织一场别开生面的运动会。这里或许可以用上楼主的设计。
class person {
}
interface parent{
bringup(person p);
}
interface work{
doWork(person p);
}
class atHome implements parent{
bringup(person p){
}
}
class atFactory implements work{
doWork(person p){
}
}
atHome 实现在家场景 atFactory实现工作场景，这样合适吗？ 但是这样的话person这个人可就没行为了。
合不合适，最重要的看你的需求，看你的业务流程。所以，光讨论一个设计类而不说明软件的需求和业务流程是没有意义的。
不过，就事物认识的一般规律来看。你这里atHome，atFactory类不好理解。因为他们语意上看是关于某处地方的事物，而实际却是执行关于某个人的抽象事物。地方不是人，一般的认识可能是——人在某地活动；某个地方营造了一种生态环境，适合人居住……
道法自然，面向对象这种软件设计方法可以很自然的表达客观世界事物之间的联系。
这句话包含信息太少了，通过你这句话，我这里有一大堆问题。
1、不同的人是指哪些不同的人？男人，女人，大人小孩，还是王公贵族？
2、不同地方是指哪些不同地方？家里，单位。其他地方呢？迪士尼，早教中心，海洋公园会不会也是你指的不同地方？
3、上面我例举的人和地方是不是只是需要解决的问题域中很小一部分，还有大量的人和地方没有例举到？
4、不同的责任也有很多理解。是不是每个地方就固定一个责任？不会是两个、三个？
5、地方决定责任还是责任决定地方？在单位是工作，在家能不能工作？在家带小孩，在单位喂奶算不算带小孩？
6、某个人在某个未知的地方会不会需要承担未知的责任？
……
大致回答上述一系列问题之后，再看看你的软件模型，能不能适应实际需求。能适应就是好模型。
面向对象重要的是提炼然后抽象业务模型，这样才能得到一个深度的软件模型。这个深度的软件模型应当能适应现实业务模型的变化而改变。现实业务模型的变化是永恒的，一方面它确实在不断发展变化，另一方面业务分析设计者理解的认识变化。
结合到这个例子，我认为可以将人、地方、责任作为抽象的对象。
结合到这个例子 ...