AS3: One class with parameter, or two similar classes - actionscript-3

In case of creating two similar custom AS3 visual components, ex. Button, with different look, but same function, which methodology is better, more efficient from the aspect of code-execution, speed, performance?
Creating two, almost identical classes, where the only difference is
in the visual components, so I have to write the button-controlling functions two times?
Creating one class, with a parameter input
that defines, which kind of button I would like to have
1:
package {
public class bigButton {
public function bigButton() {
//make a bigButton
}
}
}
and
package {
public class smallButton {
public function smallButton() {
//make a smallButton
}
}
}
or
2:
package {
public class OneKindOfButton {
public function OneKindOfButton(thisIsBigButton:Boolean) {
if (thisIsBigButton == true) {
//make it big
} else {
//make it small
}
}
}
}

In terms of an academic argument about the two structures (not this particular example), I'd have to argue that the first option is "better." Although opinion based posts are generally regarded as worthless by most of the SO community, I have a couple of points to bring up and would like to hear counter arguments.
For the second option of doing it, first off it makes me think that potentially there should be a base class that contains all the original functionality then a sub-class that tweaks some part of the functionality. Secondly it requires a condition in the constructor (and probably elsewhere littered throughout that class) to deal with the two scenarios the one class is handling. I think part of the issue here is that in AS3 there is a tendency to mash up all of the functionality and the view logic into one class, just because it's possible doesn't make it a good idea.
All said, I would probably go the route of having a base class that contains the functionality for the buttons, then make some sub-classes that do things different visually.
Also in terms of run-time efficiency I believe the first scenario will work out better again due to the extra conditions that will have to be checked at run-time with the second scenario. In any case, when performance and optimization is the issue it's always best to just run a test (build a little test app that makes 10,000 of each, run it a couple of times and get an average).

I would just create one kind of button class since you can draw or add other display objects into it. You don't even need a boolean to control that. For example :
public class OneKindOfButton extends Sprite{
public function OneKindOfButton(width:Number,height:Number) {
create(width,height);
}
private function create(width:Number,height:Number):void
{
graphics.clear();
graphics.beginFill(0xff0000,1.0);
graphics.drawRect(0,0,width,height);
graphics.endFill();
}
}
Now you can use this class to create any size of button.
var myButton:OneKindOfButton = new OneKindOfButton(200,20);
myButton.x = 100;
myButton.y = 300;
addChild(myButton);
If you want to use images instead of drawing into the button you can do that too by just adding bitmaps into the button sprite.

I think all these answers kind of miss the point of Flash.
Firstly, I don't think that View classes should ever have constructor arguments in Flash, because right off the bat you're making it impossible to ever use them on the timeline/stage. The Flash player can't (and shouldn't) provide these constructor arguments. The stage and timeline are Flash's biggest strength, so if you're not using them, you're wasting at least 25% of your time (the time where you're setting x, y, width, height, drawing graphics programmatically and all that unnecessary crap). Why lock yourself into a design that actively prevents you from using all the tools at your disposal?
The way I do it is I have one Class that defines the behavior of the button. Then the buttons are differentiated by having a library symbol for the big button, one for the small button, one for the button shaped like a pig, one for the button that looks like a spaceship, whatever. Any of these symbols will have that single Button Class as the Base Class (or more likely, just be defined as a Button in the library, so they subcass SimpleButton). Then I just place an instance of the library symbol on the stage and the variable in whatever parent Class is typed to my Button Class or SimpleButton.
The advantage of doing this is that the parent Classes don't need to know the specific implementation type, just the more general type. This means that the library symbols can have "export for Actionscript in frame N" unchecked, and they can just be compiled in where they are used. This means that initial load time can be reduced to the point that you may not ever need a preloader, depending on what else you have going on.
For more on this approach, see Combining the Timeline with OOP in AS3.

If the only difference between you two buttons is their look, but all the logic is shared, then you should definitely use only one common class.
If you're dealing with spark button, then you can simply specify a different skin for each of your instances (about spark skins).
package
{
import spark.component.Button;
public class MyCustomButton extends Button
{
static public const SMALL:String = "smallButton";
static public const BIG:String = "bigButton";
static private const DEFAULT_SIZE:String = SMALL;
public function MyCustomButton(type:String = DEFAULT_SIZE)
{
super();
if (type == SMALL)
{
setStyle("skinClass", SmallButtonSkin);
}
else
{
setStyle("skinClass", BigButtonSkin);
}
}
}
}
You then have to create to different skin classes where you'll define the visual logic of your buttons.

