I would like to map the source object to target but in my model I m using the different naming convention for getters
//instead of getName()
String name() { return name;}
is it any option to configure mapstruct to use my naming strategy
In order to use different naming convention for getters a custom AccessorNamingStrategy should be implemented.
The best approach would be to extend the DefaultAccessorNamingStrategy and override the isGetterMethod.
Really important is to make sure that you are really returning something only for getters. Otherwise methods like toString would also be considered as getters
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
What is the philosophy behind making the instance variables public by default in Scala. Shouldn't making them private by default made developers make less mistakes and encourage composition?
First, you should know that when you write:
class Person( val name: String, val age: Int ) {
...
}
name and age aren't instance variables but accessors methods (getters), which are public by default.
If you write instead:
class Person( name: String, age: Int ) {
...
}
name and age are only instance variables, which are private as you can expect.
The philosophy of Scala is to prefer immutable instance variables, then having public accessors methods is no more a problem.
Private encourages monoliths. As soon as it's easier to put unrelated functionality into a class just because it needs to read some variables that happen to be private, classes start to grow.
It's just a bad default and one of the big reasons for classes with more than 1000 lines in Java.
Scala defaults to immutable, which removes a massive class of errors that people often use private to restrict (but not remove, as the class' own methods can still mutate the variables) in Java.
with immutables which are preferred in many places, public isn't so much of an problem
you can replace a public val with getters and setters without changing the client code, therefore you don't need the extra layer of getters and setters just in case you need it. (Actually you do get that layer but you don't notice it most of the time.)
the java anti pattern of private field + public setters and getters doesn't encapsulate much anyway
(An additional view supplementing the other answers:)
One major driver behind Java's encapsulation of fields was the uniform access policy, i.e. you didn't have to know or care whether something was implemented simply as a field, or calculated by a method on the fly. The big upside of this being that the maintainer of the class in question could switch between the two as required, without needing other classes to be modified.
In Java, this required that everything was accessed via a method, in order to provide the syntactic flexibility to calculate a value if needed.
In Scala, methods and fields can be accessed via equivalent syntax - so if you have a simple property now, there's no loss in encapsulation to expose it directly, since you can choose to expose it as a no-arg method later without your callers needing to know anything about the change.
Is there a way to allow a user class with generics to be specified dynamically? That is, say I have a class hierarchy like this:
public interface IMyObject { }
Then I have a class like this:
public class MyObject<?> : IMyObject { }
I want to be able to use the object something like this:
MyObject<object> firstOrder;
MyObject<object, object> secondOrder;
MyObject<object, object, object> thirdOrder;
//And so on...
//MyObject<object, object, object> , ..., object> nthOrder;
I know for things like Func<>, Action<> or other delegates, I don't know that I've ever pushed the capacity of what these can do or whether their argument lists can so expansive.
Is there a way to do this in C#?
Thanks...
No, in C# you have to define each permutation separately. If you look at the examples you cited, Action<T> and Func<T>, you'll notice that the .NET framework provides a large number of explicit overloads (Action<T1, T2>, Action<T1, T2, T3>, etc.). But there's no way to make this open-ended; you have to define each one yourself.
No, you cannot have variadic type arguments. It might be cool, but it's not possible with the language as it stands. As for Func and Action, there are manual declarations for each number of type arguments. It's not something special that .NET just for those delegates.
Groovy automatically generates getters and setters, so e.g. when I type:
int someField
I get the field + getter + setter. Now I want to put an annotation on the setter (e.g. #Requires/Ensures from GContracts):
#Ensures({someField >= 0 && someField <= 100})
int someField
And then I get error: Annotation groovy.lang.GrUnit is not allowed on element FIELD - GrUnit and GContracts recognize annotations on methods only. The workaround for this is coding getter explicitly:
#Requires({...})
void setSomeField(int newValue) { ... }
Is there a better solution for this? In Scala there is an elegant solution for this: http://www.scala-lang.org/api/current/scala/annotation/target/package.html
Is there something like that in Groovy? Or alternatively: maybe some workaround for GContracts to allow such annotations?
There are 9 compile phases in the Groovy compiler. The getters and setters are generated very late in the compilation phases, and they are generated after GContracts runs.
If you want to have your code appear as if generated getters/setters are annotated then you'll have to generate the getter/setter pairs yourself and annotate them. Specifically, add two new FieldNodes to the ClassNode (as long as they don't already exist). A field node is an AnnotatedNode, so you can add whatever annotations you want. As long as you do this in a phase before GContracts runs, then GContracts should never know the different.
That said, this sounds like a GContracts feature request.
As you've noted, GContracts does not provide field annotations (current version: 1.2.4). It even does not execute AST transformations on synthetic (generated) methods which might have been added before GContracts runs.
In a nutshell: an easy workaround is to add a custom setter method.
On the other hand, if you would annotate a class with #Invariant holding a class invariant, it would pre-generate setter methods for all properties to check the class invariant before and after execution of the setter method.
That being said, it might be worth to think about including #Requires and #Ensures in that process - i created an issue: http://gcontracts.lighthouseapp.com/projects/71511-gcontracts-core/tickets/32
Is it possible to have EMF objects implement hashCode and equals? I would like to be able to use a model object as a key in a HashMap.
EObject's javadoc is clear about that. An EObject may not specialize hashCode or equals. However, you can use them in maps as long as you are aware of the identity semantics of Object#equals(..) and #hashCode.
I'm by no means an EMF expert but you could create a wrapper object for the EObject and implement the equals and hashCode methods in the wrapper in terms of the attributes from the EObject you are interested in and then use that wrapper as the key. That would force you always to instantiate a wrapper object when searching the map, but depending on the usage pattern that may not be too hateful.
Be aware that using mutable objects as keys in a map is tricky. If the object is mutated after being used as a key in such a way that the hash code changes then it may be difficult to find the key again later.
You can use EcoreUtil.equals(), if the algorithm behind the method suits your use case.
Or you can implement (generate) equals / hashCode methods for each EMF-*Impl class. You have to insert a #generated not comment above the method header.