First, context:
We're developing some applications using QP Framework from quantum leaps.
QP is basically an event manager for state machines.
Our approach:
Since we're using QP, our modules interact with events and signals (classes/structs and enums) except some very specific modules that interact by methods.
Problem:
For those last modules, interfaces are easy, just a collection of all the public methods in said module, however, how about the others? Can we say an interface is a composition of other classes and enumerations?
Since the modules interact by sending/receiving events, both should know what kind of data packets (events) can travel through that interface.
Can we represent an interface like this? or should an interface only be a collection of methods?
edit 1:
Replying to the comments below, I don't want to say the interface had nested classes, but that the interface would define said classes so they could be used as events, but from your answers, seems using signals would be a better approach. (The ADC:: prefix and the name of the interface are not the same, just some bad naming choices, as the package name was ADC and so was the interface)
edit 2:
From the comments and answers below, I had no knowledge of the signal stereotype, so updating the question, I think it would become something like this?
This solves the classes and signals problem, however, the enum remain...
My intention was to say the interface would define this keywords, i.e. the module that implements the interface, should define this enum and their values.
Is this the correct approach?
The interface in your diagram is perfectly legit. UML interfaces do not have the constraints of Java interfaces: they can have operations, attributes, and all kind of associations (btw, the aggregation does formally not add any semantics to associations, and you could safely consider to remove the white diamonds), including composition (black diamond).
However it might not represent what you are looking for: interfaces express a contract. It means that the classes implementing it must provide those attributes and associations, and not that the classes will get all these features by a kind of “inheritance”.
Moreover, I’m not sure if you try to express some complex interface, or just found no better way to represent event consumption/generation. In the latter cse it would be an overcomplex and misleading approach.
For event based design, you may be interested in using signals. Signals are like classes, but there are UML elements to express the ability to process a family of events, and/or to generate events. It moreover facilitates the link between sequence diagrams and class diagrams, as a message can correspond directly to an event instance.
The model per se is legit. However, it's likely not what you intended. The shared aggregation has no defined meaning. See p. 110 of UML 2.5
shared | Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
So unless you define the meaning of them the model has no defined meaning.
If you intend to inherit operations/attributes you would draw an open triangle arrow towards other classes. Enumerations should simply be an attribute (simple association with role).
P.S. As per Geert's comment I notice the nesting too. So you obviously over-define this by adding the (meaningless) shared aggregation. You could represent the nested classes by showing them inside the enlarged «interface». Or you use (as suggested by Geert) the nesting relation (personally I use that rarely, but it's an alternative).
I'm using IBM Rational Rose, but I'm not sure if I'm able to model/design the methods/procedures which are known as "operations" within a class onto "UML User Class Diagram". Is there any way to model the algorithm or the code of 'operations' (i.e something like flowchart) via the software? If so, is there any possibility to get the methods design auto-implementation integrated via code generation in order to define them within a java source file?
Another way to model behavior is to use StateMachine, Constraints, Sequence and Timing diagrams. Of course, you can simply write Notes describing behavior in plain words.
You can use activity diagram, activity diagrams are near a flow chart.
See rsa activity diagram
On your activity diagram, you create a partition and you can link your partition to you operation. Then you create callOperation action which can be linked to method call.
I create a class diagram with 4 class Class1, Class2, Class3, Class4, each one containing a method operationx.
And here is a simple example modeling operation1. The important point is that the partition named Operation1 is linked in the UML model to Class1:operation1 and the 3 actions are linked to method operations. This is not a "typo" tips.
You can look also to sequences diargam but it does not look like a flow chart.
As far as I can tell, Laravel refers to the interfaces it extends as Contracts because they are used by Laravel. But this seems a bit like circular reasoning. There is no value added in changing the terminology of an existing PHP feature simply because your project uses it.
Is there something more to it? What's the logic behind coining a new term for something that's a standard PHP feature? Or is there some feature of Contracts that are not already in Interfaces?
Edit: To clarify, it's the usage of Contract as a proper noun in the documentation that has me confused, as explained in my comment on Thomas's post
"Contract" isn't some new terminology that Taylor coined. It's a very common term programmers use.
An interface is a contract, but a contract doesn't necessarily have to be an interface. The interface in a nutshell defines the contract that the classes must implement.
An abstract class is also a contract. The difference is that an abstract class can provide actual implementations, state, etc., and as a result, it is (in a sense) a more rigorous contract.
Another key difference is that a child class can only extend 1 abstract class but it can implement multiple interfaces.
So basically, "contract" isn't a new naming convention. It's a common term that Taylor is using.
It's just a nice word to describe the idea of using interfaces.
Laravel contracts are just PHP interfaces so they don't provide any other functionality.
You can read more on this subject in the documentation http://laravel.com/docs/5.1/contracts
As others have said, that is just a fancy word for Interfaces, but I think that Taylor made that decision to make it more personal.
What I mean by personal is that interface it's a very broad/common word on programming language, you have your interfaces, libraries (that you might be using) have their own interfaces and so on.
Contracts you just assume as the Laravel interfaces it's like a wrapper or alias for all the Interfaces that belong to this repo.
Short description: Contract is a term used for interfaces, but also for abstract classes.
I'm working on a project about the live upgrade of HA applications in SA
Forum middleware.
in Part of my research, I need to make a UML profile for my input upgrade campaign file,
and validate that file regarding some dependency constraints. Now I want to use ALLOY
instead of UML in my work specially since it's more abstract and formal than UML. (of
course UML + OCL will be formal.). Now my question is that, if UML + OCL is formal so
what's the benefit of using the ALLOY?
In general what are the benefits of using Alloy against UML?
As far as I know, there are no tools that let you check your OCL constraints against the UML
model, and generate and visualize valid instances, so if you are planning to do formal analysis of your models + specifications, Alloy might be a better choice. Even if you're not planning to do much of analysis, Alloy's ability to generate and visualize valid instances is greatly helpful in making sure you got your model and specification right.
In my game engine I use Box2D for physics. Box2D's naming conventions and poor commenting ruin the consistent and well documented remainder of my engine which is a little frustrating and presents poorly when you're using it.
I've considered making a set of wrapper classes for Box2D. That is, classes which extend each of the common Box2D objects and have their functions rewritten to follow the naming conventions of the rest of my engine, and to have them more clearly and consistently commented. I have even considered building ontop of some of the classes and adding some bits and pieces (like getters for pixel-based measurements in the b2Vec2 class).
This is fine but I am not 100% sure what the negative impacts of this would be and the degree to which those would affect my applications and games. I'm not sure if the compiler alleviates some of my concerns to a degree or whether I do need to be considerate when adding somewhat unnecessary classes for the sake of readability and consistency.
I have some suspicions:
More memory consumption to accommodate the extra level of class structure.
Performance impact when creating new objects due to initializing an extra level of members?
I am asking specifically about runtime impacts.
This is a pretty common problem when it comes to integrating third party libraries, especially libraries that are ports (as Box2DAS3 is), where they keep the coding and naming conventions of the parent language rather than fully integrating with the destination language (case in point: Box2DAS3 using getFoo() and setFoo() instead of a .foo getter/setter).
To answer your question quickly, no, there will be no significant performance impact with making wrapper classes; no more than you'll see in the class hierarchy in your own project. Sure, if you time a loop of 5 million iterations, you might see a millisecond or two of difference, but in normal usage, you won't notice it.
"More memory consumption to accommodate the extra level of class structure."
Like any language that has class inheritence, a vtable will be used behind the scenes, so you will have a small increase in memory/perf, but it's negligible.
"Performance impact when creating new objects due to initializing an extra level of members?"
No more than normal instantiation, so not something to worry about unless you're creating a huge amount of objects.
Performance wise, you should generally have no problem (favour readability and usability over performance unless you actually have a problem with it), but I'd look at it more as an architectural problem and, with that in mind, what I would consider to be a negative impact of extending/modifying classes of an external library generally fall into 3 areas, depending on what you want to do:
Modify the library
Extend the classes
Composition with your own classes
Modify the libary
As Box2DAS3 is open source, there's nothing stopping you jumping in and refactoring all the class/function names to your hearts content. I've seriously considered doing this at times.
Pros:
You can modify what you want - functions, classes, you name it
You can add any missing pieces that you need (e.g. pixel-meters conversion helpers)
You can fix any potential performance issues (I've noticed a few things that could be done better and faster if they were done in an "AS3" way)
Cons:
If you plan to keep your version up to date, you'll need to manually merge/convert any updates and changes. For popular libraries, or those that change a lot, this can be a huge pain
It's very time-consuiming - aside from modifications, you'll need a good understanding on what's going on so you can make any changes without breaking functionality
If there's multiple people working with it, they can't rely as much on external documentation/examples, as the internals might have changed
Extend the classes
Here, you simply make your own wrapper classes, which extend the base Box2D classes. You can add properties and functions as you want, including implementing your own naming scheme which translates to the base class (e.g. MyBox2DClass.foo() could simply be a wrapper for Box2DClass.bar())
Pros:
You implement just the classes you need, and make just the changes necessary
Your wrapper classes can still be used in the base Box2D engine - i.e. you can pass a MyBox2DClass object to an internal method that takes a Box2DClass and you know it'll work
It's the least amount of work, out of all three methods
Cons:
Again, if you plan to keep your version up to date, you'll need to check that any changes don't break your classes. Normally not much of a problem, though
Can introduce confusion into the class, if you create your own functions that call their Box2D equivalent (e.g. "Should I use setPos() or SetPosition()?). Even if you're working on your own, when you come back to your class in 6 months, you'll have forgotten
Your classes will lack coherence and consistency (e.g. some functions using your naming methodology (setPos()) while others use that of Box2D (SetPosition()))
You're stuck with Box2D; you can't change physics engines without a lot of dev, depending on how your classes are used throughout the project. This might not be such a big deal if you don't plan on switching
Composition with your own classes
You make your own classes, which internally hold a Box2D property (e.g. MyPhysicalClass will have a property b2Body). You're free to implement your own interface as you wish, and only what's necessary.
Pros:
Your classes are cleaner and fit in nicely with your engine. Only functions that you're interested in are exposed
You're not tied to the Box2D engine; if you want to switch to Nape, for example, you only need to modify your custom classes; the rest of your engine and games are oblivious. Other developers also don't need to learn the Box2D engine to be able to use it
While you're there, you can even implement multiple engines, and switch between them using a toggle or interfaces. Again, the rest of your engine and games are oblivious
Works nicely with component based engines - e.g. you can have a Box2DComponent that holds a b2Body property
Cons:
More work than just extending the classes, as you're essentially creating an intermediary layer between your engine and Box2D. Ideally, outside of your custom classes, there shouldn't be a reference to Box2D. The amount of work depends on what you need in your class
Extra level of indirection; normally it shouldn't be a problem, as Box2D will use your Box2D properties directly, but if your engine is calling your functions a lot, it's an extra step along the way, performance wise
Out of the three, I prefer to go with composition, as it gives the most flexibility and keeps the modular nature of your engine intact, i.e. you have your core engine classes, and you extend functionality with external libraries. The fact that you can switch out libraries with minimal effort is a huge plus as well. This is the technique that I've employed in my own engine, and I've also extended it to other types of libraries - e.g. Ads - I have my engine Ad class, that can integrate with Mochi, Kongregate, etc as needed - the rest of my game doesn't care what I'm using, which lets me keep my coding style and consistency throughout the engine, whilst still being flexible and modular.
----- Update 20/9/2013 -----
Big update time! So I went back to do some testing on size and speed. The class I used is too big to paste here, so you can download it at http://divillysausages.com/files/TestExtendClass.as
In it, I test a number of classes:
An Empty instance; a Class that just extends Object and implements an empty getPostion() function. This will be our benchmark
A b2Body instance
A Box2DExtends instance; a Class that extends b2Body and implements a function getPosition() that just returns GetPosition() (the b2Body function)
A Box2DExtendsOverrides instance; a Class that extends b2Body and overrides the GetPosition() function (it simply returns super.GetPosition())
A Box2DComposition instance; a Class that has a b2Body property and a getPosition() function that returns the b2Body's GetPosition()
A Box2DExtendsProperty instance; a Class that extends b2Body and adds a new Point property
A Box2DCompositionProperty instance; a Class that has both a b2Body property and a Point property
All tests were done in the standalone player, FP v11.7.700.224, Windows 7, on a not-great laptop.
Test1: Size
AS3 is a bit annoying in that if you call getSize(), it'll give you the size of the object itself, but any internal properties that are also Objects will just result in a 4 byte increase as they're only counting the pointer. I can see why they do this, it just makes it a bit awkward to get the right size.
Thus I turned to the flash.sampler package. If we sample the creation of our objects, and add up all the sizes in the NewObjectSample objects, we'll get the full size of our object (NOTE: if you want to see what's created and the size, comment in the log calls in the test file).
Empty's size is 56 // extends Object
b2Body's size is 568
Box2DExtends's size is 568 // extends b2Body
Box2DExtendsOverrides's size is 568 // extends b2Body
Box2DComposition's size is 588 // has b2Body property
Box2DExtendsProperty's size is 604 // extends b2Body and adds Point property
Box2DCompositionProperty's size is 624 // has b2Body and Point properties
These sizes are all in bytes. Some points worth noting:
The base Object size is 40 bytes, so just the class and nothing else is 16 bytes.
Adding methods doesn't increase the size of the object (they're implemented on a class basis anyway), while properties obviously do
Just extending the class didn't add anything to it
The extra 20 bytes for Box2DComposition come from 16 for the class and 4 for the pointer to the b2Body property
For Box2DExtendsProperty etc, you have 16 for the Point class itself, 4 for the pointer to the Point property, and 8 for each of the x and y property Numbers = 36 bytes difference between that and Box2DExtends
So obviously the difference in size depends on the properties that you add, but all in all, pretty negligible.
Test 2: Creation Speed
For this, I simply used getTimer(), with a loop of 10000, itself looped 10 (so 100k) times to get the average. System.gc() was called between each set to minimise time due to garbage collection.
Empty's time for creation is 3.9ms (av.)
b2Body's time for creation is 65.5ms (av.)
Box2DExtends's time for creation is 69.9ms (av.)
Box2DExtendsOverrides's time for creation is 68.8ms (av.)
Box2DComposition's time for creation is 72.6ms (av.)
Box2DExtendsProperty's time for creation is 76.5ms (av.)
Box2DCompositionProperty's time for creation is 77.2ms (av.)
There's not a whole pile to note here. The extending/composition classes take slightly longer, but it's like 0.000007ms (this is the creation time for 100,000 objects), so it's not really worth considering.
Test 3: Call Speed
For this, I used getTimer() again, with a loop of 1000000, itself looped 10 (so 10m) times to get the average. System.gc() was called between each set to minimise time due to garbage collection. All the objects had their getPosition()/GetPosition() functions called, to see the difference between overriding and redirecting.
Empty's time for getPosition() is 83.4ms (av.) // empty
b2Body's time for GetPosition() is 88.3ms (av.) // normal
Box2DExtends's time for getPosition() is 158.7ms (av.) // getPosition() calls GetPosition()
Box2DExtendsOverrides's time for GetPosition() is 161ms (av.) // override calls super.GetPosition()
Box2DComposition's time for getPosition() is 160.3ms (av.) // calls this.body.GetPosition()
Box2DExtendsProperty's time for GetPosition() is 89ms (av.) // implicit super (i.e. not overridden)
Box2DCompositionProperty's time for getPosition() is 155.2ms (av.) // calls this.body.GetPosition()
This one surprised me a bit, with the difference between the times being ~2x (though that's still 0.000007ms per call). The delay seems entirely down to the class inheritence - e.g. Box2DExtendsOverrides simply calls super.GetPosition(), yet is twice as slow as Box2DExtendsProperty, which inherits GetPosition() from its base class.
I guess it has to do with the overhead of function lookups and calling, though I took a look at the generated bytecode using swfdump in the FlexSDK, and they're identical, so either it's lying to me (or doesn't include it), or there's something I'm missing :) While the steps might be the same, the time between them probably isn't (e.g. in memory, it's jumping to your class vtable, then jumping to the base class vtable, etc)
The bytecode for var v:b2Vec2 = b2Body.GetPosition() is simply:
getlocal 4
callproperty :GetPosition (0)
coerce Box2D.Common.Math:b2Vec2
setlocal3
whilst var v:b2Vec2 = Box2DExtends.getPosition() (getPosition() returns GetPosition()) is:
getlocal 5
callproperty :getPosition (0)
coerce Box2D.Common.Math:b2Vec2
setlocal3
For the second example, it doesn't show the call to GetPosition(), so I'm not sure how they're resolving that. The test file is available for download if someone wants to take a crack at explaining it.
Some points to keep in mind:
GetPosition() doesn't really do anything; it's essentially a getter disguised as a function, which is one reason why the "extra class step penalty" appears so big
This was on a loop of 10m, which you're unlikely to doing in your game. The per-call penalty isn't really worth worrying about
Even if you do worry about the penalty, remember that this is the interface between your code and Box2D; the Box2D internals will be unaffected by this, only the calls to your interface
All-in-all, I'd expect the same results from extending one of my own classes, so I wouldn't really worry about it. Implement the architecture that works the best for your solution.
I know this answer will not qualify for the bounty as I am way to lazy to write benchmarks. But having worked on the Flash code base I can maybe give some hints:
The avm2 is a dynamic language, so the compiler will not optimize anything in this case.
Wrapping a call as a sub class call will have a cost. However that cost will be constant time and small.
Object creation cost will also at most be affected by a constant amount of time and memory. Also the time and amount will probably be insignificant compared to the base cost.
But, as with many things the devil is in the details. I never used box2d, but if it does any kind of object pooling things might not work well anymore. In general games should try to run without object allocations at play time. So be very careful not to add functions that allocate objects just to be prettier.
function addvectors(a:vec,b:vec,dest:vec):void
Might be ugly but is much faster than
function addvectors(a:vec,b:vec):vec
(I hope I got my AS3 syntax right...). Even more useful and more ugly might be
function addvectors(a:Vector.<vec>, b:Vector.<vec>, dest:Vector.<vec>, offset:int, count:int):void
So my answer is, if you are only wrapping for readability, go for it. It's a small, but constant cost. But be very, very careful to change how functions work.
I don't know if there is a big impact for instanciation time, but I will answer your question differently: what are your other options? Do they seem they'll do better?
There is a beautiful benchmark made by Jackson Dunstan about function performance: http://jacksondunstan.com/articles/1820
To sum it up:
closures are expensive
static is slow: http://jacksondunstan.com/articles/1713
overriding, calling a function inside a subClass does not seem to have a big impact
So, if you want to not use inheritance, maybe you'll have to replace it with static calls, and it is bad for performance.
Personally, I'll extend those classes and add an eager instanciation of all objects I'll need at runtime: if it is big, make a beautiful loading screen...
Also, take a look at post bytecode optimizations such as apparat: http://code.google.com/p/apparat/
I don't think that extending will impact the performance a lot. Yes, there is some cost, but it's not so high as long as you don't use composition. I.e. instead of extending Box2d classes directly, you create an instance of that classes and work with it inside your class. For example this
public class Child extends b2Body {
public function Child() {
// do some stuff here
}
}
instead of this
public class Child {
private var _body:b2Body;
public function Child() {
...
_body = _world.CreateBody(...);
...
}
}
I guess you know that as less objects as you create the better. As long as you keep the number of created instances you will have same performance.
From another point of view:
a) adding one more layer of abstractions may change the Box2d a lot. If you work in a team this may be an issue, because the other developers should learn your naming
b) be careful about Middle Man code smell. Usually when you start wrapping already existing functionality you end up with classes which are just delegators.
Some great answers here but I'm going to throw my two cents in.
There are two different concepts you have to recognize: when you extend a class and when you implement a class.
Here is an example of extending MovieClip
public class TrickedOutClip extends MovieClip {
private var rims = 'extra large'
public function TrickedOutClip() {
super();
}
}
Here is an example of implementing MovieClip
public class pimpMyClip {
private var rims = 'extra large';
private var pimpedMovieClip:MovieClip;
public function pimpMyClip() {
pimpedMovieClip = new MovieClip();
pimpedMovieClip.bling = rims;
}
public function getPimpedClip() {
return pimpedMovieClip;
}
}
I think you probably do not want to extend these box2D classes but implement them. Here's a rough outline:
public class myBox2DHelper {
private var box2d = new Box2D(...);
public function MyBox2DHelper(stage) {
}
public function makeBox2DDoSomeTrickyThing(varA:String, varB:Number) {
// write your custom code here
}
public function makeBox2DDoSomethingElse(varC:MovieClip) {
// write your custom code here
}
}
Good luck.