I have an application which has the following structure:
(Removed image, I don't have permission to post images. See here: http://s15.postimg.org/98qc3p7uz/Capture.png)
So 'App' holds Manager instance, Manager holds a vector of 'Connection', each of them holds a Protocol, and each Protocol holds a communication class. All the communication classes reference a single HAL class.
At the moment, the communication class constructor obtains a HAL instance as a singleton, eg. hal = HAL::GetInstance().
To make development and testing easier, I'd like to remove this dependency. Dependency Injection pattern seems ideal for this as it would allow me to use a fake HAL.
However, I don't think the Communication classes should have to do anything with HAL, likewise the protocol classes and the connections.
The main 'App' class DOES have a reference however, but I'm not sure about passing that to Manager->Connections[x]->Protocol->Communication.
Maybe I can abstract it out and let Manager have a reference to the HAL, and then each connection can have a parent pointer to the Manager, but it all seems to be getting messy and overcomplicated just for the sake of providing a HAL class reference to the communication.
Is there a better way to do this?
You could let the Manager create instances of Connection, Protocol, Communication and HAL. Then the Manager connects all of them. Very simple example in C++:
Manager::createEverything()
{
Connection connection;
Protocol protocol;
Communication communication;
HAL hal;
communication.setHal(hal);
protocol.setCommunication(communication);
connection.setProtocol(protocol);
}
You could also use dependency injection for creating different HAL-implementations that way. A class design could look like the following:
YUML diagram
YUML Edit Link
The above is quite simple but should give you an idea. Some more thoughts:
Use a Factory to create the different types of IHAL
Use the Builder Pattern to do the whole creation and aggregation thing
Related
I'm facing a designissue. I'm using DDS (Data Distribution Service) protocol to communicate between application.
In my DDS Library I have 3 classes:
- DDSWriter to write messages to other applications
- DDSReader to read messages from other applications
- DDSManager to instantiate the two others, manage them and be the entry point for the application
DDSManager have an objet which refer to DDSWriter and another which refer to DDSReader.
DDSReader have a thread to read continually the data that we receive but no objet we refer to DDSManager.
How can I send data from DDSReader to DDSManager in this case ?
Thanks in advance for your help.
After discussion with an other software architect that what I need can't be implement.
But I can implement the design pattern Observer which permits to abstract DDSManager instance for DDSReader object.
Thanks for your help and I hope this can be help other person.
I want to create an application that consists of a web based front-end and a c++ back-end. My choice is to use websocket protocol in order to achieve data transfer between them.Specifically the front end will trigger some measurements that will be done in the back-end and eventually return and store the relevant values in the front-end. I decided for the websocket protocol implementation to use poco library and specifically I came across the following example https://github.com/pocoproject/poco/blob/develop/Net/samples/WebSocketServer/src/WebSocketServer.cpp. However since I haven't totally grasped the factory concept in C++ I haven't figured out the role of class RequestHandlerFactory.Is it possible for someone to explain what is the role of the aforementioned class and regarding my implementation (front-end -> trigger back-end -> back-end do measurements ->back-end returns the value to front-end in order to be depicted in a web-based gui) do I need to make any modifications to make this work for my case ?
As you might have read in the sample, there are two implementations derived from HTTPServer. So depending on the type of connection requested by the client (WebsocketRequest, PageRequest) one can return the appropriate HTTPServer. The work of factory class is to handle the incoming request, decide which class should handle it (depending on the connection requested).
Since you would be requesting to exchange data and not a request to display a HTML document, you should go for WebSocketRequestHandler. Yes it can be done. You might want to remove the PageRequestHandler since you wouldn't be using it.
I'm designing a component-based system and everything works well, but a critical feature is missing and that is to be able to obtain a type of component from within a class of type Object, whereof this class can be added/removed components. In the Object class there exists a vector of components thus:
vector<Component*> pComponents;
And in the Component class, a Component has to have a name. So, a component such as Drawable would be called like so:
pPlayer->addComponent(new Drawable("Drawable"));
And that's all that's required for the player to be drawable. Now this is the problem: when it comes to adding loads of components that rely on other components, is there a settlement in how components communicate with one another?
Currently, in my Game class (which is not of type Object, although I might have it derive from Object albeit not sure if that's a good design decision) I have this code in the update function:
void Game::update()
{
pPlayer->update(0);
pSpriteLoader->getSprite()->move(pPlayer->getVelocity());
}
I'm using SFML2 solely because it's easy to use for the 2D graphics. The player update function calls the components' respective update functions. And the sprite loader is also a component and it is in charge of handling the loading of sprites through textures/images that can be read from file or memory. If I were to omit this line of code then the sprite would not be able to appear moving on the screen. As you can see, it's odd that pPlayer has a getVelocity() function and it's because I haven't moved all the physics stuff into its own component. What is dreading is that once I have moved the physics stuff out of the Player class into a Physical component class, how can I get these components to communicate with each other without having to resort to the lines of code ascribed above?
My solution is to create a component manager which registers each component and any component that requires another component will have to consult with this component manager without having to do so directly. Would this be a viable solution, and how can I proceed with the logic of such a component manager then?
Well, I suppose you would start by designing a messaging system.
It appears that you want to heavily decouple code and create components as much as possible. This is fine, I suppose, but the answer to having dependencies without coupling is probably something among the lines of message passing.
Say you need an Achievement system. This is a perfect example of a system that needs to stick its hand into as many nooks and crannies as possible in order to allow for the greatest flexibility in designing achievements. But how would you be able to stick your hand into, say, the Physics, AI, and Input system all at the same time and not write spaghetti code? The answer would be to put listeners on event queues and then run them by certain criteria based on the contents of the messages.
So for each component, you might want to inherit a common message sending/receiving component, possibly with generics, in order to send data messages. For example, say you shoot a laser in a FPS game. The laser will most likely make a sound, and the laser will most likely need an animation. You will probably want to send a message to the sound system to play a certain sound, and then send a message to the physics system or such to simulate the effects of the laser.
If you're interested, I have a really, really crude library for modeling a event system based on queues, listeners, and generic messages here: https://github.com/VermillionAzure/Flexiglass You might get some insight from fellow newbie code.
I really suggest taking a look at Boost.Signals2 or Boost.Asio as well. Knowledge of signals/networking can often help when designing communication systems, even if the system is just between game components.
I've recently been working on an entity-component system in SFML and came across the same problem.
Instead of creating some sort of messaging system that allows components to communicate with each other I ended up adding 'System' objects to the mix instead. This is another popular method that is often used when implementing component systems and it's the most flexible one that I've used so far.
Entities are nothing more than collections of components
Components are POD structs and have no methods (e.g. a PositionComponent would have nothing more than X and Y values)
Systems update any entities that have the required components
For example, my 'MovementSystem' iterates through each of my entities and checks if they have a VelocityComponent and an InputComponent. If it does, it changes the velocity of the current entity according to the current key being pressed.
This removes the issue with components communicating with each other because now all you need to do is access/modify the data stored in the current entity's components.
There are a few different ways that you can work out whether or not the current entity has the required components - I'm using bitmasks. If you decide to do the same, I highly suggest you take a look at this post for a more thorough explanation of the method: https://gamedev.stackexchange.com/questions/31473/role-of-systems-in-entity-systems-architecture
I'm now developing a json-rpc project in C++. I've not decided yet how I handle rpc's requests. From the client side, server receives jsons like below.
{"method":"App1hoge", ...}
{"method":"App1fuga", ...}
{"method":"App2foo", ...}
The server side handles some applications, App1, App2, etc. So I think I should design ApplicationRule class for each class. In this case, App1Rule and App2Rule classes are needed. And I should also design ApplicationRuleManager for handle each rule. But I'm not sure how I design ApplicationRuleManager.
In general, how should I design the relationship between ApplicationRuleManager and each ApplicationRule? Strategy pattern is familiar with this case?
Any help would be appreciated.
This is the Documentation from Oracle Docs. I want to clarify certain jargon based questions.
On the server side, the developer specifies the web service operations by defining methods in an interface written in the Java programming language. The developer also codes one or more classes that implement those methods. Client programs are also easy to code. A client creates a proxy (a local object representing the service) and then simply invokes methods on the proxy.
In The first Bold lettered sentence,
Are these classes, the Implementation classes of the Web service ?
Second Bold lettered,
will the client create the object of those service implementation classes? If yes, how come? Will JAX WS transport the complete service implementation class code which is # server to the client?
I am very new to the concept of web services. if my doubt is silly please bear with me. Thanks!
First point. Yes you code the implementation of the web service. However this is just limited to the business logic you wish to execute you don't have to go code the low level boiler plate code like creating a HTTP socket etc.
A simple class that is exposed as a web service will look like this:
#Webservice()
public class CalculatorWS()
{
#WebMethod(#operationame="add")
public int add(#WebParam(name="i") int i, WebParam(name="j") int j)
{
//this is where you code your implementation
return i+ j;
}
}
A client proxy class does NOT transfer the implementation across the wire. It just creates a proxy that you can use to call the implementation.
You can learn all about it step by step by following this tutorial. It is easy one to understand and follow and will answer all of your questions.