I was tasked with converting some Java code to C# and came across the following enumeration (I had to generalize it, because the code is proprietary, sorry). The general purpose of the code is to convert from a "non-base unit" to a "base unit" (like converting from say kilometers to millimeters, or whatever. They have a ton of conversions). The only things I changed were the variable names. The pattern is exactly like this in the code...
public enum ThisIsAnEnum implements someInterface
{
typeKilom( MetricType.kilometer ),
typeMillm( MetricType.millimeter );
public double convertSomething(double dbl1, double dbl2)
{
// do stuff
return a double
}
}
This is then called in the code as follows:
public static void main( String[] args )
{
ThisIsAnEnum.typeKilom.convertSomething(aDouble, bDouble);
}
I have a couple questions:
Is this use of enumerations a good practice in Java?
If yes or if no, what approach should I take in C#? Can you do something similar? Even if I can, I'm not sure that this approach is correct.
I'm not asking for someone to convert this for me... just whether this is a good approach and (if so) should I try to do the same thing in C#. If it's not, then what approach should be taken?
Is this use of enumerations a good practice in Java?
Absolutely. This is exactly the sort of usage that has been envisioned when enumerations where introduced in Java.
what approach should I take in C#?
Since C# enums do not have the same capability, you would need to model it in some other way. One approach would be defining a class or an interface with the methods from your Java enum, and make a bunch of public readonly instances mimicking the enum entries:
public ISomeInterface {
Func<double,double,double> ConvertSomething {get;}
}
public class ThisIsAnEnum : ISomeInterface {
public Func<double,double,double> ConvertSomething {get;private set;}
public MetricType MetricType {get;private set;}
// Private constructor prevents outside instantiations
private ThisIsAnEnum(MetricType mt) {
MetricType = mt;
}
public static readonly ThisIsAnEnum TypeKilom = new ThisIsAnEnum(MetricType.Kilometer) {
ConvertSomething = (dbl1, dbl2) => {
...
return res;
}
}
public static readonly ThisIsAnEnum TypeMillim = new ThisIsAnEnum(MetricType.Millimeter) {
ConvertSomething = (dbl1, dbl2) => {
...
return res;
}
}
}
Using Func<double,double,double> lets you use a single class with multiple different pieces of logic, while preserving the dispatch based on the instance.
One unfortunate consequence of taking this approach is that you wouldn't be able to switch on these enums.
The use of java enums is a subjective question that I'm not well qualified to answer. I can say that you could solve your problem in C# using an extension method though. I'm not sure what relevance the interface has, but given what you've shown, you can reproduce it like this.
void Main() {
ThisIsAnEnum.typeKilom.ConvertSomething(1, 2);
}
public enum ThisIsAnEnum {
typeKilom,
typeMillm,
}
public static class ThisIsAnEnumExtensions {
// extension method
public static double ConvertSomething(this ThisIsAnEnum #this, double dbl1, double dbl2) {
return dbl1 + dbl2; // do stuff
}
}
Related
I have an interface and 2 classes implementing the interface. The only difference between the classes is the constant name, they are being used for the same thing but from different locations. I just want to count how many times the method is called from each different location. Is there a better way of doing this without the repetition or passing in the metric name as a string?
public interface OldIdResolver {
Optional<String> getNewIdFromOldId();
}
public class CustomFieldIdResolver implements OldIdResolver {
Optional<String> getIdFromLegacyId(String oldId) {
Optional<Id> newIdOptional = idService.getNewIdFromOldId(oldId);
if (newIdOptional.isPresent()) {
statsDClient.incrementCounter("customField.oldIdUsed");
}
return newIdOptional;
}
}
public class SearcherIdResolver implements OldIdResolver {
Optional<String> getIdFromLegacyId(String oldId) {
Optional<Id> newIdOptional = idService.getNewIdFromOldId(oldId);
if (newIdOptional.isPresent()) {
statsDClient.incrementCounter("searcher.oldIdUsed");
}
return newIdOptional;
}
}
Ordinarily you'd simply make one class and make a constructor:
public class AnyMetricIdResolver implements OldResolver {
private final String metricName;
public AnyMetricIdResolver(String metricName) {
this.metricName = metricName;
}
Optional<String> getIdFromLegacyId(String oldId) {
Optional<Id> newIdOptional = idService.getNewIdFromOldId(oldId);
if (newIdOptional.isPresent()) {
statsDClient.incrementCounter(metricName);
}
return newIdOptional;
}
}
If for some reason that's not good enough (you were rather vague with 'passing the metric name as a string'), you can make an actual class for each kind of metric string, but still do some code reuse. Keep the IdResolver from above (you may want to make it package private if you must), then start subclassing that:
public class SearcherIdResolver extends AnyMetricIdResolver {
public SearcherIdResolver() {
super("searcher.oldIdUsed");
}
}
You can't make a bunch of classes without actually writing them all, unless you use code generation tools such as Annotation Processors which is certainly possible, but I doubt that's what you're looking for here.
I'm creating a RTS game and one of the features is to construct differend kind of buildings. I'm finding a lot of repetition and I was thinking to extract it in helper method, but the problem is that every building is different object which inharits some propertyes from the main building class.
The building methods looks like this:
public static void buildDockyard(Base base) {
if (Validator.checkForBuilding(base, "Dockyard")) {
throw new IllegalStateException("Dockyard is already build");
}
Dockyard dockyard = new Dockyard("Dockyard");
int requiredPower = dockyard.requiredResource("power");
int requiredStardust = dockyard.requiredResource("stardust");
int requiredPopulation = dockyard.requiredResource("population");
Validator.checkResource(base, requiredPower, requiredStardust, requiredPopulation);
updateResourceAfterBuild(base, requiredPower, requiredStardust, requiredPopulation);
dockyard.setCompleteTime(dockyard.requiredResource("time"));
base.getBuildings().add(dockyard);
}
public static void buildHotel(Base base) {
if (Validator.checkForBuilding(base, "Space Hotel")) {
throw new IllegalStateException("Space Hotel is already build");
}
SpaceHotel spaceHotel = new SpaceHotel("Space Hotel");
int requiredPower = spaceHotel.requiredResource("power");
int requiredStardust = spaceHotel.requiredResource("stardust");
int requiredPopulation = spaceHotel.requiredResource("population");
Validator.checkResource(base, requiredPower, requiredStardust, requiredPopulation);
updateResourceAfterBuild(base, requiredPower, requiredStardust, requiredPopulation);
spaceHotel.setCompleteTime(spaceHotel.requiredResource("time"));
base.getBuildings().add(spaceHotel);
base.setCapacity(base.getCapacity() + spaceHotel.getCapacity());
}
I was thinking to refactor like this:
The helper method
private static void construct(Building building, Base base) {
int requiredPower = building.requiredResource("power");
int requiredStardust = building.requiredResource("stardust");
int requiredPopulation = building.requiredResource("population");
Validator.checkResource(base, requiredPower, requiredStardust, requiredPopulation);
updateResourceAfterBuild(base, requiredPower, requiredStardust, requiredPopulation);
building.setCompleteTime(building.requiredResource("time"));
}
Aimed result
public static void buildDockyard(Base base) {
if (Validator.checkForBuilding(base, "Dockyard")) {
throw new IllegalStateException("Dockyard is already build");
}
Dockyard dockyard = new Dockyard("Dockyard");
construct(dockyar, base);
base.getBuildings().add(dockyard);
}
The problem is that each building has unique properties and resource requirements and the main Building class doesn't know about them, so I can't use it as a parameter in the helper method.
All of this is happening in a static helper class for the Base class.
How would you refactor this code ?
Thank you in advance !
Your problems start with using static methods for everything. In an object oriented world you ideally have an object Base and it would have a non-static method addStructure(Struture structure) were Structure is an interface for example. Now you would have objects like Building and Dockyard which would implement Structure.
Implentation of addStructure would be something like this:
if (getBuildings().contains(structure)) {
throw new IllegalStateException(structure.name + " is already build");
}
if (validateStillHaveEnoughResourcesFor(structure)) {
throw new IllegalStateException(structure.name + " can not be added. Not enough resources");
}
getBuildings().add(structure);
Validating structure itself should not be in base. Validating how structure fits to the base should be in the base.
The best way to DRY in Java when making games is to have a clear understanding and terminology of your game. If you read any modern board game manual you will soon see that they will use exactly one word for one concept, like Turn, Round, Building, Player, Resource. This allows to form a rough structure: A Building costs a certain amount of Resource. If a player hasn't enough of Resource then tell him "We need more vespine gas.", etc. The clearer the picture, the DRY-er your Java and easier to create the necessary Classes for your code.
Parameters
If you end up with something like this:
public static void someFunction(Base base, Object param1, Object param2)
public static void someOtherFunc(Base base, Object paramA, Object paramB)
...
Then this is a strong hint that maybe both functions should be part of the Base class.
Enums
If you have a limited set of values then Java Enums can be fantastic to represent them, e.g. your Resource system:
public enum Resource {
POWER, STARDUST, POPULATION
}
Now you don't have to remember if you called it "stardust", "Stardust" or if you even still have a Resource like "stardust". Instead you can use int requiredPower = building.requiredResource(Resource.POWER);
Polymorphism
Let's suppose we have two classes, Building and StarHotel, with StarHotel being a specific kind of Building. Having an abstract class Building allows us to handle some general mechanics in a specific manner, like this:
public abstract class Building {
private ... cost;
private ... requirements;
private ...
// Std-Getter and Setter methods
public ... getCost() { return this.cost; }
}
EVERY Building has a cost, and requirements and other important variables. BUT we handled all the standard stuff of getting and setting these generic variables to a base class from which we now can extend other, more specific buildings. Thanks to the extends keyword you can get the Cost of a StarHotel Object without filling the StarHotel class with repetitive Getters and Setters.
public class StarHotel extends Building {
// Getter, Setter inherited from Building class
}
Interfaces
Java Interfaces allow you to define Interfaces which define methods. In laymen terms: This is useful, because every Class that implements an Interface must implement the method, unless the interface provides the default implementation.
public interface ResourceProvider {
void provideResourceFor(Base base); // A Resource Provider provides Resource for a base.
}
With this interface we have defined that if some Class implements ResourceProvider it has to specify how and what resources to provide for some Base object. Our interface does not care which Resource, which Base and even what provideResourceFor could mean, but as long as something implements ResourceProvider it has to provide the functionality.
Putting all together
Putting Enums, Interface and Polymorphism together, we can now create a StarHotel class that extends Building and implements ResourceProvider, providing 8 Food units and 2 Happiness units to our Base.
public class StarHotel extends Building implements ResourceProvider
public void provideResourceFor(Base base) {
base.addResource(Resource.FOOD, 8);
base.addResource(Resource.HAPPINESS, 2);
}
}
That might be much to take in, but hopefully it will give you a good direction where to look further.
I am creating a store for user preferences, and there are a fixed number of preferences that users can set values for. The names of the preferences (settings) are stored as an Enum:
public enum UserSettingName {
FOO,
BAR,
ETC
}
What I would like to be able to do is store a value type with the name so that the service will store the user's value with the correct Java type. For example, FOO might be a Long, and BAR might be a String. Up until now, we were storing all values as Strings, and then manually casting the values into the appropriate Java type. This has lead to try/catch blocks everywhere, when it makes more sense to have only one try/catch in the service. I understand that Enums cannot have generic types, so I have been playing around with:
public enum UserSettingName {
FOO(Long.class),
BAR(String.class),
ETC(Baz.class)
private Class type;
private UserSettingName(Class type) {
this.type = type;
}
public Class getType() {
return this.type;
}
}
I have a generic UserSetting object that has public T getSettingValue() and public void setSettingValue(T value) methods that should return and set the value with the correct type. My problem comes from trying to specify that generic type T when I create or retrieve a setting because I can't do something like:
new UserSetting<UserSettingName.FOO.getType()>(UserSettingName.FOO, 123L)
Sorry if this isn't exactly clear, I can try to clarify if it's not understood.
Thanks!
UPDATE
Both the setting name and value are coming in from a Spring MVC REST call:
public ResponseEntity<String> save(#PathVariable Long userId, #PathVariable UserSettingName settingName, #RequestBody String settingValue)
So I used the Enum because Spring casts the incoming data automatically.
Firstly you have to step back and think about what you're trying to achieve, and use a standard pattern or language construct to achieve it.
It's not entirely clear what you're going after here but from your approach it almost certainly looks like you're reinventing something which could be done in a much more straightforward manner in Java. For example, if you really need to know and work with the runtime classes of objects, consider using the reflection API.
On a more practical level - what you're trying to do here isn't possible with generics. Generics are a compile-time language feature - they are useful for avoiding casting everything explicitly from Object and give you type-checking at compilation time. You simply cannot use generics in this way, i.e. setting T as some value UserSettingName.Foo.getType() which is only known at runtime.
Look how it done by netty:
http://netty.io/wiki/new-and-noteworthy.html#type-safe-channeloption
They done it by using typed constants:
http://grepcode.com/file/repo1.maven.org/maven2/io.netty/netty-all/4.0.0.Beta1/io/netty/channel/ChannelOption.java#ChannelOption
EDIT:
public interface ChannelConfig {
...
<T> boolean setOption(ChannelOption<T> option, T value);
...
}
public class ChannelOption<T> ...
public static final ChannelOption<Integer> SO_TIMEOUT =
new ChannelOption<Integer>("SO_TIMEOUT");
...
}
EDIT2: you can transform it like:
class Baz {}
class UserSettingName<T> {
public static final UserSettingName<Baz> ETC = new UserSettingName<Baz>();
}
class UserSetting {
public <T> UserSetting(UserSettingName<T> name, T param) {
}
}
public class Test {
public static void main(String[] args) {
new UserSetting(UserSettingName.ETC, new Baz());
}
}
Enums are not the answer here. If you find yourself repeating code everywhere you could just create a utility class and encapsulate all the try/catch logic there. That would cut down on your code redundancy without majorly impacting your current code.
public class Util
{
public static MyObject getObjectFromString(String s)
{
try
{
return (MyObject)s;
}
catch(Exception e)
{
return null;
}
}
}
Then use as follows:
MyObject myObj = Util.getObjectFromString(string);
I have a utility class with some static methods which I use in some places around my code. I am facing a problem now. I want to replace the functions in this utility class in order to provide better implementation. Obviously this cannot be achieved directly without some serious hacking.
My question is: what is the best way to solve this problem. How can someone still use utility classes in such a way that they can still be extended upon. I am thinking around the idea of wrapping the particular utility function for each class that makes use of them so that even if the actual utility method cannot be replaced at least it is possible to replace the class method that calls it. Still, I am curious to know about what are the best practices.
Why can't you just change the implementation of the static methods in the utility class.
As long as you don't change the method signatures, the users wont get affected.
While not an exact duplicate, an answer to this can be found in the following question:
calling a super method from a static method
Personally, I would make them not be static methods, but make them relate to whatever they manipulate instead. If you post an example or two of your current utility methods, I can tell you how I'd handle them.
public interface HashAlgorithm {
String hash(String s);
String getType();
}
public class ReallyBadHashAlgorithm implements HashAlgorithm {
public String hash(String s) {
// really bad hash! I mean, really bad!
return "HASH" + Integer.toString(s.hashCode()) + "HASH";
}
public String getType() {
return "RRB"; // really really bad = RRB
}
}
public class Hash<A extends HashAlgorithm> {
String key;
String value;
A algorithm;
public Hash(String key, A algorithm) {
this.key = key;
this.value = null;
this.algorithm = algorithm;
}
public String getHash() {
if(value == null) {
value = algorithm.hash(key);
}
return value;
}
public static void main(String[] args) {
ReallyBadHashAlgorithm alg = new ReallyBadHashAlgorithm();
String key = "ABCDEFG";
Hash hashThis = new Hash<ReallyBadHashAlgorithm>(key,alg);
System.out.println(key.hashCode()); // to check it
System.out.println(hashThis.getHash());
}
}
And the result:
C:\Documents and Settings\mule\My Documents>java Hash
-488308668
HASH-488308668HASH
C:\Documents and Settings\mule\My Documents>
Well I don't really see your problem. If the new implementation of your utility class is equivalent to the old version you can just replace it, if not, existing code will still need to be able to call the old functions so you can't change anything there. So why not just add new methods to the Utility class that can be used by new code?
I could be wrong but I'm guessing from Why can't enums be declared locally in a method?
that, since an enum in Java cannot be declared locally, that therefore it is problematic for a method to return type Enum? I can declare that a method should return an Enum (see below) but how would one then go about implementing such a method to return anything other than null, or a reference to an Enum declared outside the method? My first inclination would be to investigate using Generics for this but I'd like to avoid any deadends if the SO community can help me avoid them.
private Enum resources() {
return null;
}
I think you're correct, it's only going to be able to either return null or an Enum declared somewhere else. But you don't necessarily have to specify that "something else" at compile time.
class EnumEnumerator<T extends Enum<T>> implements Iterable<T> {
private final Class<T> enumClass;
public EnumEnumerator(Class<T> enumClass) {
this.enumClass = enumClass;
}
public Iterator<T> iterator() {
T[] values = enumClass.getEnumConstants();
return Arrays.asList(values).iterator();
}
}
Later, you invoke it by specializing the generic constructor and passing in the enum class you're interested in:
class EnumEnumeratorDemo {
enum Foo {
BAR, BAZ, QUX;
#Override public String toString() {
return name().toLowerCase();
}
}
public static void main(String[] args) {
for (Foo f : new EnumEnumerator<Foo>(Foo.class)) {
System.out.println(f);
}
}
}
(Obviously this is a contrived example and in real life you should just call Foo.values(), but you get the idea.)
The entire point of the way Java does Enums is that they are typesafe--so you wouldn't return an Enum (that would be double-plus ungood) instead you return the actual type you define (like "Suit") which acts just like a class. Suit has 4 "Enumerated" instances.
If you were expecting a "Suit", what good would it be to return a "Rank" of 7? It would break everything!
Also if you passed an "Enum" or some generic value, you couldn't call methods on it. The coolest thing about TypeSafe Enums is that you can just get a "Suit" and call "Suit.getColor()" and fully expect to get the color of that suit. You could also have a ranksHigherThan(Suit s) which might fulfill:
assertTrue(SPADES.ranksHigherThan(HEARTS));
Or, more importantly:
suit1.ranksHigherThan(suit2);
(assuming they were both passed in and you don't know what they are)
Type safety is really amazing (even though it feels a little uncomfortable at first), embrace it.
All enums implement the interface Enum, so you can certainly write a method that returns an enum this way. But this method will return a single enum value. There is no way to return a generic value which encompasses the whole enum (apart from returning the class and doing reflection). You can however return all the enum values which is more or less what you want I think.
enum Resources { ONE, TWO, THREE }
private Enum<?>[] resources() {
return Resources.values();
}
One benefit of this approach is you can return more or less values for example:
enum Resources { ONE, TWO, THREE }
enum MoreResources { UN, DEUX, TROIS }
private Enum<?>[] resources() {
List<Enum<?>> resources = new ArrayList<Enum<?>>();
resources.addAll(Arrays.asList(Resources.values());
resources.addAll(Arrays.asList(MoreResources.values());
return resources.toList(new Enum<?>[] {});
}
An even better approach that is more typesafe is to have the enums of interest
implement a common interface e.g.
public interface Resources {}
enum SomeResources implements Resources { ONE, TWO, THREE }
enum MoreResources implements Resources { UN, DEUX, TROIS }
private Resources[] resources() {
List<Resources> resources = new ArrayList<Resources>();
resources.addAll(Arrays.asList(Resources.values());
resources.addAll(Arrays.asList(MoreResources.values());
return resources.toList(new Resources[] {});
}
You can add additional methods to the interface to provide more functionality.
What are you trying to accomplish? This is a way to return an Enum:
public class Test
{
public static void main(String args[])
{
System.out.println(doit());
}
public enum Foo {
BAR,
BAZ;
}
public static Enum doit() {
return Enum.valueOf(Foo.class,"BAR");
}
}
But, I'm guessing this is not what you are going for?
Yes, it definitely is possible.
private Enum getRetentionPolicy() {
return java.lang.annotation.RetentionPolicy.SOURCE;
}
If your question is about declaring Enums, you may declare them:
in their own java file, similar to a top-level class;
within a java file belonging to another class, similar to a static inner class;
Not totally sure what your goal is, but if you wanted to return a generified method (i.e. one that would be overridden) you might have something like the following:
public class MyEnumClass<T extends Enum<T>> {
public T resources() {
//do stuff here
}
}
Not entirely sure what you would gain there, although it can be beneficial if you are talking about different sets of Enums and their elements.
If you are talking about the Enum class (i.e. the percursor to Iterator) as far as I know it has not been generified, so I am not sure generics would help much here.
You can refer to a value of an enum by its name, e.g. Suit.SPADES.
You can iterate over all values by using the values() method and pick one of the values.