Related

Assign super to variable in AS3

I have this:
public class Base {
public function whoAmI() {
trace("base");
}
}
public class Extended extends Base {
public function Extended() {
this.whoAmI() //prints extended
super.whoAmI() //prints base
var test = super;
test.whoAmI() //prints extended
}
public override function whoAmI() {
trace("extended");
}
}
The problem is when I do var test = super, it seems like this is assigned to test instead of super.
Is it possible to do the assignment so that test.whoAmI() prints "base"?
Edit: In the comments it is being said that using super in the way I propose would break overriding. I don't think that's the case. The way I am thinking of it, super could be used the same way as this. I understand that is not the way super is implemented, but using it that way would not break overriding as people are claiming. So for example the same way this is possible:
var test = this;
test.whoAmI();
This should be possible:
var test = super;
super.whoAmI();
It is obviously the choice of the language implementer to not do things this way, and I don't understand the reason why. It doesn't break things, but I guess it does make them more complicated.
I am not suggesting type-casting this to the super class. Obviously that wouldn't work.
You are thinking of "this" and "super" as 2 different instances, 2 different things but they in fact point to the same object (obviously) so at the end it's always "this". Using super is just a special keyword that allows the instance to point to the overrided definitions up the inheritance chain, it does not point to a different object. So "super" does correctly its job, it points to the instance and allow you each time you use it to access overrided definitions and that's it. There's of course no point on trying to store that keyword in a variable since in that case it just return correctly the instance it points to which is always "this".
It's simply a case of misunderstood inheritance principle and I've seen it before, super is mistaken for some kind of instance wrapper up the inheriatnce chain around the object "this" while it's in fact and always the same object.
No, this is not possible.
If this were possible, then overriding methods wouldn't be possible!
For example, take this function...
public function test(a:Object):void {
trace(a.toString());
}
You'd only get [object Object] back if your idea was how things worked.
Ok I understand what you mean your question is more about language definition and specification.
Look at this exemple in c# that explain how you can manage more precisely overriding in c# :
http://www.dotnet-tricks.com/Tutorial/csharp/U33Y020413-Understanding-virtual,-override-and-new-keyword-in-C
But
let's explain a litlle how it's work.
when you extend a class, it's like if you create an object composed of all the object in the inheritance tree so if B extends A and C extends B you have two objects like this:
(B+A) and (C+B+A) with hierarchy between each other B->A and C->B->A. Super is just a way to ascend in the hierachy.
When you cast a C in A for example. In memory you always have an object (C+B+A) but interpreted as A. When you override you just say that a method in child has an higher priority than in parent.
You can try downcasting this manually to any of your class's predecessors. The pointer will still be equal to this but the methods called will use the class table of the class used to downcast.
public class Extended extends Base {
public function Extended() {
this.whoAmI() //prints extended
super.whoAmI() //prints base
var test:Base = this;
test.whoAmI() //should print base
}
public override function whoAmI() {
trace("extended");
}
}
Should your Base extend something, which methods are known or the superclass is dynamic, and there is code that adds methods to prototype of a class, you might use such a downcast to call a superclass's method that might not be there at compile time, but make sure you first call hasOwnProperty in case of a dynamic class to determine whether a method or property exists.

MVVMCross - display view inside view

