static {
try {
StringBuffer sb = new StringBuffer();
sb.add("Kiran");
string s= "Vikram";
sb.add(s); }
catch (Exception e) {
logger.fatal("Exception", e);
}
}
I would suggest: not at all.
static is an abnormality in good OO design. And static init blocks are kinda even worse.
Instead: learn how to write testable code, for example by watching those videos over here. And then change your code to not do such things. And your need to mock those things ... vaporizes.
And especially as the code in your example doesn't have any side effect; as none of the variables used in there exist outside of that block. Probably you got some "reduced" example there; and in reality your static block is doing some kind of property init. But even for that case ... you might find better ways to do that; instead of putting them into a static block!
Related
How to write test case for this function in a binary search tree ?
void insert(String key){
root=insertRec(root,key);
}
Your method does something. It obviously changes the state of the object by inserting a rec(ord?) and somehow re-evaluating what the root is. So, to test it, you should somehow be able to determine the new state, for example...
public void insert_should_create_new_record_and_set_root() {
assertThat( myObject.getRec( originalRoot) ).isNull();
Object originalRoot = myObject.getRoot();
myObject.insert("xyz");
assertThat( myObject.getRec( originalRoot) ).isEqualTo( "xyz"); // using AssertJ style here
assertThat( myObject.getRoot().value() ).isNotEqualTo( originalRoot );
}
If, on the other hand, you have no way to check the state from the outside, then you'll have a problem. But somehow your class has to communicate to the outside, hasn't it? If you really think that you cannot check the new state, then you'll have to provide more code of this class, as this answer is, of course, very general (which means "guessing", here).
i'm a beginner in learning actionscript and i'm seeing examples to learn from them. in the following lines, what should i add or remove so i can hide or not show system messages? and what are these lines actually say?
public function set showSystemMsgs(param1:Boolean) : void
{
var _loc:* = this.showSystemMsgs;
if (_loc !== param1)
{
this.showSystemMsgs = param1;
this.dispatchEvent(PropertyChangeEvent.createUpdateEvent(this, "showSystemMsgs", _loc, param1));
}
return;
}
public function get showSystemMsgs() : Boolean
{
return this.showSystemMsgs;
}
public function removeEventListener(param1:String, param2:Function, param3:Boolean = false) : void
{
_bindingEventDispatcher.removeEventListener(param1, param2, param3);
return;
}
If your goal is to understand code, stop reading decompiled code. This is not code meant to be read by humans opposed to what the code looked like before compilation.
There are plenty of resources on pretty much everything available by now, with explanations, comments and readable code.
object.showSystemMsgs = false;
Might work, where object is a reference to an object of the class which you partially posted.
When running swfs through decompilers (my own swfs, not somebody else's), I've noticed a lot of mention of certain variables:
_loc_1
_loc_2
_loc_3
.
.
.
_loc_n
As in the following example:
private function templateFilterFunction(param1) : Boolean
{
var _loc_2:* = false;
if (filterFunction != null)
{
_loc_2 = filterFunction(param1, typedText);
}
return _loc_2;
}
Alright, so these are apparently just normal variables then, right? And they may have had more descriptive names in the original AS3 code, but that's been lost in the bytecode, and now we have the same variables as before, just with non-descript names, right?
Not exactly. For instance:
package
{
public class SomeClass extends Object
{
public var var1:Number;
public var var2:Number;
public var var3:Number;
public function SomeClass(param1:Number, param2:Number, param3:Number)
{
if (!_loc_5)
{
if (!_loc_4)
{
var3 = param1;
if (!_loc_4)
{
var1 = param2;
}
}
}
var2 = param3;
return;
}// end function
}
}
These aren't declared. But they're not exactly members of Object either, and I've never seen them outside of a swf decompilation. What are they then? Thanks.
Not sure about that particular piece of code, but the decompilers I've used (as far as I remember) all call the local variables loc_n, local_n or something like that.
I think you already know why. Local variables are created and pushed onto the execution stack; they are not referenced from outside the local scope and since they are not callable by name, their names are just whipped off the bytecode. (The object pointed by the variable could be allocated on the heap and live outside the scope of the function, however, but that's not the point here).
Now, another thing you might be aware of is that some bytecode generated by the compiler just doesn't traslate to actionscript code. There are things that can be done in bytecode that are not really possible in AS code; an example, off the top of my head: the "dup" opcode (duplicates a value and pushes it onto the stack). There are others (jumps, noops, etc). Reversing this to the original source code is sometimes not possible.
There are other interesting cases such as loops. You may notice that a particular decompiler tends to generate "for loops" (or "while loops") regardless of whether the source code had a for or a while. That's because loops are a higher level construct that are usually implemented in bytcode as conditional jumps. If you want to reverse the bytecode to AS code, you just have to pick a flavor because the loop (as an AS construct) is just not there.
That said, I've seen some decompilers (can't remember which one now) generating invalid or non-sensical source code. To me, that's the case in the example you post. I may be wrong but it seems like the _loc_5 and _loc_4 vars are just gibberish and the original code must be something like:
public function SomeClass(param1:Number, param2:Number, param3:Number):void
{
var var3:Number = param1;
var var1:Number = param2;
var var2:Number = param3;
}
I'm trying to iterate through the properties of a custom class, however, the methods provided by Adobe appear to not work. I'm not receiving compile or run-time errors.
Class
package {
public dynamic class enum {
public var foo:Number = 123;
public function enum() {
this.setPropertyIsEnumerable("foo", true);
if (this.propertyIsEnumerable("foo") == false) {
trace("foo:" + foo + " is not enumerable.")
}
}
}
}
// outputs "foo:bar is not enumerable."
Implementaiton
var test:enum = new enum();
for (var property:String in test) {
trace(property);
}
// outputs nothing
I try to keep my code fast and flexible, so it's really frustrating when you must change the class to Dynamic just to be able to use for ... in on the properties. Jackson Dunstan's testing confirms that this can be 400x slower than static class properties, but those have to be explicitly referenced (impractical for property agnostic methods), or use reflection of the class (computationally expensive) to be accessible.
The only way I've found to sidestep the whole issue is to use dynamically declared variables... which is pointless since at that point using setPropertyIsEnumerable(prop, true) is superfluous; all dynamically created properties already are enumerable. Additionally, dynamic variables cannot be strongly datatyped, and performance goes out the window.
For example...
Class
package {
public dynamic class enum {
public var foo:String = "apple";
public function enum(){
this.dynamicVar = "orange";
this.dynamicProp = "banana";
this.setPropertyIsEnumerable("foo", true);
this.setPropertyIsEnumerable("dynamicProp", false);
}
}
}
Implementation
var test:enum = new enum();
for (var key:String in test) {
trace(key + ": " + test[key]); // dynamicVar: 1
}
// outputs "dynamicVar: orange"
Now that the class is dynamic, we see that only one of our 3 test properties are being iterated. There should be 2.
It almost feels like Adobe wants us to adopt bad programming habits. Words fail me...
Non-dynamic classes do not provide enumerable properties or methods.
As stated in the description of the link you provided.
Sets the availability of a dynamic property for loop operations.
I think you might want to refactor your code on this approach.
I have never had to loop over a classes properties like you are doing here.
If you want to track items dynamically you should use an associative array and track them that way not at the class level like you are doing.
And if you want strong data typing then use a vector.
I am very familiar with JavaScript and am now having a play with Flex for the first time. Obviously it's a strange felling as JavaScript and ActionScript are as they would say here in Southeast Asia "same same but different". The one thing that's getting to me (as with all static languages) is the verbosity. Are there any shorthand tricks that can slim down the following common code:
package com.mate.extensions {
public class HTTPResponse
{
public var data:String;
public var responseURL:String;
public var responseHeaders:Array:
public var status:Number;
public function HTTPResponse(data:String, responseURL:String, responseHeaders:Array, status:Number):void {
this.data = data;
this.responseURL = responseURL;
this.responseHeaders = responseHeaders;
this.status = status;
}
}
}
I guess it's a matter of what you're used to; I came to AS3 from Java, and to me, that code looks perfectly reasonable. :)
Honestly, I don't think you can trim this down substantially without taking a big hit in either readability or functionality. (Of course, now that I've said that, I look forward to somebody smarter than me proving me wrong.) In fact, it may actually be too terse; making your internal fields publicly accessible is generally considered bad form and an invitation to headaches down the road. Though one of the lovely things about AS3 is that because of how getters and setters are handled, you can switch from public fields to accessor-controlled private fields without needing to make any changes to code that uses this object.
If your concern is verbosity versus coding standards, you could throw the whole HTTPResponse class away and replace it with an Object.
var httpResponse:Object = { data: data, responseURL: responseURL, responseHeaders: responseHeaders, status: status };
But in that case you would miss the compile time types checking and code reusability.
The great thing with ActionScript is that it's same same & different.