OOP问题---从理论上讲...... [英] OOP question --- theoretically speaking....
问题描述
大家好，
我已经确定这个OOP不仅仅是一种时尚。考虑到
，我绝望地试图摆脱我的
面向功能的设计范例并切换到更多
以物体为中心的世界观。迁移某些方面
我过时的风格一直很简单。例如：
我曾经这样做过：
< old style> ------------ ------------
公共类小部件（）
{
public string property1;
public string property2;
}
....在Datahandler中的某处class：
public Widget fetchWidget（int widgetid）
{
Widget w = new Widget（）;
....做一些数据库探险......
w.property1 = ....
w.property2 = ... 。
返回w;
}
< / old style> ----------- ----------------
但现在我这样做
< new style> ----------------------------
公共类小工具（）
{
private string _property1;
{
set
{... etc.
私人字符串_property2;
{
set
{... etc.
public Widget（）{}
public Widget（int widgetid）
{
this.fetchMe（widgetid）;
}
private void fetchMe（int widgetid）
{
....做一些数据库洞察......
.... poulate内部变种。 ...
}
}
< / new style> ----------- ---------------
但是小部件的集合呢？
继续上面的第一个例子。在相同的Datahanders
类中，我曾经有过如下方法：
< old style> -------- -------------------------------------------------
public ArrayList callingAllWidgets（）
{
ArrayList widgets = new ArrayList（）;
。 ......数据库探险......
foreach（无论如何）
{
Widget w = new Widget（）;
w.property1 = ...等
...
widgets.Add（w）;
}
返回小部件;
}
< / old style> -------------------------------------------------- -----
显然，我没有理由不使用相同的设计使用
更新版本（新版本）样式小部件，即：
public ArrayList callingAllWidgets（）
{
ArrayList widgets = new ArrayList（）;
....数据库探险....
foreach（无论如何）
{
Widget w =新的小部件（foreachvalue）;
小部件。添加（w）;
}
返回小部件;
}
但这似乎是作弊;）是否有更好的，更普遍的b $ b接受的超级方式？我应该使用索引器使用相应的集合
类吗？我应该创建一些加强IList
实现吗？我当然可以看到一个专门提供一些聚合器的类的好处（即添加所有小部件
property1值），但这并不总是必要的。 br />
提前致谢..
" See_Rock_City" <关于** @ asdf.com> écritdansle message de news：
MP ************************ @ news.giganews.com ......
我已经确定这个OOP不仅仅是一种时尚。
它经受了大约30年的考验:-)）
< new style> ----------- -----------------
公共课小工具（）
{
私人字符串_property1;
{
设置
{...等
私人字符串_property2;
{
设置
{...等
public Widget（）{}
public Widget（int widgetid）
{
this.fetchMe（widgetid）;
}
private void fetchMe（int widgetid）
{
....做一些数据库探险......
.... poulate内部变量。 ...
}
}
< / new style> ----------------------- ---
我们中的一些人认为将数据库代码放入企业
对象并不是非常OO。这样做意味着，如果你改变了数据库访问组件，你必须重新编写你的类。
它确实更好，更有益于有一个单独的数据层，
知道如何读/写对象（可能使用反射），因此
允许你在不知道
您正在使用的数据库。
但是小部件集合呢？
显然，没有理由我不能使用相同的设计使用
更新版本（新风格）的小部件，即：
公开ArrayList callingAllWidgets（）
{ArrayList widgets = new ArrayList（）;
....数据库探险....
foreach（无论如何）
{
widgets.Add（w）;
返回小部件;
}
但这似乎是作弊;）是否有更好的，更普遍接受的超级方式？我应该使用与Indexer相应的集合
类吗？我应该创建一些加强IList
实现吗？我当然可以看到专门提供一些聚合器（即添加所有Widgets
property1值）的类的好处，但这并不总是必要的。
你永远不应该派生或使用ArrayList或任何其他通用列表
class。相反，您需要创建类型安全列表类，它们只知道如何操作（例如）小部件。当然你会在这个类中使用类似
ArrayList的东西，但这是你必须从对象投射到Widget再返回的唯一地方。
同样的原则适用于单个对象的列表;尝试从业务概念中分离出数据库代码。但是你可能希望通过委托到内部列表来实现IList，以允许数据
机制返回/操作一个通用列表类型
与数据库接口的简化机制（对象持久性
框架）将有如下界面：
class ObjectBroker
{
bool StoreObject（object obj）;
bool DeleteObject（object obj）;
bool RetrieveObject（object obj）;
IList RetrieveForType（类型类型）;
}
Joanna
- -
Joanna Carter
顾问软件工程师
Joanna，
它已经经受了大约30年的考验： - ））
但是几乎同时存在所谓的关系数据库
对我来说似乎是基于穿孔卡的方法而且无法在一个人中使用
保存列表结构的一种方法。
之前用数据库的东西很容易做到。
因此其中一个对我来说是错误的。 （我的意见关系
数据库）。
只是我的想法，
Cor
在文章< #p ************** @ TK2MSFTNGP14.phx.gbl>中，
jo ***** @ nospamforme.com 说...
嘿乔安娜，谢谢你的回复！
< snip>
我们中的一些人认为将数据库代码放入业务对象并不是真的非常OO。这样做意味着，如果您更改了数据库访问组件，您必须重新重写您的类。
拥有一个单独的数据层确实更好，更有益知道如何读取/写入对象（可能使用反射），从而允许您在不知道正在使用的数据库的情况下编写业务对象。
这个，我完全同意。事实上，这总是一个很大的问题
在我的脑海里。将bl层与数据
层混合起来感觉不对。我很高兴听到你说这个;）
< snip>
你永远不应该派生或使用ArrayList或任何其他通用列表<课程。
我假设你的意思是不要继承任何内在的
集合实现？
相反，你需要创建类型安全列表类，只知道如何操作（例如）小部件。当然你会在这个类中使用类似
ArrayList的东西，但这是你必须从对象转换到Widget并再次返回的地方。
同样的原则appplies列出单个对象;尝试将数据库代码与业务概念分开。但你可能希望通过委托实现IList到内部列表，以允许数据
机制返回/操作常见的列表类型
我有（在过去）创建的类只是包装一个私有的
ArrayList并实现IList，以便它们与调用客户端习惯的
标准集合命名兼容。 />
这样，我可以添加特定于类的方法等等等等。
一个与数据库接口的简化机制（Object Persistence
Framework）会有这样的接口：
类ObjectBroker
{boo StoreObject（object obj）;
bool DeleteObject（object obj）;
bool RetrieveObject（object obj）;
IList RetrieveForType（类型类型）;
}
雅'在这里迷失了我很尴尬地说。
Joanna
-
Joanna Carter
顾问软件工程师
Hello All,
I''ve decided that this OOP thing is not just a fad. With
that in mind, I''m desparately trying to get rid of my
function-oriented design paradigm and switch to a more
object-centric view of the world. Migrating some aspects
of my antiquated style has been straight-forward. For example:
I used to do this:
<old style>------------------------
public class Widget()
{
public string property1;
public string property2;
}
.... Somewhere in a "Datahandler" class:
public Widget fetchWidget(int widgetid)
{
Widget w = new Widget();
.... do some database spelunking...
w.property1=....
w.property2=....
return w;
}
</old style>---------------------------
But now I do this
<new style>----------------------------
public class Widget()
{
private string _property1;
{
set
{ ... etc.
private string _property2;
{
set
{ ... etc.
public Widget(){}
public Widget(int widgetid)
{
this.fetchMe(widgetid);
}
private void fetchMe(int widgetid)
{
.... do some database spelunking...
.... poulate internal vars. ...
}
}
</new style>--------------------------
But what about collections of Widgets?
Continuing on from the first example above. In the same "Datahanders"
class, I used to have a method like:
<old style>---------------------------------------------------------
public ArrayList callingAllWidgets()
{
ArrayList widgets = new ArrayList();
.... database spelunking....
foreach (whatever)
{
Widget w = new Widget();
w.property1=... etc.
...
widgets.Add(w);
}
return widgets;
}
</old style> -------------------------------------------------------
Obviously, there''s no reason I couldn''t use the same design using the
more updated version (the new style) of a widget, i.e:
public ArrayList callingAllWidgets()
{
ArrayList widgets = new ArrayList();
.... database spelunking....
foreach (whatever)
{
Widget w = new Widget(foreachvalue);
widgets.Add(w);
}
return widgets;
}
but this seems like cheating ;) Is there a better, more universally
accepted superterrific way? Should i use a corresponding collections
class with an Indexer? Should I create some souped up IList
implemenation? I could certainly see the benefit of a class that
specialized in providing some aggregators (i.e. add all the Widgets
property1 values) but this isn''t always necessary.
Thanks in advance..
"See_Rock_City" <as**@asdf.com> a écrit dans le message de news:
MP************************@news.giganews.com...
I''ve decided that this OOP thing is not just a fad.
Well it has stood the test of about 30 years :-))
<new style>----------------------------
public class Widget()
{
private string _property1;
{
set
{ ... etc.
private string _property2;
{
set
{ ... etc.
public Widget(){}
public Widget(int widgetid)
{
this.fetchMe(widgetid);
}
private void fetchMe(int widgetid)
{
.... do some database spelunking...
.... poulate internal vars. ...
}
}
</new style>--------------------------
There are some of us who feel that putting database code into a business
object is not really very OO. Doing this means that, should you change
database access components, you have to rewrite your class all over again.
It really is better and more beneficial to have a separate data layer that
knows how to read/write your objects (possibly using reflection), thereby
allowing you to program business objects without any knowledge of the
database you are using.
But what about collections of Widgets? Obviously, there''s no reason I couldn''t use the same design using the
more updated version (the new style) of a widget, i.e:
public ArrayList callingAllWidgets()
{
ArrayList widgets = new ArrayList();
.... database spelunking....
foreach (whatever)
{
Widget w = new Widget(foreachvalue);
widgets.Add(w);
}
return widgets;
}
but this seems like cheating ;) Is there a better, more universally
accepted superterrific way? Should i use a corresponding collections
class with an Indexer? Should I create some souped up IList
implemenation? I could certainly see the benefit of a class that
specialized in providing some aggregators (i.e. add all the Widgets
property1 values) but this isn''t always necessary.
You should never derive from or use ArrayList or any other general list
class. Instead you need to create typesafe list classes that only know how
to manipulate (e.g.) Widgets. Of course you would use something like
ArrayList inside this class but that is the only place you would have to
cast from object to Widget and back again.
The same principle appplies to lists as to single objects; try to separate
out the database code from the business concepts. But you would possibly
want to implement IList by delegation to the internal list to allow a data
mechanism to return/manipulate a common list type
A simplified mechanism to interface with databases (Object Persistence
Framework) would have an interface like this :
class ObjectBroker
{
bool StoreObject(object obj);
bool DeleteObject(object obj);
bool RetrieveObject(object obj);
IList RetrieveForType(Type type);
}
Joanna
--
Joanna Carter
Consultant Software Engineer
Joanna,
Well it has stood the test of about 30 years :-))
However almost the same time exist the so called relational databases which
for me seems to been build on punchcard methods and are unable in a one to
one way to hold a list structure. Something which was with databases before
that time very easy to do.
Therefore one of those is for me wrong. (My opinion the relational
database).
Just my thought,
Cor
In article <#p**************@TK2MSFTNGP14.phx.gbl>,
jo*****@nospamforme.com says...
Hey Joanna, thanks for the reply!
<snip>
There are some of us who feel that putting database code into a business
object is not really very OO. Doing this means that, should you change
database access components, you have to rewrite your class all over again.
It really is better and more beneficial to have a separate data layer that
knows how to read/write your objects (possibly using reflection), thereby
allowing you to program business objects without any knowledge of the
database you are using.
This, I agree with completely. In fact, this was always a big question
in my mind. It doesn''t feel right mixing the bl layer with the data
layer. I''m glad to hear you say this ;)
<snip>
You should never derive from or use ArrayList or any other general list
class.
By this I''m assuming you mean simply not to inherit from any intrinsic
collection implementation?
Instead you need to create typesafe list classes that only know how
to manipulate (e.g.) Widgets. Of course you would use something like
ArrayList inside this class but that is the only place you would have to
cast from object to Widget and back again.
The same principle appplies to lists as to single objects; try to separate
out the database code from the business concepts. But you would possibly
want to implement IList by delegation to the internal list to allow a data
mechanism to return/manipulate a common list type
I have (in the past) created classes that simply wrap a private
ArrayList and implement IList so that they are compatible with the
standard collections nomenclature calling clients would be used to.
This way, I can add class-specific methods blah blah blah.
A simplified mechanism to interface with databases (Object Persistence
Framework) would have an interface like this :
class ObjectBroker
{
bool StoreObject(object obj);
bool DeleteObject(object obj);
bool RetrieveObject(object obj);
IList RetrieveForType(Type type);
}
Ya'' lost me here I''m embarrassed to say.
Joanna
--
Joanna Carter
Consultant Software Engineer
这篇关于OOP问题---从理论上讲......的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
