Basic OOP question...
I want to add a couple functions to the Array class so that my program will be amazing and make me rich and famous overnight.
So I create a new subclass NewArray which extends Array. Do I need to write a constructor method for NewArray? If I leave it blank will it just use the parent's (Array's) constructor method?
Thanks
Yes, if you leave it blank it'll use the super-class' default constructor, which in the case of an Array is actually a constructor with a default value set:
Array(numElements:int = 0)
So by default you'll be creating an array with zero elements, which I guess is probably what you want anyway.
And don't forget this note from the docs:
You can extend the Array class and override or add methods. However, you must specify the subclass as dynamic or you will lose the ability to store data in an array.
http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/Array.html
Related
Regarding data classes it is forbidden to not use var or val keywords in the primary constructor, i.e. every parameter is implicitly turned into a class property. However, sometimes there are cases which I don't want each parameter to be turned into a class property.
So, as far as I can see, there is no chance of passing a parameter in a primary constructor that is accessible only within the constructor and is forgotten after the construction of the instance has finished. Is there a good reason for this?
The only way I see to get around this, is not to use data classes or to use a secondary constructor that allows for non-var/val-prefixed variables. However, having a lot of parameters that need to be passed, a secondary constructor would immensely inflate the class. Of course, I could wrap all the parameters into another object, but that would just kind of shift the problem to another place.
Is there a recommended approach or pattern in order to cope with that?
You are not limited at all, you just have to do things a bit differently.
Data classes are intended to be very clear about what they contain and in what order, and only allow members in the primary constructor parameter list.
But you have other options: use a secondary constructor, and/or create top-level functions with the same name as the class with different overloads, or create factory methods in the companion object:
data class Person(val name: String, val age: Int) {
// secondary constructor
constructor (name: String): this(name, 0) {
// ... make a newborn
}
// factory methods in companion object
companion object {
fun of(name: String, birthdate: LocalDate): Person {
return Person(name, yearsSince(birthdate))
}
}
}
// function with same name as class acting like a constructor
fun Person(name: String, birthdate: LocalDate): Person {
return Person(name, yearsSince(birthdate))
}
// these all work now:
Person("Fred", 30) // primary constructor
Person("Baby") // secondary constructor
Person("Geoff", LocalDate.parse("12/08/1990")) // top-level function
Person.of("Jennifer", LocalDate.parse("01/01/1981") // companion function
You can also hide the primary constructor by making it private, but you cannot hide the copy version of that constructor.
By the way, having data classes with this contract for the primary constructor really help serialization/deserialization libraries know what to do with the class that would be guesswork otherwise. It is a good thing!
Fist thing that I must say is that this is my personal opinion so take it with grain of salt.
From official kotlin documentation
We frequently create classes whose main purpose is to hold data. In such a class some standard functionality and utility functions are often mechanically derivable from the data.
So data classes are supposed to be used as data holders, and they shouldn't contain much logic.
From my perspective when you want to pass something to constructor but class doesn't store that data then there is probably some logic connected with that.
Common situation when you want to do this is:
Using some flag to change behavior of constructor
Passing some class that wraps all data needed and then extract it to each individual field.
In first case then we clearly see that this isn't part of data class use case.
And second case is simply bad code, it introduces unneeded dependency on another class and hides what that class actually needs.
Constructors should be simple, they take data that class requires and bind it to fields, not much logic should reside there, it should be up to those that use constructor to prepare all data, and if there is some repeatable code when creating new instances then it might be good idea to use factory method to encapsulate that.
Ok, so this might be me being pendantic but I need to know the best way to do something:
(This is psudocode, not actual code. Actual code is huge)
I basically have in my package a class that goes like this:
internal class charsys extends DisplayObject {
Bunch of Variables
a few functions
}
I another class which I intend to add to the timeline I want to create a function like this:
public class charlist {
var list:Array = new Array();
var clock:Timer = new Timer(6000);
var temp:charsys;
function addObj(MC:DisplayObject, otherprops:int) {
temp=MC;
temp.props = otherprops;
list.push(temp)
}
function moveabout(e: event) {
stuff to move the items in list
}
function charlist() {
stuff to initialize the timers and handle them.
}
}
So the question is, is my method of populating this array a valid method of doing it, is there an easier way, can they inherit like this and do I even need to pass the objects like I am?
(Still writing the package, don't know if it works at all)
Yes, you can pass an object into a function, but you should be careful of what you are planning to do with that object inside that function. Say, if you are planning to pass only charsys objects, you write the function header as such:
function addObj(MC:charsys, otherprops:int) {
Note, the type is directly put into the function header. This way Flash compiler will be able to do many things.
First, it will query the function body for whether it refers to valid properties of a passed instance. Say, your charsys object does not have a props property, but has a prop property, this typing error will be immediately caught and reported. Also if that props is, for example, an int, and you are trying to assign a String value to it, you will again be notified.
Second, wherever you use that function, Flash compiler will statically check if an instance of correct type charsys is passed into the function, so if there is no charsys or its subclass, a compilation error is thrown.
And third, this helps YOU to learn how to provide correct types for functions, and not rely on dynamic classes like MovieClip, which can have a property of nearly any name assigned to anything, and this property's existence is not checked at compile time, possibly introducing nasty bugs with NaNs appearing from nowhere, or some elements not being displayed, etc.
About common usage of such methods - they can indeed be used to create/manage a group of similar objects of one class, to the extent of altering every possible property of them based on their corresponding values. While default values for properties are occasionally needed, these functions can be used to slightly (or not so slightly) alter them based on extra information. For example, I have a function that generates a ready-to-place TextField object, complete with formatting and altered default settings (multiline=true etc), which is then aligned and placed as I need it to be. You cannot alter default values in the TextField class, so you can use such a function to tailor a new text field object to your needs.
Hope this helps.
This would work, I think I would assign values to the properties of the charsys object before passing it into the add method though, rather than passing the properties and having a different class do the property assignment. If you have some common properties they could either have defaults in charsys class definition or you could set literals in the addObj method.
I was reading ActionScript 3.0 Abstract Factory Design Pattern: Multiple Products and Factories, and I have the following,
private var busFactory:AbFactory;
busFactory=new BusinessFactory();
Both in BusinessFactory.as and in AbFactory.as there is no method with the same name as the class, only createProductA and createProductB. So, how could busFactory call the constructor with new BusinessFactory ?
The default constructors for both AbFactory and BusinessFactory (which the article shows inherits from AbFactory) are created by the compiler.
If you start to pass arguments to the BusinessFactory() constructor, the compiler will complain about an unexpected argument count. That's when you need to write the constructor yourself. But passing nothing means the default can be used.
Also the reason that you could set a AbFactory to a BusinessFactory means that they share the same heritage.
In Java, this can be done with LinkedHashMap by removing eldest entry/oldest accessed entry. Any equivalent class in ActionScript 3?
Thanks.
No, unfortunately not. You could easily implement one, if I were going to implement it I would extend the Proxy object It'll give you a fair bit of flexibility.
UPDATE:
This update is to clarify on the question in the comment by the OP. Comment was "It will be a new class extends Proxy and not Dictionary/etc?"
Yes, you would want to extend Proxy, the reason for this is that it allows you to override several magic methods to accomplish your goal. Particularly in your case, you can override setProperty(name:*, value:*):void. This method will be called every time a property is set on your class (its up to you to supply the set implementation) so you can count the number of values that are set at a given time. If you extend Object or dictionary, you do not have access to this, and have know way of knowing when a new property is set.
If you extended object instead, you would need to rely on an interface to to acheive your goal, requiring user to set properties through method calls.
A Proxy implementation would allow you still set properties like this:
myObj.foo = 'bar';
myObj["foo"] = 'bar';
A method implementation (extending Object) would look like this:
myObject.setVal("name", "val");
For example, suppose I this:
class Gundam00 extends Gundam implements MobileSuit {
...
public void fight(final List<MobileSuit> mobiruSuitso, final List<Gundam> theOtherDudes, final List<Person> casualities) {
....
}
}
Suppose theOtherDudes and casualities parameters are optional. How can I make this method as clean as possible? I thought about having booleans indicating if they're null, and then checking them as needed.
I could also have different versions of the method for each combination of parameters but there would be a lot of code duplication I think.
Any suggestions?
I find that past 2-3 arguments, the ability to remember what all the arguments to a function are suffers. And comprehensibility along with it.
Passing named arguments can help. Languages with a convenient hash-like literal syntax make this really easy. Take JavaScript:
g = new Gundam00();
g.fight({opponent: enemy, casualties: 'numerous'});
You can also take advantage of variable length argument features to work this in (treat odd arguments as names, even arguments as the actual parameters).
g.fight('opponent',enemy,'casualties', 'numerous');
And some languages actually support named arguments straight-out (see: http://en.wikipedia.org/wiki/Named_parameter#Use_in_programming_languages ).
Finally, you might want to consider adding other methods for this using what some call a Fluent Interface (http://en.wikipedia.org/wiki/Fluent_interface ). Basically, you've got method call which return the object itself, so you can chain calls together:
g.opponent(enemy).casualties('numerous').fight();
This might be the easiest option if you're working in a manifestly/statically-typed class-focused language.
Update
Responding to Setsuna's comment... in that last example, if you've got the luxury, you can make methods like opponent and casualties simple setters that don't affect any internal state or computation in any other way than setting a parameter for which they're named. They simply set internal properties up, and then all of the real work happens inside action methods like fight.
If you can't do that (or if you don't like writing methods whose operations are sub-atomic), you could stake out a half-way spot between this idea with the hash-like literal idea, and create your own collection class specifically for invoking named arguments:
n = new NArgs();
g.fight(n.arg('opponent',enemy).arg('casualties','numerous').arg('motion','slow'));
A little more unwieldy, but it separates out the named arguments problem and lets you keep your methods a bit more atomic, and NArgs is probably something you could implement pretty easily just wrapping some methods around one type of Collection (HashTable?) or another that's available in your language.
Add the methods. Overloading methods is generally an antipattern and a refactoring opportunity for someone else.
http://www.codinghorror.com/blog/2007/03/curlys-law-do-one-thing.html
I thought about having booleans indicating if they're null, and then checking them inside and reacting accordingly.
Or ... you could just check if they're null.
if(theOtherDudes == null)
...
If there is only one "main method" in your class, then you can implement the optional arguments as getter/setter functions. Example:
public void setOtherDudes(final List<Gundam> theOtherDudes) {} // for input arguments
public List<Person> getCasualities() {} // for output arguments
And then, in your documentation, mention that if the caller has any optional input arguments it has to be passed in before calling fight(), and the optional output values will be available when fight() has been called.
This is worthwhile if there are dozens of optional arguments. Otherwise, I suggest overloading the method as the simplest way.