I cannot seem to find any simple examples of this.
I have a WPF UI that I wish to display a view as a child control within another view. The MvxWpfView inherits from UserControl so it should be possible, however I cannot seem to work out how to do the binding.
I get a BindingExpression path error, as it cannot find ChildView property in my ParentViewModel.
So how do I bind a view to control content?
Firstly it's possible that you just need to add the BViewModel you want displayed on AView as a property on ViewModelA
E.g.
public class AViewModel: MvxViewModel
{
public BViewModel ChildViewModel
{
get;set;//With appropriate property changed notifiers etc.
}
}
Then inside AView you just add a BView, and you can set the datacontext of BView as follows:
<UserControl DataContext="{Binding ChildViewModel}"/>
However, if you want something more flexible (and you want the presentation handled differently for different platforms) then you will need to use a Custom Presenter
Inside your setup.cs you override CreateViewPresenter:
protected override IMvxWpfViewPresenter CreateViewPresenter(Frame rootFrame)
{
return new CustomPresenter(contentControl);
}
Now create the class CustomPresenter you need to inherit from an existing presenter. You can choose between the one it's probably using already SimpleWpfPresenter or you might want to go back a bit more to basics and use the abstract implementation
The job of the presenter is to take the viewmodel you have asked it to present, and display it "somehow". Normally that mean identify a matching view, and bind the two together.
In your case what you want to do is take an existing view, and bind a part of it to the second view mode.
This shows how I have done this in WinRT - but the idea is very similar!
public override void Show(MvxViewModelRequest request)
{
if (request.ViewModelType == typeof (AddRoomViewModel))
{
var loader = Mvx.Resolve<IMvxViewModelLoader>();
var vm = loader.LoadViewModel(request, new MvxBundle());
if (_rootFrame.SourcePageType == typeof (HomeView))
{
HomeView view = _rootFrame.Content as HomeView;
view.ShowAddRoom(vm);
}
}
else
{
base.Show(request);
}
}
So what I'm doing is I'm saying if you want me to present ViewModel AddRoom, and I have a reference to the HomeView then I'm going to just pass the ViewModel straight to the view.
Inside HomeView I simply set the data context, and do any view logic I may need to do (such as making something visible now)
internal void ShowAddRoom(Cirrious.MvvmCross.ViewModels.IMvxViewModel vm)
{
AddRoomView.DataContext = vm;
}
Hopefully that makes sense! It's well worth putting a breakpoint in the show method of the presenters so you get a feel how they work - they are really simple when you get your head around them, and very powerful.

How to properly structure functions?

let's say we have a class with some methods in it, of which at least one is of rather complex nature:
class Example {
public function Example()
{
}
private function complexFunction():void
{
//Do this
//And do that
//And of course do that
//and do not forget that
}
private function otherImportantFunction():void
{
//Do something
}
//[...]
}
Now "complexFunction()" has grown pretty long and also a little complicated. So a nice thing to do to increase readability would be to split up "complexFunction()" in smaller sub-functions. I usually do it like this:
class Example {
public function Example()
{
}
private function complexFunction():void
{
doThis();
doThat();
andOfCourseDoThat();
andDoNotForgetThat();
}
private function doThis():void
{
//Do This
}
private function doThat():void
{
//Do That
}
private function andOfCourseDoThat():void
{
//And of course do that
}
private function andDoNotForgetThat():void
{
//And do not forget that
}
private function otherImportantFunction():void
{
//Do something
}
//[...]
}
But by now the class is already drowning in minor functions whose sole purpose is to get called once inside "complexFunction()". Do this "splitting-up" a little more often and it becomes hard to spot the important methods between all those helper-functions.
At least this is what happens to me all the time and clarity really suffers for it. That makes me wonder if you know a way to solve that dilemma? Surely there is way or 'best practice' to handle this?
I'm dreaming of a way to group functions together, or to subordinate the minor ones to the superior ones, without creating a whole new class for that purpose. Or is that how it's done?
You are right to split up the one large function into multiple functions. Provided it isn't something like AddOne() instead of value++. Especially functions you'll probably repeat more often can be of use.
When your class is getting filled with multiple functions (or long functions), it might be a good idea to reconsider what your class does. Try to keep your class destined for one subject. For example, a good idea for a class is to make it User-related. Things like creating or removing users can be done in there. Even matching users to, for example, cars they own can be done in there. But don't include functions in the User-class which save or remove Cars. Save that for a different class.
In that case, your Example-class would have instances of the User-class and the Car-class. If it looks like this, you're programming efficiently:
class Example {
function Example()
{
}
function complexFunction():void
{
Car newCar = new Car("KK-E8", Color.Red, true);
carManager.Add(newCar);
User newUser = new User("Moritz", "Krohn", Country.Germany, true);
userManager.Add(newUser);
newUser.addCar(newCar);
...
}
It happens that some classes tend to get large, even when you try to keep things organised. That is never a bad thing, neither are long functions. Just try to keep things seperated, try not to repeat code too much (create functions for that) and try to keep things related to eachother in seperate classes.
I personally find that it increases readability of complex code a lot if it is split into simple functions.
What I don't really get in the code presented is the way those simpler functions are combined into one function, this seems only to work for functions that don't return anything at all (they just seem to have some effects). A more natural way imho to build up a complex function from simpler ones, would be by way of function composition, case distinction or something alike...
Just because a function is "long" does not make it more complex, Some things just take many lines of code.
Take for example:
var loader:Loader = new Loader();
loader.contentLoaderInfo.addEventListener(Event.COMPLETE, completeHandler);
loader.contentLoaderInfo.addEventListener(HTTPStatusEvent.HTTP_STATUS, httpStatusHandler);
loader.contentLoaderInfo.addEventListener(Event.INIT, initHandler);
loader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, ioErrorHandler);
loader.contentLoaderInfo.addEventListener(Event.OPEN, openHandler);
loader.contentLoaderInfo.addEventListener(ProgressEvent.PROGRESS, progressHandler);
loader.contentLoaderInfo.addEventListener(Event.UNLOAD, unLoadHandler);
loader.contentLoaderInfo.addEventListener(MouseEvent.CLICK, clickHandler);
var request:URLRequest = new URLRequest(url);
loader.load(request);
Is it "long"? yes
Does it have a high Cyclomatic Complexity? no
You can plainly understand what is going on here and it very easy to follow.
And you will find functions/methods with low CC values will always be easier to read.
On the other hand methods with high(+20) CC value should be putting up a red flag.
Splitting a method into separate helper methods does not remove the issue at hand and is actually making things worse for the compiler since now it has to allocate resource devoted to those methods that will only ever be called once.
The rule of thumb is to avoid going above a CC value of 20.
When you get above 20 it is time to start rethinking your class design as it is becoming tightly coupled.
Perhaps the question you should be asking is .
How can I reduce the Cyclomatic Complexity of this?

