Related
I've been reading up Java recently. So I have a enum below that acts as a map with key "JESSIE" and value "My favorite cat".
So why does anyone need to use EnumMap? Thanks
public enum Cat {
JESSIE("My favorite cat");
private String description;
Cat(String description){
this.description = description;
}
}
The enum is the key in an EnumMap, and therefore those two things are completely different. You have no way of knowing all the kinds of things you may want to associate with your cats.
The description may be an inherent part of Cat, but you might want to associate cats with their servants, or where they (currently) live or what their preferred meal (currently) is.
EnumMap<Cat, Human> catsServant;
EnumMap<Cat, House> catsHome;
EnumMap<Cat, Meal> catsFood;
Since you don't need to modify Cat to associate it with another object, it makes it a lot easier to use, and your enum would become huge if you filled it with all possible things you might want to associate your cats with.
A second issue is that enums are singletons, which means that if you were to put mutable state (strongly discouraged!) in your Cat by adding a setDescription(String) method, it will change that globally in your program. That may not matter for simple programs or a simple property like description, but it does matter when you have more complex code.
Now a more realistic example. The JDK TimeUnit enum has values such as MINUTE, and the creators couldn't have known of all the possible things that people might want to associate with them. However with an EnumMap I can provide a translation to my native language as follows:
EnumMap<TimeUnit, String> xlate = new EnumMap<>(TimeUnit.class);
xlate.put(TimeUnit.MINUTE, "Minuutti");
xlate.put(TimeUnit.SECOND, "Sekunti");
TimeUnit isn't my class, so I can't edit it to include those translations, and it would be the wrong place anyway.
A related question is why is there a special EnumMap, since you can also use a normal map, such as HashMap<Cat, Human>.
The primary reason behind this would be to design the classes in such a way that it holds the attributes that represent its entity and not which it would require a mapping with while querying.
As an example, consider another class Human as follows
#AllArgsConstructor
static class Human {
String name;
}
Now you could have looked for a Cat to its owner mapping, but how much of a sense would it make to keep the entire Human object referenced for such a mapping? Despite the fact, that you could keep such a reference, what's helpful for the purpose of query ability is to keep such a reference in an additional data structure EnumMap in this case -
EnumMap<Cat, Human> enumMap = new EnumMap<>(Cat.class);
enumMap.put(Cat.JESSIE, new Human("naman"));
enumMap.put(Cat.LUCY, new Human("user"));
I am creating a web application following the MVC pattern.
In effective Java the author mentions to validate the parameters in the constructor of the class when creating a new object.
However i am not creating some API that will be used by third parties. My classes just accept parameters from input fields of a form which are validated before beeing submited to the server.
So in this case should i create my classes the way the author mentions in Effective java or it is useless?
It is not as clear cut as reading a book and implementing what it says. You need to think and apply the knowledge to your specific situation.
It really depends on how you are initializing the variables in your class and using them right after object construction:
Some pointers:
If the variables are going to be used by some methods in the class or the object is going to be re-used right after constructions (which in most cases will), you should validate that the values that are required are not empty or null, to avoid getting nasty exceptions.
The second time to validate input parameters is when you expect the correct values to be set to specific internal variables. If you require that a parameter be constrained to a specific value range, then it is important that you validate.
Example:
Say we have a salary cap in the object:
int salary = 0;
int salaryCap = 1000;
During creation, you can validate the passed in salary amount:
public Employee(int salary) {
if(salary >= this.salaryCap)
this.salary = salary;
}
The class relationship also determines whether you want to validate the values or not. If the parameters will be passed up the inheritance chain for-example, I would take the time to validate them, especially if they will affect the state of other objects in the inheritance chain.
Example:
Whenever I have to call the super constructor, I am tempted to validated the input:
public Employee(int salary) {
super(salary); //validate salary against known constraints
}
Where are the variables coming from? If you do not trust the source (like sql parameters etc), then you should validate them and possibly sanitize the input before executing further code. This prevents security attacks.
I am always weary to do validation and parameter checking in the constructor. I prefer to have getters and setters to validate input. That way, if something happens at object creation, at least I have the guarantee of semi-working object than a complete inconsistent object whose state cannot be readily determined. Of course this depends on your context, if you constraints are strict, you can stop the object creation and prompt the client (user, calling object etc) for valid input parameters.
The advantage that using getters/setters affords me is that the object is really constructed step by step by calling on the external interface the object gives, other than constraining the validation during creation, which when an exception occurs, renders the object unusable/unstable.
So instead of this:
public Employee(int salary) {
if(salary >= this.salaryCap)
this.salary = salary;
}
I prefer this:
public class Employee {
public void setSalary(int salary) {
if(salary >= this.salaryCap)
this.salary = salary;
}
}
The latter gives me the ability to cleanly exit with a valid exception to the caller, which will not affect object creation (I don't like throwing exceptions in the constructor).
In a nutshell, do your variable have constraints? If yes, validate those constraints before setting them to internal data properties.
I would suggest validating the data in your domain and returning a (custom) exception when fields aren't filled in correctly. This way you'll be able to implement a different UI without having to do the entire validating process again, it's best to separate this as much as possible.
At the first sight it is not necessary to validate the parameters since the validation was done before. But you should take into consideration that your class will be used in other circumstances, you cannot be sure that every time the input of your constructor is valid.
It sounds like you are validating fields which have already been previously validated.
In that case, it is just a waste of time (both writing it and in run-time). If your form (client-side javascript) have not validated the fields then it would make sense. Otherwise you can skip it.
So there is a new guy that has started where I work. I'm quite a junior programmer myself, but I've been developing for a bit longer, so I'm using my "gut feeling" to guide us in developing a project. The blind leading the blind.
A relatively small thing just came up, and I would like to know what is the best way to create this for future reference and why.
Essentially there is a basic XML file with details for files (structure isn't really relevant). He went about querying this XML file and then storing all retrieved files by creating several lists, something like so:
List<Integer> fileId = new List<Integer>;
List<String> title = new List<String>;
And then you would create a method which would query against these Lists looking for the ID.
I pictured a method would be created to query for a file out of the XML file without storing/setting anything, like so:
public Form getFile(Integer id) {
Form ret = new Form();
//Query XML, set to ret...
return ret;
}
I wanted to use value objects, since that's how I'm used to working. So suggested and settled for this in the end:
List<Form> forms = new List<Form>;
So now, we have 2 methods, 1 to populate the 'forms' variable, and then 1 to query it and return the Form... still seems very strange to me.
Also, instead of:
Form tempForm = new Form();
tempForm.id = 1;
tempForm.title = "Foo";
He prefers to do:
Form tempForm = new Form(id, title);
Purely because it's in 1 line and looks tidier. Later down the line though, I don't think using a value object like this is the best way to go.
Maybe I am worrying and thinking about stuff to much as opposed to getting on with development, but any advice on this would be great.
On your second style question:
One of the reasons to use a constructor is that you can then make your Form object immutable as in:
public class Form {
private final String id;
private final String title;
public Form(String id, String title) {
this.id = id; this.title = title;
}
public String getTitle() { return title; }
public String getId() { return id; }
}
This helps avoid concurrency issues.
I'm not sure I understand your question properly, but at the basis, it sounds like a performance question. ie: is it worth reading in an entire XML file, and restructuring it such that it is faster and easier to query, or is it better to scan the xml file every time and query against it. That's a question that only you can answer. As usual, it's the space-speed tradeoff that you have to evaluate.
If your XML file is huge and would require significant amount of memory to cache and you only query against in sporadically, then perhaps your solution is better. If it is small and speed is critical, then caching it is a good idea.
All that being said, there are several different libraries that you can use to speed up the processing in different ways. You can look at using XQuery and/or XPath (see How to read XML using XPath in Java), JAXB, SAX, etc. Each technology has its own advantages and disadvantages.
Hopefully that will give you a little more background that you can discuss with each other.
Interresting question! There are however several questions in one. Let me answer each one of them separately.
Let me first lay down the definition of a value type as found on domaindrivendesign.org
Definition: A Value Object is an object that describes some
characteristic or attribute but carries no concept of identity.
For example a file path is a string, but it also has some restrictions on the format of the string and some operations. Here it would be a good idea to create a value object. Note also that a path carries no notation of identity. That is, two path objects representing the same path would be considered equal.
Now to the actual question, I strongly recommend your way of coding - Creating a class for data that belong together. In your first example id and title are only related by an index into two separate lists.
It's better to use this form
Form tempForm = new Form(id, title);
That way the Form class can be immutable which will give you great readability benefits and also performance gains. Also the fields of the class are encapsulated.
Now to the last thing you thought was strange - Having two methods, one for creating the list and one for querying against it.
Here I would actually create a new class, containing only those two methods instead of having them say in a static class. I would call it a FormCollection. You guys can probably come up with some smarter name since you have more context. Spend at most five minutes figuring out a meaningful name.
You could also refactor your code further to for example take the xml file path or stream as a constructor argument and then have a single method for querying aginst it on id. Like so:
class FormCollection
{
public FormCollection(String xmlFilePath) { ... }
public Form getById(int id) { ... }
}
This is probably a good interface to the rest of your application, since it easy and to the point. Also it's easy to test.
I have implemented a few Java applications now, only desktop applications so far. I prefer to use immutable objects for passing the data around in the application instead of using objects with mutators (setters and getters), also called JavaBeans.
But in the Java world, it seems to be much more common to use JavaBeans, and I can't understand why I should use them instead. Personally the code looks better if it only deals with immutable objects instead of mutate the state all the time.
Immutable objects are also recommended in Item 15: Minimize mutability, Effective Java 2ed.
If I have an object Person implemented as a JavaBean it would look like:
public class Person {
private String name;
private Place birthPlace;
public Person() {}
public setName(String name) {
this.name = name;
}
public setBirthPlace(Place birthPlace) {
this.birthPlace = birthPlace;
}
public String getName() {
return name;
}
public Place getBirthPlace() {
return birthPlace;
}
}
And the same Person implemented as an immutable object:
public class Person {
private final String name;
private final Place birthPlace;
public Person(String name, Place birthPlace) {
this.name = name;
this.birthPlace = birthPlace;
}
public String getName() {
return name;
}
public Place getBirthPlace() {
return birthPlace;
}
}
Or closer to an struct in C:
public class Person {
public final String name;
public final Place birthPlace;
public Person(String name, Place birthPlace) {
this.name = name;
this.birthPlace = birthPlace;
}
}
I could also have getters in the immutable object to hide the implementation details. But since I only use it as a struct I prefer to skip the "getters", and keep it simple.
Simply, I don't understand why it's better to use JavaBeans, or if I can and should keep going with my immutable POJOs?
Many of the Java libraries seem to have better support for JavaBeans, but maybe more support for immutable POJOs gets more popular over time?
Prefer JavaBeans When
you have to interact with environments that expect them
you have lots of properties for which it would be inconvenient to do all initialization on instantiation
you have state that is expensive or impossible to copy for some reason but requires mutation
you think at some point you may have to change how properties are accessed (e.g. moving from stored to calculated values, access authorization, etc.)
you want to conform to coding standards that mindlessly insist it is somehow more "object-oriented" to use JavaBeans
Prefer Immutable POJOs When
you have a small number of simple properties
you do not have to interact with environments assuming JavaBean conventions
it is easy (or at the very least possible) to copy state when cloning your object
you don't ever plan on cloning the object at all
you're pretty sure that you don't ever have to modify how properties are accessed as above
you don't mind listening to whining (or sneering) about how your code isn't sufficiently "object-oriented"
I was surprised that the word Thread did not appear anywhere in this discussion.
One of the main benefits of immutable classes is that they are inherently more thread safe due to no mutable, shared state.
Not only does this make your coding easier, it'll also give you two performance benefits as a side effect:
Less need for synchronization.
More scope for using final variables, which can facilitate subsequent compiler optimisations.
I am really trying to move towards immutable objects rather than JavaBean style classes. Exposing the guts of objects via getters and setters should probably not be the default choice.
Well it depends on what you're trying to do. If your working with a persistent layer, and you fetch some row from the database into a POJO, and you want to change a property and save it back, using JavaBean style would be better, especially if you have a lot of properties.
Consider that your person, has a lot of fields like, first, middle, last name, date of birth, family members, education, job, salary etc.
And that Person happens to be a female that just got married and accepted to have her last name changed, and you need to update the database.
If you're using immutable POJO, you fetch a Person object representing her, then you create a new Person object to which you pass all the properties that you didn't change as they are, and the new last name, and save it.
If it were a Java bean you can just do setLastName() and save it.
It's 'Minimize mutability' not 'never use mutable objects'. Some situations work better with mutable objects, it's really your job to decide if making an object mutable will better fit your program or not. You shouldn't always say 'must use immutable objects', instead see how many classes you can make immutable before you start hurting yourself.
Summarizing other answers I think that:
Inmutability facilitates correctness (structs can be passed by reference and you know nothing will be destroyed by a faulty/malicious client) and code simplicity
Mutability facilitates homogeneity: Spring and other frameworks create an object with no arguments, set object properties, and voi là. Also make interfaces easier using the same class for giving data and saving modifications (you don't need get(id): Client and save(MutableClient), being MutableClient some descendant of Client.
If there were an intermediate point (create, set properties, make inmutable) maybe frameworks would encourage more an inmutable approach.
Anyway I suggest thinking in inmutable objects as "read only Java Beans" stressing the point that if you are a good boy and don't touch that dangerous setProperty method all will be fine.
From Java 7 you can have immutable beans, the best of both worlds. Use the annotation #ConstructorProperties on your constructor.
public class Person {
private final String name;
private final Place birthPlace;
#ConstructorProperties({"name", "birthPlace"})
public Person(String name, Place birthPlace) {
this.name = name;
this.birthPlace = birthPlace;
}
public String getName() {
return name;
}
public Place getBirthPlace() {
return birthPlace;
}
}
I don't think immutable objects will get all that popular, to be honest.
I do see the advantages, but frameworks like Hibernate and Spring are currently very much in vogue (and for a good reason too), and they really work best with beans.
So I don't think immutability is bad, but it would certainly limit your integration options with current frameworks.
EDIT The comments prompt me to clarify my answer a bit.
There most certainly are problem areas where immutability is very useful, and is indeed used. But I think the current default seems to be mutable as that is what is mostly expected, and only immutable if that has a clear advantage.
And though it is indeed possible to use constructors with arguments in Spring it seems to be intended as a way to use legacy and/or third party code with you beautiful brand-new Spring code. At least that's what I picked up from the documentation.
Immutable in terms of programming in Java : Something that once created should never have change of state , both expected or unexpected!
This technique is useful in defensive programming where another entity cannot induce change in the state.
Examples where you don't expect change : External systems(single or multi threaded) which gets reference from your layer and operates upon the object and knowingly or unknowingly change it. Now it could be a POJO or an collection or an object reference and you don't expect a change in it or you want to protect the data. You would definitely make the object immutable as defensive technique
Examples where you expect change : Really don't need immutability as it will obstruct in right programming procedures.
Is is good practice to use domain objects as keys for maps (or "get" methods), or is it better to just use the id of the domain object?
It's simpler to explain with an example. Let's say I have Person class, a Club class, and a Membership class (that connects the other two). I.e.,
public class Person {
private int id; // primary key
private String name;
}
public class Club {
private String name; // primary key
}
public class Membership {
private Person person;
private Club club;
private Date expires;
}
Or something like that. Now, I want to add a method getMembership to Club. The question is, should this method take a Person object:
public Membership getMembership(Person person);
or, the id of a person:
public Membership getMembership(int personId);
Which is most idiomatic, which is most convenient, which is most suitable?
Edit: Many very good answers. I went with not exposing the id, because the "Person" (as you might have realized, my real domain does not have anything to do with people and clubs...) instances are easily available, but for now it is internally stored in a HashMap hashed on the id - but at least I am exposing it correctly in the interface.
Don't use the id's man, this is just a bad idea for all the reasons mentioned. You'll lock yourself into a design. Let me give an example.
Right now you define you're Membership as a mapping between Clubs to People. Rightfully, your Membership should be a map of Clubs to "Members", but you are assuming that all Members are People and that since all of the people id's are unique you think you can just use the ID.
But what if in the future you want to extend your membership concept to "family memberships", for which you create a Family table and a Family class. In good OO fashion you extract an interface of Family and Person called Member. As long as both classes implement the equals and hashCode methods properly, no other code will have to be touched. Personally, I would have defined the Member interface right up front.
public interface Member {
}
public class Person implements Member {
private int id; // primary key
private String name;
}
public class Family implements Member {
private int id;
private String name;
}
public class Club {
private String name; // primary key
}
public class Membership {
private Member member;
private Club club;
private Date expires;
}
If, you had used ID's in your interface, you will either need to enforce cross-table uniqueness of key values, or maintain two separate Maps and forgo the nice polymorphic interface stuff.
Believe me, unless you are writing one-off, disposable applications, you want to avoid using ID's in your interface.
Assuming this is a database ID or something used just for indexing (rather than something like an SSN), then in an ideal system, the presence of an ID is an implementation detail.
As an implementation detail, I would prefer to hide it in the interface of other domain objects. Thus, membership involves, fundamentally, individuals rather than numbers.
Of course, I'd make sure I implemented hashCode and equals() and documented well what they meant.
In that case, I would explicitly document that the equality of two Person objects is determined solely based on ID. This is somewhat a risky proposition, but makes code more readable if you can ensure it. I feel more comfortable making it when my objects are immutable, so I would not actually end up with two Person objects with the same ID but different names in the lifetime of the program.
I think the first case would be considered "purer" in the sense that the getMembership method might require more specific data from the person itself other than its id (Let's assume you do not know the internals of the getMembership method, even though this makes little sense since it's most likely in the same domain).
If it turns out that it actually requires data from the Person entity then it will not require a DAO or factory for the person in question.
This can be easily called if your language and/or ORM allows you to use proxy objects (and if you have a convenient way to create these proxies).
But lets be honest. If you're inquiring about some membership of a person, you most likely already have this Person instance in memory at hand when you call this method.
Further down the road in the "infrastructure land" there's also this notion about implementation details which Uri already mentioned while I was writing this answer (damn, that was fast bro'!). To be specific, what if you decided that this 'Person' concept suddenly has a composite primary key/identifier in the underlying database... Would you now use an identifier class? Perhaps use that proxy we were talking about?
TL;DR version
Using ID's is really easier in the short run, but if you're already using a solid ORM, I see no reason not to use proxies or some other means to express the object oriented identity of an Entity which doesn't leak implementation details.
If you are really practicing object oriented design, then you want to invoke the idea of information hiding. As soon as you start hanging internal field types of the person object in the public interface of the membership object's methods, you start forcing external developers (users) of your objects to start learning all kinds of information about what a person object is, and how it is stored, and what kind of ID it has.
Better yet, since a person can have memberships, why don't you just hang the "getMemberships" method onto the person class. It seems much more logical to ask a person which memberships they have, than to ask a "membership" which clubs a given person may belong to...
Edit - since the OP has updated to indicate that it is the membership itself that he is interested in, and not just used as a relation between Person and Club, I'm updating my answer.
Long story short, the "Club" class that you are defining, you are now asking to behave as a "club roster". A club has a roster, it isn't is a roster. A roster could have several features, including ways to look up persons belonging to the club. In addition to looking up a person by their club ID, you might want to look them up by SSN, name, join date, etc.. To me, this says there is a method on class "Club" called getRoster(), which returns a data structure that can lookup all the persons in the club. Call it a collection. The question then becomes, can you use the methods on pre-existing collections classes to fulfill the needs you have defined so far, or do you need to create a custom collection subclass to provide the appropriate method to find the membership record.
Since your class heirarchy is most likely backed by a database, and you are probably taking about loading info out of the database, and don't necessarily want to get the entire collection just to get one membership, you may want to create a new class. This class could be called as I said "Roster". You would get the instance of it from the getRoster() call on class "club". You would add "searching" methods to the class based on any search criteria you wanted that was "publicly available" information about the person.. name, clubID, personID, SSN, etc...
My original answer only applies if the "membership" is purely a relation to indicate which clubs which persons belong to.
IMO, I think it very much depends on the flow of the application - do you have the Person available when you want to get the Membership details? If yes, go with:
public Membership getMembership(Person person);
Also, I don't see any reason why the Club cannot keep track of memberships based on the Person's ID and not the actual object - I think that would mean you don't need to implement the hashCode() and equals() methods. (Although that is always a good best-practice).
As Uri said, you should document the deceleration that two Person objects are equal if their ID is equal.
Whoa. Back up a sec here. The getMembership() method doesn't belong in Club. It belongs to the set of all memberships, which you haven't implemented.
I would probably use IDs. Why? By taking IDs, I'm making safer assumptions about the caller.
If I have an ID, how much work is it to get the Person? Might be 'easy', but it does require hitting a datastore, which is slow...
If I have Person object, how much work is it to get the ID? Simple member access. Fast and available.
As described by others: use the object.
I work on a system where we had some old code that used int to represent transaction ids. Guess what? We started running out of ids because we used int.
Changing to long or BigNumber proved tricky because people had become very inventive with naming. Some used
int tranNum
some used
int transactionNumber
some used
int trannNum
(complete with spelling mistakes).
Some people got really inventive...
It was a mess and sorting it out was a nightmare. I ended up gping through all of the code manually and converting to a TransactionNumber object.
Hide the details wherever possible.
I would typically stick with less is more. The less information required to invoke your method the better. If you know the ID, only require the ID.
If you want, provide extra overloads which accept extra parameters, such as the entire class.
If you already have the object, there's no reason to pull out the ID to get a hash key.
As long as the IDs are always unique, implement hashCode() to return the ID, and implement equals() as well.
Odds are every time you'll need the Membership, you'll already have the Person, so it saves code and confusion later.
First of all I'd put any getters of such nature inside a DAO (and not on the model). Then I'd use the entity itself as a parameter, and what happens inside the method is an implementation detail.
Unless there's a significant benefit derived elsewhere, it can be said that keys in map should single-valued things, if at all possible. That said, through paying attention to equals() and hashCode() you can make any object work as key, but equals() and hashCode() aren't very pleasing things to have to pay attention to. You'll be happier sticking to IDs as keys.
Actually, what I would do is call it by id, but refactoring a bit the original design:
public class Person {
private int id; // primary key
private String name;
}
public class Club {
private String name; // primary key
private Collection<Membership> memberships;
public Membership getMembershipByPersonId(int id);
}
public class Membership {
private Date expires;
private Person person;
}
or
public class Person {
private int id; // primary key
private String name;
private Membership membership;
public Membership getMembership();
}
public class Club {
private String name; // primary key
private Collection<Person> persons;
public Person getPersonById(int id);
}
public class Membership {
private Date expires;
}