In Actionscript 3 I can't declare vars in Interfaces.
I don't get it.
I know i can work this around by defining getters and setters, but what if i just want a simple public property? I usually use getters and setters if there is something to do when i set or get a property, but what if i just want to store a value?
You can put it like this: interfaces exist because in your language you can't inherit from multiple abstract base classes. If AS3 would have allowed you to do that, it would probably not have 'interfaces', but 'pure abstract classses'.
In other words, having properties implementation in your interface would lead to name clashes and from there to other multiple inheritance problems (diamond).
However, having just a getter or a setter with no implementation should work.
public interface I { function get A():int; }
(I don't have the AS3 compiler at hand)
I'm not an actioscript programming, but interfaces (in java for example) are meant to define behavior not state, so intrerfaces in jave simply declare methods that the class implemeting the interface needs to define. Properties (or instance variable) are not in general necessary to define behavior and there are disallowed in interfaces.
Related
I have a set of C++/CLI classes I've written as wrappers to native C++ classes. For the C++/CLI classes: I placed the constructor declarations inside the private section of the class declarations and did not implement them, however this leads to linker errors in every case where I have an unimplemented constructor.
What is the appropriate way to delete the default constructor in C++/CLI?
This works in native C++ because it uses a linker. Which is happy with a missing member implementation if nobody asks for it. But that doesn't work in managed code, it doesn't use a linker. Your class definition is copied into the assembly metadata and binding happens dynamically at runtime.
Which requires all declared members to have a representation, the metadata would otherwise be incomplete and that's not supported since that would break reflection. Even for private members. Nothing particularly difficult to solve, {} is a perfectly good implementation for a private constructor.
I placed the constructor and destructor declarations inside the private section of the class declarations and did not implement them, however this leads to linker errors in every case where I have an unimplemented constructor or destructor.
Just because you make the constructor private does not mean you no longer have to implement them. You're still calling it; you have to implement it.
I know that packages are collection of Classes and Interfaces, designed to both organize and classify its contents.
I also know that Classes are the definition of Objects, and the instructions for both them, their attributes/variables, and their functions/methods.
However, I have yet to understand what an Interface is, or what it is really for...
I have read this definition on Adobe's website..:
interface
Usage
interface InterfaceName [extends InterfaceName ] {}
Defines an interface. Interfaces are data types that define a set of methods; the methods must be defined by any class that implements the interface.
An interface is similar to a class, with the following important differences:
• Interfaces contain only declarations of methods, not their implementation. That is, every class that implements an interface must provide an implementation for each method declared in the interface.
• Interface method definitions cannot have any attribute such as public or private, but implemented methods must be marked as public in the definition of the class that implements the interface.
• Multiple interfaces can be inherited by an interface by means of the extends statement, or by a class through the implements statement.
Unlike ActionScript 2.0, ActionScript 3.0 allows the use of getter and setter methods in interface definitions.
...However, this is too vague to be helpful to me.
Does anyone know the purpose and proper implementation and/or design of an Interface in ActionScript?
Interfaces basically let you announce "This class can do these things."
As a real world example, you might want to make a tutorial for a game which highlights each of the different controls on screen one by one. Each control might flash or bounce to highlight itself, so you can say they implement an "IHighlightable" interface, and let them take care of the rest:
public interface IHighlightable {
function highlight():void;
}
Then in your controls:
public class Control implements IHighlightable {
public function highlight():void {
// Bounce and flash!
}
}
This means you can do things like:
private function highlightControl(tutorialItem:IHighlightable):void {
tutorialItem.highlight();
}
Importantly, you can have a class implement multiple interfaces, which is useful when classes share abilities, but it doesn't make sense to have them all extend a common base class.
Interfaces are a contract. It is compile time mechanism to force your to implement methods. In large OOP code bases, it is the best practice to have other classes depend on interfaces rather than other classes, so you can swap the implementation without changing the code that consumes the interface (this advantage is discutable in practice, since very often the interface will change too).
I believe interfaces are borrowed from Java which introduced them to achieve polymorphism (ClassA can be of type IFoo and IBar at the same time) without inheriting from multiple abstract classes (you can only extend one class, but you can implement any number of interfaces).
Although I'm technically wrong, I consider interfaces to be similar to C++ abstract classes.
Wikipedia article on Abstract Types
Oracle Java documentation on Abstracts
MSDN article on C# Interfaces
Interfaces are meant to define properties and methods without actually implementing them. Also, they cannot be instantiated
var test:FooInterface = new FooInterface() // would error
I was wondering the differences between abstract and interface in actionscript 3 and when to use them..I have searched google but still couldn't understand them....I hope someone here can give me few tips...Thanks a lot!!!
The difference is that interface is valid actionscript, but abstract is not...
Now, in other languages you can mark a method or a class as abstract. This is somewhat like an interface, in that abstract means it has no implementation (for a method) or cannot be instantiated (for a class).
So, if a class is abstract, it means you cannot create an instance diretly (with new), but rather you have to extend the class to access its functionality.
An abstract method is pretty much like a method defined in an interface. When you extend a class that declares an abstract method, you have to provide an implementation that has the same signature, or your code won't compile. An abstract method makes the class abstract automatically, because otherwise you would be able to create an instance of an object that has an unimplemented method.
With an abstract class, you have some of the features of an interface (i.e. you define a method whose concrete implementation has to be provided) but you also can have other methods that are implemented and ready to use.
(This is a general explanation; maybe this is bit different in language X, but I think this gives you the basic idea)
I guess the question title sums it up. Is there a time when it would be considered good design for an ABC to have data members? I have been wondering if there is a situation where this is OK. The only ones I can come up with all are static, and even then it's kind of a stretch.
I don't see why an ABC couldn't properly have per-instance (aka non-static) data members, as needed to support the methods it supplies to subclasses. Take the common case in which an ABC exists to supply a Template Method DP (the hook methods being abstract) -- if part of the function of the organizing method is to update some instance variables (for example, a count of how many times the method was called), then obviously those variables should also be supplied by the ABC. Can you explain better why you think that's bad design?!
An abstract class can have whatever members it needs to support the functionality it supplies to the classes that inherit from it. That's not to say these would be directly accessible to the subclasses: they might be read and changed only through method calls made by the subclasses or their clients.
I see this in plugin architectures, like Paint.NET's.
Inversion of Control might require this. For example you have a bunch of classes that take an instance of Logger, the abstract class they're based off might have a constructor store it in an member variable or private property (assuming of course you remember to call the base constructor grin)
It is OK, when your data member in your abstract class contains base code for inheriting classes
I would think about using an interface, when the data member is just to describe your class
Yes, its possible to provide member variables in an abstract base class with the intention that its subclasses will use those members to make a concrete implementation.
Here's a concrete example, using a car analogy that we've all come to love.
Let's say we make Car an abstract base class, which has placeholders for wheels, chassis, and an engine for its its subclasses to use:
abstract class Car {
Wheels wheels
Chassis chassis
Engine engine
abstract void accelerate();
abstract void decelerate();
}
Now, for a class that extends Car, the members are already there to use, so the responsibility of a subclass is to populate those member variables:
class NiceCar extends Car {
Decoration decoration;
public NiceCar() {
wheels = new ChromeWheels();
chassis = new LightweightCompositeChassis();
engine = new LotsOfHorsepowerEngine();
decoration = new CoolRacingStripes();
}
void accelerate() {
engine.feedFuel();
}
void decelerate() {
wheels.applyBrakes();
}
}
As can be seen, the abstract base class can work as a blueprint for which components (member variables) should be filled in to get a full functionality of a class. In this case, the Car provides basic parts of a car to be used in a concrete implementation. NiceCar uses those member fields and adds some for its own features, such as a decorative paint job.
I suspect that you are drawing too tight a circle around your concept of an abstract base class.
An abstract base class (as opposed to a pure interface) is a class that intends for some of its functionality to be used by child classes. It will thus have some functionality along with methods that are intended to be over-ridden (the interface part). There is no reason why this functionality should not have member variables associated with it.
Many frameworks are based off of inheritance. These will almost inevitably have abstract classes with member variables. For instance, DirectShow is the multimedia streaming framework in Windows. The sources, encoders, decoders, etc. are all implemented in what are called "filters". There are base classes for various types of filters. Each of them will have member variables for the upstream and downstream filters, the negotiated media types, etc.
As others have mentioned one adds instance fields to any sort of class when one needs to store state. This holds true of abstract or concrete classes - there is no difference.
Why should it make difference ? After all an abstract class is just like anyclass except it can't be instsntiated, requiring subclassing etc to complete the class.
If it's a state used by all inherited classes, I think it's mandatory to move it to the base class. Even though the base is abstract. I think most people that are into refactoring would agree with me on this.
There might be several reasons why some state should be in the base. Reducing code duplication is a good reason enough.
This question already has answers here:
Interface vs Base class
(38 answers)
Closed 12 months ago.
I have been getting deeper into the world of OOP, design patterns, and actionscript 3 and I am still curious how to know when to use an Abstract class (pseudo for AS3 which doesn't support Abstract classes) and an interface. To me both just serve as templates that make sure certain methods are implemented in a given class. Is the difference solely in the fact that Abstract classes require inheritance and an Interface merely extends?
Use an abstract class if you have some functionality that you want it's subclasses to have. For instance, if you have a set of functions that you want all of the base abstract class's subclasses to have.
Use an interface if you just want a general contract on behavior/functionality. If you have a function or object that you want to take in a set of different objects, use an interface. Then you can change out the object that is passed in, without changing the method or object that is taking it.
Interfaces are typically loose, compared to Abstract classes. You wouldn't want to use interfaces in a situation where you are constantly writing the same code for all of the interface's methods. Use an abstract class and define each method once.
Also, if you are trying to create a specific object inheritance hierarchy, you really wouldn't want to try to do that with just interfaces.
Also, again, in some languages you can only have a single base class, and if an object already has a base class, you are going to have to do some refactoring in order to use an abstract base class. This may or may not mean that you might want to use an inteface instead.
As #tvanfosson notes, it's not a bad idea to use a lot of interfaces, when you really understand abstract classes and interfaces, it's not really an either/or situation. A particular situation could use both abstract classes and interfaces or neither. I like to use interfaces sometimes simply to restrict what a method or object can access on a passed in parameter object.
Abstract classes offer the possibility to implement specific methods and require others to be implemented in the inheriting class. With interfaces, everything has to be implemented in the implementing class.
As #m4bwav notes, the primary difference is that an abstract class can, and often does, provide a default implementation for at least some methods. This allows you to use the abstract class to keep your code DRY (don't repeat yourself), by keeping code common to all classes that inherit from the abstract class in the abstract class itself.
I think it's a false dilemma, though. You don't need to and arguably shouldn't choose between interfaces and abstract classes. In most cases, you would want to define the interface, then have your abstract class provide a default, skeleton implementation if one is required/desired. For me the question would be do I need an interface or an interface and an abstract class rather than an interface or an abstract class. Using the interface decouples your code from any particular implementation, even your abstract class implementation. If you should choose to have an alternate implementation, using the interface would allow this whereas if you only had the abstract class, you'd have to refactor to add the interface later.
The only situation where I can see that providing an interface in such a situation would not be desired is where you want to restrict it so that only your implementation can be used. Using the abstract class and having certain methods be not be virtual would enforce the use of your code in all circumstances where the implementer is deriving from your class.