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
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 1 year ago.
Improve this question
For my Cucumber/Selenium project I'm using a Page Object Model. There is HomePage, SettingsPage, SearchWidget, etc. Classes look like this:
public class SearchWidget extends Page {
public final By buttonDisplayTypeLoc = By.id("button-displayType");
public final By buttonResultsPerPageLoc = By.id("button-resultsPerPage");
// lots more of the same
}
Is there a more elegant way to keep track of locators (the By's), instead of having long lists of them at the beginning of each Page subclass?
I've tried a separate class Element that holds a Map of a String key and a By locator. The Map could be easily added to and retrieved from. The problem with that, is that using Element.getLocator("key"); doesn't get the IDE's help with spelling for the key anymore. So I scratched that.
There's already a Site class that holds things like URL's, etc. I could easily put it there, and although it does pertain to the site, it doesn't sit well with me to have a whole bunch of fields that I'd rather have in the class it pertains to. Although it would be kind of out of sight ...
I looked at using a factory model, but it seems like overkill.
So, again, is there a more elegant way to do this, or should I just leave it alone? They are defined in the class they belong to, and although it does look ugly, it's also easy to maintain.
The Page Object Model design pattern is designed to keep everything related to the "page" in one place. Moving these around to different classes just for house keeping sort of breaks that model as described here from the link: "Subsequently all changes to support that new UI are located in one place."
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 5 years ago.
Improve this question
All of the examples I've read about DAO classes only show DAO classes with very general methods, for example, insertNewCar(), deleteCar(), updateCar(), getCars(), getCarByID(). But can I put more specific methods into a DAO class?
In my case, I need to get all doctors who are having a shift today, and to know that, I have to get all doctors' scedules which have the date equal to today. Right now, I'm getting those doctors by a single method in doctorDAO class called getDoctorsWorkingToday(ArrayList scedulesToday). In this method, I first get all ids of doctors from the arraylist and attact them into a complete sql query. And the rest of the method is just like a normal "get" method: I use the query to get all doctors I want, put them into an arraylist and return it.
It works fine, but is that solution acceptable? Or must I only use general methods in DAO class like getAllSchedules() and getAllDoctors(), and do all the filter stuff in other classes?
As per my understanding , I usually put all db specific code (queries) in DAO's and transaction handling and business logic in service layer. This allows for service methods to invoke methods across multiple dao's and keep it all within same transaction. In my opinion, this is allows for better code reuse across dao's.
In your case,
Use 'get' method business logic in Service layer and Query related stuff in dao.
It's upto you, how you are implementing the service and dao. Just for the flow and easy understanding,we are following the standards.
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
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 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 9 years ago.
Improve this question
To design a project and draw a UML class diagram, what must the class diagram include?
Suppose our classes have textfields, buttons etc. Must they be included as members?
Suppose we need to perform some form validations, and we intend to perform it by passing data obtained from a form to a "validator" object, must it be also included in the class diagram?
I received some opinions from colleagues that a class diagram is for design phase and must not include objects like I mentioned above. However when the project completes, won't there be a large number of objects we did not draw in the class diagram?
UML is a language. The way you use it is up to you.
Ideally you will have multiple documents. The reason you will need multiple documents is because the most important tip of documentation writing is to restrict yourself to one perspective per document.
You want a static representation of objects -> don't talk about files
You want to show relations between objects -> don't talk about data flow.
You get the idea. As long as you are clear with what the purpose of the document is and consistent to the legend, UML can tell any story.
For your specific question:
Since you're creating a class diagram (a static representation of system objects), the important bits will likely be what goes into each object/class (not the input fields of the form itself, but the structure of the object those fields are eventually saved to), and how they relate to other objects.
You can include the validator object and connect it to the objects its validating, but modeling how it's validating, when it's validating, or the protocol with which they communicate is not relevant for this specific view.
Generally in UML diagrams, you exclude extraneous data. Depending on how in-depth you want to be, things such as a UI controls and getter/setter methods are usually excluded.
On the other hand, your Validator object should be defined as a control class in your UML diagram, as it has a responsibility and purpose within your system.