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
Soon I will have to implement a public API (web API). One of the requests will be that we will need to provide different methods to do the same (for example, REST and SOAP), my initial approach is as this.
Make a Controller for the REST
Make a Controller for the SOAP
Use a common Facade class that will handle requests from the REST and the SOAP interface, the Facade class will be in charge of accessing the internals of the system (directly or indirectly, dome DAOs could be used...etc).
Code will be written in Java, most likely will use Spring-MVC among other techs.
Question here is. Does this make sense to you? Is it too absurd? Do you feel any over-architecture here? Any suggestions/experiences/best practices?
Thanks for your time :)
Your approach makes sense to me. Spring MVC on its own can handle the REST endpoints, accepting and returning XML and/or JSON. For SOAP, you will need an additional framework like Spring-WS or Apache CXF.
When using the MVC pattern, it is always best to keep your Controllers as small as possible, by delegating any real work to other beans injected into the controller. These other beans often follow the Service or Repository sterotypes (using Domain Driven Design terminology). These Service and Repository beans can be re-used across REST and SOAP endpoints. I think this is what you mean in your third paragraph, if that is the case then you are on the right track.
Does this make sense to you?
Yes.
Is it too absurd?
No.
Do you feel any over-architecture here?
No.
Any suggestions/experiences/best practizes?
You can find design patterns describing what you are doing. For instance, the GoF adapter pattern says: "In computer programming, the adapter pattern (often referred to as the wrapper pattern or simply a wrapper) is a design pattern that translates one interface for a class into a compatible interface." You have the App Controller (adaptee) that it is specialized (adaptor) in two interfaces: REST and SOAP.
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 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 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 6 years ago.
Improve this question
I have experience web programing using express js framework
and this is my first time to learn playframework in java
how to make middleware in play framework
as ussualy i use express js just add middleware in front of controller in routes
example like this
router.get('/all/:key' , user_mid.login, ctrl_post.all)
user_mid.login = is my middleware
ctrl_post.all = is my controller method to handle the request
so how to make middleware in play framework
Play does not have a concept called middleware.
In Play Java, Results are returned by classes extending the Action (or Controller) abstract class. Why am I telling you this? Well, because you can compose actions. One action can forward a request to the next action, then to the next, and the other way around with the response. Play has good support for this concept: Action composition .
This goes in three steps:
Define an action by extending (usually) play.mvc.Action.Simple .
Annotate the method in your controller with #With, and your newly crated class. That way you composed two actions. They are called in the order in which the #With annotations appear, if you have multiple.
(Optionally) Define your own annotation for an action.
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
My question is how mocks objects are created not how to create a mock object using a library.
I have looked at the Mockito library source code but I didn't understand how its done. I have searched in the Internet but the articles explain what are mock object and how to create them using libraries.
For dynamic programming language perhaps it's simple as we can change methods, variable but how its done in static programming language (Java for example)
Let's begin with what a mock is: an object that you can set expectancies on it regarding methods that expects to be called, and/or parameters on those methods and/or count of calls on those methods.
Mocks are sent to tested objects in order to mimic certain dependencies without having to use the real code (in many cases this is problematic/dangerous, like dealing with payment gateways).
Since mocks will need to intercept calls to all (or some, in case of partial mocks) methods, there are several ways they can be implemented, depending mainly on the features the language provides. Particularly in Java this can be implemented via proxy classes: https://stackoverflow.com/a/1082869/1974224, an approach that kinda forces you (but in a good way) to use interfaces in your code when relying on dependencies.
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 is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
If you are familiar with the Java RDF and OWL engine Jena, then you have run across their philosophy that everything should be specified as an interface when possible. This means that a Resource, Statement, RDFNode, Property, and even the RDF Model, etc., are, contrary to what you might first think, Interfaces instead of concrete classes.
This leads to the use of Factories quite often. Since you can't instantiate a Property or Model, you must have something else do it for you -- the Factory design pattern.
My question, then, is, what is the reasoning behind using this pattern as opposed to a traditional class hierarchy system given the nature of the content the library aims to serve? It is often perfectly viable to use either one. For example, if I want a memory backed Model instead of a database-backed Model I could just instantiate those classes, I don't need to ask a Factory to give me one.
As an aside, I'm in the process of writing a library for manipulating Pearltrees data, which is exported from their website in the form of an RDF/XML document. As I write this library, I have many options for defining the relationships present in the Peartrees data. What is nice about the Pearltrees data is that it has a very logical class system: A tree is made up of pearls, which can be either Page, Reference, Alias, or Root pearls.
My question comes from trying to figure out if I should adopt the Jena philosophy in my library which uses Jena, or if I should disregard it, pick my own design philosophy, and stick with it.