I wanted to get some few pointers to below design problem.
Suppose I wanted to write some classes to enumerate USB devices and select particular device and transmit data through it for different platforms.(Just a very rudimentary scenario.More of a design question than anything related to USB).
Now I want to have a device base class for USB devices which can have functions like enumerate_devices, get_particular_device based on a string etc. Now this would be implemented differently on different platforms. So I'll probably have some child classes which will implement this using the platform specific apis.
Now the other class I want to have will be some buffer class that will transfer data to USB endpoint. This again will need to be implemented by different platforms based on the apis they provide.
Now suppose I create a Windows based USB device class and a buffer class and implement those using Windows provided apis. My question is what do I do if my Windows buffer class needs some data from my Windows device class. What kind of pattern can I use so that the base classes remain anonymous to the internal intermediate platform based structures used in child classes and yet buffer class can use particular device class data members? Want to get a good design for this. Dont know if I am clear enough in writing. Hope to get some insight.
Edit: I know factory and abstract factory. This is not related to them. I cant access child class member function through factory patterns through an object of UsbDevice*
Brief outline.
SomeWindowsUsbDevice : public UsbDevice {
public:
void findDevices() { // just a child class function. Not in base class
//Code to find devices using platform apis.
//fills below two private structures.
}
private:
DevEnum* pdevenum; //some platform specific structure.
Buffsize* pbufsize; // some platform specific structure.
}
SomeWindowsUsbDataTrf : public UsbDataTrf {
public:
DevEnum* getdevicelist() {
//Need to get access to SomeWindowsUsbDevice::pdevenum
}
Buffsize* getbuffsize() {
//Need to get access to SomeWindowsUsbDevice::pdevenum
}
}
Try Endpoint Redirection, more details are available at Endpoint Redirection
I also suggest you to read factory pattern, on reading you will get the point why it is suggested, just google factory pattern and you will have a huge description available
Abstract Factory pattern applies to your case.
"Provide an interface for creating families of related or dependent objects without specifying their concrete classes."
Related
I am working on a simple API in C++ where the end user of my code will pass an instance of a UserProfile class around to various other classes for modification. The user profile has a very basic public interface, with the data stored in a private pimpl object. I then add implementation classes as friends so they can access the internal data structure, which is defined in a separate implementation file. The basic outline of this class looks as follows . . .
// For pimpl here
class UserProfileData;
class UserProfile
{
public:
/// ctor to allocate impl
UserProfile();
/// dtor
~UserProfile();
/// Do some very simple stuff with a few methods
std::string getProfileName() const;
private:
/// Use pimpl and hide impl so API user can just use simplified interface
std::unique_ptr<UserProfileData> userProfileData;
/// Allow implementation classes access to userProfileData
friend class ClassOne;
friend class ClassTwo;
};
Building a big list of friend classes doesn't feel like the most elegant solution for hiding the data from the API user. It seems a little smelly. Are there any patterns or idioms that will allow me to achieve the same goal differently?
Think about what you're trying to achieve by hiding the implementation details of your UserProfile class. From the sounds of it, you're probably working to decouple consumers from the internal structure of the data. Doing this with the data container may be more trouble than it's worth, though.
Purely from the consumer's perspective, there's no need to hide the details of a class like this. Consider the following data types:
struct ProfileData
{
std::string profileName;
}
struct ProfileDataWithHiddenDetails
{
std::string getProfileName();
}
The purpose of each of these types is straightforward: they're used to transmit profile information between interested parties. Each type suits this purpose well, but one is much simpler to reason about than the other.
Does getProfileName communicate with a database? Does it retrieve the profile name from a deep hierarchy of values? Is the profile name just stored in a member variable? Any of these (among others) is possible; the information has been purposefully hidden from the consumer.
The first question is: Does this information need to be hidden from the consumer? If the consumer is using the object as a data container, then abstractions would only get in the way.
If your intent is to indeed hide details of the data structure, the next question is: What information do you need to hide from the consumer? If the object is not a simple data aggregator, consumers will need to adopt a different mindset when using it.
Abstractions can make it easier to reason about a system, but they can also make it harder. Try to abstract the behavior in your API rather than the data.
Example
Imagine ProfileDataWithHiddenDetails::getProfileName actually retrieves the profile name from a rich object model that you wanted to keep hidden from consumers. Something like:
std::string getProfileName
{
return objectModel.getRoot().getUserProfile().profileName;
}
These details don't need to be hidden in the implementation of getProfileName. Perhaps there was an API function call that returned the profile data:
ProfileDataWithHiddenDetails getProfileData()
{
return ProfileDataWithHiddenDetails(objectModel);
}
Instead of returning an abstraction, this API function could handle the abstraction itself:
ProfileData getProfileData()
{
auto profileName = objectModel.getRoot().getUserProfile().profileName;
return ProfileData { profileName };
}
I am currently busy refactoring big parts in my application. The main purpose is to remove as much as possible dependencies between the different modules. I now stumble on the following problem:
In my application I have a GUI module that has defined an interface IDataProvider. The interface needs to be implemented by the application and is used to 'provide data' to the GUI module. E.g. a data grid can be given this IDataProvider and use it to loop over all the instances that should be shown in the data grid, and getting their data.
Now have another module (in fact quite some more modules) that all need something similar (like a reporting module, a database integration module, a mathematical solver module, ...). At this moment I can see 2 things I can do:
I could move IDataProvider from the GUI layer to a much lower-level layer and reuse this same interface in all the other modules.
This has the advantage that it becomes easier for the application to use all the modules (it only has to implement a data provider once).
The disadvantage is that I introduce a dependency between the modules and the central IDataProvider. If someone starts to extend IDataProvider with additional methods needed for one module, it also starts to pollute the other modules.
The other alternative is to give every module its own data provider, and force the application to implement all of them if it wants to use all the modules.
The advantage is that the modules are not dependent on a common part
The disadvantage is that I end up with IGridDataProvider, IReportDataProvider, IDatabaseDataProvider, ISolverDataProvider.
What's the best approach to use? Is it acceptible to make all modules dependent on the same common interface if they require [almost or completely] the same kind of interface?
If I use the same IDataProvider interface, can this give nasty problems in the future (which I am not aware of at this moment)?
Why don't you do an intermediate implementation? Have some class implement recurring parts of IDataProvider (as in the 1st case) in a factored-out library (or other layer). Also, everyone is required to "implement" their own IDataProvider (as in the 2nd case). Then, you can re-use your IDataProvider implementation all over the place and add specific methods in custom classes by creating a derived class...
I.e.:
// Common module.
class BasicDataProvider : IDataProvider
{
public:
// common overrides...
};
// For modules requiring no specific methods...
typedef BasicDataProvider ReportDataProvider;
// Database module requires "special" handling.
class DatabaseDataProvider : BasicDataProvider
{
public:
// custom overrides...
};
There is an alternative to the disadvantage you cite for moving IDataProvider to a lower-level layer.
A module that wants an extended interface could put those extensions in its own sub-interface of IDataProvider. You could encourage this by pro-actively creating those sub-interfaces.
I wouldn't mind having multiple module depending on one interface even if it doesn't use all of the methods the interface publishes. You could also think more in a meaning for part of the interface instead of for what module is it intended. Most of the module you mention only need read access. So you could separate in this way and have another for write, etc.
The data layer doesn't need to know what the data is used for(which is the job of the presentation layer). It only needs to know how to return it and how to modify it.
Moreover, there's absolutely no problem into moving the data provider(which could also be labeled as a controller) to a lower level because it's probably already implementing some business logic(like data consistency) which has nothing to do with the UI.
If you're worried that additional methods would be applied to an interface you can use an Adaptor pattern. That is:
class myFoo{
public:
Bar getBar() =0;
}
and in the other module:
class myBaz{
public:
Bar getBar() =0;
}
Then to use one with the other:
class MyAdaptor: public myBaz{
public:
MyAdaptor(myFoo *_input){
m_Foo = _input;
}
Bar getBar(){ return m_Foo->getBar(); }
private:
myFoo* m_Foo;
}
That way you implement everything in your myBaz interface and only need to supply the glue in one place. The myFoo can have as many additional methods added to it as they want, the rest of your application need not know or care about it.
I have a couple of base/interface classes each of which has several derived classes. I have a need to store metadata on each derived class that has a lot of overlap, but different values.
I also have a Factory class for creating instances of the derived classes that's implemented as a singleton and has a few macros. For example, you'd:
REGISTER_COMPONENT("MyComponent", MyComponentClass);
// create an instance of each component
BaseComponent *base;
foreach(QString component, ComponentRegister::componentList())
{
base = ComponentRegister::create(component);
// do stuff with base
}
The question is: how and where to store the metadata from a solid design viewpoint.
I could store the data in the ComponentRegister as a QMap structure. When someone registers a component, they could also register its metadata with something like
REGISTER_COMPONENT_METADATA("MyComponent", MyMap);
If the QVariant::isValid() for a particular key, you know the metadata is set and available.
Another way would be static class variables or maybe a static class QMap.
I see advantages and draw backs to both. Most of the metadata are things like "path to QResources for this class" which is not tightly coupled to the business logic of the class itself.
Another issue with the static class variable method comes into play with inheritance. You can't enforce overriding of static class variables like you can with pure virtual functions. So if someone forgets...it could be unclear where in the inheritance tree the values are coming from. If you require access to the metadata through a series of pure virtual "getters" then setting of the MetaData is spread across all implementations of the Base class.
With data held, set, and looked up in the Register if you needed to make changes (like changing the root path for resources), you could do so at a single point...in the class registration calls, probably a header or wrapped in a application Utility function. With static data, you'd have to edit each class declaration.
Open to suggestions and thanks!
If data related to an object isn't specific to a single instance, as the path in your example, my designs usually include a class which manages my collection of objects. That's where I put the meta data.
example:
class zoo { std::vector<animals> zoo_animals; size_t count; }
count is metadata about the animals.
I have a project with a large codebase (>200,000 lines of code) I maintain ("The core").
Currently, this core has a scripting engine that consists of hooks and a script manager class that calls all hooked functions (that registered via DLL) as they occur. To be quite honest I don't know how exactly it works, since the core is mostly undocumented and spans several years and a magnitude of developers (who are, of course, absent). An example of the current scripting engine is:
void OnMapLoad(uint32 MapID)
{
if (MapID == 1234)
{
printf("Map 1234 has been loaded");
}
}
void SetupOnMapLoad(ScriptMgr *mgr)
{
mgr->register_hook(HOOK_ON_MAP_LOAD, (void*)&OnMapLoad);
}
A supplemental file named setup.cpp calls SetupOnMapLoad with the core's ScriptMgr.
This method is not what I'm looking for. To me, the perfect scripting engine would be one that will allow me to override core class methods. I want to be able to create classes that inherit from core classes and extend on them, like so:
// In the core:
class Map
{
uint32 m_mapid;
void Load();
//...
}
// In the script:
class ExtendedMap : Map
{
void Load()
{
if (m_mapid == 1234)
printf("Map 1234 has been loaded");
Map::Load();
}
}
And then I want every instance of Map in both the core and scripts to actually be an instance of ExtendedMap.
Is that possible? How?
The inheritance is possible. I don't see a solution for replacing the instances of Map with instances of ExtendedMap.
Normally, you could do that if you had a factory class or function, that is always used to create a Map object, but this is a matter of existing (or inexistent) design.
The only solution I see is to search in the code for instantiations and try to replace them by hand. This is a risky one, because you might miss some of them, and it might be that some of the instantiations are not in the source code available to you (e.g. in that old DLL).
Later edit
This method overriding also has a side effect in case of using it in a polymorphic way.
Example:
Map* pMyMap = new ExtendedMap;
pMyMap->Load(); // This will call Map::Load, and not ExtendedMap::Load.
This sounds like a textbook case for the "Decorator" design pattern.
Although it's possible, it's quite dangerous: the system should be open for extension (i.e. hooks), but closed for change (i.e. overriding/redefining). When inheriting like that, you can't anticipate the behaviour your client code is going to show. As you see in your example, client code must remember to call the superclass' method, which it won't :)
An option would be to create a non-virtual interface: an abstract base class that has some template methods that call pure virtual functions. These must be defined by subclasses.
If you want no core Map's to be created, the script should give the core a factory to create Map descendants.
If my experience with similar systems is applicable to your situation, there are several hooks registered. So basing a solution on the pattern abstract factory will not really work. Your system is near of the pattern observer, and that's what I'd use. You create one base class with all the possible hooks as virtual members (or several one with related hooks if the hooks are numerous). Instead of registering hooks one by one, you register one object, of a type descendant of the class with the needed override. The object can have state, and replace advantageously the void* user data fields that such callbacks system have commonly.
I would like to implement a data access object pattern in C++, but preferably without using multiple inheritance and/or boost (which my client does not like).
Do you have any suggestions?
OTL (otl.sourceforge.net) is an excellent C++ database library. It's a single include file so doesn't have all the complexity associated (rightly or wrongly!) with Boost.
In terms of the DAO itself, you have many options. The simplest that hides the database implementation is just to use C++ style interfaces and implement the data access layer in a particular implementation.
class MyDAO {
// Pure virtual functions to access the data itself
}
class MyDAOImpl : public MyDAO {
// Implementations to get the data from the database
}
A quick google search on data access object design patterns will return at least 10 results on the first page that will be useful. The most common of these is the abstract interface design as already shown by Jeff Foster. The only thing you may wish to add to this is a data access object factory to create your objects.
Most of the examples I could find with decent code are in Java, it's a common design pattern in Java, but they're still very relevant to C++ and you could use them quite easily.
This is a good link, it describes the abstract factory very well.
My preferred data access abstraction is the Repository Pattern.