Is it advisable to use getters and setters in Java?

[Stephan van Hulst]

Not really. Properties in JavaFX are just wrappers around a field that allow you to add a listener to them that is notified when the property changes. Personally I think it makes the API very bloated and leaky. They took all the bad stuff of JavaBeans and added more junk to it.

JavaFX's greatest achievement, in my opinion, is FXML.

[Jesse Silverman]

I was going thru one of our FAQ's this afternoon and found (broken) links to the following classic articles that are still relevant:

https://www.infoworld.com/article/2073723/why-getter-and-setter-methods-are-evil.html

https://www.infoworld.com/article/2072302/more-on-getters-and-setters.html

Note: Those articles are OLD!!  Java 5 and generics and varargs and covariant return types and a million other Modern Java things weren't there yet.

Also Note: I still see the kinds of problems he is complaining about there literally every day.

[Jesse Silverman]

Interesting to note that Holub referenced the classic Dunning-Kruger study way back in an article from January 2004, linked above.
Just noticed that for the first time on a re-read.

Anyway, this seemed quite relevant from some stuff I am reading right now:
http://misko.hevery.com/2008/07/30/top-10-things-which-make-your-code-hard-to-test/

Seems like a different topic, right?

Well, point 9 speaks to the advisability of getters and setters in Java:

Misko Hevery wrote:Mixing Service Objects with Value Objects: There should be two kinds of objects in your application.
(1) Value-objects, these tend to have lots of getters / setters and are very easy to construct are never mocked, and probably don’t need an interface. (Example: LinkedList, Map, User, EmailAddress, Email, CreditCard, etc…).
(2) Service-objects which do the interesting work, their constructors ask for lots of other objects for colaboration, are good candidates for mocking, tend to have an interface and tend to have multiple implementations (Example: MailServer, CreditCardProcessor, UserAthenticator, AddressValidator).
A value-object should never take a service object in its constructor (since than it is not easy to construct). Value-objects are the leafs of your application graph and tend to be created freely with the “new” operator directly in line with your business logic (exception to point 1 since they are leafs).
Service-objects are harder to construct and as a result are never constructed with a new operator in-line, (instead use factory / DI-framework) for the object graph construction. Service-objects don’t take value-objects in their constructors since DI-frameworks tend to be unaware about the how to create a value-object.
From a testing point of view we like value-objects since we can just create them on the fly and assert on their state. Service-objects are harder to test since their state is not clear and they are all about collaboration and as a result we are forced to use mocking, something which we want to minimize. Mixing the two creates a hybrid which has no advantages of value-objects and all the baggage of service-object.

This is from back in 2008, when Java was Java 6 (not that the article is only applicable to Java).

It seems like the concept of "value objects" has been somewhat elevated in Java since that time.

[Jesse Silverman]

http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/

In this piece he refers to "Service Objects" as "Injectables" and "Value Objects" as "Newables" because the term "Service Object" carries too much baggage in some circles.

Same idea.  Newables or Value Objects are just fine to instantiate in business logic code, they can't be handled by Injection, and trying to would be pointless and dumb.

"Injectables" or "Service Objects" should be handled by injection, usually by some framework.

[Stephan van Hulst]

I haven't read through any of the links you posted in your other topic, but it appears to me that a lot of the concepts that Miško Hevery writes about I have also developed independently over the years, except I didn't really name those concepts.

I really like "Newable" vs "Injectable". It shows a clean separation of two categories of types that beginning (and experienced!) programmers often mix up.

[Jesse Silverman]

I readily admit to highly appreciating having common names for our common concepts.
It is great when they are immediately self-identifying, i.e. are just what they sound like and sound just like what they are, but I do get confused too easily when we use several terms to mean the same things, worse still if we use the same term to mean several different things.

In the Google Document on Testability that I linked to in the other thread, they still use the terms "Value Object" and "Service Object" for the most part -- I am not sure if there is a newer version that just says "Newable" and "Injectable" thru-out.

Note that because this work was all done by "The Angular Guy", I believe a lot of use of the ideas shows up in Angular.js and Angular.
I don't personally use either.

[Tim Holloway]

If I follow your meaning, you're referring to the two types of JavaBeans that I call "Data Beans" (property holders) and "Logic Beans" (function providers). Though since I'm a big JSF fan, I have to deal with a hybrid form, since typically the UI datamodel also holds the action methods.

[Jesse Silverman]

Tim: I think so.  I'm still sorting this out, and unfortunately, I don't know beans about types of Java Beans.

Stephan: Trying to piece this together.
I think I am gathering from his writings that if you are using Spring, or Guice (because you are at Google or working on some project that has chosen Guice for dependency injection):

