设计意见要求 [英] design opinions requested
问题描述
我有设计意见。我有3个型号，我不会特别喜欢它们的b $ b，所以也许有人可以建议或帮助证明。
我有一套基本无关的课程（约6）。
class Foo;
class Bar;
class Bat;
我有一个容器类，它包含许多其他类
和其他元数据：
class Stuff {
public：
vector< pair< string，Foo * foos;
vector< pair< string，Bar * bars;
vector< pair< string Bat * bats;
}
所以这就是问题所在。我需要将一些不相关的类存储在一个有点相关的
中。我需要在插入
顺序中对它们进行排序，以便以后检索。我的意思是，后来，我需要以某种方式走出容器，然后将Foo，Bars和Bats拉出来，
彼此混合，顺序他们被插入了。
所以，我已经设想了三个答案，其中没有一个我真的很喜欢。
1）建立一个通用的基础class，Stuff_Item，它是
Foo，Bar，Bat等的基类。将所有Foo，Bar，Bat存储在一个向量中。
Stuff_Item :: stuff_type （）返回并枚举调用者使用
确定所持事物的类型。然后调用者向上投射。
2）创建一个通用基类Stuff_Item，它不是基类，
，它有方法stuff_type（）和stuff_index（）。 stuff_type
返回一个枚举，调用者用它来确定物品的类型
持有。 stuff_index将索引（或迭代器）返回到type-
特定向量中。保持Stuff_Items的单独向量。来电者可以
然后将其用作（数据库式）索引。
3）制作一个Stuff :: Item内部类，其中包含一个枚举指向
Foo，Bar，Bat ..内部类暴露了is_foo（），is_bar（），is_bat（）
方法和get_foo（），get_bar（） ，get_bat（）方法。只需存储一个
矢量Stuff :: Item。
虽然，理由，其他想法？
谢谢。
Tim
6月3日19:56，Tim H< thoc .. 。@ gmail.comwrote：
我有设计意见。我有3个型号，我不会特别喜欢它们的b $ b，所以也许有人可以建议或帮助证明。
我有一套基本无关的课程（约6）。
class Foo;
class Bar;
class Bat;
我有一个容器类，它包含许多其他类
和其他元数据：
class Stuff {
public：
vector< pair< string，Foo * foos;
vector< pair< string，Bar * bars;
vector< pair< string Bat * bats;
}
所以这就是问题所在。我需要将一些不相关的类存储在一个有点相关的
中。我需要在插入
顺序中对它们进行排序，以便以后检索。我的意思是，后来，我需要以某种方式走出容器，然后将Foo，Bars和Bats拉出来，
彼此混合，顺序他们被插入了。
虽然，理由，其他想法？
这个怎么样？：
class Stuff
{
public：
typedef boost :: variant
<
std :: pair< std :: string，Foo *>，
std :: pair< std :: string，Bar *>，
std :: pair< std :: string，Bat *>
>
value_type;
// ...
private：
std :: vector< value_typemixed_;
};
使用这种方法你可以：
- 提供仅查看对< string，Foo *>，
的序列视图，使用boost :: filter_iterator结合
boost :: get（）变量的重载。
- 遍历所有元素并执行自定义操作取决于
使用boost ::每个变体中的对象类型static_visitor
我认为你也可以通过这种方式避免与虚函数调用相关的（可能忽略不计的）开销和/或
，尽管我没有''' t
检查。
http://www.boost.org/doc/html/variant.html
亲切的问候，
Edd
T. im H< th ***** @ gmail.comwrote：
我有设计意见。我有3个型号，我不会特别喜欢它们的b $ b，所以也许有人可以建议或帮助证明。
我有一套基本无关的课程（约6）。
class Foo;
class Bar;
class Bat;
我有一个容器类，它包含许多其他类
和其他元数据：
class Stuff {
public：
vector< pair< string，Foo * foos;
vector< pair< string，Bar * bars;
vector< pair< string Bat * bats;
}
所以这就是问题所在。我需要将一些不相关的类存储在一个有点相关的
中。我需要在插入
顺序中对它们进行排序，以便以后检索。我的意思是，后来，我需要以某种方式走出容器，然后将Foo，Bars和Bats拉出来，
彼此混合，顺序他们被插入了。
所以，我已经设想了三个答案，其中没有一个我真的很喜欢。
1）建立一个通用的基础class，Stuff_Item，它是
Foo，Bar，Bat等的基类。将所有Foo，Bar，Bat存储在一个向量中。
Stuff_Item :: stuff_type （）返回并枚举调用者使用
确定所持事物的类型。然后调用者向上投射。
2）创建一个通用基类Stuff_Item，它不是基类，
，它有方法stuff_type（）和stuff_index（）。 stuff_type
返回一个枚举，调用者用它来确定物品的类型
持有。 stuff_index将索引（或迭代器）返回到type-
特定向量中。保持Stuff_Items的单独向量。来电者可以
然后将其用作（数据库式）索引。
3）制作一个Stuff :: Item内部类，其中包含一个枚举指向
Foo，Bar，Bat ..内部类暴露了is_foo（），is_bar（），is_bat（）
方法和get_foo（），get_bar（） ，get_bat（）方法。只需存储一个
矢量Stuff :: Item。
虽然，理由，其他想法？
我必须看看Stuff类是如何用来计算最好的
解决方案......
6月3日下午12:36，Daniel T. < danie ... @ earthlink.netwrote：
Tim H< thoc ... @ gmail.comwrote：
我有设计意见。我有3个模特，我不会特别喜欢他们的b $ b，所以也许有人可以建议或帮助证明。
我有一组基本上不相关的类（大约6个）。
class Foo;
class Bar;
class Bat;
我有一个container-ish类，其中包含许多其他类
和其他元数据：
class Stuff {
public：
vector< pair< string，Foo * foos;
vector< pair< string，Bar * bars;
vector< pair< string Bat * bats;
}
所以这就是问题所在。我需要将一些不相关的类存储在一个有点相关的
中。我需要在插入
顺序中对它们进行排序，以便以后检索。我的意思是，后来，我需要以某种方式走出容器，然后将Foo，Bars和Bats拉出来，
彼此混合，顺序他们被插入。
所以，我已经设想了三个答案，其中没有一个我真的很喜欢。
1）创建一个通用基类Stuff_Item，它是
Foo，Bar，Bat的基类，将所有Foo，Bar，Bat存储在一个向量中。
Stuff_Item :: stuff_type（）返回并调用调用者使用的枚举
确定所持有的东西的类型。然后呼叫者上线。
2）创建一个通用基类Stuff_Item，它不是基类，
，它有方法stuff_type （）和stuff_index（）。 stuff_type
返回一个枚举，调用者用它来确定物品的类型
持有。 stuff_index将索引（或迭代器）返回到type-
特定向量中。保持Stuff_Items的单独向量。呼叫者可以使用
然后将其用作（数据库样式）索引。
3）制作一个Stuff :: Item内部类，其中包含一个指向en />
Foo，Bar， Bat ..那个内部类暴露了is_foo（），is_bar（），is_bat（）
方法，以及get_foo（），get_bar（），get_bat（）方法。只需存储一个Stuff :: Item的
向量。
虽然，理由，其他想法？
我必须看看Stuff类是如何用来计算最好的
解决方案...
大部分时间Stuff将以两种模式之一处理。
for stuff.big_list {
if item is_foo（）
handle_foo（）
else if item is_bar（）
handle_bar（）
else
handle_bat（）
}
或
每个
stuff.big_list中的项目{
if item is_foo（）
handle_foo
}
To事情变得更复杂，实际上有三个不同的东西容器，每个容器都可以容纳一部分东西。对于
示例，Stuff容器可以容纳Foo，Bar或Bat。一个垃圾容器
可以持有Bar或Bat，但不能拥有Foo。一个Mess容器可以容纳Foo或
Bat，但不是吧。
这个额外的复杂功能让我远离选择1和2。
Stuff_Item类必须知道可以在所有各种容器中存储的各种各样的东西。为什么一个物品进入一个垃圾容器，知道任何关于Foo的事情 - Foo无效
在垃圾容器内！另一方面，我的选择＃3结束了
在每个容器的内部类中重复样板代码。
一旦这些容器被构建，他们经常不会改变很多。他们会经常阅读。
I have a design opinion. I have 3 models in mind, and I don''t
particularly like them, so maybe someone can suggest or help justify.
I have a set of essentially unrelated classes (about 6).
class Foo;
class Bar;
class Bat;
I have a container-ish class that holds many of those other classes
and other meta-data:
class Stuff {
public:
vector<pair<string, Foo * foos;
vector<pair<string, Bar * bars;
vector<pair<string Bat * bats;
}
So here''s the problem. I need to store the unrelated classes in a
somewhat related way. I need to sort them all together in insert
order, for later retrieval. What I mean is that later, I need to walk
the container somehow and pull out al the Foos, Bars, and Bats,
intermingled with each other, in the order they were inserted.
So, I have dreamed up three answers, none of which I really like.
1) Make a generic base class, Stuff_Item, which is a base class for
Foo, Bar, Bat, etc. Store all Foo, Bar, Bat in a single vector.
Stuff_Item::stuff_type() returns and enum that callers use to
determine the type of the thing held. Callers then up-cast.
2) Make a generic base class, Stuff_Item, which is not a base class,
and which has methods stuff_type() and stuff_index(). stuff_type
returns an enum that callers use to determine the type of the thing
held. stuff_index returns an index (or an iterator) into a type-
specific vector. Keep a seperate vector of Stuff_Items. Callers can
then use that as a (database-style) index.
3) Make a Stuff::Item inner class, which holds an enum of pointers to
Foo, Bar, Bat.. That inner class exposes is_foo(), is_bar(), is_bat()
methods, and get_foo(), get_bar(), get_bat() methods. Just store one
vector of Stuff::Item.
Thoughs, justifications, other ideas?
Thanks.
Tim
On 3 Jun, 19:56, Tim H <thoc...@gmail.comwrote:I have a design opinion. I have 3 models in mind, and I don''t
particularly like them, so maybe someone can suggest or help justify.
I have a set of essentially unrelated classes (about 6).
class Foo;
class Bar;
class Bat;
I have a container-ish class that holds many of those other classes
and other meta-data:
class Stuff {
public:
vector<pair<string, Foo * foos;
vector<pair<string, Bar * bars;
vector<pair<string Bat * bats;
}
So here''s the problem. I need to store the unrelated classes in a
somewhat related way. I need to sort them all together in insert
order, for later retrieval. What I mean is that later, I need to walk
the container somehow and pull out al the Foos, Bars, and Bats,
intermingled with each other, in the order they were inserted.
Thoughs, justifications, other ideas?How about this?:
class Stuff
{
public:
typedef boost::variant
<
std::pair<std::string, Foo *>,
std::pair<std::string, Bar *>,
std::pair<std::string, Bat *>>value_type;
// ...
private:
std::vector<value_typemixed_;
};
Using this approach you can:
- provide a view of the sequence that only sees pair<string, Foo *>,
for example, using boost::filter_iterator in combination with the
boost::get() overloads for variants.
- iterate over all elements and perform a custom action depending on
the type of object in each variant using boost::static_visitor
I think you''ll also avoid the (possibly negligible) overhead
associated with virtual function calls this way, too, though I didn''t
check.
http://www.boost.org/doc/html/variant.html
Kind regards,
Edd
Tim H <th*****@gmail.comwrote:
I have a design opinion. I have 3 models in mind, and I don''t
particularly like them, so maybe someone can suggest or help justify.
I have a set of essentially unrelated classes (about 6).
class Foo;
class Bar;
class Bat;
I have a container-ish class that holds many of those other classes
and other meta-data:
class Stuff {
public:
vector<pair<string, Foo * foos;
vector<pair<string, Bar * bars;
vector<pair<string Bat * bats;
}
So here''s the problem. I need to store the unrelated classes in a
somewhat related way. I need to sort them all together in insert
order, for later retrieval. What I mean is that later, I need to walk
the container somehow and pull out al the Foos, Bars, and Bats,
intermingled with each other, in the order they were inserted.
So, I have dreamed up three answers, none of which I really like.
1) Make a generic base class, Stuff_Item, which is a base class for
Foo, Bar, Bat, etc. Store all Foo, Bar, Bat in a single vector.
Stuff_Item::stuff_type() returns and enum that callers use to
determine the type of the thing held. Callers then up-cast.
2) Make a generic base class, Stuff_Item, which is not a base class,
and which has methods stuff_type() and stuff_index(). stuff_type
returns an enum that callers use to determine the type of the thing
held. stuff_index returns an index (or an iterator) into a type-
specific vector. Keep a seperate vector of Stuff_Items. Callers can
then use that as a (database-style) index.
3) Make a Stuff::Item inner class, which holds an enum of pointers to
Foo, Bar, Bat.. That inner class exposes is_foo(), is_bar(), is_bat()
methods, and get_foo(), get_bar(), get_bat() methods. Just store one
vector of Stuff::Item.
Thoughs, justifications, other ideas?I''d have to see how the Stuff class is used to figure the best
solution...
On Jun 3, 12:36 pm, "Daniel T." <danie...@earthlink.netwrote:Tim H <thoc...@gmail.comwrote:I have a design opinion. I have 3 models in mind, and I don''t
particularly like them, so maybe someone can suggest or help justify.
I have a set of essentially unrelated classes (about 6).
class Foo;
class Bar;
class Bat;
I have a container-ish class that holds many of those other classes
and other meta-data:
class Stuff {
public:
vector<pair<string, Foo * foos;
vector<pair<string, Bar * bars;
vector<pair<string Bat * bats;
}
So here''s the problem. I need to store the unrelated classes in a
somewhat related way. I need to sort them all together in insert
order, for later retrieval. What I mean is that later, I need to walk
the container somehow and pull out al the Foos, Bars, and Bats,
intermingled with each other, in the order they were inserted.
So, I have dreamed up three answers, none of which I really like.
1) Make a generic base class, Stuff_Item, which is a base class for
Foo, Bar, Bat, etc. Store all Foo, Bar, Bat in a single vector.
Stuff_Item::stuff_type() returns and enum that callers use to
determine the type of the thing held. Callers then up-cast.
2) Make a generic base class, Stuff_Item, which is not a base class,
and which has methods stuff_type() and stuff_index(). stuff_type
returns an enum that callers use to determine the type of the thing
held. stuff_index returns an index (or an iterator) into a type-
specific vector. Keep a seperate vector of Stuff_Items. Callers can
then use that as a (database-style) index.
3) Make a Stuff::Item inner class, which holds an enum of pointers to
Foo, Bar, Bat.. That inner class exposes is_foo(), is_bar(), is_bat()
methods, and get_foo(), get_bar(), get_bat() methods. Just store one
vector of Stuff::Item.
Thoughs, justifications, other ideas?
I''d have to see how the Stuff class is used to figure the best
solution...Most of the time Stuff will be handled in one of two patterns.
for each item in stuff.big_list {
if item is_foo()
handle_foo()
else if item is_bar()
handle_bar()
else
handle_bat()
}
or
for each item in stuff.big_list {
if item is_foo()
handle_foo
}
To make matters more complicated, there are actually three different
Stuff containers, and each can hold a subset of the total things. For
example a Stuff container can hold Foo, Bar, or Bat. A Junk container
can hold Bar or Bat, but not Foo. A Mess container can hold Foo or
Bat, but not bar.
This extra complication is what steers me away from choices 1 and 2.
The Stuff_Item class has to know about all the various things that can
be stored in all the various containers. Why should an Item that goes
into a Junk container know anything about Foo - Foo is not valid
inside a Junk container! On th eother hand, my choice #3 ends up
repeating boilerplate code in each container''s inner class.
Once these containers are built up, they are not going to change very
often. They are going to be read fairly often.
这篇关于设计意见要求的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
