I have a very large java application with interdepent classes, it is being decided to convert our big application into modules. To start with this task, I would like to gather ideas.
My questions is almost same as asked here : How to modularize a (large) Java App?
Re-asking this question mainly because it was answered 5 years ago. Any new ideas are welcomed.
This isn't the full answer to this question, I believe the link in the question is still valid.
This answer is meant as some process suggestions.
One way to start is to create facades. Initially on paper decide where the boundaries of your modules lie. (which classes are part of a group of classes that make up a module) Then create a facade class (depending on the framework you use, implementing singleton or using spring for ioc) Then whenever you access a class from outside your module, have the outside class call the facade, and have the facade call the actual class.
If you have an external class do several calls on module classes then either this class belongs inside that module, or you need to extract the macro behaviour (series of calls and interactions) into 1 method and move that method into the facade.
Related
I have a modular program I am writing that aims to have modules that are fully functional as standalone units in conjunction with the core program.
This entails the program not breaking at all when a new module is "plugged in" or removed, and requiring no change to any other code for the program to compile and execute with or without some module.
My question is, should I have public getters and setters for all variables in all modules, and make all methods public, so that if a developer needs to access or change a variable (for example) in some module while developing their own module, they can do so without having to change the access modifiers, or should I reconsider my design?
Thank you in advance!
I will try to answer based on my understanding of your question as long as I need to help you. if you still need to ask anything, please leave a comment otherwise don't forget to rate my answer.
Access modifiers (public, private, etc) were built to achieve abstraction and encapsulations within your classes, both of them are key concepts of object oriented programming. so you have to analyze your requirements what you should reveal or disclose to the outside world especially if you want to ship your code and be used in different systems and you don't need other developers to change some properties which are used internally only for example something like database connection string.
Modular where you define your public functionalities through interfaces and implement those interfaces.
Also, one principle it came to my mind where you should favor composition over inheritance to to avoid lots of code changes and breaks and dependencies.
Dependency Injection frameworks helps you to inject your modules, for example Spring framework came with dependency injection.
All of these principles will achieve Open-close and Liscov substitution principles that target to make it easy and open to scale and extend your code easily and still keep your system close for modification.
Now it should come to design patterns where you should architect your components together, still it is based in your requirements where you can use Factory Method for example in case you have one factory building multiple types of objects. Strategy where you need to change the behavior at runtime based on user activaties, ..etc.
the answer even should be more longer than this however I tried to gave a glimpse where you should search and continue from here.
I'm developing a small web app with Spring and java. And came up with a question about package names.
I have a layer separation app, having:
-the "web" layer with my controllers
-the "domain" layer with my model
-the "connector" layer, in charge of doing http communication with external web services
-the "service" layer, with contains my bussiness and app logic.
I have transformers, comparators used for sorting and other classes, all are used inside my service layer, because are part of the bussiness logic. My question is, should the transformers be inside the service package, something like "service.transformer", and same with "servcice.sorting", or should they be a completely separated package, outside the "service" package?
I'd like to hear your opinions
There are a couple of considerations to be made when packaging your classes. First, where are the classes used? And, second, how should they be packaged? Regarding the first, you say that your transformers, comparators and associated miscellaneous classes are only used by your service classes. If so, then it makes sense to put them inside your service package.
Regarding the second question, you should think about whether they would ever need to be used elsewhere in this project or another. If so, then you might want to package them at a higher independent level. That makes it easier to package them up into their own library for use elsewhere.
If your using a modern IDE, I wouldn't think too hard about it since it is trivial to refactor your code later as needs change. For example, in Eclipse adding and optimizing import statements, or moving classes from one package to another is a few keystrokes.
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 am creating a RESTful web service and I need to map the methods that I want to expose as paths. I got one question regarding the organization of service classes.
Is it normal to create one service class that is the endpoint of the application which internally delegates to other service classes?
And how do you organize methods and paths belonging to a resource? Do you create one MyClassCrudService class, one MyClassOperationsService class etc? And then add that path mapping annotations on each class, or do you create one MyClassResourceService class?
I find it hard to divide the service methods in different classes, and naming them properly.
I could need some guidance on how it is normal to organize the services.
I would recommend starting with one Resource class per logical resource and only adding complexity when necessary. Definining necessary really just takes experience and developing a personal taste or team standard.
If you're new to REST, I would also recommend Bill Burke's RESTful Java with JAX-RS.
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
Recently I came across this javalobby post http://java.dzone.com/articles/how-changing-java-package on packaging java code by feature.
I like the idea, but i have few questions on this approach. I asked my question but didn't get a satisfactory reply. I hope someone on StackOverflow can clarify my questions.
I like the idea of package by feature which greately reduces the time for moving across the packages while coding and all the related stuff will be at one place(package). But what about interactions between the services in different packages?
Suppose we are building a blog app and we are putting all user related operations(controllers/services/repositories) in com.mycompany.myblog.users package. And all blog post related operations(controllers/services/repositories) in com.mycompany.myblog.posts package.
Now I want to show User Profile along with all the posts that he posted. Should I call myblog.posts.PostsService.getPostsByUser(userId) from myblog.users.UserController.showUserProfile()?
What about coupling between packages?
Also wherever I read about package by feature, everyone says its a good practice. Then why many book authors and even frameworks encourage to group by layers? Just curious to know :-)
Take a look at uncle Bob's Package Design Principles. He explains reasons and motivations behind those principles, which I have elaborated on below:
Classes that get reused together should be packaged together so that the package can be treated as a sort of complete product available for you. And those which are reused together should be separated away from the ones those are not reused with. For example, your Logging utility classes are not necessarily used together with your file io classes. So package all logging them separately. But logging classes could be related to one another. So create a sort of complete product for logging, say, for the want of better name commons-logging package it in a (re)usable jar and another separate complete product for io utilities, again for the want of better name, say commons-io.jar.
If you update say commons-io library to say support java nio, then you may not necessarily want to make any changes to the logging library. So separating them is better.
Now, let's say you wanted your logging utility classes to support structured logging for say some sort of log analysis by tools like splunk. Some clients of your logging utility may want to update to your newer version; some others may not. So when you release a new version, package all classes which are needed and reused together for migration. So some clients of your utility classes can safely delete your old commons-logging jar and move to commons-logging-new jar. Some other clients are still ok with older jar. However no clients are needed to have both these jars (new and old) just because you forced them to use some classes for older packaged jar.
Avoid cyclic dependencies. a depend on b; b on c; c on d; but d depends on a. The scenario is obviously deterring as it will be very difficult to define layers or modules, etc and you cannot vary them independly relative to each other.
Also, you could package your classes such that if a layer or module changes, other module or layers do not have to change necessarily. So, for example, if you decide to go from old MVC framework to a rest APIs upgrade, then only view and controller may need changes; your model does not.
I personally like the "package by feature" approach, although you do need to apply quite a lot of judgement on where to draw the package boundaries. It's certainly a feasible and sensible approach in many circumstances.
You should probably achieve coupling between packages and modules using public interfaces - this keeps the coupling clean and manageable.
It's perfectly fine for the "blog posts" package to call into the "users" package as long as it uses well designed public interfaces to do so.
One big piece of advice though if you go down this approach: be very thoughtful about your dependencies and in particular avoid circular dependencies between packages. A good design should looks like a dependency tree - with the higher level areas of functionality depending on a set of common services which depend upon libraries of utility functions etc. To some extent, this will start to look like architectural "layers" with front-end packages calling into back-end services.
There many other aspect other than coupling for package design i would suggest to look at OOAD Priciples, especially package design priciples like
REP The Release Reuse Equivalency Principle The granule of reuse is the granule of release.
CCP The Common Closure Principle Classes that change together are packaged together.
CRP The Common Reuse Principle Classes that are used together are packaged together.
ADP The Acyclic Dependencies Principle The dependency graph of packages must have no cycles.
SDP The Stable Dependencies Principle Depend in the direction of stability.
SAP The Stable Abstractions Principle Abstractness increases with stability.
for more information you can read book "Agile Software Development, Principles, Patterns, and Practices"