You really don't need to be creating factories for your Injectables, you leverage what your framework gives you and go with that.

For "Value Types" or "Newables", you should *not* be trying to inject those (some people in the comments section seem to be saying they do that, but it is not the right approach), so all the good stuff about Abstract Factory or Factory Methods patterns still (probably) applies?

Lastly, there seems to be a third category of "Entity Types" that are still "Newables".
I have only about halfway internalized the discussion here:
http://misko.hevery.com/2009/03/16/design-for-testability-and-domain-driven-design/

Several interesting things come up in that discussion that I have spent some time thinking about but don't feel are resolved for me as a designer at this point.

[Tim Holloway]

The term "Entity" in the Java Persistence Architecture (JPA) refers to a particular kind of data-only bean - one that maps a database table or view. What JPA does to them is strictly out of sight, so you're really mostly just talking about 2 types of beans.

I won't say you'd never inject a data bean, but there's relatively little you can do with data bean injection in most cases. It's like a problem that used to come up on the JSF forum where people tried to use Enterprise JavaBeans directly as JSF Managed Beans. Virtually impossible to do anything useful that way.

[Stephan van Hulst]

Jesse Silverman wrote:You really don't need to be creating factories for your Injectables, you leverage what your framework gives you and go with that.

Well, most application frameworks that rely heavily on dependency injection usually also provide a mechanism to configure factories for the thing you want to inject. It's not super common that you need this, but it's there.

For "Value Types" or "Newables", you should *not* be trying to inject those

Difficult to respond to this without knowing exactly what you mean by "injecting". At the end of the day, dependency injection is really just passing an argument to a method or constructor that needs that thing to do its work. When you take this perspective, what is wrong with passing a "newable" or "value type" to a method or constructor that needs it? Can you quote an argument against doing so?

The inverse is true however: "Injectables" or "services" should not be created by the method or constructor that needs them. They must always be injected. Instances of service types are either provided to the dependency injection framework by configuring fixed instances, or by configuring factories or providers.

If you're not working with a dependency injection framework, your own main method or controller classes assume the role of dependency injection framework.

Lastly, there seems to be a third category of "Entity Types" that are still "Newables".

Yes, entities are another important category, but not a separate category from newables. Rather, I would say that the category of newables is divided in two major subcategories: "Value types" and "entities". The difference between the two is simple, but important:

Value types are identified by the entirety of their state. Two objects that have the same state are indistinguishable from each other.

Entities are identified by a subset of their state, or by an external identifier. Two objects that have the same state may represent separate entities, and two objects that have different state may represent the same entity.

Value types should be immutable and they should usually have their equals() method overriden. An example of a value type is a PostalAddress. If a postal address has a different street name than another postal address, they are different postal addresses. If two postal addresses have the same street name, house number, zipcode, etc. etc., they are equal to each other.

Entities usually have an "id" field (or a set of fields that together make up the identity of the object), or they are identified by associating them with an external identifier (such as their memory address, or by putting them at a specific index in an array, or by associating them with a specific key in a map). Entities may or may not be mutable, and they generally should NOT have their equals() method overridden. An example of an entity is an Employee. Two different employees may have the exact same state (name, age, salary, etc.), but they are not equal to each other. If an employee has an internal field that identifies them (such as an employee number), then if you have two different instances with the same employee number, you should still not treat them as equal, because having two different instances with the same identity is usually an indication that your application is bugged. It usually means you retrieved an object from a database twice during the same request, or you cloned an object when you really shouldn't have. Think of it as a case of identity fraud.

People often make the mistake of overriding the equals() method for entity types. Sometimes this is even allowed or encouraged by the persistence framework. Do not fall for this trap. It almost always leads to bugs where you think two objects are equal, set the properties of the wrong one, and then overwrite a database record with inconsistent data. Even if you decide to override Employee.equals() so that two employees are only considered equal when ALL of their state (including an internal identifier field) are equal, what does that bring you?

[Tim Holloway]

Stephan van Hulst wrote: At the end of the day, dependency injection is really just passing an argument to a method or constructor that needs that thing to do its work.

No it's not. The essence of injection is that it's done from the outside. Inversion of Control. I don't code my injectables to construct things, I mark the injection point so that the injection framework knows that it should consult its factories and locate or construct something that meets the indicated specification. Perhaps it's that so often we use annotations instead of exterior XML that may make it seem like the target is seeking from the source, but what's actually happening is that the injector is scanning the target for injection markers just as the old XML was scanned.

