We Keep Coding

SonarQube Major Issue: Duplicated blocks of code must be removed

Consider the below DTO. In SonarQube scan it says the fields name and age are duplicated in getters and setters. Why is this even an issue? Can someone tell me how to fix this, as I have a ton of DTOs with the same issue?
public class Employee {
String name;
int age;
public void setName(String name) {
this.name = name;
}
public String getName() {
return name;
}
public void setAge(int age) {
this.age= age;
}
public int getAge() {
return age;
}
}

The point is, if you have multiple DTOs that all have the same "name" and "age" property, it would make sense to define a "Person" class with those properties and have Employee extend from that.
In any case, SonarQube issues are just issues. It certainly does not say "it must be removed". You are free to interpret the severity of the problem in your own context. There is no doubt that duplicated code and properties can be a maintenance problem. If you choose to ignore it, that's up to you.

Is it a good practice to create methods inside an abstract class and not override them inside the class which extends it?

I have got a question.
Should I create getter and setter methods inside abstract class? The below example contains these methods inside abstract class which is extended by Individual class. Is it a good practice to have different variety on methods inside abstract class? Should I be overriding those methods inside Individual class? However it doesn't make sense for me to override those as these will not do anything different, just set and get different attributes. Any advice?
public abstract class Human {
private String name;
private String surname;
public Human(String name, String surname) {
this.name = name;
this.surname = surname;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getSurname() {
return surname;
}
public void setSurname(String surname) {
this.surname = surname;
}
}
public class Individual extends Human{
private String dob;
public Individual(String name, String surname, String dob) {
super(name, surname);
this.dob = dob;
}
public String getDob() {
return dob;
}
public void setDob(String dob) {
this.dob = dob;
}
public void viewIndividual(){
System.out.println("First name of individual is: " + getName());
System.out.println("Surname of individual is: " + getSurname());
System.out.println("Date of birth of individual is: " + getDob());
}
}

Should I create getter and setter methods inside abstract class?
Yes, if a method is common to most expected implementations of an abstract class, it's perfectly fine to implement those methods in the abstract class. If it's really good to have getters and setters for the properties of your Human, it hard to say. The way you're currently using it, it doesn't make much sense, as you're mixing behavior aspects (viewIndividual) with data aspects (getters and setters) in one class. Given the code above you would be fine with protected members in the abstract class, and potentially setters to avoid code duplication in the implementations. But if you want to use your objects as Java-Beans, it's fine.
Is it a good practice to have different variety on methods inside abstract class?
You mean both, abstract and non-abstract methods? Yes, this is pretty standard. Take this example:
public abstract class Example {
public final void publicMethod() {
// do some preparations
internalMethod();
// do some cleanup
}
protected abstract void internalMethod();
}
Consumers of implementations of Example will only be able to access publicMethod and it is guaranteed that all needed preparations and cleanup tasks are executed without repeating this code over and over again in the implementations of Example as only internalMethod needs to be overridden.
Should I be overriding those methods inside Individual class?
No, definitively not. At least as long as you don't add additional functionality to the methods, abstract methods should not be overridden just for implementing them inside the instantiatable class.
In general you should be careful with inheritance as code tends to become very hard to understand, if you implement something in a deep type hierarchy. IMHO hierarchies start to become hard to use with a hierarchy level of 4-5 already, but this is probably heavily opinion based. There is the rule to prefer composition over inheritance to avoid over-exhaustive use of inheritance for simple utility stuff.

Java: Adding fields and methods to existing Class?

Is there, in Java, a way to add some fields and methods to an existing class?
What I want is that I have a class imported to my code, and I need to add some fields, derived from the existing fields, and their returning methods.
Is there any way to do this?

You can create a class that extends the one you wish to add functionality to:
public class sub extends Original{
...
}
To access any of the private variables in the superclass, if there aren't getter methods, you can change them from "private" to "protected" and be able to reference them normally.
Hope that helps!

You can extend classes in Java. For Example:
public class A {
private String name;
public A(String name){
this.name = name;
}
public String getName(){
return this.name;
}
public void setName(String name) {
this.name = name;
}
}
public class B extends A {
private String title;
public B(String name, String title){
super(name); //calls the constructor in the parent class to initialize the name
this.title= title;
}
public String getTitle(){
return this.title;
}
public void setTitle(String title) {
this.title= title;
}
}
Now instances of B can access the public fields in A:
B b = new B("Test");
String name = b.getName();
String title = b.getTitle();
For more detailed tutorial take a look at Inheritance (The Java Tutorials > Learning the Java Language > Interfaces and Inheritance).
Edit: If class A has a constructor like:
public A (String name, String name2){
this.name = name;
this.name2 = name2;
}
then in class B you have:
public B(String name, String name2, String title){
super(name, name2); //calls the constructor in the A
this.title= title;
}

The examples only really apply if the class you're extending isn't final. For example, you cannot extend java.lang.String using this method. There are however other ways, such as using byte code injection using CGLIB, ASM or AOP.

Assuming this question is asking about the equivalent of C# extension methods or JavaScript prototypes then technically it is possible as this one thing that Groovy does a lot. Groovy compiles Java and can extend any Java class, even final ones. Groovy has metaClass to add properties and methods (prototypes) such as:
// Define new extension method
String.metaClass.goForIt = { return "hello ${delegate}" }
// Call it on a String
"Paul".goForIt() // returns "hello Paul"
// Create new property
String.metaClass.num = 123
// Use it - clever even on constants
"Paul".num // returns 123
"Paul".num = 999 // sets to 999
"fred".num // returns 123
I could explain how to do the same way as Groovy does, but maybe that would be too much for the poster. If they like, I can research and explain.

Preferred way of declaring methods in a class

I am having a doubt with method creations in a class for setting information.
creating separate methods for setting each attribute
class Address{
private String name;
private String city;
public setName(String name) { ... }
public setCity(String name) { ... }
}
creating single method for setting all attributes
class Address{
private String name;
private String city;
public setAddress(String name,String city) { ... }
}
from above two ways which is preferable in memory point of view?

Common practice is to use JavaBean style
class Address {
private String name;
private String city;
public setName(String name){
this.name = name;
}
public String getName() {
return name;
}
public setCity(String city){
this.city = city;
}
public getCity() {
return city;
}
}
Another common practise, which is quite similar to you second approach is to create immutable object. Parameters are passed to constructor instead of big setter method.
class Address {
private final String name;
private final String city;
public Address(String name, String city) {
this.name = name;
this.city = city;
}
public String getName() {
return name;
}
public getCity() {
return city;
}
}
From memory point of view, difference would be that second example is setting all attributes in constructor and all those attributes are immutable. In general, object constructed this way are safer when used by multiple threads.
In second example, there is no need for synchronization. You'd need to handle synchronization/memory issues when multiple threads using standard JavaBean object.

I can't see how the two approaches would be any different memory-wise.
Choose the approach that makes most sense to have in the interface of the class.
I would recommend to go with approach 2 only if both properties are logically strongly related, or if there is some class invariant that you don't want to temporarily break (even temporarily).
In your Address example, I would definitely go with two setter methods, since when talking about addresses, the name and city are quite unrelated.
For methods in general I'd say that whether or not you split a method up in two has little effect on memory consumption. Each object doesn't get its own set of methods allocated. The memory containing the methods is shared between all instances of a class.
Rule of thumb: Strive to make the interface of your class clean and logical.

Why not to use method #2
Your second example is not recommended because if you added a new field to the Address class, then do you add it into the existing setter method or do you create a new setter method? If you add it into the existing setter method, then any classes that called that method would be broken. And if you created a new setter method, then it is confusing for anyone who wants to use that class why certain fields are grouped together that way while others are not.
Using a separate setter method for each field that you wish to expose
The common practice is to have a single setter method for each field in your class that you wish to expose (i.e. your first example). Whether or not this is a good practice is debatable because it forces a class to be mutable. It is best to make an object immutable, if possible, for a number of reasons.
Initializing your fields using a constructor
One way to make a class immutable is by getting rid of the setter methods and instead making your fields settable via your class constructor, as below. The downside to implementing it this way is that if your class has a lot of fields, it may potentially lead to large, unreadable constructor calls.
public class Address {
public String name;
public String city;
private Address(String name, String city) {
this.name = name;
this.city = city;
}
}
Initializing your fields using the Builder pattern
Below is a completely alternative implementation (inspired by this article) that is a variation of the Builder pattern. It simulates object mutability without sacrificing readability.
public class Address {
public String name;
public String city;
private Address() {}
private void setName(String name) {
this.name = name;
}
private void setCity(String city) {
this.city = city;
}
static class Builder {
private Address address = new Address();
public Builder name(String name) {
address.setName(name);
return this;
}
public Builder city(String city) {
address.setCity(city);
return this;
}
public Address build() {
return address;
}
}
}
With the above class, you could create an immutable instance of the Address class as follows:
Address address = new Address.Builder()
.name("Mansoor's address")
.city("Toronto")
.build();
Which approach uses more memory?
From a memory point of view, there shouldn't be any difference since the size of a class in memory is dependent on the fields in the class. Since all three implementations have the same fields, they should take the same amount of space in memory, regardless of which approach you use.

This is not a clear question. Do you mean, would you rather have two methods like setFoo(String) and setBar(int), or one method like setFooBar(String, int)? It really depends on whether these are logically different properties, in which case you want individual methods, or whether it often (or only) makes sense to set them together. You could provide both.
Neither has any impact on memory, no.

The JavaBean standard is to have getters and setters for each property: http://en.wikibooks.org/wiki/Java_Programming/Java_Beans. If you don't want to follow that standard convention, its what makes the most sense for your shop. As per other answers on this thread, there probably is a minimal memory delta, if any.

Nb.1 without a doubt.
And you don't write that code by hand, only declare your fields.
Then you let Eclipse do the rest for you.
In Eclipse use Source --> generate getters and setters.
A very similar construct as #2 is done in the objects constructor.
The updated question with regards to memory. Don't worry one second in production code for the memory difference between those two ways.

You generally write a setter and a getter method for each attribute.
I don't really see the case when one method is enough for setting all the attributes. In this case, all attributes should have the same value? Or you always would have to pass parameters for all attributes. Both cases are not really what you want. So you should clearly prefer your first approach.

What's the most object-oriented way to design an address book?

I am asking myself how to design an object-oriented address book in Java.
Let's say a contact can have several contact details, like addresses, phone numbers and e-mail addresses.
One way to implement this would be to give every contact an ArrayList for every type. But there must be a better and more object-oriented solution. What is it?

The most OOP suggestion I can give you is to create a class for every item/piece of information. For example:
public abstract class ContactInfo { /* ... */ }
public class Address extends ContactInfo { /* ... */ }
public class PhoneNumber extends ContactInfo { /* ... */ }
public class EmailAddress extends ContactInfo { /* ... */ }
public class Contact {
private String name;
private Set<ContactInfo> info;
// ...
}
and finally,
public class AddressBook {
List<Contact> contacts;
// ...
}
This may or may not be overkill for your specific case, but as a thought experiment, it's the way to go. It obviously takes care of the literal part of OOP — using objects — but also lays groundwork for encapsulation, abstraction and inheritance, which are closely related principles.

You're on the right track. The only thing I would do differently would be to use a List interface instead of an ArrayList collection to reference the contacts' attribute collections. This is advice based on the code-to-interfaces rule-of-thumb as described in this article and many others.

I don't think that's particularly un-object oriented. If your domain is such that a Person can have zero or more EmailAddresses, then you've almost exactly described the situation to use a list.
The only alternative approach I can think of would be to have fields such as
WorkEmail
PersonalEmail
OtherEmail1
OtherEmail2
OtherEmail3
but in my opinion that's worse, because:
You simply cannot support more than five email addresses (well, you could add more fields, but that increases the pain of the latter points and still imposes some finite limit.)
You're implying some extra semantics than may be present (what if the same address is used for work and personal? What if neither applies, can you just fill the Other ones? What if you don't know the purpose?)
You now have to test each field manually to see which is null, which is going to involve a non-trivial amount of duplication in Java. You can't use nice features like the enhanced-for loop to apply the same block to every email address, and you can't trivially count how many addresses there are
The list of properties that a Person has is now much less clean. I suppose you could package these properties into an EmailContactDetails class or something, but now you've got an extra level of indirection (more conceptual complexity) for no real gain.
So, if a person has a possibly-empty, unbounded list of email addresses, what's wrong with representing that as a list?

You can also use a Map, and then get specific values e.g. via myMap.get("emailAdress1") or iterate over the whole map like you would do with a list via myMap.entrySet().

One simple way to handle most of the use cases can be like this
public class AddressBook {
private Map<String, Contact> contacts;
AddressBook(){
contacts = new HashMap<String, Contact>();
}
public boolean addContact(Contact contact) {
if(contacts.containsKey(contact.getName())) {
System.out.println("Already exists");
return false;
}
contacts.put(contact.getName(), contact);
return true;
}
public boolean updateContact(Contact contact) {
contacts.put(contact.getName(), contact);
return true;
}
}
class Contact{
private String name;
private String email;
private String phone;
private Address address;
public Contact(String name) {
this.name = name;
}
public Contact(String name, String email, String phone, Address address) {
this.name = name;
this.email = email;
this.phone = phone;
this.address = address;
}
// getters and setters
#Override
public String toString() {
return "name is "+name+" and address is "+address;
}
}
class Address{
private String street1;
private String street2;
private String city;
private int zipcode;
public Address() {}
// getters and setters
#Override
public String toString() {
return "street1 is "+street1+" and zipcode is "+zipcode;
}
}