Sign in to follow this  

C#/C++ design pattern ideas

This topic is 4735 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

abstract class getIntersectionPoint 
{
public:
    static Vertex pnt;
    static float distance;

    func(Vertex A, ...);
};
What if classes weren't used to group functions together, they were just used to simulate complex return types and provide common groupings of other object types? I'd like support for an on-the-fly sort of object to be associated only loosely with a function or functions, rather than the full strength interconnected object oriented paradigm of our grandparents. Python seems to prove to me how useful this concept can be. Other idea: I tried using pointers to parent objects instead of inheriting from them, and so far except for the need for some sort of aliasing thing because going this->parent->parentsparent->location.x seems annoying, it works pretty well and it forces me to make my interfaces good through the layers. Has anyone else tried this? I imagine that C# properties make it not a hard thing to do, to alias and hide the depth.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by pTymN
What if classes weren't used to group functions together, they were just used to simulate complex return types and provide common groupings of other object types?
The pattern isn't thread safe. You'd be better off just by returning a new object that holds all the return values. Or make the members non-static and the class non-abstract, so all threads can create their own instance of it.
Quote:
I'd like support for an on-the-fly sort of object to be associated only loosely with a function or functions, rather than the full strength interconnected object oriented paradigm of our grandparents. Python seems to prove to me how useful this concept can be.
Then just use Python :). Or templates in C++, if things can be resolved at compile time.

Share this post


Link to post
Share on other sites
I'm not sure if I understand the point of your post, but these thoughts might help. If they don't, you're free to ignore them.

Quote:
What if classes weren't used to group functions together, they were just used to simulate complex return types and provide common groupings of other object types?


Generally, one would define a class or structure to contain "complex" return types. This is sometimes annoying since you may only need the class/structure for one function and it seems silly. There is no good solution for this in C++/C# that I know of. I have sometimes used out parameters (C#), but it often seems cludgy. Some languages support tuples, which are pretty nice for that sort of thing. There is, in fact, a tuple for C++ implemented using templates, buy its implementation is rather convoluted. You can find it in the boost library, and some other C++ libraries as well.

Quote:
I tried using pointers to parent objects instead of inheriting from them, and so far except for the need for some sort of aliasing thing because going this->parent->parentsparent->location.x seems annoying, it works pretty well and it forces me to make my interfaces good through the layers. Has anyone else tried this? I imagine that C# properties make it not a hard thing to do, to alias and hide the depth.


The problem you are describing is called inheritence vs. composition. They are both strategies that solve very similar problems, but one or the other is usually better in a given situation. You don't want to always use composition, because you run into the aliasing problem you are describing. Always using inheretence has worse problems. The solution isn't to implement some kind of alias (which really can't be done well in C# anyway), but to simply use whichever strategy is most appropriate. It takes some time and experience to know the difference, but I think you will find that problems like the one you are describing don't happen as often as you'd think in a well designed system.

Share this post


Link to post
Share on other sites
Maybe I've misunderstood you - but have you tried boost::any.

Here's my settings manager, that handles all sorts of variables (sort of like encapsulated global variables).


//Header only - you should get the idea
#include <map>
#include <string>

#include <boost/any.hpp>

class SettingsManager
{
public:
SettingsManager(void);
~SettingsManager(void);

static SettingsManager* Instance();
void Kill();

// General purpose functions
void PushSetting(const std::string& name, const boost::any& thisData);
const boost::any& GetSetting(const std::string& which) const;

void ParseIniFile(const std::string& filename);

private:
typedef std::map<std::string, boost::any> thisType;
typedef thisType::iterator thisTypeIterator;
typedef thisType::const_iterator thisTypeConstIterator;

static SettingsManager* instance_;
thisType theSettings_;
};



// Usage - Set
SettingsManager::Instance()->PushSetting("theInstance", hInstance);

// Usage - Get
HINSTANCE hInstance = boost::any_cast<HINSTANCE>(SettingsManager::Instance()->GetSetting("theInstance"));






The only problem is that the user of an end variable has to do an any_cast, and therefore needs to know what type the variable is, as well as know the calling code. But it works for me as a storage pot (and I couldn't see a way around this).

HTH (or is at least on topic!).
Jim.

Share this post


Link to post
Share on other sites

This topic is 4735 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this