We Keep Coding

How to refactor a large class with many methods that have single responsibility?

Searching for design patterns and better code optimization mostly pops up articles on inheritance and relationships between classes and tools on how to create class diagrams. I would like a little insight on how to, say split, a big class. Am working on a java program with a class that has crossed 1600 lines of code and about 20 methods. What it does is query for data from a data source and generate huge text file.
Now there are lots of data modification logic(for each logic I have created small methods) that goes on to queried data like:
-check data dates of users and perform changes
-append strings
-logic to check if a record needs to be ignored
and storing filtered data in Collection and generating text file. I don't think creating separate class for each small logic is good idea. Perhaps I can create separate utility class and stuff static methods into it? I can't post code for confidentiality issues. If someone can shed a little light to get me thinking in right direction that would be great. Thanks.

The best thing you can do is forget what the code does, and think about what it is.
From the description you gave, you are "still" thinking about what your code is supposed to do. It queries a data source, checks dates, appends strings, filters, etc. This is not wrong for a functional or procedural approach, but not ideal for object-oriented code.
Try a little bit to forget what it supposed to do, and think about what "things" it is about. Are those things Accounts, Users, Machines, VirtualServers, etc. What is that huge text file? Is it a UsageReport, a BalanceSheet, etc.
Once you got the "things", you can start thinking about what "responsibilities" you need to assign each of them. Again, "querying the database" is not a responsibility. You have to do something with the data you get, for example generating a UsageReport, that is a responsibility.
That is OO in a nutshell. A few more pointers: Try to avoid utilities, try to avoid getters, try to avoid setters even more. Try to avoid Services, Processor, Handler, Renderer and similar classes. Those are not "things", but usually procedures in disguise.

Perhaps you should consider whether your initial premise is correct. The single responsibility principle states that a class should only have one reason to change.
In the case of the class you're describing, there are multiple responsibilities: querying a data source, filtering, string manipulation (presentation?), text file generation.
Each of these should be separated into its own class. This decouples the concerns and provides smaller more manageable code.

SRP (Single Responsibility Principle) suggests that we should have only one reason to change a class. i.e. a class should have only one single responsibility. So one class should do only one thing. So in an ideal object oriented environment, we would have classes for each of our work.
Ex:
Assume you are building a Calculator app with basic math support. Assume you have to implement Summing two numbers feature. In ideal way, you would have to do something like this.
public interface NumberMath{
public float value();
}
public class Sum implements NumberMath{
private float num1;
private float num2;
public Sum(float num1, float num2){
this.num1 = num1;
this.num2 = num2;
}
#Overrride
public float value(){
return num1 + num2;
}
}
I think you already found that it will make our code much verbose. So practically no one will follow object orientation (or SRP) in ideal way. Instead most of us would prefer one class containing methods for sum, subtract, division, multiplication etc. It makes our code less verbose.
But in your case 1600 lines of code with 20 methods for 1 class can't be good.
The best ways you can decompose your huge single class into multiple simple classes
Identify independent methods.
Combine similar small methods(behaviors) into a single class with a proper scope for that class, and a name that would properly define that scope.
Try to completely avoid code duplication by adhering into method reuse instead.
Again it is somewhat difficult to provide a very specific answer for your problem since details are limited. Anyway hope this helps. :)

Passing many variables to a class (swing components) [duplicate]

