关于面向对象的程序设计，迷惑

Question

最近学分析，感觉4年工作经验白做了，很迷惑啊比如User类 
我倾向于 User类继承于Person类，我老师的意思 User类包含一个基本属性 person基本信息
Login方法，我倾向于Login方法写到行为层 ，因为login方法与外界进行了交互，还要考虑外界的数据结构和组件迁移老师的意思login放到user类上， 或者user类上面多一个Account属性，包括 username password 和 login方法，原因是login上用到user类的属性最多，所以应该放在 user类上（谁的属性多，谁的数据全就放到谁上面，分析的时候不要考虑如何实现）等等等等问了几个程序员，大部分同意我的意见，唉迷惑啊，我也说服不了我老师，老师是大学的老师，也在外面公司任职，这两个月指导我学分析，我们现在感觉一般都是把 实体 行为 业务 分开，因为不分开很多时候会产生混乱，重复引用等到底是社会毒害了我们，还是.net毒害了我们, .net的技术是不是太多了，新技术是不是来得太快了，很多东西都是肤浅的学一下，你真正理解了吗？工作了4年，很多东西还没一个大学生理解的深刻，我好混乱

Answer 1

这个东西没什么死规定，老师有老师的道理，你有你的道理，很多模型在实际操作中，都会更改，除非你在又开始，就把方方面面想的非常完美
如果user类是所有用户的基类，而且必须通过login才能登陆的话，老师的做法未尝不可

Answer 2

login是user的一个行为，老师的做法未尝不可，个人看法，我也正学习这方面的知识。哈哈

Answer 3

根据实际情况来吧。
 对于user 继承于 人 这种思路， 局限了当前系统的所有user必须是“人”。
如果将“人”作为user一个属性， 就适用于User不一定是“人”的情况。所以我觉得你们老师考虑的是系统能更好扩展的问题。一个是继承关系，一个是组合关系。 user由人来组合的时候，它的范围更广泛些。对于login方法而言，在分析阶段确实可以放在user上面，“不要考虑如何实现”，分析阶段的视角跟实现阶段是不同的。个人认为。 实现阶段就不会放到user了，user到实现阶段就是个实体类，而login方法会存在于某个接口或者服务中。

Answer 4

个人理解首先我想说的是你的Login 应该是做成一个接口的
因为可能以后别的地方要用Login，也可能因为其他的原因，反正Login是不应该写到哪一个固定的类里
不知道你是否同意我的观点呢？  如果同意往下看其次你的Login正常应该是  Login(userName,passWord)
那么User类 他肯定会有一个登陆的动作，用户嘛，如果他不用登陆何来的个人信息呢？
所以你应该在User类里加一个Login的方法，而他这个方法实现的就是之前写好的接口内提供的Login Method
简化的来说就是 有一个统一实现方法的接口，其他类调用的是这个接口，而调用这个接口的地方也要想好
不能到处都调，因为登陆只可能存在于User里的动作，目前看应该是。。

Answer 5

我到现在没理解 你的老师让你把Login的实现方法写到User里，所以你才反对的？
还是你的老师说User里应该实现一个Login你反对？如果是前者，我觉得你应该据理力争一下，每个人想法不同，写到外面可能以后还有用处，也可能修改针对数据库访问的方法时便于查询等等因素吧
如果是后者，我觉得老师的观点是正确的

Answer 6

老师的意思login放到user类上， 或者user类上面多一个Account属性，包括 username password 和 login方法，原因是login上用到user类的属性最多，所以应该放在 user类上（谁的属性多，谁的数据全就放到谁上面，分析的时候不要考虑如何实现）
这点老师说的很对，你可以模仿测试用例一样
Class User
{
    public .... Login()
    {
         Interface.Login(_username,_password);
    }
}这样省得你到处去找用户名，密码等信息
你只要走到哪里带着User类就好了，其他的你就不用操心了，这个观点非常正确

Answer 7

人和人的理解不一样，可能产生不同的设计思想，不要太在意，只要能完成公司的业务需求，就是好的设计。
例如：用户可能不是一个人，而是一个企业，那么我们就不能继承自Person，但用户一定要有个联系人，所以应该有个person。这样就解决的企业用户和个人用户的矛盾。

Answer 8

Login(userName,passWord) 其实这已经可以说不是面向对象了 呵呵，我们的缺点就是把技术和实现看得太重要了，往往分析事务的本质才是最重要的

Answer 9

呵呵，就是考虑数据迁移，复用的原因才会这么复杂的，你想，万一我另一个程序的数据存储结构不一样，或者登录逻辑不一样，那么user 上面写一个 login方法可能就不好了我其实基本理解了，分析的时候  login应该是属于user的一个方法，但是具体实现的时候，不一定要写在user上面，最好也不写到user上面，需求就是需求，不管怎么实现

Answer 10

工作4年了， 应该从你的工作总结了一套好的方法，
不管怎样分层还是为工作或者团队工作更方便，更有利对象化，模块化。
何必太拘谨于，框架里的类。
再说 他们那个年代 面向对象 概念比较模糊（oop）

Answer 11

login方法写在接口中合适，我的观点

Answer 12

user继承人基类，还是用人这个对象，还是根据项目的扩展性来定

Answer 13

其实看个人用法,也不用说服别人,自己觉得好用并且符合oo原则就好了
定义user是人,而且是一对一聚合
我个人有个想法,不能一个人有多个帐户吗??

Answer 14

。看需求，我们上一个公司的设计模式是一个Account对多个User

Answer 15

1 关于User与Person，我倾向于使用基本属性，
根据职责明确，职责单一的原则，Person用于人员的基本信息，属于不经常修改的内容，修改人员为管理人员，包括添加人员、修改人员基本信息，删除人员基本信息。
User用于用户的信息，包括登录信息，包括用户名、密码，这个是由用户自己更改的。
用户的操作，这个与用户是一对多的关系，应该另外有实体。
2 没有太明白

Answer 16

不习惯把login放在user中
 user类一般用做实体类，业务逻辑不放在此层。
他就放属性和get set方法

Answer 17

我也基本是都是这么用的，user只是个实体类