Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
(for a custom engine) Just a simple question, I was wondering if there was an advantage adding a child this way:
`myNode.transform.parent = newParent` // unity like
instead of this:
`myNode.transform.AddChild(newChild)`
Or is it just a matter of preference.
For my part I find it weird that a setter will do background stuff for example deleting himself from its previous parent children conteiner.
Thanks !
They may be using an AddChild method in the C++ backend to make the addition.
Unity's core engine is written in C++, C# is merely the scripting layer that they use. Unity registers their backend methods to front end methods and properties. When somebody uses that property or method, the backend implementation is called instead. This isn't the case for all of Unity's stuff, Unity's UI is predominantly C#, and it's open source to, in case you're curious:
https://bitbucket.org/Unity-Technologies/ui/overview.
Here's an article that may clear up some aspects of which would be best to choose, although in practice, it usually comes down to preference:
https://msdn.microsoft.com/en-us/library/ms229054(v=vs.100).aspx
In general though:
methods represent an action, properties represent data.
Another user asked a similar question: Properties vs Methods
Take a peak if my answer doesn't clear it up.
Also, in case you're curious about how Unity calls its backend methods, this may clear it up: https://github.com/mono/mono/tree/master/samples/embed
Hopefully this'll help.
The other answer is really good but I just wanted to add a little bit of an explanation to why you would use addChild(...) or .parent = ....
It basically comes down to how you build your code, if you do the parent instance then when it is drawing its location, it can just get its parent and then draw it relative to that parent.
Where as if you did the addChild(...) system then the parent has to tell the child where its location is (or you have to have a link anyway to the parent) to draw it relative.
That is just one reason and I'm sure there is plenty, but it does mostly come down to preference.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
So I'm adding some new features to an older project. I'm able to unit test a few classes without relying on any of the features from the legacy code. However I've gotten to a point where the next phase in functionality is just so dependent on the legacy code that it seems like I will basically have to run the main from the project( or at least most of the set up) in order to be able to Unit test my newest class. Is there some sort of approach for dealing with ridiculous dependencies when trying to unit test?
However I've gotten to a point where the next phase in functionality
is just so dependent on the legacy code that it seems like I will
basically have to run the main from the project( or at least most of
the set up) in order to be able to Unit test my newest class.
I have come across this type of problem. You are asked to write a small class with 4 methods.
But, unfortunately, your code needs to create an object of a legacy class. So, you need to build libraries of legacy code, link your code with them, run 3 dozen processes, bring up database, fill up sample data in database, set up configuration for processes, schedule events to kick-in .. etc.
You can avoid some of that pain by mimicking your input (I assume you already did that).
You can also stub out legacy classes. If you don't have source code of legacy classes in your control, you can even stub out methods of legacy classes selectively (by putting your stub libraries on the command line of the compiler ahead of the actual legacy libraries).
There are different tricks to deal with different type of problems that arise in unit testing. If you have a specific problem in mind, you can add that to your question so that people can help you in a better way.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am constructing a custom UI with Qt 5 an MVC using QML/C++ and I am wondering how to structure the code in regard to what to put in C++ and what to put in QML. The purely visual parts (view) will obviously be put in QML and the data (model) in C++, but what about the parts that aren't that clear? Should I lean towards putting things in C++ and try to reduce the QML code somewhat, or is it better to lean in the other direction, i.e increasing the QML code and reduce the C++ parts? I have not worked enough with Qt/QML to be able to know what is the best way to do this.
Both parts are perfectly feasible imho, but it would take a lot of effort if I need to change this afterwards and therefore I want to get this at least somewhat right before I begin to create a lot of code.
What are your experiences in this when designing QtQuick interfaces? Do you design components mostly in C++ with a thin QML interface on top or the other way around? What are the pros/cons for each solution? What is the preferred way to structure code when designing a UI in QtQuick?
Here's my two cents worth. This applies to Qt version 5.1 (ish)
QML was designed to implement the UI. So I've designed those parts that do the visual implementation in QML. Some UI elements can't be done well in Javascript so I do "helpers" or views in C++.
I'm using model/view for data display. All the models are implemented in C++ (I used sqlite databases for my last application).
QML is still a work in progress so if you stray too far from standard telephone interfaces there isn't much implemented. The standards for UI behavior you expect from desktops aren't present at all.
Good luck!
Ideally make your models and controllers in c++. Use QML for the view.
Inside the QML view you can rather easily incorporate components written in C++ (there is a plug-in system and an API for visual and non-visual C++ components to integrate well within QML)
QML performance has improved a lot in Qt 5.1+ with regards to UI rendering, but you should limit the amount of logic you do in javascript (inside qml).
What QML excels at is declaring what the UI looks like and how it should be connected to signal and slots of the controller, if you end up writing convoluted logic inside your qml files, you are probably doing something wrong.
PS: there are several big open-source project that use QML, you can find them on github. You could use them as style guidelines.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am writing a game in Cocos2D-x and I am struggling with feeling like my OO is sloppy. I can't shake the feeling and I can place m finger on why.
Game Scene class
In This a Layer is created
Layer Class
responsible for creating itself
Also calls HUDS when needed
contains std::vectors of objects on the layer
Object Class
hold everything about itself
has a sprite member variable that is on the layer
HUD1
called when the user taps the layer and the touch even occurs in the Object
is a Menu of things that you can do to the Object
When you click a menu item it needs to change values in Object
When you click a menu item it actually runs code in Object (object::doSomething())
What feels sloppy I think is that there is a lot of dependency on these classes together.
I feel like I should abstract this out and create a class that controls all of this happening instead of some code in Object, Layer, HUD, etc.
Can anyone talk to me about how this is laid out and if I am making an OO mistake?
As it turns out graphics and games do not fit into OO designs very well despite being an example in many OO texts. Your instinct is right with respect to decupling the control from the data. A popular design pattern for games these days is to have components, entities, and systems instead of a rigid OO hierarchy.
The idea is that you have Entities or GameObjects that are just collections of components and perhaps some messaging infrastructure. Components store data about the Entity they are attached to, for example you might have a Transform component and a velocity component. Now one approach is to have a messaging system that components can hook into and use that to update their data. For example a Velocity component might hook into the Update message and in the Update handler it could get the transform of the object and move it. By using messages for all communication between components you can decouple them to a large degree.
Systems are a different way to handle updating component data. The idea with Systems is that you have a process that can say "I operate on entities with these components" and then it gets a list of all of the relevant entities when it runs. This decouples data from function even more and can make it easier to manage threading and dependencies
Essentially object oriented design is about capturing "what things are" in the real world, but with a game you don't really want that, all you care about is what things look like and you would like to be able to change the individual facets of something's behavior without pain.
Good resources for Entity-component systems:
http://piemaster.net/2011/07/entity-component-primer/
http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/
Have a think about what you are trying to achieve before trying to dive in to code (even though the urge to do this is very strong!)
Try to decouple your classes by using Dependency Injection. This may involve adding a bunch of extra classes and complexity now, but trust me, it will make your life much easier later on when you will inevitably need to refactor certain parts of your game. Avoid using 'gum and duct tape' solutions as the technical debt you will incur by doing this will come back and bite you later!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I parse/process data coming from many different streams (with different formats) and the number of different sources for data keeps growing in my system. I have a factory class which based on a config file specifying the source will give me the appropriate parser/processor pair (abiding to a small common interface) requested in something like this:
static Foo* FooFactory::createFoo(source c, /*couple flags*/)
{
switch (c)
{
case SOURCE_A:
{
//3 or 4 lines to put together a parser for A, and something to process stuff from the parser
return new FooA(/*args*/);
}
break;
//too many more cases which has started to worry me
default:
return NULL;
};
}
the problem is as the number of sources has grown I am facing two issues. First, when I build, I find myself pulling in all the FooA, FooB, FooC, FooD, FooE... relevant code - even if I was only interested in perhaps building a binary in which I'll only request FooA lets say. So how to go about modularizing that. A secondary issue is, right now in the case of SOURCE_A, I am returning FooA, but what if I am interested in SOURCE_A but I have different ways of parsing it and perhaps I want FooA_simple and FooA_careful but with the ability to plug and play as well?
For some reason, one thing that came to mind was the -u option to the linker when building a binary...it somehow suggests to me the notion of plug and play but I'm not sure what a good approach to the problem would be.
Well, you just create a factory interface and divide the logic among subtypes of that factory. So there might be a sub-factory (type/instance) for libFooA, and another for libFooB. Then you can simply create a composite factory depending on the subfactories/libraries you want to support in a particular scenario/program. Then you could even further subdivide the factories. You could also create factory enumerators for your composite types and do away with all that switch logic. Then you might say to your libFooA factory instance to enable careful mode or simple mode at that higher level. So your graph of FooFactory instances and subtypes could easily vary, and the class structure could be like a tree. Libraries are one way to approach it to minimize dependencies, but there may be more logical ways to divide the specialized sub-factories.
I'm not sure if you can get around importing FooA,FooB... because at any given moment any one of them might be instantiated. As for modularizing it, I'd recommend creating helper functions that gets called inside the switch statement.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
In Grails, there are two mechanisms for modularity in the view layers: Template and TagLib.
While I am writing my own Grails app, I am often facing the same question when I need to write an UI component: do I need to use a template or a TagLib?
After searching the web, I didn't find a lot of best practices or rules of thumb concerning this design decision, so can you help me and tell me:
What is the main difference between the two mechanisms?
In which scenarios, do you use a TagLib instead of a Template (and vice-versa) ?
There is definitely some overlap, but below are several things to think about. One way to think about it is that Template is like a method-level reuse, while TagLibs are more convenient for API-level reuse.
Templates are great for when you have to format something specific for display. For example, if you wan to display a domain object in a specific way, typically it's easier to do it in a template, since you are basically just writing HTML with some . It's reusable, but I think its reusability in a bit limited. I.e. if you have a template, you'd use it in several pages, not in hundreds of pages.
On the other hand, taglibs is a smaller unit of functionality, but one you are more likely to use in many places. In it you are likely to concatenate strings, so if you are looking to create a hundred lines of HTML, they are less convenient. A key feature taglibs allow is ability to inject / interact with services. For example, if you need a piece of code that calls up an authentication service and displays the current user, you can only do that in a TagLib. You don't have to worry about passing anything to the taglib in this case - taglib will go and figure it out from the service. You are also likely to use that in many pages, so it's more convenient to have a taglib that doesn't need parameters.
There are also several kinds of
taglibs, including ones that allow
you to iterate over something in the
body, have conditional, etc - that's
not really possible with templates.
As I said above, a well-crafted
taglib library can be used to create
a re-usable API that makes your GSP
code more readable. Inside the same *taglib.groovy you can have multiple tag definitions, so that's another difference - you can group them all in once place, and call from one taglib into another.
Also, keep in mind that you can call up a template from inside a taglib, or you can call taglibs withing templates, so you can mix and match as needed.
Hope this clears it up for you a bit, though really a lot of this is what construct is more convenient to code and how often it will be reused.
As for us...
A coder is supposed to see specific object presentation logic in template, not anywhere else.
We use taglibs only for isolated page elements, not related to business logic at all. Actually, we try to minimize their usage: it's too easy to write business logic in a taglib.
Templates are the conventional way to go; for instance, they support Layouts (btw, they can be named a third mechanism)