I have just started to learn Java and is curious is it any good practice in Java for good object decomposition? Let me describe a problem. In big software project it's always a big classes like 'core' or 'ui' that tends to have a lot of methods and are intended as a mediators between smaller classes. For example, if user clicks a button on some window, this window's class sends a message to 'ui' class. This 'ui' class catches this message and acts accordingly by doing something with application user interface ( via calling method of one of it's member objects ) or by posting message to application 'core' if it's something like 'exit application' or 'start network connection'.
Such objects is very hard to break apart since they are a mere mediators between a lots of small application objects. But having a classes in application with hundreds and thousands of methods is not very handy, event if such methods are trivial task delegation from one object to another. C# solves such problem by allowing to break class implementation into multiple source files: you can divide god object any way you choose, and it will work.
Any practices by dividing such objects in Java?

One way to begin breaking such a large object apart is to first find a good subset of fields or properties managed by the large object that are related to each other and that don't interact with other fields or properties of the object. Then, create a new, smaller object using only those fields. That is, move all logic from the large class to the new smaller class. In the original large class, create a delegation method that simply passes the request along. This is a good first step that only involves changing the big object. It doesn't reduce the number of methods, but it can greatly reduce the amount of logic needed in the large class.
After a few rounds of doing this, you can begin to remove some of the delegation by pointing other objects directly at the newer, smaller objects, rather than going through the previously-huge object that was in the middle of everything.
See Wikipedia's Delegation pattern discussion for example.
As a simple example, if you have a personnel object to represent staff at a company, then you could create a payroll object to keep track of payroll-related values, a ratings object to keep track of employee ratings, an awards object to keep track of awards that the person has won, and so on.
To wit, if you started out with one big class containing the following methods, each containing business logic, among many other methods:
...
public boolean isManagement() { ... }
public boolean isExecutive() { ... }
public int getYearsOfService() { ... }
public Date getHireDate() { ... }
public int getDepartment() { ... }
public BigDecimal getBasePay() { ... }
public BigDecimal getStockShares() { ... }
public boolean hasStockSharePlan() { ... }
...
then this big object could, in its constructor, create a newly created object StaffType and a newly created object PayInformation and a newly created object StaffInformation, and initially these methods in the big object would look like:
// Newly added variables, initialized in the constructor (or as appropriate)
private final StaffType staffType;
private final StaffInformation staffInformation;
private final PayInformation payInformation;
...
public boolean isManagement() { return staffType.isManagement(); }
public boolean isExecutive() { return staffType.isExecutive(); }
public int getYearsOfService() { return staffInformation.getYearsOfService(); }
public Date getHireDate() { return staffInformation.getHireDate(); }
public int getDepartment() { return staffInformation.getDepartment(); }
public BigDecimal getBasePay() { return payInformation.getBasePay(); }
public BigDecimal getStockShares() { return payInformation.getStockShares(); }
public boolean hasStockSharePlan() { return payInformation.hasStockSharePlan(); }
...
where the full logic that used to be in the big object has been moved to these three new smaller objects. With this change, you can break the big object into smaller parts without having to touch anything that makes use of the big object. However, as you do this over time, you'll find that some clients of the big object may only need access to one of the divisible components. For these clients, instead of them using the big object and delegating to the specific object, they can make direct use of the small object. But even if this refactoring never occurs, you've improved things by separating the business logic of unrelated items into different classes.

The next logical step may be to change the BigClass into a java package. Next create new objects for each group of related functionality (noting in each class that the object is part of the new package).
The benefits of doing this are dependency reduction and performance.
No need to import the entire
package/BigClass just to get a few
methods.
Code changes to related
functionality don't require a
recompile/redeploy of the entire
package/BigClass.
Less memory used
for allocating/deallocating objects,
since you are using smaller classes.

I've seen some cases where this is solved by inheritance: let's say class Big takes care of 5 different things, and (for various reasons) they all have to be in the same class. So you pick an arbitrary inheritance order, and define:
BigPart1 // all methods dealing with topic #1
BigPart2 extends BigPart1 // all methods dealing with topic #2
...
Big extends BigPart4 // all methods dealing with the last topic.
If you can really layer things up, so that the breakage makes sense (Part2 actually uses stuff from Part1, but not vice versa, etc.) then maybe it makes some sense.
The place where I've seen this is in WebWorks, where a single class had tons of getter/setter methods -- the setters used for dependency injection (e.g., URL args passed to the object upon execution) and the getters for making values accessible to various page templates (I think it was JSPs).
So, the breakdown grouped stuff logically, e.g., assuming the class was called MyAction, there was MyActionBasicArgs (fields and setters for basic CGI arguments), extended by MyActionAdvancedArgs (advanced-option args), extended by MyActionExposedValues (getters), extended by MyActionDependencies (setters used by Spring dependency injection, non-CGI args), extended by MyAction (which contained the actual execute() method).
Because of the way dependency injection in WebWorks works (or at least, used to work, back then), it had to be one huge class, so breaking it down this way made things more maintainable. But first, please, please, see if you can simply avoid having a single huge class; think carefully about your design.

Yes, C# provides partial classes. I assume this is what you are referring to when you say:
C# solves such problem by allowing to break class implementation into multiple source
files: you can divide god object any way you choose, and it will work.
This does help make huge classes more manageable. However, I find partial classes best used when one needs to extend code created by a code generator. When a class is as large as you're talking about, it can almost always be divided into smaller classes by proper object oriented design. Using a partial class sidesteps the more correct object oriented design, which is sometimes OK as the end goal is stable, reliable, maintainable code, and not a textbook example of OO code. However, many times, putting the code of a large object into a large number of smaller partial class instances of the same class is not the ideal solution.
If you can possibly find subsets of the properties of the "god" object that do not interact with one another, then each one of those sets would logically make a good candidate for a new object type. However, if all properties of this "god" object depend on one another, then there is not much you can do to decompose the object.

I don't know why you would ever have such a large class.
I suppose if you were using a gui builder code generation and being lazy about it, you might end up in such a situation, but codegen usually ends up nasty unless you take control yourself.
Splitting a single class arbitrarily is a terrible solution to a terrible manufactured problem. (Code reuse, for one thing will become virtually impossible)
If you have to use a GUI builder, have it build smaller components, then use the small components to build up a bigger GUI. Each component should do exactly one job and do it well.
Try not to EVER edit generated code if you can avoid it. Putting business logic into a genned "frame" is just a horrid design pattern. Most code generators aren't very helpful with this, so try to just make a single, minimal edit to get at what you need from external classes (think MVC where the genned code is your View and the code you edit should be in your Model and Controller).
Sometimes you can just expose the getComponents method from the Frame object, get all the components out by iterating through the containers and then dynamically bind them to data and code (often binding to the name property works well), I've been able to safely use form editors this way, and all the binding code tends to be very easily abstracted and reused.
If you're not talking about generated code--Well in your "God" class, does it do exactly one small job and do it well? If not, pull out a "Job", put it in it's own class, and delegate to it.
Is your GOD class fully factored? When I've seen huge classes like this, I've usually seen a lot of copy/paste/edit lines. If there is enough of a similarity to copy and past and edit some section, then there is enough to factor these lines into a single chunk of code.
If your big class is a GUI class, consider decorators--reusable and moves stuff out of your main class. A double win.
I guess the answer to your question is that in Java we just use good OO to ensure that the problem doesn't arise in the first place (or we don't--Java's certainly not immune to the problems you are talking about any more than any other language)

Starting a new project, how to structure it? [closed]

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
I have a very simple task in Java, and I am not sure which structure to give to my project.
I want to create a little project in Java, that makes some statistical calculations. For example, I will need to create a method that gets an array, and returns the mean, another method gets an array, and returns a standard deviation, I will also need a method that gets two arrays, and returns the correlation coefficient.
What I want to know, is how to do this now that I have opened a new project in Eclipse ?
Should it all be in one class ? Should I have a separate class for each method, making it a static method ? At the end, I want to give this code for someone else to integrate it in his project. I need to do it as simple and efficient as possible.
Can you please guide me on how to do it ? One class, several classes ? Public / private ? I am not familiar with these things, but I can program the methods themselves.
Thank you in advance

All your methods have the following attributes:
That they don't possibly have another implementation as long as your give them specific enough names. After all mathematical doesn't change. This means you don't possibly need structure like interfaces or subclasses.
That when people use them they have tendency to use several of them or group by functionality. That means you should group your methods by usage e.g. statistical methods; signal processing methods; and so on.
That the methods don't keep internal status and all the output is returned without any side effect of other callers/threads. Thus your methods don't have to have class contain themselves or any statue variables.
That your methods essentially provider utility to the main program but the semantics of the methods doesn't vary due to the caller or calling context.
So as all the above shows, your methods should be inside 1 or several classes as grouped by their nature or usage. The methods should be static methods without any side effect. That's exactly what java.lang.Math does.

I want to create a little project in Java, that makes some statistical calculations. For example, I will need to create a method that gets an array, and returns the mean, another method gets an array, and returns a standard deviation, I will also need a method that gets two arrays, and returns the correlation coefficient.
Looks to me that you are interested in creating a utility class for statistical calculation. The scope of how to achieve is this quite broad but it is advised to follow common coding conventions and basic OOP concnepts.
Should it all be in one class ? Should I have a separate class for each method, making it a static method ?
Since each of the methods ( mean, standard deviation ...) are related to the same core background (i.e to perform some statistical calculation), it seems logical to have a single utility class with a separate static methods for each of the function that you need to create.
Of-course you will have to take care of the basic OOP concepts like (data hiding) keeping the fields private and exposing them properly public getter/setters. Also, it would be a good idea to keep your calculation methods private and just exposing a public method which calls your private functions. Something like
public class MyUtilityClass{
// A bunch of private fields
int field1; ...
private MyUtilityClass(){} // We don't want anyone to create an object of this class
// method exposed to user
public static float calcArithmeticMean(float[] arr1, float[] arr2){
return getMean(arr1, arr2);
}
// method for internal use
private float getMean(float[] f1, float[] f2){
//do your calculation here
}
// remember to expose only those fields that you want the user be able to access
// getter/setters here
}
At the end, I want to give this code for someone else to integrate it in his project.
If you follow proper OOP coding conventions, then your utility class will be portable and anyone will be able to understand and extend it in their application.

I would create a single class representing the array of numbers itself.
public class DataSet extends HashSet<Double> {
public double mean () {
// implementation
}
public double standardDeviation () {
// implementation
}
public double correlationCoefficient (DataSet other) {
// implementation
}
}

My first suggestion is to start your project using Maven. It gives you a solid project structure with a great tool to manage your jar file dependencies and build lifecycle. In addition, all major Java IDEs, including Eclipse, easily create, understand and use your Maven settings.
Secondly, for your application design, it is recommended to avoid using lots of static methods because they hurt testability of your code as for example explained here.
Regarding the number of classes and methods, it depends on your specific use case but the guideline is to try to aggregate similar methods, based on their responsibilities, in one class while separating classes if there are too many responsibilities being handled by a single class. Low coupling and high cohesion are your friends in this case.
Arrays may be slightly faster than collections but be careful with them because they are reifiable and do not mix well with generics. Generally, rely on Collections. Also, if you can use Java version 8, have a look at Streams API.
Last but not least, Java has tons of open source code out there. So, always look for a library before starting to write one. In case of Math, have a look at this and that.

Create one class with a different methods with public access for each calculation type(one method for each of mean, standard deviation and so on). These methods can internally refer to helper methods in another utility class(es) not publicly accessible, as per your convenience.
Put all these classes in a single package and export it for integrating in other projects.
Since it will be used by others as a library by others , make sure you document and comment it as much as possible.

I vote for single class. The methods should be static and the parameters that you don't want to show should be private.

It depends on many thing such as other part of project, future changes and extensions,...
I suggest to start with single-class/public-static and change it in demand when you expand the project.

$Include #include equivalent in Java

I have a very large and bloated class and I want to split it into separate files, but it should be completely transparent to the user and compatible with existing projects that use the class.
In particular, I have my own ImageMatrix class and it defines a ton of unary functions, a ton of binary functions with a scalar, a ton of binary functions with another image, etc. To keep the class clean and maintainable, I wish to put each class of operators in a separate file.
Is there a way to just cut/paste these methods into a file and include them in the source?
So I wish that I can still do this, but the methods actually reside in different files:
ImageMatrix img = new ImageMatrix(800, 600, 3);
img.clear(0.5f, 0.0f, 0,0f);
img.addSelf(anotherImg);
img.normalize();
img.abs();
img.addSelf(0.5);
Each method is around 15-30 lines of code because the implementations are extremely optimized for performance, the like of which is impossible to achieve with Bufferedimage or even a plain int[]. There is a lot of code duplication, which is the main reason to group similar methods together. If I add a function or if I change global behavior (like error checking), I can easily keep things coherent.

Unfortunately it is not possible to split a Java class definition into multiple files.
Try to restructure your code so that a huge class definition isn't necessary. Often this means exposing some state through getter and setter methods, and writing supporting classes which use these methods to add functionality to your main class.
In your case, you might consider adding supporting classes like ImageFilters, or even something more narrow like ImageNormalizer if you like very small classes.

You can also use delegate methods. This means the definitions of your methods are still in ImageMatrix, but they are implemented in another class. Depending on the complexity of your methods this could reduce the amount of code in ImageMatrix.
class ImageMatrix {
MatrixHelperOne helperOne = new MatrixHelperOne();
...
public void complexMethod1(Arg arg) {
helperOne.complexMethod1(arg);
}
...
}

Well, you could create a more generic class and put more generic methods there and then have ImageMatrix extends that one. Also, if you have a lot of matrix manipulation functions you will probably end up with a lot of code duplication, i.e. repeating the same code in different methods instead of moving the common code into an aux method and calling it from different places, etc.

You can't split a Java class across files. If each of your methods is self-contained, you could create classes with static methods. So to a certain extent, you would only need to cut and paste code.

Where to put potentially re-useable helper functions?

This is language agnostic, but I'm working with Java currently.
I have a class Odp that does stuff. It has two private helper methods, one of which determines the max value in an int[][], and the other returns the occurrences of a character in a String.
These aren't directly related to the task at hand, and seem like they could be reused in future projects. Where is the best place to put this code?
Make it public -- bad, because Odp's functionality is not directly related, and these private methods are an implementation detail that don't need to be in the public interface.
Move them to a different class -- but what would this class be called? MiscFunctionsWithNoOtherHome? There's no unifying theme to them.
Leave it private and copy/paste into other classes if necessary -- BAD
What else could I do?

Here's one solution:
Move the method that determines te max value in a two-dimensional int array to a public class called IntUtils and put the class to a util package.
Put the method that returns the occurrences of a character in a String to a puclic class called StringUtils and put the class to a util package.
There's nothing particularly bad about writing static helper classes in Java. But make sure that you don't reinvent the wheel; the methods that you just described might already be in some OS library, like Jakarta Commons.

Wait until you need it!
Your classes wil be better for it, as you have no idea for now how your exact future needs will be.
When you are ready, in Eclipse "Extract Method".
EDIT: I have found that test driven development give code that is easier to reuse because you think of the API up front.

A lot of people create a Utility class with a lot of such methods declared as static. Some people don't like this approach but I think it strikes a balance between design, code reuse, and practicality.

If it were me, I'd either:
create one or more Helper classes that contained the methods as static publics, naming them as precisely as possible, or
if these methods are all going to be used by classes of basically the same type, I'd create an abstract base class that includes these as protected methods.
Most of the time I end up going with 1, although the helper methods I write are usually a little more specific than the ones you've mentioned, so it's easier to come up with a class name.

I not know what the other languages do but I have the voice of experience in Java on this: Just move to the end-brace of your class and write what you need ( or nested class if you prefer as that is accepted canonical convention in Java )
Move the file scope class ( default access class right there in the file ) to it's own compilation unit ( public class in it's own file ) when the compiler moans about it.
See other's comments about nested classes of same name if differing classes have the same functionality in nested class of same name. What will happen on larger code bases is the two will diverge over time and create maintainability issues that yield to Java's Name of class as type of class typing convention that forces you to resolve the issue somehow.
What else could I do?
Be careful not to yield to beginner impulses on this. Your 1-2 punch nails it, resist temptation.

