Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 days ago.
Improve this question
I haven't had much to do with OOP for some time now and I am uncertain how to approach the following problem. To refresh my knowledge I decided to do a small program in java.
The main problem lies in the modelling of three classes. So there exists an abstract base class like human and child classes Mother, Father, Child. Mother and Father can have multiple kids. But a kid can become a parent aswell and have children and so forth. I haven't considered the idea of working with interfaces yet.
Personally the second approach seems more accurate but I am not sure. And how would I model that in a database.
Edit: To specify what i meant: In my case there are certain attributes that a mother/father has but a child doesn't, therefore my approach with the hierarchy. And with change i meant that at some point the child might become a parent aswell and thus having children. Sorry for the confusion i didn't mean to say that my scribble is a uml diagramm but rather a visual representation of what i thought of.
There is no need to create separate classes for the various members of a family, because:
Every member is a human.
Every human has parents (even mothers and fathers have mothers and fathers).
Every human may or may not have children.
So every person in your database, whether they're a mother or a father or a child, has:
A biological mother (link to one other human).
A biological father (link to one other human).
Zero or more children (links to zero or more other humans). But you don't necessarily need to represent this in the database, since it's implied by the links to parents.
So you can just model them all as Humans with those properties, and they can all be in the same table of humans. If a "child" ends up having children, just add to its set of children.
It's up to you if you want to store parent <-> child links in a separate table or not. Depends on your situation, what your DBMS likes, etc. If you'd like to cover the possibility of unknown parents then you can make the mother and father links optional.
Other properties, such as gender, age, adulthood status, whatever, are extra things you can add if you'd like but generally speaking they're all humans with a hierarchical structure.
Related
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 2 years ago.
Improve this question
I am beginner and trying to learn by studying material online. I just draw a diagram and want to show you so that you please put me on the right path.
Question-1: Is that drawn correctly
Question-2: How to implement this diagram into Java Code
Trying to build SiteTemplate that has 3 sub classes e.g. (1) different elements like modal, buttons, combo box, table etc (2) Java Script element like error checker and messages (3) all URLs that'll be used in project so that if the site move from one server to another we just change URLs and it start work again
I am trying to that if I inherit SiteTemplate class then have access to all methods of sub classes and their child classes
Best Regards
if I inherit SiteTemplate class then have access to all methods of sub classes and their child classes
No, the fact SiteTemplate is inherited directly or indirectly by other classes does not allow SiteTemplate to have access to the methods of these classes.
In fact this is in the reverse direction, the child classes inherits the public/protected methods of the inherited class(es).
If SiteTemplate correspond to an element of a site your generalizations are right, but what I said above still apply. May be also SiteTemplate is an interface and in this case the generalizations are realizations. In Java you use extends for generalizations and or implements for realizations.
SiteTemplate by default does not know the classes inheriting/realizing it, to make it explicitly knowing them is a bad architecture.
If you want to say a SiteTemplate is composed by any number of ProjectURL and JSElement and HTMLElement the generalizations are wrong and you can use aggregation (or even composition) :
that allows SiteTemplate to access to the elements composing it, and then to apply on these instance the public operations their classes define.
In Java they are attribute, and because the number of instances are unknown you use collections.
Warning, do not name class at plural, so ProjectURL etc whatever these classes have several instances, this is why in my answer I do not use plural
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 2 years ago.
Improve this question
I am preparing for Software Engineering interviews and figured out its good to get a sense of Object Oriented Design for my interviews. In all the examples of UML diagrams I looked at, I am having trouble figuring out where the methods belong. For example, the following is one of the UML diagrams from a Object Oriented Design course for a Airline Reservation System.
The main issue I have with this diagram are things like:
Flight class containing addFlightSchedule() method
Airport class containing getFlights() method etc.
Having done some work in this area, I always have a service class (like FlightScheduler class) that has addFlightSchedule() method and the Flight object is merely the one that contain attributes / methods applicable for a flight. So, is it right to design classes in that way during the interview ? Is there a reason why all online UML diagrams have service (operation) methods as part of the class itself ?
This is a domain model that tells something about the domain logic. It's not an implementation model of how the system should work:
1. The flight
In this model, the fight represents an airline route between two airports. And flight companies like train companies like regularity. Therefore the same route (flight) can be operated on a periodic schedule (here on one or several days of a week. Alternatively, it can be a charter flight operated only on specific dates, and therefore the flight can have none, one or more custom dates.
In such a model it is therefore logic to find addSchedule() in the fight, because this allows the flight to be described more in details. So it's definitively part of the expected flight behaviors. If any other class would do it, you'd create a dependency and a coupling to a specific implementation.
The only suprising thing here, is that CustomeSchedule and WeekSchedule are not specializations of a FlightSchedule.
2. THe airport
It is a clear role of an airport to know what planes are supposed to arrive and to depart from the airport and when. In every airport I can consult the list of expected arrivals and departures, with some infos about the flight.
And this is what getFilghts() is about: it's up to the aiport to deliver this information to other classes that only know the airport. If this model would not provide this airport method, every passenger would have to know about all the planes in all the world and findout the planes departing from the airport. This would break encapsulation, because the apassenger would have to know way too much details about the world.
THis being said, in real world, you'd expect this method to take a specific data as a paramter: again, it's not up to to filter the flights and find the one suitable for a given date.
Principle of least knowledge
This model aims to encapsulate the objects sufficiently, so that each object does not have to know how to relate all the others.
It tires to comply with the principle of the least knowledge, so that every class has to know as few classes as necessary. In perticular, passengers know about airport and about planes. THey do not in principle have to know about how schedules work.
This model is clearly a simplification and it is also imperfect. It's for example not clear how instances of a flight are created. But perhaps your book addresses this question and the different alternatives in a dedicated chapter ;-)
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 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.
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.