I have followed the link Can I find number of methods without number of getters via CQL? and excluded the properties from one of my NDepend queries.
One of our coding guidelines is also to ensure that the number of properties in a class(including auto-properties) should not exceed 10.(To be consistent with another guideline that no more than 20 methods can be defined for a class.)
The problem is even if we have 10 properties in a class, which is within the defined limits, the number of methods is being shown as 20. I understand that this is because a get_ and set_ for a single property are being counted as two different methods. But is there any way, by which we can change the NDepend query to have the get_ and set_ methods for a property to be counted as a single method?
Thanks
Here is a CQLinq rules that warn for types having more than 10 properties and that lists the properties through a getter or (exclusive) a setter. The astute consists in using a Lookup table where getters and/or setters are indexed by the property name, inferred from getter/setter names:
// <Name>A class should not have more than 10 properties</Name>
warnif count > 0
from t in Application.Types
let accessers = t.Methods.Where(m => m.IsPropertyGetter || m.IsPropertySetter)
where accessers.Count() > 0 // Optimization!
// Here we build a lookup that associate for each property name, the getter, the setter, or both.
// The property name is getter and/or setter simple names, without "get_" or "set_" prefixes (4 chars).
let propertiesLookup = accessers.ToLookup(a => a.SimpleName.Substring(4, a.SimpleName.Length -4))
where propertiesLookup.Count() > 10
let properties = propertiesLookup.Select(p => p.First())
select new { t, properties }
This rule also lists properties for each matched class.
We have demand on our User Voice for creating an NDepend.CodeModel.IProperty interface, that will make such rule easier to develop, don't hesitate to vote for this!
Related
What is the reason of using custom getters and setters in an application.
That's fairly very simple
First let me show you a sample of how getters and setters in Dart look like, which is essentially the language behind Flutter
class Foo {
// Creating a field/instance variable
String _fooName; //Keeping it private always
// Using the getter
String get foo_name {
//We can do something else here, like saving the variable somewhere and then returning it to the caller function
return _fooName;// private variable return for use in outside class
}
// Using the setter method
set foo_name (String name) {
// We can do something else, like update another variable based on fooName
this._fooName = name;//private variable being assigned new value
}
}
From the name, setters are involved in setting the values to an instance variable in an object oriented programming paradigm whereas getters are involved in getting the value of an instance variable
Now you would ask why not return the instance variable directly and why having such a roundabout approach to setting and getting the value
Well the answer is while getting as well as setting, we might want to do some other operation too other than just setting or getting the value and it's always better not to give admin access to the variables and that's why they are private so as to promote consistency within the objects accessing the field
It's a matter of preference, but you really shouldn't needlessly create one for a single field
https://dart.dev/guides/language/effective-dart/usage#dont-wrap-a-field-in-a-getter-and-setter-unnecessarily
One use case for creating a setter would be to perform some type of validation
For a getter, it'd be useful for a calculated field based on other properties, rather than a single property alone
In the Drools documentation it says that accessing a property through a getter is the same as accessing it directly. For example:
Person( age == 50 )
// this is the same as:
Person( getAge() == 50 )
But then there is a note saying "We recommend using property access (age) over using getters explicitly (getAge()) because of performance enhancements through field indexing."
What is the performance benefit of accessing the property directly?
What would happen if "getAge" would not just return the property value but instead does some calculation which is based on the values from the other properties of the object and then returns a value?
Drools supports the usage of properties of Pojos using a simple name. For example Person(age==10) to match a Person instance that has a getAge() method returning 10.
My problem now is that I have to handle something that is not a pure Pojo and instead has a generic getter. So for the Person example above I need a transformation to Person(myGenericPropertyLookupMethod("age")==10). And I need this for all such property usages, which includes for example the usage of from and chaining like $street : String() from $person.address.street. where at least street must be looked up using myGenericPropertyLookupMethod.
With MATLAB it is possible to add dynamic properties to a class instance like this:
% Define a class supporting for dynamic properties
classdef DynamicClass < dynamicprops
end
% Add a dynamic property named 'toto' to some instance
c = DynamicClass();
c.addprop('toto');
Anyhow I did not find a way to later obtain the list of dynamic properties through reflection, indeed:
m = metaclass(c);
returns an empty list for properties:
PropertyList: [0x1 meta.property]
Even listing properties in dynamicprops superclass returns an empty list:
m.SuperClassList(1).PropertyList ==> 0x1 property array
Is there a way to obtain (through reflection) the list of dynamic properties added to a class ?
NB: Some workaround would be to maintain manual list newprop(end+1) = c.addprop(...) but it's not very practical to pass to another base class (where til now I was working with reflection to obtain information about properties in the child class).
Dynamic properties are not properties of the class, they're properties only of the object - note that if DynamicClass inherits from dynamicprops, then different objects of class DynamicClass can have a different set of properties:
>> a = DynamicClass;
>> b = DynamicClass;
>> a.addprop('hello');
>> a
a =
DynamicClass with properties:
hello: []
>> b
b =
DynamicClass with no properties.
For this reason, you're not going to be able to get any information about them via reflection, which is by definition getting information about the class.
You've given a solution (use properties to retrieve a list the names of all properties of the object, dynamic or not, then use findprop to get the property itself, and then get information about the property).
This is likely to work OK in most cases, but note that properties only returns a list of the properties that are both Hidden = false and GetAccess = public (and that's true even if you call properties inside a method of the object). By default, properties added via addprop meet both of those criteria, but it's possible to change their attributes after adding them, and they won't show up with your solution. The same goes if you call fieldnames on the object.
Another thing that might work for you would be to use isprop to directly check whether the object has a property of interest. This works even if the property is Hidden, or GetAccess = private. Usefully, isprop works on arrays of objects, so you can create an array of objects of class DynamicClass, then apply isprop to get an array of logicals.
But the only way I know of reliably getting everything (private or not, hidden or not, and whether you know the names of the properties beforehand or not) is to just dump the object into a struct temporarily, then get the fieldnames, as #Marek suggests.
cs = struct(c)
if it's only for listing and accessing the names of the properties, this should be sufficient
fieldnames( cs)
I found a workaround to retrieve meta information even for dynamic properties. I'm using properties to obtain the list of properties (this includes dynamic ones) and findprop to retrieve information through reflection in base class:
function [] = baseClassRoutine(obj)
propNames = properties(obj);
propCount = length(propNames);
for idx = 1:propCount,
propName = propNames{ki};
propMeta = obj.findprop(propName);
... So now can inspect meta about all properties (including dynamic ones) ...
end
end
I am curious about this Error I get while testing out Eclipses' functionality:
I tried to use the command "generate hashCode & Equals", but because the class only has static methods it rejected it. How does this work(i.e. hashCode()/equals() needing non-static methods ? )?
thank you
hashCode and equals methods are belonging to a concrete object and need members belonging to the object to compute any meaningful value.
Eg. if you want to compare two instances of the same class, you do that by comparing their "computed values" through their equals and/or hashCode methods.
Static methods and members belong to the class and not to the concrete instance uniquely.
hashCode is supposed to generate a unique identifier for each instance of the class and equals compares this instance to another instance to see if they are equal or not. By definition, these methods are necessary for each instance of this class, so the method cannot be static. Also, these methods are inherited from Object as non-static methods and you cannot change that.