Stephan van Hulst wrote:
When you take this perspective, what is wrong with passing a "newable" or "value type" to a method or constructor that needs it? Can you quote an argument against doing so?

I couldn't. Just can't think of many common cases where I need to do so.

Stephan van Hulst wrote:
The inverse is true however: "Injectables" or "services" shouldmust not be created by the method or constructor that needs them. They must always be injected. Instances of service types are either provided to the dependency injection framework by configuring fixed instances, or by configuring factories or providers.

Amended. When the target is shaping the source, it's not IoC, it's Service Locator (or worse, service construction).

Stephan van Hulst wrote:
Entities usually have an "id" field (or a set of fields that together make up the identity of the object), or they are identified by associating them with an external identifier (such as their memory address, or by putting them at a specific index in an array, or by associating them with a specific key in a map). Entities may or may not be mutable, and they generally should NOT have their equals() method overridden. An example of an entity is an Employee. Two different employees may have the exact same state (name, age, salary, etc.), but they are not equal to each other. If an employee has an internal field that identifies them (such as an employee number), then if you have two different instances with the same employee number, you should still not treat them as equal, because having two different instances with the same identity is usually an indication that your application is bugged. It usually means you retrieved an object from a database twice during the same request, or you cloned an object when you really shouldn't have. Think of it as a case of identity fraud.

People often make the mistake of overriding the equals() method for entity types. Sometimes this is even allowed or encouraged by the persistence framework. Do not fall for this trap. It almost always leads to bugs where you think two objects are equal, set the properties of the wrong one, and then overwrite a database record with inconsistent data. Even if you decide to override Employee.equals() so that two employees are only considered equal when ALL of their state (including an internal identifier field) are equal, what does that bring you?

This is just plain wrong. Enterprise Java Beans can have many objects bouncing around in RAM that can all represent the same row of a database table but with differing non-key values. Some may be attached, some may be detached. Which means that there are often invisible fields in the Entity as well. Some are the "before" some are the "after". EJB was designed to be able to distinguish between two instances of the same row regardless of its overall state by using equals() and hashCode(). It also used hashCode() for caching purposes. If the equals() method for two EJB entities compare anything but key fields, then you can have a case where the same row looks like two different rows.

I realize that not all ORM systems may use this approach, but that's how EJB was set up. For one thing, annotations didn't exist back then so being able to peer directly into an EJB and determine its key field(s) wasn't possible. For another, given that the key fields are the ONLY things that can determine whether two objects refer to the same row (regardless of the other column values), it's pointless to duplicate the one way that can determine whether they do or not. And finally, not all database tables have any defined key fields at all. SQL not only doesn't require it, keys and indexes are not part of core SQL at all. Granted, a table without keys can be a royal pain to work with, but it is allowable.

[Stephan van Hulst]

I'm not explaining how entities work in EJB, I'm explaining how entities should work in my opinion.

The fact that EJB considers two entities equal based on only their keys is, to me, a shit design. You can have have two objects that differ in almost every field, and the framework will still say that they are equal. I realize that ORM is difficult, but this is just plain wrong.

[Tim Holloway]

"Should" doesn't matter. Our present-day world is in a real mess right now because too many people live in a "should" world as opposed to the real world.

The whole purpose of the "equals" method over straight equality comparison was that it is extremely useful in many cases for multiple instances of the same object to be considered as essentially the same object. Otherwise it would just be useless overhead instead of a feature in the very core of all Java classes. Why do "equals" if "==" is sufficient? The equality operator is arguably more efficient and even is shorter to type.

That's especially true in ORMs, where you're more interested in a database row item than you are in its current non-key column values. Among other things, you can change columns in a record experimentally, then decide to merge those changes into a master copy of the record before ultimately writing that data out to the database. Or, alternatively, discard those changes without having to back them out of the master copy.

EJB version 1 had a real deal-breaker in that the database connection was inseparable from the entity bean. That's a major mess in a web environment where connection pooling is a key performance concept. They had to handle it by replicating the bean as a POJO Data Transfer Object. Here, for example, it was important that the possibly mutated DTO be easily matchable back to the connected object.

EJB3/JPA finally managed to ditch that limitation and use POJOs as entities, but they did it by introducing the concept of "attached" and "detached" objects. Although to the app, entities are POJOs, the ORM framework is actually decorating certain instances with the attachment state in a way that's essentially invisible to the application code (meaning that in reality, some entities only look like POJOs, but appearances are everything here). When an object is detached, a clone is made that lacks the invisible decorations. The reverse is true when/if the object is re-attached (merged). You MUST work with that clone, since the original only superficially appears identical. It's "equals()" but very definitely not "==". Use the wrong copy at your peril (been there/done that).

