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 7 years ago.
Improve this question
Let's say you have some issue to develop. And as recommended practice it is good idea to use interfaces ( I don't mean GUI, I mean interface or abstract class ). And you can apply two ( I'm pretty sure, but for now I noticed I apply two ) ways:
Design interfaces upfront and then implement them.
Implement classes and then on basics of classes discover interface.
Personally I prefer second option, but during discussions with other developers I noticed that somebody prefers first approach. I can say that I prefer second approach for the following reasons:
I can faster write code
I avoid unnesessary code ( something that I never will use )
Interfaces in that case are more binded to "real" life
For me it is more convenient.
I'd like to hear other advices why somebody prefers option 1 or option 2.
As usually I code in C#, but AFAIK java also have idea of interfaces
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
is there really a preferable relationship between classes ? or it depends on the software we have ?
I know that we have is-a and has-a relationships in classes relations but, is there a one relation that is Confident and it most preferable between software-designers.
The only preferred relationship between classes is independence. Because independence means guranteed separation of concerns and freedom to evolve. (Joke)
But unfortunately independence is not very useful: Lots of lonesome classes will only help to solve lots of little isolated problems. If you really want to make something useful, you'll have to relate the right classes. And then, the only thing that matters is what relationship helps you to best address your needs. Sometimes it's inheritance (is-a), sometimes it's composition (has-a). It all depends on the context.
What your "doctor" probably meant was to prefer composition over inheritance. This is a useful advice. But it is a simple rule of thumb: it is not a universal truth.
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 7 years ago.
Improve this question
How would you decide which design pattern to use?
I am asked the above question in at-least 2 different interviews .Apparently I am not the only one.Somebody else posted the same question on glassdoor.
http://www.glassdoor.com/Interview/How-would-you-decide-which-design-pattern-to-use-QTN_47521.htm
Any thoughts/suggestions/comments on how to answer that question ?
Well in fact it is overwhelming. There is no simple answer or chosen design patterns. I will begin to apply the "separation of concern" design principle. One class/set of functions only do one thing. That will help to reduce the complexity. Then you can apply structural design patterns. To begin, you can just use delegation.
Before thinking DP, think separation of concern to divide your code in small understandable parts. Then use some DP to link them all.
Do not go looking for situations where to use design patterns, look for code that can be optimised. When you have code that you think is not structured correctly. try to find a design pattern that will solve the problem.
Design patterns are meant to help you solve structural problems, do not go design your application just to be able to use design patterns.
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
Say I have a method that is used for opening application with an android app from a sidebar
openApplication(Sidebar s, Context c ... )
and now I want to use this openApplication to open from a Topbar
openApplication(TopBar t, Context c ... )
The function openApplication is very similiar but needs to do little-changes based on Sidebar or TopBar attributes/ members
I dont what to make two different functions that basically do the same thing but different in 2-3 lines of code. What is good practice for approaches like this
I was considering passing a boolean or enum to the function to tell the difference but then I would have lots of if statements in the function for little things. Was also condering making private members _topbar, _sidebar but then if statements again ?
Is there a good practice to generalize functions ? or design pattern out there?
Look at the common interface or superclass that both Topbar and Sidebar share, and use that as the type.
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
I know that for methods, a explanation is provided and the #param, #return, and #throw. But for classes, are there any particular things that need to be included besides the explanation of the class?
At the class level, the documentation should explain:
Why/when would I want to use this class?
How do I use this class (examples)
How does this class play with other classes?
What is unexpected/special about this class? (thread safety, global variables, ...)
All in all, the class documentation should give a broader view, showing how the class fits into the rest of the code.
The tendency is to not include these comments or keep them very brief and let naming conventions drive our understanding of what the class should do. For example, a plain-old Java object (POJO) named "Address" might need very little in the way of documentation, other than what makes it truly unique. Take a look through recent Java projects on GitHub and you'll see this to be the case. Annotations and package names also help describe the class inherently.
If you focus more on naming, you shouldn't need to document much - other than what makes the class unique or limitations it may have.
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
As the title says, why better programmers write the code to create a GUI element. E.g. jTable, I am noob and I am used to drag it from swing controls and drop it there on my panel. But smarter way is to create jPanel in the code, isn't it?
I can see one reason and it is that later in the GUI class I have easier access to it.
So the question is why is there both possibilities and which one is the right one and which one is more professional?
EDIT: I am not asking on your personal opinion I am asking what is better and for what reason. I want to know facts not opinions.
This is entirely subjective, but many people stay away from gui builders for several reasons:
They hide implementation details from you, which is bad for novices.
The code they generate is not really meant to be fiddled with by humans, so going in and changing your code is much more difficult.
Using a gui builder adds a dependency on that gui builder, which is generally a bad thing. What if that gui builder stops being maintained?
Again though, this is entirely subjective, and whether you use a gui builder or code it yourself is up to you and your context. This isn't really a question for SO.