I know global variables are supposed to be bad but is it possible to create global classes? I am creating an application and I want to have one class that handles sound. From any class I would like to be able to say soundhandler.playSound(); without having to pass references all over the place. It should just know it is there.
Any help greatly appreciated.
You're referring to static members.
Your class SoundHandler would have a static method called playSound(), which can be implemented like so:
package
{
public class SoundHandler
{
public static function playSound():void
{
// #todo Logic
}
}
}
Your playSound() method is now accessible via:
SoundHandler.playSound();
Note: You mentioned global methods being bad, however this is a perfect candidate for these and something I would actually recommend (as much as I hate using static).
Additional: ActionScript 3's Math class contains mostly static members e.g. Math.round()
Your question (comment): Do I need to initiate SoundHandler in the document class?
No, in fact you shouldn't make an instance of SoundHandler at all. The only requirement is that you must have SoundHandler imported in your current class to access it:
import yourpackage.SoundHandler;
Related
I know some of the terms I use are confusing. To clarify, a driver class is basically one built on a class definition (starting with public class...) but is a method itself with the header public static void main (String args[]).
The point of this post is to resolve my serious confusion. (I am a beginner in programming)
to me, since a driver class is a method, all it does is to implement itself. But things kinda turn out to be the opposite . For example:
to implement a constructor in a driver class, you simply put down the constructor heading, like public Rectangle(), with its name being the same as that of the class. but in a class definition, to creat a object/ implement a constructor, you also have to write down happen inside that constructor, so you use the expression "type name = new type name ()".
PS: I might have used some terms wrongly, correct me thanks. Or some concept
I'll try to answer this the best way that I can.
Let's look at each of the keywords in a "driver class method" and determine the meaning.
public - this method is publicly callable by a class outside of it
static - this method is callable WITHOUT an instance of the class. In Java, look at the Math class. You don't need to instantiate an instance of the Math class to use the sqrt function (Math m = New Math(); m.sqrt(25);), you can just use Math.sqrt(25).
void - this method returns nothing
main - name of the method
Now that we have that cleared up, let's ask ourselves why these things have to be here for a "driver class"
The Virtual Machine (the program that runs your custom programs) is hard coded to look for a method named main that is public and can also be called WITHOUT CREATING AN INSTANCE OF YOUR CLASS.
So this means that when your program first runs, there is no instance of it.
To counter this, you can either create all of your methods and properties as static (generally considered bad practice) OR you can create an instance of your own class inside of it's own entry method, and begin to call the non-static methods and properties that belong to the instance.
I hope this makes sense.
I've bought an external component composed by the MXP component and two external swf.
Obviously I haven't any source or fla file.
I've imported the component in my own project and it works fine (combined with the two external swf). Now I've debugged and decompiled one of this two external swf whith a stand alone program (SWF Decompailer) in order to find two functions I wanto to manage.
I've found their name [forceNextImage() and forcePrevImage()] and the class where they are declared.
The problem is that those functions are protected and I've the necessity to call them inside my project (the project where I've imported the components, of course). There's a way to do that? And how?
I hope I've been understandable even with my lacking english, but if not don't esitate to ask me..
Thanks in advance.
Fabrizio
Can you subclass it, and then call it from the subclass?
protected methods are callable from subclasses, so you can extend the component and expose them:
public class YourComponent extends Component
{
public function nextImage():void
{
forceNextImage();
}
public function prevImage():void
{
forcePrevImage();
}
}
Say I have the following set up of classes...
Road - extends MovieClip Car - extends Road
Controller - extends Car
And I want to incorporate some common Mathematical functions in them all to make them faster e.g.(replacing Math classes with some speedy bitwise versions).
What is the best way to incorporate these functions into all of them without writing the functions in the classes or extending from class of the functions. Is importing the class into each the fastest way or is their a better way?
You can create a public function that you can import into any class. Some examples in the base language are navigateToURL() and getTimer(). These are just public functions in a package, not classes.
So create a public function like so
package nameOfYourPackage{
public function doSomething(a:arguments):returnType
{
// Stuf the function does goes here;
}
}
then you can import it into any class like so:
import nameOfYourPackage.doSomething;
and then youc an call it anywhere in a class that imports it as:
doSomething(args);
I agree with the comments that your design may needs some work. You can't use a Class in another Class without an import statement that refers to it in some way--even if you're just importing an Interface that the Class implements.
The most flexible way to handle this is to have the functional object be passed in to the object that needs it, rather than having that object create the instance itself. This will allow you to swap out a different implementation when you need to (for instance, you might want to use a mock instance for unit testing, or you might need slightly different functionality optimized for a mobile device).
You can pass in the instance either in the Constructor or use a property (which would allow you the freedom to change out the implementation at runtime).
I currently pass a reference to my model through the constructor to any class that needs it in my simple mvc pattern, this can get annoying at times when it starts to go deeper.
How do Classes such as LoadMax allow you from anywhere to simple import the class, and do something like addChild(LoaderMax.getContent("bg"));? Replicating this should surely be a good way to have my model work, without the complexity of big frameworks?
Statics are your friend
As previous answers have noted, TweenLite/Max etc. makes heavy use of static members to get work done. This is exactly like the Math class, for example, and can be a very convenient design pattern. You have global access to the class, and that can definitely alleviate the issue of getting access to variables through deeply nested classes.
Statics are the enemy
Statics, however, bring certain problems to the table. Most importantly, they tend to reduce flexibility and modularity of classes through the often unnecessary addition of tightly coupled relationships. It's a bit like pouring concrete over your application. It does work, but changing behavior becomes difficult as project features change.
Static members != instance members
Note, very clearly, that a static member "belongs" to the class itself, and not an instance of that class. Static members have no access to instance members. This causes troubles when you want to mix these members up in logic. You tend to have to make everything static (the so-called "static-cling" effect). Static patterns are often argued to be argued to be "anti" object-oriented, for precisely this reason. Once you build a structure on a static pattern you tend to lose many of the principles that makes OOD powerful.
In small does, they're pretty nice
That all being said - TweenLite is a great example of a static pattern that is totally appropriate - its a utility package, one that logic is not dependent on. And that should probably be how you leverage statics, too.
To reduce reliance on statics, or even global vars, it does often mean writing more code, but the flexibility in app structure gained is often quite worth it. #Marty_Wallace has a pretty good solution imo.
Demeter and the Paperboy
Finally, I'll just mention the Law of Demeter, or the Principle of Least Knowledge, and the related Paperboy and the Wallet example, which is often pointed to in discussions of statics:
Each unit should have only limited knowledge about other units: only
units "closely" related to the current
unit.
Each unit should only talk to its friends; don't talk to strangers.
Only talk to your immediate friends.
Hopefully that sheds a little bit of light on a fairly complicated and not-often obvious issue.
This is done using the static namespace, however I discourage the use of this.
package
{
public class Main
{
public static function sayHell():void
{
trace("hello!");
}
}
}
You can now call sayHello() like this from anywhere in the application (assuming you've imported the class).
Main.sayHello();
Another thing you can do (to make the entire class accessible from within the application) is create a static property that refers to the class itself:
package
{
public class Something
{
public static var instance:Something;
public function Something()
{
instance = this;
}
public function someFunction():void
{
trace('hello!');
}
}
}
Which you can now use like so:
Something.instance.someFunction();
The only thing to note here is that you need to create an instance of Something for this to work to call the constructor and define instance.
What I would do
Create a base class for all objects in your application
Create a manager class that takes care of these objects
Create a setter within your base class to define the manager
Here's an example:
Base
package
{
public class Base extends Object
{
private var _manager:Manager;
public function set manager(m:Manager):void
{
_manager = m;
init();
}
protected function init():void
{
manager.someFunction();
}
public function get manager():Manager{ return _manager; }
}
}
Manager
package
{
public class Manager extends Object
{
public function someFunction():void
{
trace('hello!');
}
}
}
Now anything that extends Base will have access to anything held in Manager via the manager getter property. All you need to do is make sure you define the manager, which is easily achieved from within anything that extends Base like so:
var something:SomeExtendingClass = new SomeExtendingClass();
something.manager = manager;
The example you gave is just a static method, but to answer your question about a global instance of a class:
package myPackage
{
public var globalVariable:MyClass = new MyClass();
}
You can access it with:
import myPackage.globalVariable;
trace(globalVariable);
I think you have to rethink in which way you want to name your classes.
You can instantiate whatever class you want, at run-time, but to access a instance by name, you have to make changes in your structure. For example, the getContent() function you mentioned in LoaderMax, all it does is to search in an array for the given loader that matchs the name, among other things. You can read the name variable comment for a description.
A name that you use to identify the loader instance. This name can be fed to the getLoader() or getContent() methods or traced at any time. Each loader's name should be unique. If you don't define one, a unique name will be created automatically, like "loader21".
So in this system, you have to name every single member (loaders in this case) if you want to be able to search them. Because if I call getClassInstance("myinstance"), what is "myinstance" representing? Where should I name it?
That said, if you want to do it for DisplayObjects only, you can use getChildByName. But again, you have to name every DisplayObject (just set the name variable).
Hope this helps.
Please retag this question to include languages to which it is relevant
So my java book had a whole chapter on nested classes, but ended on the note that you should only really use them when it comes to "modeling composition relationships and implementing internals of a class you want to hide". So lets discuss when you would want to use nested classes and some examples.
A nested/inner class is just a class that's only ever used specifically in the context of another class, which doesn't have it's own class file. If it's linked to an instance, it can only be instantiated in the context of a parent class instance; it can see private data, or only private static data if it's a static class.
The java developer site has a nested classes tutorial with one example:
http://java.sun.com/docs/books/tutorial/java/javaOO/nested.html
A couple examples of usage:
Hide a concrete implementation of an
interface:
(Thinking of a database session for a tool like Hibernate): Suppose you have a Session interface, and a SessionFactory which returns an instance of a Session. The SessionImpl concrete class that implements the Session interface could be an innner class of the factory that knows how to construct and initialize it.
Supply information by implementing an
interface:
In the Wicket web framework, each GUI component has an associated "model", whose job is to wire data to the component. The interface looks something like:
public interface IModel extends IDetachable {
public Object getObject();
public Object setObject();
}
Suppose you have some special logic to retrieve data for a custom GUI component that you've written. Since no other component retrieves data the same way, you could use an anonymous class at the point where the IModel is supplied to take care of the data retrieval. If you have another point in the same class where you need to reuse your IModel implementation, you could make it an inner class. Later, if you need the model elsewhere, you could convert it to a top-level class.
Generally you use an inner class in a situation where you need a class definition, but that class is only usable or only makes sense in the context of the parent class.
A real life usage i had with nested classes, was in a global settings object.
The parent class was a Singleton, with nested classes as settings categories.
Settings
File settings
Print settings
Etc.
There was no real point in making the inner object as separate classes, as their would be no use for them outside the settings class scope.
I use nested classes for encapsulating algorithms that would be usually done as a method with lots of arguments. I use class that has raw data and I put algorithms into separate file in nested class (using partial keyword). That way I can put properties for that algorithm and its (working) data lives after algorithm is done.
I know that can be easily done without nested classes but this feels right because algorithm is purposely built for parent class.
public partial class Network
{
partial void initFDLF()
{
fdlf=new FDLF(this);
}
public FDLF fdlf;
public class FDLF
{
internal bool changed=true;
internal bool pvchange=true;
public double epsilon = 0.001;
public bool fdlfOk=false;
public void init(){...}
public void run(){...}
...