本文介绍了设计决策:Order类中的OrderNumber属性 - Public或Private?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在建立一个订购系统。在这里我有一个订单类,它有一个名为 OrderNumber 的属性。如你所知, OrderNumber 只能分配一次,所以我不想让它 public (所以我使其私人)。



然而,订单号是根据存储在数据库。
例如,数据库中的值为10,现在我订购一个订单号,订单号将为$ code> Year-Month-10 ,值将增加到11.该值将每月重置。



您可以看到,订单号生成具有对数据库即可。如果我使 OrderNumber private ,我只能在订单中调用生成订单号码方法 class(可能在构造函数中),这不是很好,难以进行单元测试。而且,我不想在订单类中使用任何 ServiceLocator ,我认为这是 / strong>



如果我订购订单号 public ,上述问题可以解决。但是订单编号现在可能会被一些编码者的错误所改变,因此不安全



所以,我可以让 OrderNumber property public?你的理由?



更新:



感谢Yahia给我一个暗示。
现在我考虑使OrderNumber属性只读,并将生成器(例如IOrderNumberGenerator)传递给Order类的构造函数。



但还有另一个问题:
在我的senario中,当Order对象被创建时,订单号是不是。客户可以创建并保存订单,而不会将订单传递到订单验证器。
所以在订单被传递给订单验证者之前,订单号不被分配。 OrderNumber仅在客户点击请求订单验证按钮时分配,然后无法再次更改OrderNumber。工作流程转到下一步(订单验证)。



我创建了一个新问题,请看这里:



BTW :我正在使用C#



谢谢!

解决方案

我建议拥有一个公共只读属性 OrderNumber (即使设置 private)基于一个私人领域...这给了你两方的好处,没有任何消极的方面。



你应该考虑的事情:



您所描述的案例通常通过实现Factory模式来解决...



编辑 - 关于更新的OP:



创建一个类 OrderNumber 并将其作为公共属性放入订单类。
OrderNumber类只有私有构造函数,只能通过Factory模式创建。



因此, code>订单最初已将 null 分配给 OrderNumber 属性...该属性具有一个私有集方法,只有当内部字段为 null ...才能分配 OrderNumber 您有一个状态属性,当更改为订单验证调用保存的引用 IOrderNumberGenerator (从构造函数),并设置 OrderNumber 一次...


I'm building an ordering system. And here I have an Order class, which has a property named OrderNumber. As you know, OrderNumber can only be assigned once, so I don't want to make it public (so I made it private).

However, the order number is generated according to a sequencial value stored in database.For example, the value in database is 10, now I genearte an order number, the order number will be "Year-Month-10", and the value will increase to 11. The value will be reset every month.

You see, the order number generation has a dependency to database. If I make OrderNumber private, I can only call the generate order number method in the Order class (maybe in the constructor), that's not good and hard to do unit testing. And, I don't want to use any ServiceLocator in the Order class, I think it's bad too.

If I make the order number public, the problems above can be resolved. But the order number might be changed by some coders' mistake now, it's not safe.

So, can I make the OrderNumber property public? And your reasons?

Updates:

Thanks to Yahia for giving me a hint. Now I consider making OrderNumber property readonly, and pass the generator (e.g. IOrderNumberGenerator) to the constructor of the Order class.

But there's another problem: In my senario, the order number is not assigned when the Order object is created. The customer can create and save an order without passing the order to the order verifier. So before the order is passed to the order verifier, the order number is not assigned. OrderNumber is assigned only when the customer click the "Request Order Verification" button, and then the OrderNumber cannot be changed again. And the workflow moves to the next step (Order Verification).

I've created a new question, please look here: Design Decision: Generate OrderNumber which depends on a database value

BTW: I'm using C#

Thanks!

解决方案

I would recommend having a public readonly property OrderNumber (i.e. make set private) based on a private field... this gives you the benefits of both without any negative aspects.

Something you should consider:

Cases like the ones you describe are usually solved by implementing the Factory pattern...

EDIT - regarding the update of the OP:

Make a class OrderNumber and put it as a public property into your Order class.The OrderNumber class has only private constructor and is only created via Factory pattern.

Thus your Order has initially null assigned to the OrderNumber property... this property has a private set method which only allows assignment when the internal field is null... to assign an OrderNumber you have for example a Status property which when changed to Order Verification calls the saved reference to IOrderNumberGenerator (from the constructor) and set the OrderNumber once...

这篇关于设计决策:Order类中的OrderNumber属性 - Public或Private?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

09-22 16:20