I'm trying to get information of all the caller of specific method of class programmatically and came across solution given here. But as per latest release of the project org.eclipse.jdt.ui (3.21) consisting those classes used in above example are not present. The classes were part till 3.13 release.
Are those classes refactored or removed because of defects introduced?
Related
I have read about Dependency Inversion (the 'D' in SOLID) and looked at a few examples here.
However, I can't see how the dependency can be totally gotten rid of!
According to the article the relation Consumer --> Utility can be changed to Utility --> Consumer by introducing a contract/interface in the consumer package.
Further more, the reversed dependency can be fully decoupled by moving the contract/interface to a separate package like Consumer --> Contracts <-- Utility.
Now, with the above layout; for Consumer to use the Utility shouldn't there be a factory? Which then brings back the original dependency as follows:
Consumer --> Factory --> Utility
If it helps, I'll describe a place where Dependency Inversion Principle came about where I work.
I do work with a Content Management system - a system that stores images and lets people retrieve them.
Well, here's what our current (bad) C++ code looks like:
Retrieve()
// code to initialize a vendor's API
// code to pass in system credentials
// code to clear the vendor's "current workitem list"
// code to pull the document to the current workitem list
// code to get content files from that document
// code to format those files for passing back to the user
Basically, hooks into the vendor left and right. And this is just one function - it's the same throughout the code.
Now, imagine you're told:
"Sumith, we're moving to a new Imaging system - we're moving from Vendor ABC to Vendor XYZ. Start working on changing the code to work with the new system."
... uh... um.... yeah... you're going to have to redo all that code. In every single function, in every part of your program that interfaces with that vendor. The Dependency Inversion joke basically goes, "You wouldn't sodder your lamp directly into the electrical wiring, would you?" Well, our group has.
Now, here's how Dependency Inversion handles that.
Retrieve()
// Code that initializes an Interface we coded up
// Code that uses that interface, to pull up a doc (which, again, is an interface)
// Code that returns that doc interface's data
... and that interface?
Interface SimpleExample
void Initialize();
DocExample GetDoc();
Interface DocExample
byte[] GetFileData();
So, when the manager says, "Hey, we're moving to Vendor XYZ..."
... all you need to think to yourself is, "Okay, I need to program a new class that implements my 'SimpleExample' interface, and then I can plug it right into my existing code without having to change any of that program's code!"
Right now, I'm working on rewriting the whole thing, and let me tell you, Dependency Inversion Principle is already saving me boatloads of time. I write a "ContentManagement" interface (well, I'm using an abstract class, but it functions similarly) - and all I have to do, is program a class that implements the ContentManagement interface. Then I can have code like this:
ContentManagement vendorToUse;
if (some criteria or such)
vendorToUse = instanceOfNewVendor;
else
vendorToUse = instanceOfOldVendor;
vendor.Initialize();
Document doc = vendor.Retrieve(...);
... etc
... trying to do that without D.I. would be a nightmare - you'd basically have to have two separate versions of the function.
I'm trying to use JavaFX in my android device, with the help of javafxports.
I used the XStream to parse some XML file in my program.
When i compile them, the javafxports outputs the following warnings:
Note: there were 9 classes trying to access annotations using reflection.
You should consider keeping the annotation attributes
(using '-keepattributes *Annotation*').
(http://proguard.sourceforge.net/manual/troubleshooting.html#attributes)
Note: there were 32 classes trying to access generic signatures using reflection.
You should consider keeping the signature attributes
(using '-keepattributes Signature').
(http://proguard.sourceforge.net/manual/troubleshooting.html#attributes)
Note: there were 56 unresolved dynamic references to classes or interfaces.
You should check if you need to specify additional program jars.
(http://proguard.sourceforge.net/manual/troubleshooting.html#dynamicalclass)
Note: there were 3 class casts of dynamically created class instances.
You might consider explicitly keeping the mentioned classes and/or
their implementations (using '-keep').
(http://proguard.sourceforge.net/manual/troubleshooting.html#dynamicalclasscast)
Note: there were 39 accesses to class members by means of introspection.
You should consider explicitly keeping the mentioned class members
(using '-keep' or '-keepclassmembers').
(http://proguard.sourceforge.net/manual/troubleshooting.html#dynamicalclassmember)
Note: you're ignoring all warnings!
The output .apk can be installed and run until it calls the xstream classes to read annotations in my classes. The reason is actually described in the warnings.
So my question is, how can i disable the proguard when generating .apk, or send it a custom proguard.pro configuration.
And my build.gradle is almost the same as that in the helloworld example.
Thanks.
I'm looking for a clean way to make incremental updates to my code library, without breaking backwards compatibility. This could mean adding new members to classes, or changing existing members to provide additional functionality. Sometimes I am required to change a member in such a way that it would break existing code (e.g. renaming a method or changing its return type), so I'd rather not touch any of my existing types once they are shipped.
The way I currently set this up is through inheritance and polymorphism by creating a new class that extends the previous "version" of that class.
The way this works is by creating the appropriate version of StatusResult (e.g. StatusResultVersion3), based on the actual value of the ProtocolVersion property, and returning it as an instance of CommandResult.
Because .NET does not seem to have a concept of class versioning, I had to come up with my own: appending the version number to the end of the class name. This will no doubt make you cringe. I could easily imagine yourself scratching your eyes out after zooming in on the diagram. But it works. I can add new members and override existing members, without introducing any code breaking changes.
Is there a better way to version my classes?
There are typically two approaches when considering existing code and assembly updates:
Regression Testing
This is a great approach for non-breaking changes, where you can simply overload functions to provide new parameters, etc. Visual Studio has some very advanced unit testing capabilities to make your regression testing relatively easy and automated.
Assembly Versions
If your changes are going to start breaking things, like rewriting the way some utility works, then it's time for a new assembly version. .NET is very good about working with assembly versions. You can deploy the versioned assemblies to different folders so that existing code can continue to reference the old version while new code can take advantage of the features in the new version.
The problem with interfaces is that once published they're largely set in stone. To quote Anders Hejlsburg:
... It's like adding a method to an interface. After you publish an interface, it is for all practical purposes immutable, because any implementation of it might have the methods that you want to add in the next version. So you've got to create a new interface instead.
So you can never just update an interface, you need to create a completely new one. Of course, you can have a single class implement both interfaces so your maintainability effort is fairly low compared with (say) polymorphic classes where your code will become spread out between multiple classes over time.
Multiple Interfaces also allows you to remove methods in a way that classes do not (Sure, you can Deprecate them but that can result in very noisy intellisense after a few iterations)
I personally lean towards having entirely stand-alone versions of the interface in each assembly version.
That is to say...
v 0.1.0.0
interface IExample
{
String DoSomething();
}
v 0.2.0.0
interface IExample
{
void DoSomethingElse();
}
How you implement them behind the scenes is up to you, but most likely it'll be the same classes with slightly different methods doing similar jobs (otherwise, why use the same interface?)
All the old code should be referencing 0.1.x.x and new code will reference 0.2.x.x. About the only issue is when you find (say) a security flaw and the fix needs to be back-ported to an earlier version. This is where a decent VCS comes in (Personal preference is TFS but SVN or anything else which supports branching/merging will do).
Merge the fixes from the 0.2 branch back into the 0.1 branch and then do a recompile to result in (say) 0.1.1.0.
As long as you stick to a process like this:
Major or Minor build will increment if there are any breaking changes (aka signatures will not change on Build/Revision increments)
Use publisher policies if the new Major/Minor version should be used by older programs (equivalent to guaranteeing nothing broke so use the new version anyway)
References in client apps should point at a Major/Minor version but not specify revision/build
This gives you:
A clean codebase without legacy clutter
Allows clients to use the latest version with no code changes if nothing has broken
Prevents clients using newer versions of an assembly which do have breaking changes until they recompile (and, one hopes, update their code as appropriate to take advantage of the new features.)
Allows you to release security patches for previous versions
The OP solved his problem as indicated by this comment:
In the end, I went with the interfaces idea because it allows me to keep multiple versions of a class member in a single class file. When I need to update the class, I'll just add the new interface, shadowing the member that has been changed, and change the return type on some of my methods. This works without breaking backwards compatibility because of polymorphism.
If this is mainly for serialization, This can be achieved in .Net using DataContractSerializers and DataAnnotations. They can deserialize different versions an object into the same object to allow for different versions of the same class to be deserialized, leaving any properties it can't map blank.
I have two frameworks in my Xcode project that both define a class with the same name (B.framework and C.framework both have a class named MyClass), resulting in a couple warnings like so:
Duplicate symbol _OBJC_METACLASS_$_MyClass originally in B.framework/B(MyClass.o) now lazily loaded from C.framework/C(MyClass.o)
Duplicate symbol _OBJC_CLASS_$_MyClass originally in B.framework/B(MyClass.o) now lazily loaded from C.framework/C(MyClass.o)
Then at run time only one of the implementations is loaded, and trying to use the other one will result in a "unrecognized selector sent to instance" because they are totally different classes (even though they have the same name).
I use one of the MyClass implementations directly in my code, but the other framework only uses its MyClass internally and I have no idea why its even exported (its not even mentioned in the frameworks header files, i used nm to view the symbols).
How can I make both frameworks work?
There's no such thing as "exported" classes in Obj-C. Or rather, there's no such thing as "non-exported" classes. This problem is precisely why the use of 2- or 3-letter prefixes on classes is strongly recommended for all Obj-C code. Your only solution (besides not using these frameworks) is to edit one (or both) of the frameworks to change the class name, or if you don't have access to the source, then you need to contact the vendor and ask them to make that change.
I'm building a couple of customs FxCop rules and one of the rules needs to enforce that a constructor is called in specific methods. For that, I need to create a list of callers, to that specific constructor, prior to performing the actual test. How is this possible? Is there some kind of handle to acquire a list of all loaded assemblies in the ApplicationDomain, where I can iterate through the classes and find the constructor Method object? Ideally the list of callers should be composed in the BeforeAnalysis method.
The Microsoft.FxCop.Sdk.CallGraph.CallersFor(Method) method may give you what you want. However, the general approach you seem to be describing is rarely a good idea because it would typically assign the problems to the wrong target. For example, in the scenario you describe, it would presumably be desirable to attribute the problems to the methods that should but do not contain the target contructor call. However, if your analysis target is the constructor, the detected problems will be attributed to the constructor rather than the methods that should have called it.
I think I haven't explained the question very well, but I see your point.
I have 3 different assemblies and for certain method calls from one assembly to another, I need to ensure that a benchmark constructor invoked. The benchmark class resides in a 4th assembly. Now my problem was that only VS2010 only loads one target assembly for analysis and when I used the CallGraph to construct the a list of methods calling the constructur, it would not find any. When Invoking FxCopCmd.exe manually I could just add the dependent assemblies manually with the /file: parameter.
My solution is to load the different assemblies manually (not relying on the loaded assembly in RuleUtilities.AnalysisAssemblies and contruct the list of callers in the BeforeAnalysis method.
RuleUtilities.GetAssembly(
RuleUtilities.AnalysisAssemblies
.First().Directory + "\\" + additionalAssemblyFilename)
.Types.SelectMany(type => type.Members)
.Where(member => member.IsPublic)
.Where(CanBeCastedToMethod)
.Cast<Method>()
.SelectMany(CallGraph.CallersFor);
With this approach I can contruct a list of callers, for each of the assemblies and for the benchmark class constructor. Works perfectly i VS2010.