I'm sure this must be a common problem with the Visitor pattern, so thought I'd see if there is a standard solution.
How can you re-code a tree traversal where the methods are built into the tree classes themselves, say
class Node {
void Traverse(SomeType& t) { ... }
};
into code that uses a visitor. Two solutions that come to mind are either
class Visitor {
stack<SomeType> argumentStack;
void Visit() {
// do work, add new arguments onto stack
// call accept() on child objects
// pop stack
}
};
or adding the arguments to the accept(Visitor&) and visit() methods themselves. But then this is no better than the original traversal built into the classes.
As a further problem, what happens if each of the built in traversal methods take different arguments, or some return values and others don't, or they don't all return the same types?
Related
Good morning stackoverflow,
I'm currently implemeting a visitor pattern on something like an AST.
Now my question is, how do I iterate through the elements ?
I think its somewhat more logical to just return the object to the visitor and let the visitor traverse from there on. Because you're keeping up flexibility , when you would like to traverse the object in different ways.
On the other side one could say, the visitor shouldn't concern about the structure of the object. So in case the object changes, you don't have to change the visitor too.
Are there any general recommadations how to solve this? I've got two books about Visitor Patterns but both are not dealing with the question how to deal with more complex nodes.
Regads
toebs
It seems pretty straightforward for a tree structure. The accept method in a node could look like this:
void accept(Visitor visitor) {
visitor.visitMyTypeOfNode(this);
for each child {
child.accept(visitor);
}
}
Obviously you need to consider if this makes sense in the overall architecture of your application.
How would you do a functionally pure linked list in C? Is a linked list what I should even be doing? I'm trying to have a list of objects but I can't think of how to add an item to the list from a function without modifying outside states.
I basically want this:
void AddItemToList(Item item);
To be able to be called from anywhere, without the caller having to worry about what list is being added to.
Right now I just have:
void AddTypeToList(entityType_t *type, entityType_t *listHead)
{
type->next = listHead;
listHead = type;
}
void RegisterEntityType(entityType_t *type)
{
AddTypeToList(type, typeList);
}
But this is obviously not functional (or is it?) because RegisterEntityType is modifying typeList. (which is a global entityType_t)
You'd need a different function, generically speaking,
List AddItemToList(List list, Item item);
Because you should return a new list with the item added, without modifying the original list. This involves other questions, such as that a Garbage Collector should be needed in order to keep track of the intermediate lists your are going to create and discard.
I don't think that C is the best language to implement functional programming techniques, you'll have to build everything from the ground up. The obvious, ideal choice would be a pure functional programming language, or at least a programming language with support for functional techniques, such as for example C++, C# or Python.
Maybe you would like to check this question.
Hope this (somehow) helps.
I have an application which has a data tree as a databackend. To implement the the MVVM pattern I have a logic layer of classes which encapsulate the data tree. Therefore the logic also is arranged in a tree. If the input is in a valid state the data should be copied to a second thread which works as a double buffer of the last valid state. Therefore one way would be cloning.
Another approach would be to implement the complete data backend to be immutable. This would imply to rebuild the whole data tree if something new is entered. My question is, is there a practical way to do this? I'm stuck at the point where I have to reassign the data tree efficently to the logic layer.
**UPDATE - Some Code
What we are doing is to abstract hardware devices which we use to run our experiments. Therefore we defined classes like "chassis, sequence, card, channel, step". Those build a tree structure like this:
Chassis
/ \
Sequence1 Sequence2
/ | \
Card1 Card2 Card3
/ \
Channel1 Channel2
/ \
Step1 Step2
In code it looks like this:
public class Chassis{
readonly var List<Sequence> Sequences = new List<Sequence>();
}
public class Sequence{
readonly var List<Card> Cards = new List<Card>();
}
and so on. Of course each class has some more properties but those are easy to handle. My Problem now is that List is a mutable object. I can call List.Add() and it changed. Ok there is a ReadOnlyList but I'm not sure if it implements the immutability the right way. Right as in copy by value not reference and not just blocking to write to it by blocking the set methods.
The next problem is that the amount of sequences and step can vary. For this reason I need an atomic exchange of list elements.
At the moment I don't have any more code as I'm still thinking if this way would help me and if it is possible at all to implement it in a reasonable amount of time.
Note that there are new immutable collections for .NET that could help you achieve your goal.
Be very cautious about Dave Turvey's statement (I would downvote/comment if I could):
If you are looking to implement an immutable list you could try storing the list as a private member but exposing a public IEnumerable<>
This is incorrect. The private member could still be changed by its container class. The public member could be cast to List<T>, IList<T>, or ICollection<T> without throwing an exception. Thus anything that depends on the immutability of the public IEnumerable<T> could break.
I'm not sure if I understand 100% what you're asking. It sounds like you have a tree of objects in a particular state and you want to perform some processing on a copy of that without modifying the original object state. You should look into cloning via a "Deep Copy". This question should get you started.
If you are looking to implement an immutable list you could try storing the list as a private member but exposing a public IEnumerable<>
public class Chassis
{
List<Sequence> _sequences = new List<Sequence>();
public IEnumerable<Sequence> Sequences { get { return _sequences; } }
}
18/04/13 Update in response to Brandon Bonds comments
The library linked in Brandon Bonds answer is certainly interesting and offers advantages over IEnumerable<>. In many cases it is probably a better solution. However, there are a couple of caveats that you should be aware of if you use this library.
As of 18/04/2013 This is a beta library. It is obviously still in development and may not be ready for production use. For example, The code sample for list creation in the linked article doesn't work in the current nuget package.
This is a .net 4.5 library. so it will not be suitable for programs targeting an older framework.
It does not guarantee immutability of objects contained in the collections only of the collection itself. It is possible to modify objects in an immutable list You will still need to consider a deep copy for copying collections.
This is addressed in the FAQ at the end of the article
Q: Can I only store immutable data in these immutable collections?
A: You can store all types of data in these collections. The only immutable aspect is the collections themselves, not the items they contain.
In addition the following code sample illustrates this point (using version 1.0.8-beta)
class Data
{
public int Value { get; set; }
}
class Program
{
static void Main(string[] args)
{
var test = ImmutableList.Create<Data>();
test = test.Add(new Data { Value = 1 });
Console.WriteLine(test[0].Value);
test[0].Value = 2;
Console.WriteLine(test[0].Value);
Console.ReadKey();
}
}
This code will allow modification of the Data object and output
1
2
Here are a couple of articles for further reading on this topic
Read only, frozen, and immutable collections
Immutability in C# Part One: Kinds of Immutability
is it wasteful/bad design to use a vector/list where in most instances it will only have one element?
example:
class dragon
{
ArrayList<head> = new ArrayList<head> Heads;
tail Tail = new tail();
body Body = new body();
dragon()
{
theHead=new head();
Heads.add(theHead);
}
void nod()
{
for (int i=0;i<Heads.size();i++)
{
heads.get(i).GoUpAndDown();
}
}
}
class firedragon extends dragon
{
}
class icedragon extends dragon
{
}
class lightningdragon extends dragon
{
}
// 10 other one-headed dragon declarations here
class hydra extends dragon
{
hydra()
{
anotherHead=new head();
for (int i=0;i<2;i++)
{
Heads.add(anotherHead);
}
}
}
class superhydra extends dragon
{
superhydra()
{
anotherHead=new head();
for (int i=0;i<4;i++)
{
Heads.add(anotherHead);
}
}
}
EDIT:(part 2 of the question)
Thanks for the replies. They have been very helpful.
I've actually run into this situation more than once, and I'd like to give a second example that is unrelated to inheritance. This is actually a real-world example, and though I've decided my current project is small scale enough to be safe with using vectors based on your answers, it's a concept that I imagine I'll use on a much larger scale at some point.
In creating an engine for my current Android game project, I found it necessary to create an Imagepoint object that is basically a set of XY coordinates that are used to track significant parts of a sprite image. Say you have a bone character made up of several bitmaps, it's useful to know where the neck attaches to the torso, the forearm to the bicep, etc. This xy offset data is used later to calculate the position for various purposes, such as where to position other sprites by using trigonometric functions to find the xy offset given the current angle.
Most sprite objects will need only one image point. The bicep needs one for the forearm, the forearm needs one for the hand, the neck needs one for the head, etc. The torsos in my current character models are the exception, and they need several for the shoulders, the legs, the neck, and any removable decorative sprites.
The sprite is the object that contains the imagepoint vectors, there will be no inherited classes, because each : torso, leg, etc is simply an instance of the sprite class, which is strictly a graphical object, containing a pointer to the bitmap, these imagepoints, and assorted position/orientation data, and will not be used for any specialized purposes. If I were to use this concept on a large scale game with massive numbers of instances, where most would require only a single imagepoint, with a few objects requiring several or none, and where there would be no special cases meriting the use of inheritance. What would your thoughts be?
Yes and no.
I mean your question really depends on how are you going to use these objects.. personally I like to split behaviours and attributes as much as possible to "clusterize" them according to the kind of object they represent without caring about reusing some code a little bit less compared to a really inheritance approach like the one you proposed. Something like:
interface BigLizard
{
void nod();
}
class Dragon implements BigLizard
{
Head head;
void nod() { head.upAndDown(); }
}
class ReallyScaryDragon extends Dragon { ... }
class Hydra implements BigLizard
{
ArrayList<Head> heads;
void nod() { for (Head h : heads) h.upAndDown(); }
}
And so on. This approach is like "having just exactly what you need for your objects without force anything to be a specific case". Of course this means that it will have two different implementations of nod() but when you don't need to optimize (and you should care about it only at the end) just stick with your personal preference, assuming that it doesn't go against any standard, widely accepted convention.
You don't have to make anything inherit from a single object, just customize the hierarchy as you like.. also a composite solution (like already suggested) would be a solution also if the concept of "head part" is not the same for your Dragon and for your Hydra..
A third solution for your specific case could be to use a LinkedList instead that an ArrayList. In this case whenever you have just one head you won't waste space (except for instantiation of the list) and you'll have just the next pointer of the head (of the list :D ) pointing nowhere.
If the head is publicly accessible, it'll need to be available as an array/list/collection so that consumers can deal with it.
Another way of dealing with this may be to switch to a more behavioral design rather than a stateful design. In other words, instead of having code telling the dragon to nod, have the dragon respond to an event that would cause him to nod, if that makes sense.
say("Dragon, would you like a yummy princess?");
if(dragon.Stomach.Contents.IsEmpty)
{
dragon.Nod();
}
compared with:
say("Dragon, would you like a yummy princess?");
dragon.offerFood(princess);
// in dragon class
void offerFood(Food yummyFood)
{
if(Stomach.Contents.Empty)
{
head.Nod(); // can be overridden by subclasses.
}
}
In the second example, the consumer of the dragon class isn't asserting authority to make the dragon do things... all the consumer is doing is things (saying things, offering a princess) that he has the authority to do - the dragon gets to decide whether it wants to nod its head or not (which makes sense. I doubt that I'd be able to get a dragon to nod its head if it didn't want to!)
I call this 'behavioral' because the interfaces focus on the interactions between the objects (the dragon and whatever is offering the yummy princess) rather than the state of the dragon (its heads).
I don't think there is a single answer to this question. It seems to me like it would be application dependent. If the application is a relatively lightweight dragon simulation that will never deal with more than a few thousand dragons at any one time, then it probably isn't a big deal to use a vector. If, though, it is a game involving millions of dragons, then it might make sense to optimize it slightly differently and maybe save a bit of memory and possibly shorten access time. But even that probably depends on the underlying class implementation. It is quite possible that the vector class you use could be optimized to handle a single element without extra overhead.
In this particular case, it'd probably be better to override nod() for your multi-headed dragons. Whether they have 1 head or 5 is a detail that really shouldn't be worried about in the base class (which should be as simple as you can reasonably make it).
You don't want to have to account for every possibility that every one of your code's users (even you) will ever need at every point in time. Otherwise, you'd need to account for 2-headed dogs (which are a lot more real than even 1-headed dragons). People extending your classes and such will be developers, too; let them do the work to account for the more exotic/bizarre cases, if they need to.
You could change the Head implementation to be a Composite type. That way, each extension of Dragon needs only one instance of Head and the Head takes care of GoUpAndDown().
I would implement such features in deriving classes. To make this behaviour work, you have to be able to override methods (in your case, the nod() method). The baseclass shouldn't cater for all possibilities, it should present the base case, which can be extended. Just make the appropiate methods overrideable, so the deriving classes can implement the specific behaviour, and everything will work out fine.
I have a C function named SetParams(...) with a variable number of arguments. This function sets up a static data structure (let us name it Data). SetParams is used with pairs of arguments, e.g. SetParams("paramA", paramA_value, "paramB", paramB_value) etc. It can also be called many times, e.g.
SetParams("paramA", paramA_value);
SetParams("paramB", paramB_value);
...
When all 'parameters' have been set, another function is called (let us name it Execute) that takes no args:
Execute();
// uses data from static 'Data' and performs error_handling and execution
I was wondering if I could structure this kind of code in a more object-oriented way. So, I would like some advice, especially for error-handling, since some pairs of args may contradict others.
The general practice for creating an object oriented design in C is for every method you have you will pass in a reference to a struct which is used to store all the classes member variables. In otherwords in C++ where you'd have listObj.clear() you have in C list_clear(&listObj).
This is kind of ugly, but it's necessary unless you want to use static member variables and limit the implementation to being used only once.
In the example below, notice how in each method a reference to a struct ParamUtilObj is passed in.
// --- paramUtil.h
// Stores all the objects member variables (public and private)
struct ParamUtilObj {
int paramCnt;
char param1[25];
char param2[25];
...
};
bool paramUtil_initialize( struct* ParamUtilObj pData );
bool paramUtil_addParam( struct* ParamUtilObj pData, const char* pKey, const char* pValue );
bool paramUtil_execute( struct* ParamUtilObj pData);
With respect to variadic methods. I'd try to avoid them if possible and just add them in one at a time. The business logic to validate the params is an entirely different topic in my opinion. I'd need more info to recommend the best approach. But... It seems to me since you're going to have to do validation such as if( MethodA ) then check for presence of some other argument... it might be easier to create several SetParam methods for each MethodType which the user could specify in the script.
I would recommend using a linked list to store your params and put all your methods as function pointers to a struct.
struct MyClass {
struct LinkedList* params;
void (*setParams)(...);
void (*execute)()
}
the linked list would be a key value pair
struct LinkedList {
struct LinkedList *next;
char * key;
char * value;
}
I dont know how you have your SetParams implemented, from the sound it just does a little bit of parsing and storing and forwards error handling downstream to the Execute call.
Since you are using variable length arguments, are you using the va_* macros? Doing so with a format string might allow you to insert the error handling into your SetParams call and allow Execute to just iterate over the values and do its thing.
Generally, if you have a function that handles setting parameters that should be where you manage errors associated with setting parameters. Errors encountered in the execution of command should be addressed in the execute function.
You cannot do it this way, because in C variadic functions don't know the number of arguments you've supplied, so you need somehow let function know it, like specifying number of params as first parameter or use printf way, when number of parameters can be found from format string.