OO设计问题 [英] OO Design question

问题描述

Hello All，


请帮助验证此设计问题


假设我的项目中有多个实体（例如供应商，

客户等）。

所有这些都保存了几个常见的属性 - 名称，地址，城市，

州，邮政编码等


我想创建一个基类 - BusinessEntity（包含所有

以上的属性）

然后，创建派生自的基于类的供应商/客户类BusinessEntity

&有自己的专业行为。


这种方法有效吗？


此外，一个类可以仅仅基于共同的基础上制作基类

数据，它可以容纳？

在我的例子中，

供应商没有重复点（名称，地址......） ，客户

因此，我想用所有上述属性创建BusinessEntity

因此，只有数据和基数的基类是否有效？没有行为

（方法）？

我很想听到支持/反对上述方法的论据


干杯< br $>
Kalpesh

解决方案

是的，我会说'有效..而且有上周发布了一个很好的帖子

这个例子（虽然我找不到它）..你可以/应该打破它

甚至更进一步：


让供应商和客户继承BusinessEntity ..


和BusinessEntity有几个成员，如：


public PhoneEntry MainPhone = new PhoneEntry（）;

public PhoneEntry MainFax = new PhoneEntry（）;

public PhoneEntry TollFreePhone = new PhoneEntry（）;


public联系方式MainContact = new联系方式（）;

public联系方式SalesContact = new联系方式（）;

public联系SupportContact = new联系方式（） ;


而PhoneEntry可能会像Entry一样姓名，号码，号码格式 - 联系

可以有姓名，地址，也许还有几个PhoneEntry持有

家庭电话，商务，移动，传真等的字段。


所以是的，将任何重复功能分解成是一件好事它是

自己的班级.. HTH


" Kalpesh" < SH ********* @ gmail.com>在消息中写道

news：11 ********************* @ f14g2000cwb.googlegro ups.com ...

大家好，

请帮助验证这个设计问题

假设我的项目中有多个实体（例如供应商，客户等）。<所有这些都保存了几个常见的属性 - 名称，地址，城市，状态，邮政编码等

我想创建一个基类 - BusinessEntity（包含所有的
以上属性）
然后，创建源自BusinessEntity的供应商/客户类
&有自己的专业行为。

这种方法有效吗？

此外，一个类可以完全基于常见的数据制作基类，它可以举行吗？
在我的例子中，供应商，客户没有重复点（名称，地址......）因此，我想到创建具有上述所有属性的BusinessEntity

那么，只有数据和基数的基类是否有效？没有行为
（方法）？
我很想听到支持/反对上述方法的论据

干杯
Kalpesh

" Kalpesh" < SH ********* @ gmail.com> écritdansle message de news：
11 *********************@f14g2000cwb.googlegroups.c om ...


|那么，只有数据和基数的基类是否有效？没有行为

| （方法）？


它有时候是有效的，但是不要练习它:-)


Joanna


-

Joanna Carter [TeamB]

顾问软件工程师

>另外，一个类是否可以仅基于它可以容纳的常见数据而成为基类？


这并不是设计类层次结构的好方法。这是大多数人开始使用的方式，就像大多数正在学习的人一样，程序编程将代码分解为单独的函数

在多个地方使用时。不过，过了一段时间，一个

倾向于采用更复杂的类层次结构设计视图。


你创建一个BusinessEntity类的想法是不是糟糕的一个...我只是

认为有更好的理由这样做比一些

的东西共享数据。


对我而言，重要的一点是，供应商和客户分享现实世界中的一些共同特质，而不仅仅是存储在里面的数据。电脑。作为一家企业，我可以购买（或出售给）一个（非法人）个人或公司。我还可以从个人或公司签订合同

服务。事实上，我可以与（外部）个人和

公司有很多关系，并且在某些方面它们是可以互换的（在真实的

world），所以在我的班级层次结构中的某个地方我有理由认为
会有一个代表通用外部的类

person / corporation我正以某种身份进行交易（作为一个

供应商，一个客户或一个承包商，或者可能是这些的一些组合

）。


所以，简单的类设计可能就是你提出的建议：有一个

BusinessEntity（我公司以外的某个人或公司）和

供应商和客户都是BusinessEntity。


那么说，你能看到在一个非常庞大的系统中，事情会如何迅速变得更加复杂吗？ />

例如，假设作为个人的客户，或者非公司b $ b的客户，可能会有那些

的客户是公司的复杂信息，所以现在你有IndividualCustomer和

CorporateCustomer。那很好......他们是客户的子类。但是

那么也许你也有个人供应商和企业供应商，

也许你有一个客户也是供应商。怎么办？你有
你有一个CorporateCustomer对象和一个企业供应商对象

真的代表同一家公司吗？你的班级等级不再是

代表现实和以前一样。


我没有一个方便的班级设计我的袖子。 ..我想要的全部

要指出的是，最终它应该是现实世界的关注，应该是b
决定你的班级等级。而什么数据存储在哪里和

类有什么共同的数据可能是有用的问题，指导

你专注于现实世界的问题，这是真正的世界，实际上是

的底线。


例如，仅仅因为客户和供应商共享一个地址并且

电话号码并不一定意味着它们应该来自

相同的基数类。在这种情况下，这似乎是一个好主意，但SalesOffice，

一个代表你自己公司某些部分的对象，可能不是一个好的候选人，可以从中继承基础类作为客户和

