I am looking at a source code and it has a method named updateDisplayList. There are various methods in this source code with similar name. However I am interested in one particular updateDisplayList method. I want to check where this method is getting called. I have tried using CTRL+SHIFT+G in eclipse which returns me all the references of this method in that source code. However as there are many methods with same name, those references are also getting returned. How can I know where that particular updateDisplayList method is getting called?
As stated in the comments updateDisplayList() is a Flex component life cycle method. Practically every Flex component implements this method.
If you've modified this method in one class, lets call it ClassA, and you're also seeing the effects of this modification in other classes, it must mean that the other classes inherit from ClassA in some way.
To determine who's inheriting from ClassA, you can just search for that class name in your project. This will likely find the other class that you're looking for. However, there could be a series of classes that inherit from ClassA so you might have to look deeper than that (find all the classes that extend ClassA and then search for those classes). This might be a slippery slope and may not be fruitful.
Another approach is to set a breakpoint in the updateDisplayList() method in ClassA. As I mentioned, you'll hit this breakpoint frequently. In FlashBuilder/Eclipse, you can use the "expressions" window and inspect the value of this. If this is ClassA, it's not the droid(s) you're looking for, so let execution resume.
I'm sure there are a handful of other ways to get to the bottom of this. But updateDisplayList() is such a common method, there's no point in searching for that method name :)
Related
Headline: description called by super.init()
This is a new take on an old question. As a primarily Swift programmer I tend to not use NSObject for class definitions because of the residual side effects of Objective-C. Like if I have a read-only property called length and I then want to create a setter function called setLength, I get warnings about it conflicting with a similar definition from Objective-C. I just discovered the set(var){} setter. If I subclass a Cacoa class like UIDocument, etc. that inherit from NSObject, I have to live with these side effects.
I have a class that uses two other classes in the property definitions, none of them NSObjects. This class has a description computed variable that uses the description computed variables for the other two classes in its composition. All three classes need to conform to the CustomStringConvertable protocol. Ok, everything is good.
At some point this class got upgraded to being a UIDocument and the CustomStringConvertable became redundant and was removed. Everything still works.
Here is what I found out today. I wanted to break at a point in the program where it was printing one of the two properties and as a convenience I set the break point in the description variable for that class, thinking that it should only be called at the point I am interested in, where it is printed out. What I discovered is that the description variable gets called during all the super.init() of the UIDocument sub-class! And there were a few of them. I think composing strings as being relatively expensive but didn't care because they were only used in debug, but with them being called and who knows how they are used in super.init(), I need to change this.
I checked another UIDocument class in the same program that has 200 files associated with it and it is also calling description in super.init().
Does anyone have any input on the Best Practices for using description vs debugDescription?
I'm going to answer my own question as a matter of documentation.
I switched the UIDocuments subclasses to define and use debugDescription. I am debugging some code that loads all the files and does some manipulation and I was able to reduce the load time from 9.8 seconds to 6.8 seconds.
I also went through all the places where the Swift 3 conversion added String(describing:) to the program and found I could change a lot of them to using debugDescription and eliminate the String(describing:) wrapper.
I think the best practice is to only define and use debugDescription and for my non-NSObjects change conformance from CustomStringConvertable to CustomDebugStringConvertable.
In c# we have the protected accessor which allows class members to be visible on inherited clases but not for the rest.
In Swift this doesn't exist so I wonder what's a correct approach for something like this:
I want to have a variable (internal behavior) and and a public method using this variable on a base class. This variable will be used also on inherited clases.
Options I see
Forget about base class and implement variable and methods everywhere I need it. WRONG, duplicated code
Implement inheritance by composition. I'd create a class containing common methods and this will be used by composition instead of inheritance. LESS WRONG but still repeating code that could be avoided with inheritance
Implement inheritance and make variable internal on base class. WRONG since exposes things without any justification except allowing visibility on inherited clases.
Implementation Details for Base Class
I want to have a NSOperationQueue instance and and a public method to cancel queued operations. I add new operations to this queue from inherited classes.
In Swift the correct answer is almost always protocols and extensions. It is almost never inheritance. Sometimes Cocoa stands in our way, because there are classes in Cocoa more often than protocols, but the goal is almost always protocols and extensions. Subclassing is our last choice.
Your particular case is confusing because NSOperationQueue already has a public method to cancel queued operations (cancelAllOperations). If you want to protect the queue from outside access (prevent callers from using addOperation directly for instance), then you should put the queue inside another type (i.e. composition), and forward what you want to the queue. More details on the specific problem you're solving would allow us to help suggest other Swift-like solutions.
If in the end you need something that looks like protected or friend, the correct solution is private. Put your subclass or your friend in the same file with the target, and mark the private thing private. Alternately, put the things that need to work together in a framework, and mark the attribute internal. The Swift Blog provides a good explanation of why this is an intentional choice.
I have been developing my skills at creating large object orientated programs (30+ classes).
I am trying to make my code as clean as possible after reading a fantastic book called clean code.
One problem I am having is to do with calling a method on an object from "across the program"
Say I have 5 classes.
`ClassA
ClassB
ClassC
ClassD
ClassE`
an instance of ClassA contains an instance of ClassB, which in turn contains an instance of classC, so
`ClassA > ClassB > ClassC`
I'm not saying that this is the inheritance chain, rather that in the constructor of classA an instance of ClassB is created and so on.
Now, say that ClassD > ClassE in a similar way. ClassD is instansiated with an instance variable containing an instance of ClassE.
This is all well and good, and the classes are small and only handle one job, and it all seems nice and clean.
However, say that at some point in the program I need the instance of classC to call a method on the instance of ClassE.
The two objects are on 'opposite sides of the program' so to speak. Yet the method call is necessary.
I am left with three options as I see it
make the instance of classE a global variable, so that classD AND classC can access it (as well as anything else in the program). I feel like this is bad form as global variables are generally considered bad news
Create the instance of ClassE at the top level, then pass it in as an argument to the constructors of ClassA, ClassB, and ClassC. The trouble with this is that I would end up with really long constructor argument lists if this is happening more than once, and it seems like lots of work to pass ojects down chains of constructors like this
Move the object of ClassE to be instantiated by ClassC. The trouble with that is that its more strongly coupled with ClassD and only needs to be called once in the entire running of the program by ClassC.
So what do I do in situations such as these? And are there any resources I can read about this. I know that I could use the observer pattern for situations similar to this, but when its just for one method call it seems excessive, as I would be making things observable all over the program. I want my code as clean as possible!
Thanks in advance :)
Three words: Single Responsibility Principle. If you worry that your class has too many constructor arguments it's probably because this class needs to deal with too many different things. If you keep classes focused, they will be small.
You correctly indicate the coupling problem in the third solution you've described. The coupling problem is also present in the first solution (depending on a global variable is even harder to find/diagnose later). So the second option seems to be the best - as long as you refactor the code to keep your classes simple.
You could read up on Law of Demeter (Short explanation on wikipedia: http://en.wikipedia.org/wiki/Law_of_Demeter or a longer but very well written example http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/paper-boy/demeter.pdf)
Depending on the context / content of your example you could for instance: Build your Class D as a wrapper to your class E (or similar facade / adapter). Meaning if your class c sometimes needs to talk to an E instance it does so via it's class D instance.
Another way to go would be to provide a reference to a class E instance to those objects that need one.
If all your objects are talking to the same instance of E you could also think about the singleton pattern where there is only one instance of a class. But this instance is more or less globally available.
Give a bit more context info and we can develop this further.
EDIT: btw. a funny explanation of lad of demeter can be found here:
http://www.daedtech.com/visualization-mnemonics-for-software-principles
EDIT Nr.2 (your comment): ad. 1.) Maybe you can implement your class D in a way that reliefs your other classes of ever talking directly to an E object. Instead they ask their D instance to do something (not knowing that D delegates the call to E). Depending on what you are trying to do this might be an option for you.
ad. Singleton.) Yes and No. The Singleton main use is that it guarantees (if implemented correctly) that only one instance of the singleton object exists. If you are talking about config settings this might not be a requirement. You are right however that basically the thing is kind of a global variable with all it's downsides. Your object D sounds as if it's immutable in a sense that it does not change it's state while your program is running so maybe the problem is not that you create a complex dynamic behaviour but that you create too many dependencies.
Just another link/principle to get you thinking:
What is Inversion of Control?
The documentation says this is allowed:
ClassMethod GetContacts() As %ListOfObjects(ELEMENTTYPE="ContactDB.Contact")
[WebMethod]
I want to do this:
Property Permissions As %ListOfObjects(ELEMENTTYPE="MyPackage.MyClass");
I get an error:
ERROR #5480: Property parameter not declared:
MyPackage.Myclass:ELEMENTTYPE
So, do I really have to create a new class and set the ELEMENTTYPE parameter in it for each list I need?
Correct syntax for %ListOfObjects in properties is this one
Property Permissions As list of MyPackage.MyClass;
Yes, a property does sometimes work differently than a method when it comes to types. That is an issue here, in that you can set a class parameter of the return value of a method declaration in a straightforward way, but that doesn't always work for class parameters on the class of a property.
I don't think the way it does work is documented completely, but here are some of my observations:
You can put in class parameters on a property if the type of the property is a data-type (which are often treated differently than objects).
If you look at the %XML.Adaptor class it has the keyword assignment statement
PropertyClass = %XML.PropertyParameters
This appears to add its parameters to all the properties of the class that declares it as its PropertyClass. This appears to be an example of Intersystems wanting to implement something (an XML adaptor) and realizing the implementation of objects didn't provide it cleanly, so they hacked something new into the class compiler. I can't really find much documentation so it isn't clear if its considered a usable API or an implementation detail subject to breakage.
You might be able to hack something this way - I've never tried anything similar.
A possibly simpler work around might be to initialize the Permissions property in %OnNew and %OnOpen. You will probably want a zero element array at that point anyway, rather than a null.
If you look at the implementation of %ListOfObjects you can see that the class parameter which you are trying to set simply provides a default value for the ElementType property. So after you create an instance of %ListOfObjects you could just set it's ElementType property to the proper element type.
This is a bit annoying, because you have to remember to do it every time by hand, and you might forget. Or a maintainer down the road might not now to do it.
You might hope to maybe make it a little less annoying by creating a generator method that initializes all your properties that need it. This would be easy if Intersystems had some decent system of annotating properties with arbitrary values (so you could know what ElementType to use for each property). But they don't, so you would have to do something like roll your own annotations using an XData block or a class method. This probably isn't worth it unless you have more use cases for annotations than just this one, so I would just do it by hand until that happens, if it ever does.
In Objective-C, if I override a class method using a category, is there a way I can call the original method (the one that was overridden)?
I present you with three icky ways to do this in +(void)load. In every case, name your method MyCategory_method or so.
class_getMethodImplementation() and class_replaceMethod(). Store the old IMP, and call it directly. You need to get the method's type encoding. Note that you can just use a normal C function too...
class_getInstanceMethod(), method_getImplementation(), method_setImplementation(). As above, but you don't need to get the method's type encoding.
class_getInstanceMethod() on both methods, and then method_exchangeImplementations(). Call MyCategory_method to get the original implementation. This is the easiest way to do it.
Sometimes, it's the only reasonably easy way to make it do what you want...
EDIT: And only do this if you know what you're doing!
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocCategories.html
Doesn't look like it is possible.
When a category overrides an inherited method, the method in the category can, as usual, invoke the inherited implementation via a message to super. However, if a category overrides a method that already existed in the category's class, there is no way to invoke the original implementation.
What this is saying to me is that if you override a method on a subclass via a category, you can call [super methodName] as you would normally, but if you override the base class method directly, you can't invoke the original.
If you dynamically provide the category override (see resolveInstanceMethod:), you can cache the previous method selector beforehand, and call that.