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 9 years ago.
Improve this question
I need a panel with text fields a,b,c for project AA.
I need another panel with text fields a,b,d,e,f for project BB.
In future I will definitely need another panel with text fields a,b,d,y,z for project CC.
Again in future I may need another panel with... etc.
a and b text fields are common for all projects and d is common for BB and CC.
Layout of common fields may differ. Panels include methods such as createComponents, guiLayout, refresh, save, getGUIErrors...
Now, How should I design my panels? What about inheritance? Is defining a common panel including fields a,b and extending it for projects correct? Is it possible to use composition, decorator pattern ?
Of course question can be extended to models and controllers.
thank you .
Now, How should I design my panels? What about inheritance? Is defining a common panel including fields a,b and extending it for projects correct? Is it possible to use composition, decorator pattern ?
While code reuse is generally good, it seems to me you are overcomplicating things here. Why bother with all that work if it is simply to re-use two textfields on a panel. We are talking about two lines of code.
If all your panels look pretty similar, use a decent layout builder and reuse that one (see for example the builder available for the FormLayout of JGoodies).
Next to that, the typical UI layer is pretty thin. Re-use your business side (the models behind the UI) if needed/possible, but do not bother with the UI. In my experience, this lead to much cleaner code.
I have seen too many UIs/panels where the constructor takes a lot of boolean flags to include/exclude certain fields, a bunch of protected methods to provide access to all components (e.g. to disable a certain field on certain conditions), ... in short, a lot of code because in the end no two UIs are the same and you always have to customize.
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 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 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 8 years ago.
Improve this question
I was wondering if it is a good practice to extend classes which were made, in a first moment, to be used without the need to extend it, just to add some information that you will be using in the application in a further moment.
For example, I was using the Swing Java API to create a GUI for a application I was developing. While building it, I had the necessity to create a JTable which model would be changed several times on the runtime depending on what the user did. So, I had like three different models that could be applied to that JTable depending on the situation. That said, in my application I realized that it would be much more easier to me if I could extend the JTable and create another class which would have a Enum (or any other type) internally which could provide me which model is active on the JTable in the exact moment that I've checked it. So, my question is: Is it a good practice to extend, for example, that JTable, just to add fields that have information that will probably be useful to access in the application? For me, it would be a lot easier to hold this information directly in the JTable and access it whenever I have access to JTable.
Is it a good practice? Horrible practice? What your opinion? Thanks!
Assuming an M-V-C or Model-View-Control program structure, or something reasonably close to this,
...create a JTable which model would be changed several times on the runtime depending on what the user did. So, I had like three different models that could be applied to that JTable depending on the situation.
Key here is this: what is actually changing? The JTable or its TableModel? If the TableModel, I would avoid sub-classing JTable.
That said, in my application I realized that it would be much more easier to me if I could extend the JTable and create another class which would have a Enum (or any other type) internally which could provide me which model is active on the JTable in the exact moment that I've checked it.
This seems to confuse View with Model. The TableModel information should be part of the program's Model, and if it changes, you could then have the Model notify listeners of the change.
So, my question is: Is it a good practice to extend, for example, that JTable, just to add fields that have information that will probably be useful to access in the application? For me, it would be a lot easier to hold this information directly in the JTable and access it whenever I have access to JTable.
In this situation, I would not subclass JTable but rather have significant state changes and their notifications be part of the main program's Model, not its View (as you're trying to do).
Yes, extending classes this way is good java.
If a class is not meant to be extended it should be declared final.
It depends on your application business requirements and architectural strategy, but this is a common design pattern with the Decorator pattern.
http://en.wikipedia.org/wiki/Decorator_pattern
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 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
My team has been tasked with creating what you can generically call an entity management application. The 3 primary entities being managed are: Merchants, Organizations, and Contacts
Separate pages have been created for the management of each entity. However, many of the functional patterns on these pages are quite similar. The 2 patterns in particular that are repeated everywhere I look are:
Pattern 1: Associating entity of type Y with entity of type X
Pattern 2: Listing entities of type Y that are already associated with entity of type X
Unfortunately these pages were created adhoc by multiple developers. This has resulted in a hodge-podge of solutions, none of which are readily reusable. So what I want to do is abstract out the two patterns I identified above into reusable components, but I am fairly new to wicket and I'm unsure of the best strategy to use.
My first thought is to encapsulate the patterns in two parameterized component classes that extend panel. But I would like to hear from those with more experience.
Any suggestions?
EDIT:
Forgot to mention, for any wondering, that any of the 3 entities can associate in a many to many relationship with either of the other 2.
Sounds like a pretty good idea to me. Additionally I'd check if any specific logic (like DAOs, Validators and stuff) could be provided via Dependency Injection (Google Guice comes to mind) so you could just use one panel with different handlers/workers/dataproviders for your different usecases.
It's hard to be more specific since your question is kind of broad and a little bit on tue vague side..
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.