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
This question is more about design than a technical problem.
I'm developing a backend application using java and Spring Rest Services.
It is a small application so in the beginning I just created a controller for all the end points (5 or 6 end points). I have for example an endpoint to request a token i.e /token, and another to make a request, based on the token received previously i.e /readresource.
So now I'm wondering if I should split the controller into two or more controllers, each one with the end points that are related to each other.
Of course in terms of legibility of the code this is useful, but also, from a technical point of view, if the default scope of a spring bean is SINGLETON, if I have only one controller, that would make only a single instance for the whole application, so let's imagine we have two requests that arrive to the server at the same time, even if each request is running a completely separate thread, and they are requesting different end points, in the end they are accessing the same instance so, one request should wait for the other to finish, we cannot execute on the same instance two different threads at the same time, am I right?
So... in terms of performance or good practices, is it better to avoid big controllers with many end points to have instead many small controllers?
What do you think about it?
Thank you!
we cannot execute on the same instance two different threads at the same time, am I right?
Wrong. This is only the case if the method that is being called has the synchronized access modifier. Otherwise, concurrent calls can occur on the same instance in different threads.
Having multiple controllers has no obvious impact on the performance of the application. It means an extra bean is loaded into memory, which equates to a few extra KB of RAM taken up.
This cost is far outweighed by having code that can be read and understood easily. Remember, you shouldn't write code for yourself. You should write it for the next guy, or as a man much smarter than myself once said..
Write your code as if the next person to read it is an angry psychopath, and he knows where you live.
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 4 years ago.
Improve this question
I'm currently developing a restful service using spring MVC.
I have read that logging is a cross cut concerning so I was wondering if it is bad practice to have log statements like log.info("A variable value") inside service facade methods.
Should we remove those log statements and put them inside an interceptor kind of object whose single responsibility is logging?
Is a method full of log.debug messages whose responsibility is to help tracing the method execution bad practice? If it is, how can we move this responsibility to a interceptor if the interceptor only have access to the method parameters
If I need a more informative tracing execution how can I achieve that?
If you do not understand what a method is doing there is a major problem, you have lost control of the software.
There are times when it is needed but should be removed as soon as possible. Among other things log statements make understanding the code more difficult by adding non-logic "noise".
Methods should be small enough that they are easily completely understood with only a small effort, with only a few exceptions. See "Uncle" Bob Martin.
I was brought in on one project because the performance way unusable slow. I solved that problem in a day, it was the logging, I removed it and the performance increased by a factor of > 25x.
It's not necessarily bad practice, but you should try and avoid the mistake twitter made where it's logging messages had user passwords in plain text before encryption
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 5 years ago.
Improve this question
Today I had an interview for test automation in one of the MNC.
They asked me "why do we need to create an object?"
I explained about OOPs concepts with example of individual bank account holders. But he is not convinced. He just need a definition.
What could be a suitable answer for that question?
You require an object to represent state.
At the most simple definition, a class defines behaviour and an instance of a class (an object) represents state.
Of course there are other things like static contexts which can also maintain state, which you can mention also, but above is the clearest answer which I believe they were looking for.
It also always helps to give an example. You could talk about, for example, an Employee class. You would need an object to represent John and another to represent Jane.
I think that this question is kind of generic and does not give much value to an interview. But some generic question should have a generic answer, and here is mine:
We need to create objects in java so we can get instances that have a state inside our application. This allows us to have persistent encapsulated elements that contain any required information, and methods that operate with it.
Just plain basic OOP theory.
There are many reasons why we create a object apart from basic oops
1) To bring up persistent state data to transactional state to perform action (curd and other) and persist back to data storage.(EJB, POJO,etc )
2) Creating handler to serve service and send fluid data across wire like web-service.
3)Stuctural behavior in action.for example you designed a class for a workflow and to make in action state we create a object and serve the behavior example validation , authorization , etc class
All in all to make design time architecture to response based live 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 8 years ago.
Improve this question
Recently I am working on an applications (in Java and C#, but I think the problem is not closed to those languages) where I use a few container classes (which responsibilities are storing data in a proper order) and services being method packages, operating on data stored in container classes. All of the classes mentioned above should have only one copy existing in memory, and all of them are expected to be in the memory for the whole time the application is running.
I used to think that a singleton is a good idea here, as I am sure there is only one instance of each class, so it meets my expectations. However, I learned that the Singleton pattern is deprecated, as it hides dependencies and so on. Then I heard that for such usage (always available container class or method package) static classes may be a good idea. On the other hand I recently looked at a few projects where people refused to use any static stuff, as if it was an awful practice to do so.
My question is simple (at least in its formula): are static classes a good idea for creating always available, easy to hanlde containers and method packages? If not, what should I use instead (if not singletons)?
You don't really say where the data comes from. If the data is static, then a static class is a fine solution. For example, I could envision a static class to represent the 50 US states.
In contrast, for a class that represents a list of authorized users, I would use a singleton pattern. Although there is only 1 list, that list could change while the app is running.
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
What is a good design pattern to document or log every operation (business logic) that is done inside the system?
Let's say I want to write a small log or notify the user about every operation? For instance, in the system you may order a cleaning service for your house and I want to give the user feedback after each step:
Cleaning service ordered > cleaning is being done > cleaning is finished
I was thinking about Observer pattern but I'm a bit confused. Thanks.
If you wish to log every time /something/ happens then it's what's called a cross cutting concern. By this I mean something that happens /outside normal operation/ - it happens everywhere. Look at Aspecxt orientated programming (AOP) - logging is a classic AOP problem. http://en.wikipedia.org/wiki/Aspect-oriented_programming for more info.
What you want desire is know as a cross-cutting concern. Take a look at Aspect Oriented programming. You can write code that is executed on method calls, where you select the method call based on semantic java signatures.
This will decouple your logging concern from your business logic concerns. You should find some immediate examples in the AspectJ documentation.
http://eclipse.org/aspectj/doc/released/progguide/starting-development.html#profiling-and-logging
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
I've been hunting for tips on good Java coding practices, by looking at the code of accomplished programs. My first target was Minecraft, since I'd tried my hand at modding it, and I started to question my choice. Here was code from an accomplished game, and it was giving me two very different ways to go about things.
For those who don't know, Minecraft instantiates its items once and subsequently references that single instance and its methods for any operations it needs to carry out, using information from other sources for the method parameters. Its entities, on the other hand, are instantiated once for every individual entity in the world and are responsible for their own information.
So, the crux of the issue is: Which method is more efficient? Is there a particular reason to favor one over the other? Is it situational? Is it more efficient to do it one way or the other?
The answer is, in most cases, it depends.
What you describe is the singleton pattern, which there's one and only one instance of an object. This is beneficial if having more than one instance is either expensive (such as multiple instances of a DAO), or doesn't make much sense (such as multiple instances of a DAO).
Individual instances of objects is necessary if you hold two separate, distinct instances of the same class - for instance, say you're holding two diamond pickaxes. I wouldn't imagine that a singleton would make sense in that context, since you can interact with each pickaxe individually.
Use the pattern most suited for the situation. There is (and won't ever be) any one-size-fits-all way of solving problems like this.