供应商。也许SalesOffice的一个更好的解决方案是创建一个名为PhysicalLocation的

类，它又包含一个Address对象

和一个ContactInfo对象，它们也是
BusinessEntity。继承并不是分享信息的唯一途径。

Hello All,

Please help validate this design problem

Assume that I have several entities in my project (eg Supplier,
Customer etc).
All of them save several common properties - name, address, city,
state, zipcode etc

I thought of making a base class - BusinessEntity (with all of the
above properties)
Then, create Supplier/Customer class which derives from BusinessEntity
& have their own specialized behaviour.

Is this approach valid ?

Also, can a class be made base class solely on the basis of common
data, that it can hold ?
In my example, there is no point repeating (name, address...) in
Supplier, Customer
Hence, I think of creating BusinessEntity with all the above properties
So, is it valid to have base class with only data & no behaviour
(methods) ?
I would love to hear arguments in favour/against of the above approach

Cheers
Kalpesh

解决方案

Yes, I''d say that''s valid.. and there was a good posting last week that had
an example of this (although I couldn''t find it).. You could/should break it
down even further:

Have Supplier and Customer inherit from BusinessEntity..

And BusinessEntity has several members, something like:

public PhoneEntry MainPhone = new PhoneEntry();
public PhoneEntry MainFax = new PhoneEntry();
public PhoneEntry TollFreePhone = new PhoneEntry();

public Contact MainContact = new Contact();
public Contact SalesContact = new Contact();
public Contact SupportContact = new Contact();

And PhoneEntry could have like EntryName, Number, NumberFormatted - Contact
could have Name, Address, and perhaps several "PhoneEntry" fields that hold
homephone, business, mobile, fax, etc..

So yes, it''s a good thing to break up any repeating functionality into it''s
own class.. HTH

"Kalpesh" <sh*********@gmail.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...

Hello All,

Please help validate this design problem

Assume that I have several entities in my project (eg Supplier,
Customer etc).
All of them save several common properties - name, address, city,
state, zipcode etc

I thought of making a base class - BusinessEntity (with all of the
above properties)
Then, create Supplier/Customer class which derives from BusinessEntity
& have their own specialized behaviour.

Is this approach valid ?

Also, can a class be made base class solely on the basis of common
data, that it can hold ?
In my example, there is no point repeating (name, address...) in
Supplier, Customer
Hence, I think of creating BusinessEntity with all the above properties
So, is it valid to have base class with only data & no behaviour
(methods) ?
I would love to hear arguments in favour/against of the above approach

Cheers
Kalpesh

"Kalpesh" <sh*********@gmail.com> a écrit dans le message de news:
11*********************@f14g2000cwb.googlegroups.c om...

| So, is it valid to have base class with only data & no behaviour
| (methods) ?

It is valid, sometimes, but don''t make a practice of it :-)

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

> Also, can a class be made base class solely on the basis of common data that it can hold ?

That''s not really a good way to design your class hierarchy. It''s the
way that most people start out, just as most people who were learning
procedural programming split code out into a separate function only
when it was used in more than one place. After a while, though, one
tends to adopt a more sophisticated view of class hierarchy design.

Your idea of creating a BusinessEntity class isn''t a bad one... I just
think that there are better reasons for doing it than that a couple of
things share data.

For me the important point here is that Supplier and Customer share
some common qualities in the real world, not just in the data that''s
stored inside the computer. As a business, I can buy from (or sell to)
an (unincorporated) individual or a corporation. I can also contract
services from an individual or a corporation. In fact, there are lots
of relationships that I can have with (external) individuals and
corporations, and in some ways they''re interchangeable (in the real
world), and so it makes sense that somewhere in my class hierarchy I
would have a class that represents a generic external
person/corporation with which I''m dealing in some capacity (as a
supplier, a customer, or a contractor, or maybe some combination of
these).

So, a simple class design might be what you proposed: that there is a
BusinessEntity (some person or corporation external to my company) and
that Suppliers and Customers are BusinessEntitys.

That said, can you see how in a very large system things could quickly
become more complicated?

For example, it''s fair to assume that Customers who are individuals, or
unincorporated, might have less complex information that Customers who
are corporations, so now you have IndividualCustomer and
CorporateCustomer. That''s fine... they''re subclasses of Customer. But
then perhaps you have IndividualSuppliers and CorporateSuppliers too,
and perhaps you have a customer who is also a supplier. Now what? Do
you have a CorporateCustomer object and a CorporateSupplier object that
really represent the same corporation? Your class hierarchy no longer
represents reality as well as it once did.

I don''t have a handy class design up my sleeve for this... all I wanted
to point out is that in the end it''s real-world concerns that should
dictate your class hierarchy. While "what data is stored where" and
"what data do classes have in common" may be useful questions to direct
your focus on real-world issues, it''s the real world that is really the
bottom line.

For example, just because Customer and Supplier share an address and
phone number doesn''t necessarily mean that they should derive from the
same base class. In this case, it seems a good idea, but SalesOffice,
an object representing some part of your own company, might not be a
good candidate for inheritance from the same base class as Customer and
Supplier. Perhaps a better solution with SalesOffice is to create a
class called PhysicalLocation, which in turn contains an Address object
and a ContactInfo object, which are also objects used in
BusinessEntity. Inheritance isn''t the only way to share information.

这篇关于OO设计问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！