到底传什么样的对象才算是‘好对象’呢？

[软剑攻城狮]

代码看的多，却写的不够，每次写的时候都会发现些傻傻的问题，就像这个一样。
为了面向对象，那么增加这么一个账单条目的对象到底意义多大？


感觉这样写确实是对的 只不过对‘对象’这个词的定义到底是什么
一开始就是直接把字段全部放在了账单里，但结果发现创建账单的时候要写很多东西进来
就像这样子：
public void AddMainBill(Customer customer, User user, Project project)
于是又重新写了一个条目对象
然后才变成了这样子：
public void AddMainBill(BillItem item)
其实疑惑的地方就是还是一样写了这么多代码，甚至还多创建了一个对象，那直接传项目，用户，客户这些对象不也是对象吗？
到底传什么样的对象才算是‘好对象’呢？

一开始比较傻的：

public class MainBill : Entity<MainBill>
    {
        public virtual string RunninNumber { get; set; }

        public virtual string CustomerName { get; set; }

        public virtual string Payee { get; set; }

        public virtual string ProjectName { get; set; }

        public virtual decimal ProjectPrice { get; set; }

        public void AddMainbill(Project project,User user,Customer customer)
        {
            CustomerName = customer.Name;
            Payee = user.Name;
            ProjectName = project.Name;
            ProjectPrice = project.Price;
        }

    }

之后改进了一点：

public class MainBill : Entity<MainBill>
    {
        public MainBill()
        {
            BillItems = new List<BillItem>();
        }

        /// <summary>
        /// 流水号
        /// </summary>
        public virtual string RunninNumber { get; set; }

        public virtual BillItem BillItem { get; set; }

        public virtual IList<BillItem> BillItems { get; set; } 


        public void AddMainBill(BillItem item)
        {
            BillItems.Add(item);
            AddBillItem();
        }

        public void AddBillItem()
        {
            foreach (var item in BillItems)
            {
                BillItem = item;
            }
        }
    }

代码写的比较丑，不好意思了。。

[threenewbee]

取决于你的业务逻辑。

你的业务逻辑到底想表达什么意思，一个帐单有很多条目，每个条目对应一个项目，一个用户，一个客户，还是一个帐单对应一个项目，一个用户，一个客户，还是一个帐单对应多个项目、用户、客户，但是这三者本身之间没有对应关系。你的业务逻辑决定了你怎么设计。

你的代码让人费解。

[以专业开发人员为伍]

[Quote=引用楼主 的回复:]
其实疑惑的地方就是还是一样写了这么多代码，甚至还多创建了一个对象，那直接传项目，用户，客户这些对象不也是对象吗？[/Quote]
设计，关心的是“成熟、自然”的问题，而不是“是不是多写了几个字符”这类貌似技术（实则不自然）的问题。比如说你跟别人沟通，你是用“账单”这个词儿就直截了当地沟通了，还是要每一次都解释一下账单的定义？

一个设计的结果，既可以给计算机使用，也可以给人使用。特别是，那些根本不懂软件为何物的普通人，比许多程序员更懂得面向对象的设计——只不过他们不会使用软件设计的语言来表达罢了。

如果人们都“自然而然地”用一个词儿沟通了，那么就说明我们需要创建一个对象（类）来反映这个词儿。这哪里是由你“写代码的多少”来决定的？

[以专业开发人员为伍]

在你写代码时，你既可以写
public void AddMainBill(Customer customer, User user, Project project)
也可以写
public void AddMainBill(BillItem item)
更可以二者都写。

但是关键是“主账单是否包含账单明细”呢？如果是，那么就存在BillItem这种东西，你总之是需要为一种“组合了Customer、User、Project三类东西的新东西定义一个对象（类）。

其实这不叫做“面向对象”，这充其量是“基于对象”。它是结构化的。如果你连结构化设计都不接受，想去应用“继承、多态”式的面向对象设计就更困难了。

[stonespace]

你这些对象都是好的对象，其实都是很简单的对象，这些对象对应实体，都是“实体类”，即使是BillItem也是实体类，账单条目也是一个实体，

对象设计一个原则是容易理解，最容易理解的方式就是有什么实体定义什么类，一个类对应一个实体，实体类当然是好的类，当然这样会让程序稍显麻烦，要多写一些代码，不过能达到容易理解的目的，多写代码也是值得的，

BillItem这个实体类绝对值得写，其实不光是在AddMainBill中用到，以后查询的时候也会用到，你总不能查出的结果都用属性来表示，比如查询一个条目的时候，返回一堆Customer , User , Project 这样很乱，而且你要查的是账单条目，又不是Customer , User , Project ，账单条目不等于Customer , User , Project ，也许需要其他属性，你总不能查询的时候要返回所有属性，这样很难维护，

[stonespace]

关键问题是：账单条目不等于Customer + User +Project，你想想，在你的概念中，账单条目应该包含的内容远多于Customer + User +Project，所以你不能用Customer + User +Project代表账单条目，既然账单条目是一个独立的概念，应该有一个类和它对应，否则你以后维护很困难，理解也困难，不光是AddMainBill的问题，

或者你应该加入一个方法：

class BillItem
{
public void CreateBillItem(Customer customer, User user, Project project);
}

[卓一航啊]

不想当将军的对象不是好对象