Is it possible to change an inherited access modifier in ActionScript 3?

I'm currently working on a project where I have a ton of classes inheriting from other classes which inherit from other classes and so on. It's probably more complex than it should be, but I am a sucker for abstraction.
Anyway, at times I need to change a getter/setter from being public to private. I suppose it's not really a need, but a desire to cut off things that are preset in child classes, but still need to be publicly accessible in the parent classes.
So an example would be:
Class Base {
public function set label( value:String ):void{};
}
Class A extends Base {}
Class B extends A {
public function B() {
super();
this.label = "stuff";
}
override public function set label( value:String ):void {
//this setter should not be publicly available since the label should not be possible to change in this class
}
}
Currently, I am doing one of two things in these cases:
override the setter to do nothing or set it to the default value so that it can still update/render/whatever
throw an error saying it is unavailable in that class
I've done some searching and everything seems to point to this being impossible, but I've never found it explicitly stated that it is impossible. So is it possible to change the access modifier on an inherited property/function?
It is not possible, and it really should not be, because it leads to confusing and unpredictable class hierarchies. For starters, if you did something like that, you would break the Liskov Substitution Principle: A super class should at all times be replaceable by its derived classes. Changing the API would clearly prevent that - and thus possibly lead to runtime errors and/or inexplicable glitches, if another programmer accidentally exchanged types.
If the classes you are modeling have different behavior in such a way that would make you "hide" an otherwise public API method, you should probably not use inheritance for this - or perhaps in a different way. From what you are describing, I would guess that in a larger part of your hierarchy, you should probably be using composition instead of inheritance, anyway.
It is not possible for the very reason in the comments by Marty Wallace. But it's not an uncommon thing to do.
However in the alternative you used, The property owner is the base class & hence it should always know of anything that the derived class does with it's own properties.
Instead of your hack I would thus prefer something like this :
public class Base {
protected var _isLabelUsable:Boolean = true;
public function set label( value:String ):void {
if (!_isLabelUsable)
throw new Error("Access of undefined property label.");
// Set Label here
}
}
public class A extends Base {
}
public class B extends A {
public function B() {
super();
_isLabelUsable = false;
}
}
These are all valid points, but...
There are cases where they are all void.
Given a base class that comes from an external source. Like, say, mx:Panel.
It has the property 'titleIcon:Class'
The derived class inherits all properties and functions. But people using it shall never set the titleIcon directly, because part of the derived class' functionality depends on the availability of an icon name being known. It provides a property iconName:String. Setting it will also set the titleIcon.
Now how to prevent people from still setting the icon directly? The UI is offering the old property for AS3 and MXML, and the compiler will (of course) not complain.
If titleIcon is a setter/getter pair (in this case, it is), and not final, then the derived class can override the setter and throw an error, while the iconName setter will assign the icon class to super.titleIcon.
However, this is clumsy and will not work for final functions or variables.
If there were a way to at least tell the UI to not offer the property anymore or show a warning...

