I started trying to learn tdd and wanted to use it on a real project. So I decided on programming a simple file synchronization with a client and a server in java.
After more or less finishing the client part, I got stuck while writing the server part.
In order to unit test the logic without accessing external resources, I put those in separate classes, so that I could mock them. So far, so good.
Now here's my question:
This image shows how I imagined everything could look like, where green parts are finished and the yellow parts are not yet implemented.
In my case I'd have to pass RemoteServer a ConnectionManager. The ConnectionManager would a need a FileAdapter and a Communicator in order to create a ClientConnectionHandler. That sounds like a little bit too much passing for me. Is this normal for tdd'ing or am I doing something wrong in order to keep everything testable?
edit: The class ClientConnectionHandler is only responsible for the file sync logic on the server side, which means: Following my own mini protocol to receive files from a client.
It's pretty normal. If you get one class that has many dependencies, it likely has too many responsibilities as well. But having one class that depends on another class that depends on another - that's normal.
This is why IoC Container libraries like Spring are popular. They make it easier to wire up (configure and resolve) all of the dependencies.
Related
In the project allocated to me I have to understand a big Java project which uses Spring framework and angularjs for the frontend and I don't know where to start with. There is a lot of code running on the server (Jetty) and lots of logs generated. The back-end code is more of an interest for me than the UI side.
My question is where do I start? The Java code that we use for practice in college/academics very simple and had a 'main' method to start with.
In the big project I don't see a main method. How do I find out the 'starting point' of the project and then explore it further?
This question is somewhat similar but not exactly to Understanding a big company project in Java
One possible way to start exploring is find an important entry point to the application and then analysis layer to layer from code to code.
My following explanation is based on the information you have give in the comments of your questions. (application is based on angularjs and spring). It would be a good idea to adjust your question, so that these important informations are a part of the question (comments are temporary and could be removed without notice)
Start the application and find one of it's main functionality (or the functionality you want to extend on the next task).
Open the developer tools of your favourite browser and record all requests and responses. Trigger the action you want to discover. Analysis the records and find the corresponding REST call. Look at the request and response param and think about what this API should do.
Then you search for the corresponding REST-Controller inside the backend code. In most situation you can find it, if you search for some of the latter values of the REST-Call-URL path (which is bind to the controller or a controller method).
Now you have your entry point for that action and you can discover further on more or less similar as you would do it on a main method.
You can repeat this steps to get a understanding of the implementation of some features (one by one). Nevertheless there could be some important part of the application you will not find with this approach. But it would give you a starting point to explore the functions which are exposed by the web-interface to the user.
Depending on the architecture it might be that you find a place with some central core functionality. Then it would be a good idea to explore these core functions independently of the api to the frontend. If the application f.e. would take advance of a domain driven design approach you would find a layer where a functional (not technical) domain is designed. Then you will find the bigger picture here.
If you have anyone who know how the application is designed you should of course start you discovery by interviewing this person. If every one who has knowledge is not reachable, you have to look at some documentation or you have to discover the application on your own like I try to describe.
I have a web service that return an xml file. Now I want to create a new web service that uses a part of information that contains the output of first web service. My question is what is better solution:
1.call first web service and use result in new web service?
recreate a part of code of first web service and create an new web service which is independent from first.
I know with first solution I can handle better the code but maybe it will be slower and use more traffic in network.
Οn the other hand,the second proposal solution don't reuse code and it will be more difficult to conserve the project. I would like an complete answer using arguments.
Thank you
Each has its own pros and cons. I'm trying to describe them below:
Using the service has the advantage of not engineering (Dev and Qa) the same functionality twice. You can call a remote service, and just use the functionality it provides. That's why services exist, isn't it? Also, when the service gets evolved, you do not have to worry about anything, like changing your local jar, etc. However, the service runs as a separate component. It thus needs to be monitored and operationally managed.
Using a jar/library in place of a service has the advantage of "locality". The code being executed within the process is much high performing. You can avoid creating a socket connection, and dealing with complexities of calling another service. However, you might have to abstract out the function as a library.
It altogether depends on "what" functionality you are looking at, how complex is it to implement, will the functionality frequently evolve, and would it be useful for other set of clients? If it's complex, evolving, and useful to a multitude of clients, the answer is "write a service".
Experts advice to avoid the 'remote' solutions for as long as possible, as they brings complexity in testing, debugging, maintaining, etc. Just imagine, how would you handle situation when the first WS is going down? How would you test all this? How would you handle situation when the first WS reponds with some invalid data? Lots of questions arises here.
It is really hard to give you the 'right' answer, because it always depends on context and your needs. Sometimes there is just no choice, but implementing the distributed solution.
For inspiration, I would strongly recommend reading the "Enterprise Architecture Patterns" book of M. Fowler.
Diplomatic Question. Its depends on organization to organization , strategy, architecture and design you have followed.
My Suggestion is :
Go with Option 1:
That is divide and rule, if it is service oriented architecture with many consumers for your service
Go with Option 2:
If you are the consumer and provider for this service.
We are working on large scale project which is having hundreds of method.
We are using Spring MVC, hibernate and DWR architecture for our Project.
Currently we are adding all methods of all functionality in Few Service Class. This Service Class are divided according to Modules (Front, Admin, Billing etc).
NOW project size is huge and so the methods in Services class are increasing. This service class contains hundreds of methods of all functionality.
MANAGING as well as UNDERSTANDING this is getting problem.
want to know that is this a proper way every one in industry do or we are going wrong.
ELSE HOW WE CAN IMPROVE THIS.
I've noticed a few patterns in file structure between different languages and programmers. In Java, they like to make many classes, spread out. While in C/C++ they try to keep as many methods in a single file as possible (I've commonly seen 2-5k .cpp files). Either way you go with is fine, just make sure that you keep your code as clean and as documented as possible. It's nice to have a multi-line comment before each method explaining the parameters, algorithm and return.
I need advice on how to rewrite a java GUI. Ultimate goal is easier to maintain & enhance.
What I have built is a Java Applet Client interface that acts and behave similar to Eclipse. developer can design their data entry forms without using a single line of code (drag and drop), and define its attribute. This part is pretty well iron out. however, i am left with more than 40,000 lines of codes that is very difficult to maintain.
Each time a bug is occur or a new enhancement, i normally cant program in a more direct way. more than half the time, i need to workaround the problem and that adds up the lines of code.
Consideration:
-Java Web Applet (because it runs on any browser with J2RE installed)
-runs on slow machine
-deployment of around 200 nodes and growing
Problems that i currently have:
-Listeners are all over the place. sometimes is inside the element.AddListener(new listener..). Sometimes is outside of the class, could be in another package that contain all the rest of listener.
Question: is it always good idea to put all listener in another package? if that is that case, i cant use "this." to get the reference i need.
-JTable this is a killer to me :( the problem i had on Cannot access the Jtable column data after set invisible still persist. Imagine i have JTable with 3 column. First column is a dropDown, second and third column is a textfield. Whenever a value choose from dropdown, i need to base on the selected value, and update to the second column and third column. the problem is, if the user click and it click on other row very fast, it will update to a column that is in the wrong row.
-Currently the program is coded in the sense of it is single thread. whenever the user does a http connection to the server side, reading a file, writing a file and etc, i need to make it as asynchronous process so it doenst feel like "program hang". what is the best way to do this?
Really appreciate help here! Thanks!
Lots of questions here and I'm not sure where to start but I can sympathize with you one this one. Unless you have a well seasoned team that has already gone through the pains of Swing application development things can quickly become out of control and unmanageable.
Before you adventure into re-writing a project I would start with defining some simple standards for development. Like package structures and listeners. I would also recommend splitting the application up into well unit tested modules or sub projects.
Also, ask yourself if you really need to re-write the application or does it just need some TLC. As a consultant and Director of IT I see developers always wanting to re-write applications just because they've learned something new or don't think it's up to par. When they come to me and tell me that it's junk and needs to be re-written I usually send them back and ask them to come up with alternative solutions to a re-write and the impact of each solution including - doing nothing. In a lot of cases we didn't write the application at all.
[UPDATE]
Lastly, If you are going to re-write I would use a Domain Driven Design and MVC approach. Yes, I said MVC for desktop applications!. We've had great success with these methodologies. It keeps a good separation of concern and makes things easily re-usable. It also provides the structure to easily switch out the presentation layer. Most importantly it's easy to unit test and any developer that understands MVC can understand the basics of your project without knowing the details.
I have some more thoughts but i'll leave it at that for now. ;)
use dsl for gui:
swinghtmltemplate
swixml
yaml
there are some more of them
this will remove the need to describe listeners, allow binding in dsl manner
Why dont you just reuse the eclipse framework to build your own gui instead of writing it from scratch in Swing ?
I'm going to write my first Java based web app, and I'm sort of lost how to begin.
Firstly, I would like a web app and a desktop app that do pretty much the same thing, without the hackish idea of embedding a web browser into the desktop app because that doesn't allow to easily make changes to the desktop without affecting the web app and vice versa.
Now, here my questions.
Right now, I have a bunch of POJOs and they communicate with a single class that, right now, uses a flat file as a "database", of course, in production, I would use a legitimate database and just change that single class. Is this a good idea? Will I be able to go from POJOs to a web app?
Should I use a framework? I would like to have this app written pretty soon, seeing that all the buisness logic is there, I just need to wrap it so its usable, so, I don't want to spend an extreme amount of time learning, say, Spring (which AFAIK is huge), but, I don't want to keep reinventing the wheel throughout my app either. I can always just use JSP and scriptlets...
If you said yes to the above, what framework(s) do you suggest? Please note that I would like a framework that I can start using in maybe 3-4 weeks of learning.
Will I have to start from scratch with the POJOs that I have written? They're well over 30k LOC, so, if it is like that, I'll be hesitant.
You will need:
a web framework. Since you have Swing background, JSF 2 will be your best bet (everything will be painful, of course, but JSF will get you up and going quickly and will help you avoid the most tragic mistakes). Also, wrapping business pojos into web guis is the main use-case for JSF and it's biggest focus.
a "glue framework". One thing that is much different with web applications as opposed to desktop ones is that you cannot create view components by yourself - they must be created when browser requests a page. So you have to find a way to create the view objects and deliver all the references to the pojos that represent logic, some of which may have very different lifecycles (this is not a problem on desktop, but on web you have to distinguish between pojos that live along with the whole application, along with a single user session, along with a single request, and so on).
The "glue framework" could also provide the additional benefit of managing transactions. You have three choices:
Spring. It's not half as complex as you thing; you only need to learn some basic stuff.
EJB. You would need a real application server, like Glassfish or JBoss
bare JSF has good support for dependency injection, the only drawback is the lack of automatic transaction management.
If I were in your position, I would go with bare JSF 2.0 - this way you only need to learn one new technology. At first, try to avoid libraries like PrimeFaces - they usually work worse than advertised.
edit - and addendum
or - what is "dependency injection"(abridged and simplified)
When request comes to a web application, a new task starts in a new thread (well, the thread is probably recycled, but that's not important).
The application has already been running for some time and most of the objects you are going to need are already built and should not get created again: you have your database connection pool, maybe some parts of business layer; it is also possible that the request is just one of many request made during one session, and you already have a bunch of POJOs that the user is working on. The question is - how to get references to those objects?
You could arrange your application so that resources are available through some static fields. They may be singletons themselves, or they could be acquired through a singleton locator. This tends to work, but is out of fashion (hard to test, hard to refactor, hard to reuse, lifecycles are hard coded in application). The real code could look like this:
public void doSomething() {
Customer Service cs = AppManager.getInstance().getCustomerService();
System.out.println(cs.getVersion());
}
if you need clustering and session management, you could build a special kind of broker that would know and provide to anyone all kinds of needed objects. Each type of object would be registered as a factory under a different name. This also works and is implemented in Java as JNDI. The actual client code would look like this:
public void doSomething() throws Exception {
CustomerService cs = (CustomerService)new InitialContext().lookup("some_fancy_looking_name_in_reality_just_string");
System.out.println(cs.getVersion());
}
The last way is the nicest. Since your initial object is not created by you but by the server just after http request arrives (details depend on the technology you choose, but your entry point might be a JSF managed bean or some kind of action controller), you can just advertise which references you need and let the server take care of finding them for you. This is called "Dependency Injection". Your acts as if everything is taken care of before your code is ever launched. Spring or EJB container, or CDI, or JSF take care of the rest. The code would look like this (just an example):
#EJB
CustomerService cs;
public void doSomething() {
System.out.println(cs.getVersion());
}
Note:
when you use DI, it really uses one of the two former methods under the hood. The good thing is: you do not have to know which one and in some cases you can even switch them without altering your code;
the exact means of registering components for injection differs from framework to framework. It might be a piece of Java code (like in Guice), an XML file (classic Spring) or an annotation (classic EJB 3). Most of the mentioned technologies support different kinds of configuration.
You should definitely use a framework as otherwise sooner or later you'll end up writing your own.
If you use maven then simply typing mvn archetype:generate will give you a huge list of frameworks to choose from and it'll set up all of the scaffolding for you so you can just play with a few frameworks until you find the one that works for you.
Spring has good documentation and is surprisingly easy to get started with. Don't be put off by the pages of documentation! You could use JPA to store stuff in the database. You should (in theory) just be able to annotate your existing POJO's to denote primary keys and so on and it should just work. You can also use JSP's within Spring if that makes life easier.
... I a bunch of POJOs and they communicate with a single class that, right now, uses a flat file as a "database", of course, in production, I would use a legitimate database and just change that single class. Is this a good idea? Will I be able to go from POJOs to a web app?
qualified yes. if the pojo's are sane you should not have many problems. many people use hiberbate.
Should I use a framework? I would like to have this app written pretty soon, seeing that all the buisness logic is there, I just need to wrap it so its usable, so, I don't want to spend an extreme amount of time learning, say, Spring (which AFAIK is huge), but, I don't want to keep reinventing the wheel throughout my app either. I can always just use JSP and scriptlets...
probably. spring is huge, but things like grails or roo can help.
if you want to have a responsive web app, you will need to do some kind of rich client (AJAX). this may require a lot of your code to run on the client. this means writing a lot of javascript or using gwt. this will be a pain. it probably will not be so easy to just "wrap it". if you have written a swing app, then basically that code will need to run on the client.
If you said yes to the above, what framework(s) do you suggest? Please note that I would like a framework that I can start using in maybe 3-4 weeks of learning.
i like groovy and grails - grails uses spring-mvc, spring, hibernate. but there is roo, play and others.
Will I have to start from scratch with the POJOs that I have written? They're well over 30k LOC, so, if it is like that, I'll be hesitant.
the code that will run on the server can probably be mostly left alone. the code that has to run on the client needs to be rewritten in javascript or maybe you can get some reuse out of that code by using gwt,
The Play Framework is doing great things. I would recommend it highly. Having worked with EJB apps and Tomcat/Servlet/Spring apps it's a breath of fresh air. After framework installation you get a working app in a few seconds. Reminds me of Ruby on Rails or Node.js with the type-safety of Java.
Much quicker turnaround on getting started, faster development cycles, and a clearer configuration model than previous Java web app frameworks.
http://www.playframework.com/