This question already has answers here:
Can I write validation logic in setter methods?
(7 answers)
Closed 7 years ago.
Should getters have validation in java(for example. checking if something is null)? or should they simply get whatever it is suppose to get with one return statement. To me this is how i usually do it.
public class GetterDemo
{
private String name;
private int age;
public GetterDemo(String name, int age)
{
this.name = name;
this.age = age;
}
public String getName()
{
return this.name;
}
public int getAge()
{
return this.age;
}
}
Now suppose that the constructor has an array of hobbies from a class called hobbies.
public class Hobbies
{
private String hobby;
private String category;
public Hobbies(String hobby, String category)
{
this.hobby = hobby;
this.category = category;
}
public String getHobby()
{
return this.hobby;
}
public String getCategory()
{
return this.category;
}
}
Now, lets update version of GetterDemo with an array of hobbies in the constructor as i said above. and it has a next method to get the next hobby in the array everytime its called.
public class GetterDemo
{
private String name;
private int age;
private int count = 0;
private Hobbies[] hobbies;
public GetterDemo(String name, int age, Hobbies[] hobbies)
{
this.name = name;
this.age = age;
this.hobbies = hobbies
}
public Hobbies getNextHobby()
{
//Create a counter.
Hobbies result;
if (this.hobbies == null || this.hobbies.length == 0
|| this.count >= this.hobbies.length) //Called more then length times.
return null;
result = this.hobbies[count];
count++;
return result;
}
public String getName()
{
return this.name;
}
public int getAge()
{
return this.age;
}
public void reset()
{
this.count = 0;
}
}
Okay so thats a little code example. There might be errors, probably many as I blankly coded it.
To explain in terms of testing for null(JUnit testing). If I call getNextHobby() hobby length times or more it will return null and I can AssertNull() and it will pass. However, for example, if I do AssertNull where the array of hobbies is Null and I try getNextHobby.getCategory(), it will throw a NullPointerException even though I want it to be null. Would the only way to fix this would be to create a method that checks for this? or a getter that checks for null somehow? Possibly the code below?
public boolean checkNull()
{
boolean result = false;
if (getNextHobby().getCategory() == null || getNextHobby().getHobby())
result = true;
return result;
}
I assume that it is a matter of taste.
I prefer that setters and getters do only what they suppose to do which means set some value or get some value. My reasons are the following:
The signature of the method should explain what this method is doing and as we know good method should do one thing well. Thus when you start adding some validation I would assume that you need to change the signature otherwise the caller might assume that only set/get operation happens.
Every IDE has an opportunity to generate getters and setters and for some reason they don't generate some validations for the parameters of the getter method thus I assume that you shouldn't do it as well.
I try to separate getters and setters from other methods, thus if I need to kind of get the value, however, it is not exactly a getter because you need to do some other actions, I prefer to use other words like fetch, retrieve, obtain. In this case it will be very clear that you don't need to test getters and setters because they don't really do anything, however, fetch and others you must.
Related
I want to create a method to check whether the value of each attribute of the object is the same or different
here's the description:
matches(HalamanA1, HalamanA2): public static Compares A1 with A2, returns 1 if equal 0 otherwise. Two pieces object is equal if every attribute value of an object is equal to the attribute value on other objects.
class HalamanAlamat {
private String name;
private String address;
private int phone;
private String email;
private int nbInstance;
HalamanAlamat(){
this.name = "null";
this.address = "null";
this.phone = 0;
this.email = "null";
this.nbInstance++;
}
void setName(String name){
this.name = name;
}
void setAddress(String address){
this.address = address;
}
void setPhone(int phone){
this.phone = phone;
}
void setEmail(String email){
this.email = email;
}
String getName(){
return this.name;
}
String getAddress(){
return this.address;
}
int getPhone(){
return this.phone;
}
String getEmail(){
return this.email;
}
public void tostring(){
System.out.println("Nama : " + getName());
System.out.println("ALamat : " + getAddress());
System.out.println("No.Handphone : " + getPhone());
System.out.println("Email : " + getEmail());
}
}
public class BukuAlamat {
public static void main(String[] args) {
HalamanAlamat halaman1 = new HalamanAlamat();
halaman1.setName("Rizki okto");
halaman1.setAddress("Ambarita");
halaman1.setPhone(629768328);
halaman1.setEmail("rizok#gmail.com");
halaman1.tostring();
}
}
There are multiple things to improve concerning this piece of code. The equals method your question requests is at the end of this answer, but you might want to read it if you actually want to learn coding instead of copy-pasting.
Use access parameters. Just as in the BukuAlmet class, the HalamanAlamat class should have access types for every method and the class itself if not for the specific purpose of making a class package-private (and it doesn't look like it should be, if the class is modifierless for the purpose of staying in the same file, you might want to split the file up, since this isn't a good practice.)
Initializing ints to 0 is unneccessary since all primitive types have a default value of 0 except for booleans which are false by default. Initializing strings to "null" is also unneccessary, when printing out an uninitialized string, "null" will be printed anyways.
Do not use this. for everything. This should be used in cases like this:
private int ID;
public void setID(int ID) {
this.ID = ID;
}
Where not using this results in a compiler error.
It can be used for readability in certain cases but when using it that often, it only takes readability away and might even cause bugs in debugging tools in some rare edgecases.
Do not write a tostring() method! Override the Object.toString method instead. (By adding #Override in the line above the method) The reason for this is A: one typo can make you call the wrong method and debugging that is a nightmare. B: If you have a tostring method, toString is redundant. C: Not using camelCase when working with other developers is like putting a whole file in one line. Works but. . . NO!
Why do you have this int nbInstance? It is always 1 because it is not static. I guess you want to count how many instances of the class you have, but to do this, that int has to be static (and therefore not be called by this.nbInstance!)
Here you got you CopyPaste Exercise (a little different that you asked for, so you have to understand it to use it):
#Override
public boolean equals(HalamanAlamat cmp) {
boolean equ = name.equals(cmp.getName());
equ |= address.equals(cmp.getAddress());
equ |= email.equals(cmp.getEmail());
return equ && phone == cmp.getPhone();
}
public String getPet() {
public String getName() {
return name;
}
public String getType(){
return type;
}
public String getDescription() {
}
return description;
}
I would like to bundle three getters into one, so that getPet()
gets getName(), getType(), and getDescription(). I typed this out, but there is something wrong with my syntax that I cannot figure out.
You cannot directly have nested methods in Java. You can call as many methods as you want inside of a method though.
So you could have something like this
public Pet getPet() {
getName();
getType();
getDescription();
// create a pet from these method calls and return it i suppose?
}
public String getName() {
return name;
}
public String getType(){
return type;
}
public String getDescription() {
return description;
}
Like others have said though, there is no real reason that I could see to do this.
What you want is redundant, but here it comes another funny but valid option:
public Pet {
...
public Pet getPet(){
return this;
}
}
Then you can access all your methods from getPet(), but, as I said this is redundand:
Pet p = new Pet();
Pet q = p.getPet();
So you can access, from getPet() all of the other methods:
p.getPet().getName();
p.getPet().getType();
p.getPet().getDescription();
But that's redundant, since you can access these directly:
p.getName();
p.getType();
p.getDescription();
It is pretty probable, there's some misunderstanding on the Object Oriented fundamentals you're trying to implement. May I suggest, take a read to: https://docs.oracle.com/javase/tutorial/java/concepts/index.html
This question already has answers here:
Setter methods or constructors
(10 answers)
Closed 3 years ago.
I have confusion about use of setter and constructor about value assigning. Why we use setter to set values independently if we can do it in a single constructor.
I have tried both methods using setter and construtor passing values and found no differnce. Need reasons for the differnece between them.
//setter
public class NegaE {
String name;
int id;
public void setname(String a){
this.name=a;
}
public void setid(int b){
this.id=b;
}
public String getname(){
return name;
}
public int getid(){
return id;
}
// now through constructor
public class NegaE {
String name;
int id;
public NegaE(String a,int b){
this.id=b;
this.name=a;
}
public String getname(){
return name;
}
public int getid(){
return id;
}
You only call a constructor once. If you set the values in the constructor, and don't have setters, a user can never change the initial value unless some other object method with private access does it.
Objects that have private final data members that are initialized in the constructor and no setters are called "immutable" == "unchanging".
This can be a very good thing. Immutable objects are thread safe; you can share them between threads without concern. It's a more functional style of programming.
If you have setters you can update the state directly as you wish. These are mutable objects. You have to be careful sharing these across threads. Mutable, shared data is not thread safe.
A constructor sets the initial values, but those values will need to have the ability the change over time because things change.
Setters and getters allow you to make rules and modify the data if needed.
Here's a real basic example to get the idea.
public String setName(String name){
if(name == null){
throw new InvalidNameException();
}
this.name = name;
}
public String getName(){
if(this.name == null){
return "No Name here";
}
return this.name;
}
Believing and using Which #NotNull Java annotation should I use?, I have a class which has certain fields marked as #NotNull [package javax.validation.constraints] to pass on to the clients. The class also implement the default getter and setter for such fields. Sample class below -
public class MyClass
{
public MyClass() {
}
#NotNull
private String name;
private Boolean bool;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public Boolean isBool() {
return bool;
}
public void setBool(Boolean bool) {
this.bool = bool;
}
}
I am left a little puzzled up with the usage of the getter as follows in the business logic -
if(new MyClass().getName() !=null) {
//do something
}
Is this null check not redundant, (if not) curious to know WHY?
Also if its redundant, would like to give a thought of setting a null value and getting the value of the param. Gave this a try as -
void test() {
myClass.setName(null);
if (myClass.getName() == null) {
System.out.println("It should not be null"); // this got printed
}
}
#NonNull is only a hint for your tooling, it does not affect how the java language itself handles nulls. It also requires every interaction to be properly annotated to ensure all mistakes are found.
This happens in your case, while the name field is annotated the methods interacting with that field are not, so the tooling cannot make any assumptions about those methods and their nullability.
However if you introduce more annotations like this:
public void setName(#Nullable String name) {
this.name = name; // should now have a warning
}
#NonNull
public String getName() {
return name;
}
Now the tooling should indicate new MyClass().getName() != null as always true. It also warns in setName that you're setting a nullable value to a non-null property and that is probably wrong.
The way that is fixed:
public void setName(#NonNull String name) {
// setName(null) would cause a warning
// Also add an exception if the annotation is ignored.
this.name = Objects.requireNonNull(name);
}
/* or */
public void setName(#Nullable String name) {
if (name == null) return; // Guard against setting null
this.name = name;
}
firstly, pardon my pseudo-code, i think in this case it is more legible than full code. Please assume that a property in the pseudo-code is in fact a field with a getter & setter method, except for the ArticleElement where it just needs be a property accessible from the object either by a direct getter method, or a two step getter method (ie getArticleSource().getName()).
Say i have a template entity:
ArticleTemplate
Long id;
String name;
String description;
Integer amount;
Schedule schedule;
and it is used (via its schedule) to create many potential children entities on different dates:
Article
Long id;
String name;
String description;
Integer amount;
Date date;
Boolean complete;
ArticleTemplate template;
some children entities are not created from a parent, they can be stand-alone (template can be null).
for my UI I want to create a sorted & merged list of :
a) potential children entities from parent entities
b) real children entities previously created from parent entities
c) orphan children entities created stand-alone
however, I need to add some properties to the elements of this list to determine the differences between the elements:
ArticleElement
// actual value if from Article, null if from potential from ArticleTemplate
Long id;
// actual value if from Article or ArticleTemplate
String name;
// actual value if from Article or ArticleTemplate
String description;
// actual value if from Article or ArticleTemplate
Integer amount;
// actual value if from Article, simulated if from potential from ArticleTemplate
Date date;
// actual value if from Article, false if from potential from ArticleTemplate
Boolean complete;
// actual value (nullable) if from Article, self if from potential from ArticleTemplate
ArticleTemplate template;
// false if from Article, true if from potential from ArticleTemplate
Boolean templateSimulation;
// once the list is sorted, a running tally of this.amount is to be stored on this object
Integer runningTally;
// would be type of interface if Article and ArticleTemplate implement same
Object source;
Clearly I'm going to have at least 3 classes but there's a few different approaches with interfaces etc.
I'd like to avoid cloning and property copying wherever possible, and use inheritence wherever beneficial.
suggestions appreciated!
p.
Here's my current solution, and i'm not sure I like it, but i haven't come up with anything better just yet:
firstly, i'll leave Article and ArticleTemplate alone. I could make them implement an interface describing their similarities but it doesn't add much benefit for this case.
create the UI contract
public interface UiElement<T>
{
T getSource();
Class<T> getType();
// redundant - refer to source
// Long getId();
String getName();
String getDescription();
Integer getAmount();
Date getDate();
Boolean getComplete();
// redundant - not needed anymore
// ArticleTemplate getTemplate();
// redundant - replaced by getType()
// Boolean getTemplateSimulation();
Integer getRunningTally();
}
create implementation for Article - pass through contracted calls to the source object for most properties
public class ArticleUiElement implements UiElement<Article>
{
private Article source;
private Integer tally;
public ArticleUiElement(Article source) {
this.source = source;
}
public Article getSource() {
return source;
}
public Class<Article> getType() {
return Article.class;
}
public String getName() {
return source.getName();
}
public String getDescription() {
return source.getDescription();
}
public Integer getAmount() {
return source.getAmount();
}
public Date getDate() {
return source.getDate();
}
public Boolean getComplete() {
return source.getComplete();
}
public String getRunningTally() {
return tally;
}
public void setRunningTally(String tally) {
this.tally = tally;
}
}
create implementation for ArticleTemplate - pass through contracted calls to the source object for most properties
public class ArticleTemplateUiElement implements UiElement<ArticleTemplate>
{
private ArticleTemplate source;
private Integer tally;
private Date date;
public ArticleTemplateUiElement(ArticleTemplate source) {
this.source = source;
}
public ArticleTemplate getSource() {
return source;
}
public Class<ArticleTemplate> getType() {
return ArticleTemplate.class;
}
public String getName() {
return source.getName();
}
public String getDescription() {
return source.getDescription();
}
public Integer getAmount() {
return source.getAmount();
}
public Date getDate() {
return date;
}
public void setDate(Date date) {
this.date = date;
}
public Boolean getComplete() {
return false;
}
public String getRunningTally() {
return tally;
}
public void setRunningTally(String tally) {
this.tally = tally;
}
}
can someone offer improvements, or an entirely better solution?