Game logic and game loops in ActionScript 3

I am making a Shooting game in flash actionscript 3 and have some questions about the flow of logic and how to smartly use the OOPs concepts.
There are mainly 3 classes:
Main Class: Initializes the objects on the screen.
Enemy Class: For moving the enemies around on the screen.
Bullet Class: For shooting.
What I want to do is find out if the Enemy has been hit by a bullet and do things which must be done as a result ...
What I am doing right now is that I have a ENTER_FRAME event in which i check collision detection of each enemy unit (saved in an array) with the bullet instance created, and if it collides then perform all the necessary actions in the Main class .. clogging the Main class in the process ..
Is this the right technique ? or are there better solutions possible ?
Try to think more OOP, what is every object responsible for?
We have the enemies wich we can hit:
class Enemy : extends NPC implements IHittable {
. . .
function update(delta) {
// move, shoot, etc.
}
function handleHit(bullet) {
// die
}
}
A hittable object:
interface IHittable {
function handleHit(bullet);
}
The bullet is suppose to move and hit things:
class Bullet : {
function update(delta) {
// update position
}
function checkHits(world:World) {
for each(var hittable:IHittable in world.objects) { // might want to cluster objects by location if you're handling lots of objects / bullets)
if (isColidingWith(hittable))
o.handleHit(bullet);
}
}
}
And then we have the world with everything inside:
class World {
var npcs: Array ...
var bullets: Array ...
var hittables: Array ...
function update(delta) {
foreach(var c:NPC in npcs)
c.update(delta);
foreach(var b:Bullet in bullets) {
b.update(delta);
b.checkCollisions(world);
}
}
}
And your main loop is just simple as that:
var lastTime:int;
function onEnterFrame(...) {
var now:int = getTimer(); // FlashPlayer utility function to get the time since start (in ms)
world.update(now - lastTime);
lastTime = now;
}
A few other notes:
try to do all the computation based on a delta of time, otherwise the game's speed will vary with the framefrate.
what happens when a character dies? bullet disappear? Well, you could do it several ways:
fire an event, like EnemyDied and remove it from the world
implement an interface CanDie that has a (get dead():Boolean property) and use that to cleanup the world at every update.
but don't write the code to remove the enemy in the Enemy class, because then you will be polluting the class with code that should be handled by the World, and that will be hard to maintain later.
Sorry for the long answer, but I couldn't help myself :)
Was clogging the Main class the problem, or finding out what bullet hit what enemy the problem? If it was the bullet, you need to describe the bullet behavior - can it hit multiple enemies, how fast does it move (is it possible that when testing using "enterFrame" the bullet will first appear in front of the enemy, and, on the second frame, it will appear behind the enemy?). May enemy be simplified to some basic geometrical shape like circle or rectangle, or do you need pixel-perfect precision? Finally, how many bullets and how many enemies are you planning to have at any one time? It could be too expensive to have a display object per bullet, if you are going to have hundreds of them, and then it could make more sense to draw them into single shape / bitmapdata.
If the problem is that the Main class is too long, there are several possibilities here.
A nobrainer answer to this problem - use inheritance to simply put parts of the code in separate files. Not the best way, but a lot of people do it.
If you did the first, then you'd realize that there are certain groups of functions you put into superclass and subclasses - this will help you split the "clogged" class into several smaller independent pieces that have more particular specialization.
After you did the second, you may find out that there is certain dependency between how you split the big class into smaller classes, so you can try generating those smaller classes by a certain pattern.
And then you write the clogged code that generalizes those parts you just managed to split.
Above is basically the cycle from more concrete to more generic code. In the process of perfecting the last step, you'll write some concrete code again. And that will move you to the step 1. Lather, rinse, repeat :) In fact, you don't want to write OO code, or procedure code or anything that fashion of the day tells you to do. You want to write good code :) And you do it by moving from more generic to more specific and back to more generic, until it's perfect :P
Probably not the best answer, but you must admit, you didn't give much info to give you more precise answer.