So, I have an object-oriented assignment to do. Small part of it is to make a graph, made out of nodes, which can be either a type category or type product.
The category has only a name ([a-zA-Z0-9]+) as parameters.
The product hast a name ([a-zA-Z0-9]+) and an id (>=0).
At the beginning a made just a node, with two objects category in product, which where both null, and depending on the input I created an instance of one of the two things, and everything was fine.
I really put a thought in it and after I checked the lectures I found about the thing abstract classes :D . No my idea is to make Node abstract and Product and Category extending Node,since:
Category has setter and getter for Name and toString
Product has setter and getter for Name AND ID (of course) and toString.
Setter,getter and toString for Name are identical.
There's a differnce in the constructor for Product, because it sets also the ID.
So,
Is it going to work that way, is it better?
Can I create a Node and then after the input say -> this node is from type category
You cannot just create a Node if it is abstract.
You should be getting the input, and in that probably the type that wants to be created, and create the appropriate non abstract class for that one.
Alternatively you can create them as Category and if the user types an Id create a new Product and copy the data across from the first object to the second. But that doesn't makes much sense.
Seems like category should just be part of product. That is you have a category class, and a product class which has two properties: category class and id. That way, you can create a category out of any point on your graph, and then if it is a product, pass it to a second constructor to give it an id.
I think this should be an abstract method validate that each node type can implement independently.
Node suggests that this is a graph of states that you're navigating. Perhaps you want a method to fire on entering or leaving that state. Each type can put whatever they need into it. Interfaces and strategy patterns will help here.
Keep the graph separate from what's done.
Related
I am currently studying OOP and UML together, there is confusion regarding the use of association class or just the plain association. Let say a Company hires Person, as far as I know there are two ways to associate them, the first way is just a regular type of association(I think this is aggregation) like this.
Regular association
The second way is to use an associative class, kind of like the one the ER diagram, but the Company class no longer has the responsibility to hire any Person.
My questions are:
Which one is correct? (It seems like the second one makes more sense, but the first one isn't wrong either)
If the first way is not wrong, but then wouldn't Company knows too much about Person?
In what situations do I consider using association class over regular association?
Your association is not an aggregation, an aggregation has an empty diamond (<>), so it is a simple association.
None of the association ends has a name even when navigable, so why are you using an association rather than may be a dependency if you do not want property ? Of course if it is not an association you cannot have an association-class.
In the class Company we can see the attribute Employees, are you sure you do not want :
or
You named the association as the operation (hire), of course you can but an association just represent a semantic relationship, so hire does not represent the operation.
As rightly said by #Axel Scheithauer in his answer in case of an association-class the name of the class and the name of the association are common properties and must not be duplicated so cannot be different, from formal/2017-12-05 ยง 11.5.3.2 Association Classes page 200 :
Both Association and Class are Classifiers and hence have a set of common properties, like being able to have Features,
having a name, etc. These properties are multiply inherited from the same construct (Classifier), and are not duplicated.
Therefore, an AssociationClass has only one name, and has the set of Features that are defined for Classes and
Associations.
About to use an association or an association-class it is a choice.
If you want to know the date the company hired an employee and the employee salary (when hired / current) for sure an association-class is a good choice clearly showing what you want.
But you can also have Onboarding as a third class out of an association class and having association between the 3 classes :
and you can also have date and salary as attributes of Person supposing a person is necessary an employee :
else you can have the class Employee inheriting Person and having these additional attributes :
You have Java and C# as tag, none of these language support association-class, so even you use an association-class in UML when implementing it in Java / C# you will probably use one of the two other solutions.
Because there is no bidirectional navigability a company knows his employees but an employee does not know the company or companies where he/her works, do you really want that ?
I agree with everything that bruno said in his answer. However, I would add a third possibility: a simple Class.
If the relationship between two classes has properties, you have two options: An association class or a simple class associated with the two classes. The only advantage of taking an association class is, that you then can specify, that each pair of instances of the two associated classes can only be linked once. That means, each person can only work once for the same company. This is not quite realistic. In order to allow multiple links, you would need to specify {non unique} for the association ends of the association class ({unique} is the default). So, only in the {unique} case an association class adds semantics. If that's not needed I would avoid it.
One additional note: The association class is one element, but it is shown twice in a diagram, once as a rectangle and a second time as a line. Since they denote the same element, the name must be the same.
I am learning software design now. I am a front-end guy so this may be a stupid question, but I really want to know the answer. Hope you could help me.
I have to design an E-commerce system. More specifically, I am designing the buying system in E-commerce. I have done some research on how to do it and found EAV. But after knowing the EAV is the anti-pattern, I don't want to use it and also I have to keep it simple for a beginner like me to understand the design.
Here is the class diagram I have designed by myself.
And of course, I don't think this design is correct. I have spent like three days doing research and thinking about how to solve the Product and ProductType problem.
I just want to have a product like an iPhone, for example, has the attributes belong to the phone, a coke has the attributes belong to the drink, etc.
How could I do this?
Please tell me how to solve this problem in a simple way, cause I am new to this. Some articles or books about software design could be appreciated too.
Thank you <3
Basically you know that all the products have (at least) a product type. And you know that a product type instance will end up being a drink, a telephone, etc. So, you first need
Product Type Abstractization
You will need to make sure that ProductType is either an interface or an abstract class or a base class. An interface is a declared entity type, whose capabilities are known, but not implemented. It is the job of the classes implementing the interface to implement its methods. An abstract class is a fully declared, but only partially defined entity type. If you have an abstract class, then you are able to implement some of its methods, but you delegate the implementation of some of its method to its implementing subclasses. A base class is a class which is fully defined.
So your first decision is to make ProductType one of the following:
interface
abstract class
base class
You will need to think about what the common capabilities of product types are. If they should have some methods which work exactly the same, then you do not necessarily need an interface, but you will need an abstract class or a base class. If you decide not to define an interface at this point, that's fine. Later you can define it if you realize that you need it anyway. So, assuming that the methods of the separate product types are at least partially common, you will need to have some class. By default it should be a base class, that is, a normal class which has all the methods a ProductType should have implemented. Son't worry, if some specific product types should behave in a different manner in the case of some methods in comparison to the base class, you can always override base class methods for subclasses.
However, you might need an abstract class. In order to decide whether an abstract class is the way to go is to find out whether there is at least such a method that should NOT be implemented by the base class in any circumstances, because that method is always known only on subclass-level. For example, if you have an evaluate method, then you will probably need to implement it separately for your product types, because a phone is evaluated in a different manner in comparison to car.
Next, you need to define specific ProductType subclasses, that is, classes which extends/implement ProductType. We know that a ProductType may have 0 or more Products, but can a product be of more product types?
Handling one-to-many vs. many-to-many relations
A product will need to have a ProductType if there is no possibility for more product types to be associated to a single Product. Otherwise you will need a collection of product types by product.
Abstractization of Product
Since Product is also something much more general, you will probably need to invoke Product methods from ProductType. This means that you will need to decide whether Product is an:
interface
abstract class
base class
as well, with a similar thought process as the one you have used when decided what ProductType should be.
ProductType and Product trees
It's a big question whether there can be subtypes, sub-subtypes, etc. for ProductType and Product. If that's the case, you will need to implement trees for them with proper insert/update/delete/search functionalities, as you need them
Use your abstractizations
Whenever possible, do not refer to specific product types, because then you will have to copy-paste that code for other products and product types. Whenever the same pattern is true for all your product types or products, refer them by their most abstract representation (their interface, abstract class or base class, respectively) and only use concrete types at instantiation and when you are forced to.
Factories
Use factory methods for instantiation instead of constructors, because a factory method can return the instance of a subtype if that's what you need.
I have a question that may seem pretty trivial to many, but it's one that has made me think repeatedly about the readability of the code that I write.
Lets assume that I have a class that encapsulates details of an entity, such as an employee, called EmployeeDetails. (Note - I also have a class named Employee which exists at the DAO layer. I do not want to return any DAO level classes from my service methods, which is why I created the EmployeeDetails class to be returned from my service layer methods. I also wanted to avoid confusion between class names by keeping the service and DAO layer class names distinct).
I also have a service level method that, given a list of Employee numbers, returns a List<EmployeeDetails>. My question is this - what is the best coding convention for naming the return variable? I had two options in mind.
employeeDtls - I do not like this because the person who reads my code may think that "employeeDtls" refers to an instance of EmployeeDetails instead of a list.
employeeDtlsList - I do not like this because it seems "too wordy".
Does anyone follow any specific coding conventions for variables? What is the most widely used naming convention for list variables?
Well...let's consider what we're modeling here.
A general rule of thumb, is that if it's a collection, then it should be pluralized and scoped to the contents of what you expect.
So, that'd make your variable name List<EmployeeDetails> details or List<EmployeeDetails> employees. If you can help it, try to avoid the compound name, unless that truly and concretely represents what it is you're getting back.
If you were using the Data Transfer Object model, and you had named it something along the lines of EmployeeDto, then the name of the variable would be more specific at employees, as you expect back some collection of something representing an Employee (at its core).
I usually name the return variable result, for all methods:
List<EmployeeDetails> result;
The reason is that it's obvious which list I'm adding to, and that it's gong to be returned, especially if there are multiple lists within the method.
This also conforms to good practice by naming things for what they represent, rather than what are they are. Your idea is a bit like naming an int variable as intVariable. Naming it simply result means you can change they type of the result, eg to Set<EmployeeDetails> without any refactoring of the name.
I would rather call the class EmployeeDetail so it is a singular noun which represent "detail information" of an employee.
Then the variable naming will be straight forward for its collection : employeeDetails
In case I really encounter a class named in plural form (for which I usually try to avoid), I usually use ~List as the variable name for the collection of such type. Although it is a bit too verbose, at least it doesn't cause any confusion.
Use DTO (Data Transfer Object) pattern to carry the data of underlying entity.
In your case, EmployeeDetails should be EmployeeDTO
Take a look at discussion here
All,
I have to be doing this wrong. It seemed like a good idea at the time but as I get deeper into it, I think there is a more proper programmatic way of going about it. Thus I ask you...
One note. I'm using Google AppEngine and the Datastore to store this information.
Ok... lets say I have a Super Class of Vehicle, which then has 3 Sub-Classes... Car, Truck, Motorcycle.
In the Super Class, there are 3 properties... Manufacturer, Model, Type
For example, these might be:
Manufacturer: Ford
Model: Focus
Type: Car
So in the Datastore, I have numerous Vehicle entities with these properties.
So if the user wants to see all the cars... I pull everyhing with a "Car" type.
If the user then wants to add one of these Vehicles to a "favorites" list, I then convert the Vehicle object into its specific Sub-Class based upon what type it is. This then adds the extra properties of that specific Sub-Class.
This new child entity is store in the Datastore with its added properties.
So basically, I'm downcasting, for example, from a Vehicle to a Car. I have done this by creating an extra constuctor in the Car class that takes Vehicle as an argument. Once created, the Car object now has all the properties (Manufacturer, Model, Type) set, and all the new properties that come with its specific implementation.
This just seems convoluted and wrong. It works but there has got to be a better way of doing this.
The main reason I chose this way is because of the way the GAE Datastore works. Its "cheaper" to store the Super Class and its limited properties and query those. Long story.
I'm trying to wrap my head around using Interfaces and/or Abstract classes for this but I wanted to get all of your input.
Thanks for the help.
I don't think you want a super/sub class structure here. Your problem as described has you "changing" an object from one type to another, and you cannot change the type of a Java object. You can create a new object, but then you have to move all your information from one to another, and maintenance becomes a problem.
I suggest that you have a class that represents your vehicle, and that it contain a reference to type-specific information; the classes representing each specific type can all extend something, and probably should so that methods within vehicle trying to do something with the type can call a common method to do it regardless of type. But this way, once you decide the specific type, you can add it to an existing vehicle object instead of "changing" it.
You could also explore whether an enumerated type would serve your purpose for type-specific data -- enum types can take constructors, have additional methods, etc. - the Oracle/Java tutorial on enums covers that pretty well.
The type of vehicle is encoded twice: once as an object type, and once as a property. Get rid of one of these, so that there is not a possibility of having a Truck (object type) with property value set to Car. Keep your object structure, or property pointing out the kind of vehicle (I recommend using an Enum), but not both.
To downcast, you do not need to create a new object of the child type. Just downcast:
Car myCar = (vehicle instanceof Car ? (Car)vehicle : null);
I'm using this tutorial: http://www.objectdb.com/tutorial/jpa/eclipse/ee/ejb
Is the persist function required? The class isn't extending any other classes.
Is DAO required in my model name? I see List<Guest> is <Guest> referring to GuestDao or the package name? If I had to guess I'd say GuestDao
Thanks for clearing this up
The persist method is a type-safe persist method. It can cut down one type of programming error (saving the wrong entity type through the DAO).
It's required in the sense that a GuestDao would be expected to have Guest-specific methods.
It also keeps knowledge of the persistence mechanism itself out of the mainline code: separation of concerns. All the mainline code needs to do is persist guests via the DAO.
Dao is not required in the model name. It would actually be confusing, since it wouldn't be a DAO. Guest refers to a guest. GuestDao refers to a DAO for Guests.
List<Guest> refers to a collection of guests. List is a generic type, the symbol between the "<>" is the collection type, in this case, Guest. Guest refers to exactly that--the Guest class.
Inside of List<?> is the type.
There should be another domain class called Guest. Is it mentioned in the tutorial or earlier? Guest class should contain all the attributes of the Guest domain class, i.e. name, telephoneNo etc.