One of the other things about ORM systems is that while the POJOs are yours alone, the attached beans of necessity must be managed by the ORM supervisor. Just aside from everything else, why re-write a bunch of housekeeping code every time you create a new app? Even more so if you're in an app space where the same ORM can be shared between multiple apps?

So equals() and hashCode() make it possible to locate, use, and manage the various ORM entities and their different generations/attachment states in a standard low-overhead POJO way.

[Jesse Silverman]

And finally, not all database tables have any defined key fields at all. SQL not only doesn't require it, keys and indexes are not part of core SQL at all. Granted, a table without keys can be a royal pain to work with, but it is allowable.

Boy, oh boy do I hate tables without primary keys, or with duplicates.
By 1981 (and certainly by 1985) it was clear in my mind that this was a Legacy Mistake that we all should have wished was never allowed in the first place.

You think nulls in maps and raw types usage in Java is a Legacy Mistake we are all still living with -- this one predates the release of Java by more than a decade.

Forever compatibility has its drawbacks too.

It will take me some time to understand the Clash of the Titans here that my questions engendered, but tables with neither a simple nor composite primary key -- UGH!!

EDIT -- I paid no attention to SQL in 1981, I was a kid writing BASIC and 6502 on an Atari 400.  However, when I first learned SQL, and C. J. Date and friends were reflecting upon BIG mistakes in SQL, 1979 thru 1986, he convinced me that they should have ruled out duplicate records and required keys somewhere in the mid-80's.

[Jesse Silverman]

Could this all be pointing to the possibility that a first question to ask is:

What are the different categories of class types that we find today in Modern Java?

When we agree on that, we can then ask a better defined question:

Which of these types should have getters and setters?

I think this is an example of a question that sounds like a "Beginning Java" or "Basic Java" question but can't be fully answered until one has at least basic awareness of some endemic frameworks that are on top of Java SE.

I am finding some others like that in the simple-enough sounding sub-topic of "Creational Design Patterns in Modern Java".

[Tim Holloway]

Without going into specific usages, I think we can break Java classes down into 3 fundamental types:

1. Data-only classes (property containers)

2. Code-only classes (method containers)

3. Mixed classes (.e.g., JSF backing beans)

I'll further ignore method/class contexts for properties and methods as they don't really matter for this discussion.

My policy is if something has a fixed property, that property should have set/get methods. My IDE can add them automatically, and even in bulk if desired, so the only thing it "wastes" is code space and I expect optimizers to make that minimal at the object level. On the other hand, you can never tell when you may find a need to intercept access or even provide synthetic properties. Of course, via AOP or some of the other languages with access tap-ins, you can get the same effect without actually coding set/get, but let's stick to core Java.

I had an opportunity to meet with C.J.Date at a convention in Toronto many years ago and if my company had been using SQL at the time, I probably would have shown him considerable annoyance. Tables without keys are one thing, but what I'll really never forgive them for is the radical difference between syntax for INSERT versus update. The number of times when I've had to dual-code for the common case of INSERT if not present ELSE UPDATE I cannot count and with a more consistent syntax a simple swap of verbs would have sufficed. Some DBMS's ended up adopting an "INSERT OR UPDATE", but it's not an original standard. One of the reasons I like ORMs. It becomes their problem and not mine.

[Jesse Silverman]

