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 ;-)
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 6 years ago.
Improve this question
Question might be silly for experts but please help me with pointers if it is already solved somewhere.
Interview Question : "Design class diagram in best possible way"
You need to design a game "SuperHeroes".
Super hero examples are Batman, Spider-Man, Thor, Hal Jordan, Wonder Woman, Captain America .... n
Spiderman can jump, crawl, generateFire ....n
Batman can jump, crawl, fly .... n
Thor can swim, fly .... n
There can be millions of behaviour.
There can be millions of Super heroes.
Some have few behaviours common in them and some specific to hero.
Design should be flexible enough to add behaviours to the super heroes
Important point to focus was told that "System should be scalable"
I tried twisting decorator pattern to accommodate problem requirements but was failing at many places, also I have to make many interfaces for this, so scalability was questionable.
I tried another approach as Writing all behaviours in one class(If require will classify behaviours in respective classes, kind of utility class which will have all implementations of behaviours). and an Spiderman class which will have list of allowable Behaviours(kind of enum). and it is allowed to call methods from behaviour utility only if such behaviour is allowed in list. I think it is not a good approach.
Please help me with best way to achieve this.
If I understood the question correctly, the problem could be solved with the mixin pattern; however, multiple inheritance is required for a straightforward implementation, which is not available in Java. The subject is discussed in this question.
In games it is pretty easy to get a very huge inheritance tree up to the point, where it is very difficult, if not impossible to add a new entity with a different behaviour. To solve this, something called the Entity Component System is used. It is very flexible, does not limit you to inheritance and is commonly used in larger games.
There is also a follow-up article that describes a specific implementation, and has examples on how it can be used in different situations.
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 6 years ago.
Improve this question
I'm working on what's basically my first GUI program in Java and it's been working well for me so far. Everything runs smoothly, however I want to make sure I use and understand solid programming principles.
For my GUI class I have about 300 lines of code (which I've come to understand is pretty small). I've been using SWT and this GUI one window for now. I have four tab items that each contain a different set of widgets for use. I intend on having a class for each tab to take care of their respective back end requirements.
As I've searched existing questions I've found the Single responsibility principle referenced on several occasions. To my understanding, one window per class would fit this principle. When (if ever) would I break a GUI into multiple classes outside of multiple windows?
Design principle are guidelines for writing good code. Single responsibility principle says we should have only single source of change for a class.
How do we know what is the source of change in a class ?
What can change in a class ?
Answers to these questions lies with the team directly in touch with the end users. For this it is important to reach to the team interacting with the client as soon as possible with a basic simple design. It is quite obvious , we will be asked to add more new features or add new requirements.
The process above will let us know what is the set of responsibilities that our class is performing is changing. We must put those set of behaviors in separate class(s). Now our existing class should communicate with the newly created classes via. Abstractions. This is dependency inversion. Now our class no longer is dependent upon the entities which change or which can potentially change with high probability. In the abstractions only the behaviors needed by the our old class are put. Implementation details are put in newly created concrete classes which extend the Abstraction class we have created.
From the very beginning, trying to figure out all the responsibilities and putting them in separate classes even when (they may never possibly change) will make the code scattered.
Large classes are verbose. They are not browsable, they have high risk of getting affected with changes un intentionally.
Regarding your specific question on when you would want to break out stuff into a separate class:
Let's assume you write an address book. You would probably want to present a contact's details in various places of the application. Or present multiple contacts at once. This would be accomplished by writing a separate class, like ContactDetailsPanel.
In general, most of the usual patterns apply to GUI classes as well: don't repeat yourself, single responsibility, and so on. One pattern I would like to point out when writing GUI code is MVC: Model-View-Controller. It's basically about separating business logic, presentation, and data.
You might want to take a look at what kind of things get separate classes in SWT, too.
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 currently have several "manager" classes in a project I am working on but have seen a lot of things that advise you to not use manager classes but don't seem to provide any alternatives in my situation. I have a ClickManager which contains a map of "clickable" objects and a ConfigManager which is responsible for loading and saving config files as the config class comes from an API I am using and is too stupid to load itself.
What are some alternatives to using "manager" in these cases?
Ward Cunningham once said (1) that every programmer should have a dictionary and a thesaurus on his or her desk. There's also a saying that there are only two hard problems in computer science: cache invalidation and naming things. (2)
The point is that naming things is important, and it's hard, and it's often neglected. This is why there are classes named Data and Manager littered around many code bases.
There are at least two potential things going on here. One is that the class is doing something reasonable, and it just needs to have a good, concise, descriptive name applied to it. For example, with ClickManager, does it dispatch events to the clickable objects? If so, maybe it's a Dispatcher. Does it lay out the clickable objects? Maybe it's a Positioner. Does it contain the clickable objects (as Erwin Bolwidt suggested)? Maybe it's a Container. Does it execute something in response to a click? Maybe it's an InteractiveCommand. It's sometimes helpful to think more specifically about what a class is doing in order to come up with a good name.
Another possibility is that the class has too many responsibilities, that is, it violates the Single Responsibility Principle. This is often the reason that something is hard to name, because it does a bunch of different stuff. Suppose the class simultaneously contains clickable objects, dispatches events to them, positions them, and executes commands. It's no wonder that it's hard to come up with a name other than Manager because it's doing all of these related, but independent functions. (Note that in many UI toolkits, these responsibilities have been separated into different classes.)
If this is the case it might be advisable to do some refactoring of a big Manager class into smaller classes, each of which has fewer (or one) responsibilities. It should be easier to come up with better names for those classes.
(1) I think it was at an OOPSLA about ten years ago.
(2) And off-by-one errors.
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.