I'd like to visualize method chains of our codebase (which method invokes which method) starting from a given method with jqassistant.
For normal method calls the following Cypher query works. workupNotification is the method I am starting from:
MATCH (begin:Method {name: "workupNotification"}) -[INVOKES*1..20]-> (method:Method) WHERE not method:Constructor and exists(method.name) RETURN begin, method, type
But many of the methods calls in our software are calls to interfaces of which the implementation is not known in the method (SOA with Dependency Inversion).
serviceRegistry.getService(MyServiceInterface.class).serviceMethod();
How can I select the implementation of this method (There are two classes implementing each interface. One is automatically generated (Proxy), the other is the one I'm interested in.)
You need to do what the JVM is performing at runtime for you: resolving virtual method invocations. There's a predefined jQAssistant concept that propagates INVOKES relations to implementing sub-classes: java:InvokesOverriddenMethod. You can either reference it as a required concept from one of your own rules or apply it from the command line, e.g. with Maven:
mvn jqassistant:analyze -Djqassistant.concepts=java:InvokesOverriddenMethod
The rule is documented in the manual, see http://buschmais.github.io/jqassistant/doc/1.6.0/#java:InvokesOverriddenMethod
(The name of the concept is not intuitive, it would be better to replace it with something like java:VirtualInvokes).
It is deprecated. In 1.9.0 version it should be used this command line:
mvn jqassistant:analyze -Djqassistant.concepts=java:VirtualInvokes
http://jqassistant.github.io/jqassistant/doc/1.8.0/#java:VirtualInvokes
Related
In nix, overlay is a function with 2 arguments: self and super. Based on the manual, self corresponds to the final package set (or some others call it result of the fix point calculation) and only to be used when dealing with dependencies. While super is the result of the evaluation of the previous stages of nixpkgs and only to be used when you refer to packages you want to override or to access certain function.
Sadly I don't really understand this. In what way that the nixpkgs gets updated by the overlays such that there's 2 restriction mentioned above?
These restrictions follow from the requirement that evaluation of an attribute should terminate.
Suppose you want to override the hello package. To reference the old definition of the package, you need to use super.hello, because that attribute can be evaluated without evaluating the hello definition in your overlay. If you would instead reference self.hello, that means that for evaluating the final hello attribute, Nix will have to evaluate self.hello, which references the final hello attribute, which references self.hello, and so on, creating an infinite recursion.
self can actually be used to reference functions, but the convention seems to be to use super instead. The idea that the next overlay may monkey-patch the lib.head function is not very enticing, although using super the same can still be done in a previous overlay.
You may also want to check out this excellent NixCon 2017 presentation by Nicolas. He both introduces the concept and explains how you can use it in the best way.
After I went through OData doc, I still do not understand the meaning of <FunctionImport>.
What is that used for?
Some one said that "Function imports are used to perform custom operations on a JPA entity in addition to CRUD operations. For example, consider a scenario where you would like to check the availability of an item to promise on the sales order line items. ATP check is a custom operation that can be exposed as a function import in the schema of OData service."
But I think above requirement can be achieved by general <Function> also, right?
What is the difference between <FunctionImport> and <Function> exactly?
I do appreciate anyone's help!
Thanks
There are three types of functions in OData:
Functions that are bound to something (e.g. an entity). Example would be
GET http://host/service/Products(1)/Namespace.GetCategories()
such function is defined in the metadata using the <function> element and with its isBound attribute set to true.
Unbound functions. They are usually used in queries. E.g.
GET http://host/service/Products?$filter(Name eq Namespace.GetTheLongestProductName())
such function is defined in the metadata using the <function> element with its isBound attribute set to false
Function imports. They are the functions that can be invoked at the service root. E.g.
GET http://host/service/GetMostExpensiveProduct()
Their concept is a little bit similar as the concept of static functions in program languages, and they are defined in metadata using the <functionimport> element.
Similar distinguishing applies to <action> and <actionimport> as well.
OK, I got the answer by myself.
<OData Version 4.0 Part 1: Protocol Plus Errata 02>:
Operations allow the execution of custom logic on parts of a data model. Functions are operations that do not have side effects and may support further composition, for example, with additional filter operations, functions or an action. Actions are operations that allow side effects, such as data modification, and cannot be further composed in order to avoid non-deterministic behavior. Actions and functions are either bound to a type, enabling them to be called as members of an instance of that type, or unbound, in which case they are called as static operations. Action imports and function imports enable unbound actions and functions to be called from the service root.
I was trying to define a dynamic method using the GroovyDSL scripting capabilities in IntelliJ. The starting guide "Scripting IDE for DSL awareness" gives you a good idea on how to get started with this. The dynamic method definition in my DSL is more complex than the example though and I am not quite sure how to build this. You can imagine it working like dynamic finder methods in Grails except that you can combine an arbitrary number of criteria with a boolean And keyword in any order. All keywords are not defined in the class that I am invoking the method on but could be defined in the GDSL file. The method always starts with submitTransactionWith. Here's an example:
clientDSL.submitTransactionWithCriteria1AndCriteria2AndCriteria3(arg1, arg2, arg3)
I started out with this but that only works for one criteria and doesn't take into account that you can combined multiple criteria in any order.
def ctx = context(ctype: "my.client.ClientDSL")
contributor(ctx) {
['Criteria1', 'Criteria2', 'Criteria3'].each {
method name: "submitTransactionWith${it}",
type: 'java.util.Map',
params: [args: 'java.util.Collection']
}
}
I was wondering if there's special support for that kind of dynamic method. I'd also be interested in how the DSL for Grails is modeled internally in IntelliJ.
The Grails DSL in located in ${idea.home}/plugins/GrailsGriffon/lib/standardDsls
It would probably help you for your problem. They create string arrays of all the method name combinations ahead of time, and then just iterate through them in their contributor creating a method using the arrays of strings for names.
When coding, I often come across the following pattern:
-A method calls another method (Fine), but the method being called/callee takes parameters, so in the wrapping method, I pass in parameters. Problem is, this dependency carrying can go on and on. How could I avoid this (any sample code appreciated)?
Thanks
Passing a parameter along just because a lower-layer component needs it is a sign of a Leaky Abstraction. It can often be more effective to refactor dependencies to aggregate services and hide each dependency behind an interface.
Cross-cutting concerns (which are often the most common reason to pass along parameters) are best addressed by Decorators.
If you use a DI Container with interception capabilities, you can take advantage of those to implement Decorators very efficiently (some people refer to this as a container's AOP capabilities).
You can use a dependency injection framework. One such is Guice: see http://code.google.com/p/google-guice/
Step 1: Instead of passing everything as separate arguments, group the arguments into a class, let's say X.
Step 2: Add getters to the class X to get the relevant information. The callee should use the getters to get the information instead of relying on parameters.
Step 3: Create an interface class of which class X inherits. Put all the getters in the interface (in C++ this is as pure virtual methods).
Step 4: Make the called methods only depend on the interface.
Refactoring: Introduce Parameter Object
You have a group of parameters that naturally go together?
Replace them with an object.
http://www.refactoring.com/catalog/introduceParameterObject.html
The advantage of the parameter object is that the calls passing them around don't need to change if you add/remove parameters.
(given the context of your answers, I don't think that an IoC library or dependency injection patterns are really what you're after)
Since they cannot be (easily) unit tested, most developers choose to inject objects into Views. Since the views are not (normally) used to construct other views, that is where your DI chain ends. You may have the issue (which I have run into every once in ahwile) where you need to construct objects in the correct order especially when using a DI framework like Unity where an attemt to resolve the object will deadlock. The main thing you need to worry about is circular dependency. In order to do this, read the following article:
Can dependency injection prevent a circular dependency?
In Ninject's dependency injection, if you set up a binding of a class to itself like so:
Bind<SomeClass>().ToSelf();
Ninject very nicely resolves any dependencies SomeClass has and gives you the object back. I want to be able to do something to the SomeClass it returns every time it creates a new one, so like a post-processing event. I could use the .ToMethod (or ToFactoryMethod) binding to explicitly new it up, but I would like all its dependencies resolved by Ninject beforehand.
It wouldu be nice to do something like:
Bind<SomeClass>()
.ToSelf()
.After(sc => sc.MethodIWantToCall()); // then after here, Ninject returns the object.
Is there some way to do this in Ninject 1.0/1.1?
If you can't put the code you want to execute in the constructor, you can implement IInitializable or IStartable. The former provides an Initialize() method that gets called after all injection has completed, and the latter provides both a Start() and Stop() method, called during activation and deactivation, respectively.
I ran into the same problem, but I could not use Nate's solution because I couldn't make the type implement IInitializable. If you're in a similar boat, you can use .OnActivation and avoid having to modify the definition of the target types:
Bind<SomeClass>().ToSelf().OnActivation(x => ((SomeClass)x).MyInitialize());
You can see how we call some arbitrary initialization method (MyInitialize) upon activation (instantiation) of the class.
This has the advantage of not baking in a hard dependency to Ninject in your own classes (aside from your modules, of course), thus allowing your types to remain agnostic about the DI-framework you end up using.