The INSERT vs. UPDATE thing is the least of the set of things that should have been fixed when SQL went from a throwaway, experimental prototype at IBM (to prove that Relational Databases could indeed work, and we weren't stuck with CODASYL/IMS for the rest of eternity) and an ISO standard.

To C. J. Date's credit, he complained about almost all of them, from nearly the beginning, and just kept doing it.

Somehow he managed to simultaneously have the top Database textbook for decades, and be one of the most prolific authors, without too many of those things actually getting successfully addressed.

The most painful thing I've read was the attempts by himself and his co-author Hugh Darwen to digest the ISO standard into something that made any sense, in their books.  Which is to say, they can bring up the questions as to "What does this even mean?  Does it mean this?  Does it mean that?" but it was impossible to answer many of these things authoritatively, because the spec was a giant mess.  Darwen was actually on the committee himself, he did what he could but....yeccch...

It is a sad truism that some of the most widely used standards are some of the most poorly specced and documented, SQL is an extreme case.

Anyway, away from SQL a bit, for people doing Modern Java, does it makes sense to focus more on Hibernate?  JPA itself?  There's a big overlapping ecosystem of persistence and ORM stuff out there, best solutions, most used solutions, etc. -- what does a roadmap for understanding Persistence in Modern Java look like at the end of 2021?

[Tim Holloway]

When I think "IMS" I do not think of SQL. IBM's IMS/DB was not a relational database, it was a hierarchical database. The "tables" (segments) had very rigid relationships and if you think that the SQL language is awkward, try DL/1. However, a friend who spent his entire career at (large insurance company) swore that IMS/DB could stomp SQL DBMS's performance-wise. Although since it is a large company, the SQL people are cheap H1-Bs. The IMS people were relics from when performance and reliability were more important than how large a basket of developers you could rent with a fixed budget.

The actual Codd & Date book on SQL talks about SQL in a mostly mathematical sense. It's not interested in real-world implementations and since indexes are not actually required to do SQL, there's nothing on indexes or keys, foreign or domestic. Stuff like that is important for performance and reliability, but not for functionality per se.

[Tim Holloway]

Jesse Silverman wrote:Anyway, away from SQL a bit, for people doing Modern Java, does it makes sense to focus more on Hibernate?  JPA itself?

If you mean Legacy Hibernate, I advise avoiding it altogether. The Hibernate team were a major contributor to the design of JPA, so I'd use Hibernate JPA.

Note, however, that since JPA is a JEE standard spec, whether you're using Hibernate JPA, Apache OpenJPA or something else should not matter (especially if you're letting Spring do the grunt work).

[Jesse Silverman]

I think the primary thing here is that JPA is the standard, and the other things are just implementation details?

I am trying to keep a big list in my mind at least, of "things to ignore as legacy junk you are unlikely to need to work with but there are tons and tons of materials talking about all over the web (and Amazon and other book stores).

I'd almost like to see a FAQ or list of these.

Example, I think:
EJB -- ignore anything talking about, teaching or showing < 3.0 -- the changes were very large, the things that changed sucked before and are much better now -- just pretend that EJB started at 3.0 and only pay attention to materials covering 3.0 thru 4.0 -- there are plenty of these as long as you know to ignore the older stuff.

There is a pattern about how when something new comes out there is huge buzz, but because legacy stuff dies slowly it is harder to realize you are looking at something that should no longer be used on new projects or in new code.  We have both complained about that here.

I do think I might like to see a roadmap of all things jee-related of "Do yourself a favor and just ignore stuff talking about anything before this version" -- I am finding that piecemeal and painfully.

[Tim Holloway]

Before EJB3/JPA, ORM was pretty wild.

Legacy Hibernate was substantially different from JPA. Among other things, instead of an EntityManager, it used a "Session" (not to be confused with HttpSession). I worked with an alternative ORM called Kodo JDO (Java Data Objects). Kodo, based out of Atlanta got bought by Oracle and they converted and open-sourced it to form what is now Apache OpenJDO. There were other scheme such as iBatis as well.

JPA brought all those plus EJB together into a nice neat functional package and now the world is a better place.

EJB as originally conceived was mostly about remote data objects and remote data methods (Entity and Session EJBs). It was along the same lines as the now effectively-extinct CORBA except that CORBA was vendor and language-neutral and EJBs were not. Regardless, they were a security and performance nightmare. EJB2 moved away from the worst of EJB1, but it took EJB3 to convert EJBs from object that inherited from specific EJB base classes and/or implemented specific EJB interfaces to being POJOs. After that, it was easy to join forces with the systems that had been primarily POJO-based all along.

[Tim Holloway]

Correction. There is no OpenJDO that I know of. I meant OpenJPA.

[Soumya Suman]

Yes, it is advisable to use getters and setters in Java. Getter and Setter are method used to guard your information and make your code highly secure.

Getter returns the value of data type, int, string, float, etc., getter starts with the word “get”.
Whereas, Setter sets or updates the value for any variable which is used in the programs of a class. It starts with the word “set”
For example:-

// Importing input output classes
import java.io.*;

// Class 1
// Helper class
class GetSet {

	// Member variable of this class
	private String name;

	// Method 1 - Getter
	public String getName()
        {  
             return name; 
         }

	// Method 2 - Setter
	public void setName(String N)
	{

		
		this.name = N;
	}
}

// Class 2
// Main class
class GFG {

	// Main driver method
	public static void main(String[] args)
	{
		// Creating an object of class 1 in main() method
		GetSet obj = new GetSet();

		// calling setter method for setting the name 
		obj.setName("Soumya");
		// calling getter method getting the name 
		System.out.println(obj.getName());
	}
}

Output will be Soumya.

[Campbell Ritchie]

Welcome to the Ranch

If you go back through the remainder of this thread, I think you will find we all disagree with you.