Java – getters for display

I'm studying getters / incubators. The general idea is that they are evil and should be avoided You should let the object complete its work and generate results

Reading materials:

Why getter and setter methods are evil

Are getters and setters poor design? Contradictory advice seen

Why use getters and setters?

Considering all this, suppose I have a Book class that looks like this:

publc final Book{

    private final String title;
    private final List<Authors> listofAuthors;
    private final int numberofpages;

    //constructor not included in example.

    //getters for title,listofAuthors,and numberofpages

    public int numberofpagesleft(int pagesRead){
        //code to determine number of pages left
    }

    public boolean isWrittenBy(Author author){
        //code to determine if book contains author
    }

}

If I have a user interface (such as JavaFX, web pages, etc.) and want my course to be flexible, will the getter, listofauthors and number of pages for display purposes break the encapsulation?

Example:

//library is an List<Book> collection,and author is an object of the Author class.
for (Book book : library){
    if(book.isWrittenBy(author){
      System.out.println("Books in your collection written by " + author.toString() + " include:" );
      System.out.println(book.getTitle());
    }
}

or

for (Book book : library){
    //returns a Collections.unmodifiableList().
    if(book.getAuthors(){
        //code to build a set of authors in my library
    }
}

Question:

> call getTitle () or getAuthors () in the loop? > If the answer to the above question is yes, how will I display the true meaning of the book if iswritenby() returns? How do I collect all the authors in my library?

Solution

There are differences between the properties of the object and the implementation details of the object

>A book has a title – this is not an implementation detail. > A book has an author – this is not an implementation detail. > How to store book authors - this can be an implementation detail

Getters are not evil, but you must use them carefully because they may expose implementation details and limit changes to implementation

class Book {
    private ArrayList<Author> authors = new ArrayList<>();

    public ArrayList<Author> getAuthors() { return authors; }
}

The situation is bad for two reasons First, it returns a modifiable set to the caller, allowing the caller to change the set Second, it promises the caller that the collection returned is ArrayList

Book book = ...;
ArrayList<Author> authors = book.getAuthors();

We fix the first problem by wrapping the collection:

class Book {
    private ArrayList<Author> authors = new ArrayList<>();

    public List<Author> getAuthors() {
        return Collection.unmodifiableList(authors);
    }
}

Book book = ...;
List<Author> authors = book.getAuthors();

Now callers cannot modify the set, but they still promise that the set is list If we find that we want to store our authors as sets (because authors don't create a book many times), we can't simply change the internal storage

class Book {
    private HashSet<Author> authors = new HashSet<>();

    public List<Author> getAuthors() {
        return Collection.unmodifiableList(authors); // ERROR - authors not a list
    }
}

We have to collect authors into a new list or change the signature of getauthors (), but this will affect the callers who expect to return the list

Instead, the code should return only one collection This does not expose the implementation details stored by the author

class Book {
    public Collection<Author> getAuthors() {
        return Collection.unmodifiableCollection(authors);
    }
}

Note: the author may be ordered to list the main authors first In this case, you might want to return a list to promise the caller that the data is actually ordered In this case, the list is not an implementation detail, but part of the interface contract

So, does GetTitle () break the encapsulation? No, absolutely not

Will getauthors () break the encapsulation? It depends on its return and what you promise If it returns a collection, No If it returns a list and you don't promise ordered results, yes