Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I read this article
about a base class for hibernate entities.
Is is nowadays a good idea to use a base class for common fields like id, version, create_at, create_by, etc.?
What about hashcode and equals-Methods? I do not like to use the id field for my equals methods.
Is it possible to solve this by composition?
What are the downsides?
While using a base class for entities has a lot of uses, for mapping common fields I'd rather do it by embedding:
Define a class with your common fields and mark it as #Embeddable.
In the containing Entity, add a reference to the "embeddable" class, and mark the reference as #Embedded or #EmbeddedId, whatever applies.
When applicable, mark the reference with additional #AttributeOverrides or #AssociationOverrides to customize the mapping.
The main problem I see with #MappedSuperclass (the approach used in your linked post) is that you can only have a superclass per entity. This might be fine in many use cases, but it is too inflexible for the most complex ones. Embedding gives you the flexibility to combine as many #Embeddables as you want. The tradeoff is that it is not transparent. If you had:
select u.streetname from User u
And move streetname to an embedded address, now you will have to do:
select u.address.streetname from User u
In the end, if you know your model is simple, #MappedSuperclass will do the trick. If you have a complex model you can benefit from #Embeddable and #Embedded.
If you only work with attached instances and in a single session, you shouldn't have to implement hashCode() or equals(). Because in this case there is always only one instance per row.
You also can write your own hashCode() or equals() methods in subclasses, not calling the methods from the superclass.
Sources: http://docs.jboss.org/hibernate/stable/core.old/reference/en/html/persistent-classes-equalshashcode.html, http://docs.jboss.org/hibernate/stable/core.old/reference/en/html/transactions.html#transactions-basics-identity
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have a class that has many fields made of objects of other classes. This class is used by multiple people who keep adding more fields to it according to their needs. I want to know if there's a drawback to this compared to having one collection field, say a Hashmap, in this class which can be used to contain other classes as and when necessary. This looks cleaner to me than declaring many fields which might end up not being used
A class with too many fields and methods is certainly harder to grasp and change later on - the shorter the class is, the easier it is to understand its uses.
On the other hand, keeping different class variables inside one hashmap in order to make the class shorter is not a good idea at all because you will lose type safety and will have to add many additional checks and castings later on.
In conclusion you should always keep the classes as simple and clean as possible without sacrificing best coding practices - perhaps instead of having so many different fields in one class you could have multiple smaller classes, each with their own responsibility, instead.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 months ago.
Improve this question
I have a Product class, and Builder classes, one of them can build that product subclass getting data from database, another builder can build that product getting data from other sources.
So far I have an interface:
public interface ProductDao {
Product buildProduct(RetrieveBy by, String s);
}
an enum with building options:
public enum RetrieveBy {
NAME, TYPE, BRAND
}
I do not know what is the best way to name class that is going to implement the interface and will build the product getting data from database, and other classes that can build that product getting data from other sources(JSON, XMLs, or property files).
Someone suggested me to create just a single class and name it ProductBuilder, but, IMO this violates single responsibility principal.
Thing is: there are no hard rules here, just conventions, and most importantly: that "precedent" that exists in your company/team/project.
In other words: do what everybody else does around you.
My personal style:
I would call the interface ProductBuiler ... DAO means "data access object", and that interface has nothing to do with that (directly)
I would then name the class ProductBuilderImpl for example. Or if you have one implementation per "source", then simply JsonProductBuilder or maybe ProductBuilderForJson.
But as said, the real answer is: there are no universal laws that dictate names. You should use what "feels" good for you and your team.
I dont know if I have sure about your doubt but, a DAO is a Data Access Object basically it isolates the application/business layer from the persistence layer.
If you want to create a builder interface, maybe interface something like ProductBuilder.java, and the implementation ProductBuilderImp.java.
Check this two links
DAO Pattern
Naming Convention
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I need to create a hierarchy of different kinds of vehicles.
I'm not sure exactly how I am supposed to name each of the different types of cars. My first thought was to name them FordTruck and FordCar, but that seemed like a bit too much for each class.
My other idea was to just create separate packages for cars and trucks, so that the names won't interfere. Having the same name in different packages seems to have the disadvantage of less readable code when trying to implement methods that use both Cars and Trucks.
What is the convention and what is the best practice for naming the files?
The Make is better suited as an Enum of Vehicle instead of being a Class itself.
Edit: I'm going to expand upon this a little bit. You make a Class to represent nouns (things), the Make (Dodge, Ford, Chevy, etc...) is an adjective, something that describes a noun. Instead of giving it its own class, you make it a property of the class it is describing. A String would do as well, I just chose Enum because I prefer them.
Make should be a flag inside Truck and Car, not a class. As Mike N said, and Enum constant would do.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am writing my persistent classes for a Java EE 6 project.
I am seeking best practices in writing these classes.
For example, i know that adding version field is recommended.
I am waiting for your help. Merci
UPDATE 1:
I am writing classes for an ecommerce: persons, products, reviews ....
That really depends on what are the requests.
Adding fields just because it is "recommended" may hurt performance, as they are mapped to columns at DB.
Maybe your flow does not require "versioning" at all?
What I would like to suggest for you is (if you insist on using JPA/Hibernate) is:
A. Think of your business logic entities - for example, if this is an application for a library, entities may be - Book, Author, Shelf, Room, Librarian, Reader, and so on...
B. Model the relationships between these entities - For example - a Book may be written by several author. Each other may write several books
Once you're done with this Java/OOP modelling, move on and intorduce relationships, based on JPA annotations:
For example, for the above book author relationship you will need the #ManyToMany annotation.
At this point you will also need to define what are your primary key columns.
You should also consider whether an entity which is used once per each other entity instance - for example - an Address will be used once per Reader, should be kept in a separate table, having OneToOne annotation, or will you prefer to keep it at the Reader table, using an Embeddable class.
However, the best practice can really change when it comes to the domain of the application, the required performance and the use cases.
I would suggest you to start building/designing your application and ask more specific questions.
If you are using JPA in your application, you should need to understand EntityManager and Relationships at least. See this link to learn the usages of JPA. It may be helpful for you.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm developing an application in Java with MVC architecture. Doing so has greatly decoupled and simplified my code, but the problem is that the model has no intrinsic visual representation. That is, there are no characters, no specific enemies, no buttons, no text boxes - the model is made up of hundreds of instances of one type of object. Each instance is controlled by an instance of a strategy pattern (technically, it's a hierarchy of strategy patterns); it is the only differing point between each instance in the application. The type of strategy each instance uses should therefore ideally make it look slightly different than others around it.
I'd like to avoid a giant if statement chain with dozens of "instance of" calls checking for the type of strategy used when developing a view for this application. I'd also like to avoid a similar chain using an enumeration. Any suggestions as to how I can make my view without succumbing to a massive if chain? Any suggestions as to how I could design my view properly so that it wouldn't be so tightly coupled to the strategy instances?
Thanks in advance for your time!
#DJClayworth asks the critical question:
Are you interested in presenting to the user the strategy [to be] selected, or the results of that strategy?
Assuming you'll need both, let the model contain an enumeration relating strategy names, implementations and descriptive text. The implementation can use a class literal as a runtime-type token.
In this example, enum Rule serves all three purposes as an implicit model. It supplies a legible name and description, as well as a constant representing a particular composite strategy. No case statements are required.