In my experience, most large projects will have some files for "general" functions, which are usually all sorts of helper functions like this one which don't have any builtin language library.
In your case, I'd create a new folder (new package for Java) called "General", then create a file to group together functions (for Java, this will just be a class with lots of static members).
For example, in your case, I'd have something like: General/ArrayUtils.java, and in that I'd throw your function and any other function you need.
Don't worry that for now this is making a new class (and package) for only one function. Like you said in the question, this will be something you'll use for the next project, and the next. Over time, this "General" package will start to grow all sorts of really great helper classes, like MathUtils, StringUtils, etc. which you can easily copy to every project you work on.

You should avoid helper classes if you can, since it creates redundant dependencies. Instead, if the classes using the helper methods are of the same type (as kbrasee wrote), create an abstract superclass containing the methods.
If you do choose to make a separate class do consider making it package local, or at least the methods, since it may not make sense for smaller projects. If your helper methods are something you will use between projects, then a library-like approach is the nicest to code in, as mentioned by Edan Maor.
You could make a separate project called utils or something, where you add the classes needed, and attach them as a library to the project you are working on. Then you can easily make inter-project library updates/fixes by one modification. You could make a package for these tools, even though they may not be that unified (java.util anyone?).

Option 2 is probably your best bet in Java, despite being unsatisfying. Java is unsatisfying, so no surprise there.
Another option might be to use the C Preprocessor as a part of your build process. You could put some private static functions into file with no class, and then include that file somewhere inside a class you want to use it in. This may have an effect on the size of your class files if you go overboard with it, of course.