Tag Info

Hot answers tagged

9

You really have two separate concerns here: wrapping an API and keeping the argument count low. When wrapping an API, the idea is to design the interface as if from scratch, knowing nothing other than the requirements. You say there is nothing wrong with their API, then in the same breath list a number of things wrong with their API: testability, ...


9

The strategy I've used when there are several initialization parameters is to create a type which just contains the parameters for initialization public class DataTypeTwoParameters { public String foo; // use getters/setters instead if it's appropriate public int bar; public double baz; public String quuz; } Then the constructor for ...


7

That cannot be done. Your problems arise from violating ISP. That said, the only idea I can think of is to force client classes to register with your classes in orden to be able to call their methods or they get a NotRegisteredException. Once they register you can check their type and rise a YouAreNotAllowedToCallThisMethodException if the registered class ...


5

Hiding inherited methods is a terrible idea and almost guaranteed to cause you grief. I would say that this is what Interfaces are for; a "disclosure agreement" between two or more classes that accurately describes what each is allowed to know about the other[s]. Of course, this will get just a mite fiddly if its mixed with inheritance as you describe - ...


4

NaN has a very specific meaning as the result of an undefined numerical operation such as division by zero or taking the square root of a negative number (within the realm of real numbers). It's not an appropriate return value from code that parses a floating point number. Code like that should signal an error when it comes across text that can't be ...


4

I use enums this way all the time. Enums are a great way to write immutable helper objects that you only need exactly one copy of; they help reduce the chance of memory leaks and easily group many related classes together in a clear way. What I would not do is expose the control of which particular BusinessLogic you're using to external classes using a ...


4

A simple fix would be to replace the internals of your wrapper to use Threadlocal. So the format() changes from: private DecimalFormat format = new ...; private final Object lock = new Object(); public String format(double value){ synchronized(lock) { return format.format(value); } } to private ThreadLocal<DecimalFormat> format = ...


3

When the compiler enters a "new scope", new variables within that scope are stored for that scope, and when the scope "disappears", those variables disappears. This is, normally, done in the form of some sort of stack/list type, which in turn holds the variable names and their type. So, if we have: int x; void func() { float x, y; int a; } the ...


3

It may be a good idea to encapsulate behavior into a Java enum (or C++ enum class) when you find yourself writing switch statements like the following, especially when the switch is repeated in different parts of the code. MyEnum x = ...; switch (x) { case A: // Do something break; case B: // Do something break; case C: // Do ...


3

Coding to the SLF4J API doesn't force the dependency on users of your library. From the user's guide: As of SLF4J version 1.6.0, if no binding is found on the class path, then slf4j-api will default to a no-operation implementation discarding all log requests. ... Embedded components such as libraries or frameworks should not declare a ...


3

It's usually a good idea to separate the serialization method (JSON) from your business logic so that if in the future you decide to use some other type of serialization, you can do so without affecting the business logic. Jackson is probably the most popular open-source library for JSON serialization/deserialization in Java. In the situation where some ...


3

Yes, too many or too complicated mock objects are a bad thing. Yes, there is a better design, and I have been toying with the idea in my mind for years. Unfortunately, I cannot fully explain it here because the paper that I am writing about it is not complete yet. But, in coarse terms, here is what is happening: You are mixing business logic with GUI ...


2

You cannot do exactly what you want - see the other answers, but there are a couple of things you could do. You could have a package private interface that exposes the setters, and a public interface that exposes the getters. You mention that you want to use the setters in multiple packages in your own code. Why is this? This is a code smell for me - if ...


1

Why can we use the same name for local variable in different scopes? Each method has its own set of local variables. The compiler converts these local variable names, in essence, to per-method unique numbers (stack frame offsets). After compilation the names of local variables are lost (disregarding some of the newer reflection APIs). Local variables ...


1

I often prefer standard and good enough over best. There could be a "less is more" argument for using the included Java Logging: http://docs.oracle.com/javase/6/docs/technotes/guides/logging/overview.html


1

I think you might be interpreting Uncle Bob's recommendation too strictly. For normal classes, with logic and methods and constructors and such, a polyadic constructor does indeed feel a lot like code smell. But for something that is strictly a data container that exposes fields, and is generated by what is essentially a Factory object already, I don't think ...


1

It all comes down to risk management and gut feeling. Try to estimate the following: How big are the costs of the mistake as it is in the code right now. Does it cause recurrent costs? Or costs in form of a risk that it might turn into a bug in the future? What is the cost and the probability of that bug? How big are the costs of fixing it right now: Risk ...


1

Usually Abstract classes are used when one has a class which has some methods which needs to be implemented by one of its child classes, thus, when one sees an abstract class one also expects to see a series of abstract methods which must be implemented. So although you can use abstract classes to denote non instantiable classes, I do not think that if you ...


2

You've got two basic approaches, one is to watch the network traffic, the other is to look at the source. For looking at the source, you would do something like use a java decompiler and see what it gives you. Note, however that this means you are looking at the source (or something close to it) and any works based on it may be considered a derived work ...


1

In addition to the good answer by @Doval, throwing a NumberFormatException is more general: it works for similar methods like Integer.parseInt(). There is no NaN equivalent for ints, shorts, etc. So, throwing a NumberFormatException is both more specific/informative than returning NaN, it is also more generalizable. That's truly a win-win!


1

This lets you easily detect the cases where the input is completely nonsensical. You can parse the string "NaN" and get NaN, so if the user wanted to give you NaN, he could type that. The fact that you received "ABC" means they weren't even trying to enter a double at all.


1

You can use JPA with inheritance. There are several variations ("patterns"): all objects share the same table and there is a "discriminant" column/attribute (this is the closest to the one you explain). It is quick for queries, but you will have a column for each attribute of a subclass (if you have 20.000 instances, and only two instances of a subclass ...



Only top voted, non community-wiki answers of a minimum length are eligible