P
persres
Hello,
I am a bit confused about so many design approaches to even the
simplest of problems. I am not able work with all of them together. It
seems I have to pick one of these.
Mainly there seems a distinct choice between the two.
1. The new generic programming way. All this stl algorithms, range
functions, transforms, generates and function objects etc. (This is
my favourite for fun).
2. The object oriented, polymorphic, way. Say the trolltech QT
framework. You really wouldn;t be approaching with style1 if you were
to design something like QT. I guess.
When do you do what. Can I say that if its a computation/algorithmic
problem we are solving- style 1. If it is one of software design -
style2. Is that true?
For instance, consider a simple problem of designing a data structure
for an n-ary tree of integers. How would you design one if all you
know is you need an n-ary tree?. What interfaces would you
provide.
1. My choice would be to just store the entire tree in a vector.
Access each node by a pair - row, index. Provide an interface to
GetElementAt() and GetChildrenOf() . Simple and enough I should
think. I will not worry about making the underlying implementation
configurable. It will always be vector.
2. Just to iterate there are a myriad of alternatives.
a)Say the iterator pattern. I can design an one say -
CreateIterator()., Next(), to iterate through rows are children.
b) I can create an enumerator. Say row_enumerator->GetNumofElements(),
element_enumerator->GetNumOfChildren(), element_enumerator-
iterator pattern is better. I wonder why this iterator pattern exists
or is used.
The problem the above two approaches don't get along with stl
algorithms.
c) I implement an iterator that is compatible with stl algorithms.
3. a)Design some policies to configure the underlying implementation.
Is this really worth it?. I really feel this is just going too far and
over designing. Any thoughts?
b) Design policies to configure interfaces. You could do Multiple
inheritance and inherit from a certain class that defines an
interface. This also seems too complicated.
I prefer the stl kind of approach. It seems so different from the old
style oops. What are your thoughts?
I am a bit confused about so many design approaches to even the
simplest of problems. I am not able work with all of them together. It
seems I have to pick one of these.
Mainly there seems a distinct choice between the two.
1. The new generic programming way. All this stl algorithms, range
functions, transforms, generates and function objects etc. (This is
my favourite for fun).
2. The object oriented, polymorphic, way. Say the trolltech QT
framework. You really wouldn;t be approaching with style1 if you were
to design something like QT. I guess.
When do you do what. Can I say that if its a computation/algorithmic
problem we are solving- style 1. If it is one of software design -
style2. Is that true?
For instance, consider a simple problem of designing a data structure
for an n-ary tree of integers. How would you design one if all you
know is you need an n-ary tree?. What interfaces would you
provide.
1. My choice would be to just store the entire tree in a vector.
Access each node by a pair - row, index. Provide an interface to
GetElementAt() and GetChildrenOf() . Simple and enough I should
think. I will not worry about making the underlying implementation
configurable. It will always be vector.
2. Just to iterate there are a myriad of alternatives.
a)Say the iterator pattern. I can design an one say -
CreateIterator()., Next(), to iterate through rows are children.
b) I can create an enumerator. Say row_enumerator->GetNumofElements(),
element_enumerator->GetNumOfChildren(), element_enumerator-
CreateIterator()., Next() etc. What do you feel. Any reason whyGetChildAtIndex(). I prefer the GetNumOfChildren compared to
iterator pattern is better. I wonder why this iterator pattern exists
or is used.
The problem the above two approaches don't get along with stl
algorithms.
c) I implement an iterator that is compatible with stl algorithms.
3. a)Design some policies to configure the underlying implementation.
Is this really worth it?. I really feel this is just going too far and
over designing. Any thoughts?
b) Design policies to configure interfaces. You could do Multiple
inheritance and inherit from a certain class that defines an
interface. This also seems too complicated.
I prefer the stl kind of approach. It seems so different from the old
style oops. What are your thoughts?