Develop Reference

Enhance POJO with Bytecode manipulation [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
I need to do some "bytecode hacking" to inject something into a POJO without adding a "visible" property.
Consider this code:
public class Entity {
private Multimap<String, Entity> linkMap;
public void setLink(String linkName, Entity entity) {
if(linkMap == null) {
linkMap = HashMultimap.create();
}
boolean isSet = false;
entity = byteCodeHack(entity, false);
linkMap.put(linkName, entity);
}
public void addLink(String linkName, Entity entity) {
if(linkMap == null) {
linkMap = HashMultimap.create();
}
boolean isSet = true;
entity = byteCodeHack(entity, isSet);
linkMap.put(linkName, entity);
}
}
Where there are two types of link, one is "set" and one is "not set (or multi)" and there's no way to determinate if the "link" is a "set" or "not set" even if the Multimap contains only one entry for a given link name, it does not mean that it is a "set" it could be an "addLink" which is just one. The point here is the underlying database can link objects one-to-one (set) or one-to-many (add). And the stage that will process this Entity needs to know from the Multimap which database operation to do, "set" or "add" -- but as mentioned that can't be inferred by just iterating over the Multimap.
So my strategy is to inject a value into the entity before inserting it to the Multimap, the byteCodeHack method.
What would be the best way to implement this?

An alternative solution without class enhancing is to add an additional method to set the Multimap in such as way when it is "set" it will first remove all the other elements existing, then another method "add" to just add causing to have multiple similar keys:
public void addLink(String linkName, Entity entity) {
linkMap.put(linkName, entity);
}
public void setLink(String linkName, Entity entity) {
Collection<Entity> oldValues = linkMap.get(linkName);
if(Objects.nonNull(oldValues)) {
linkMap.remove(linkName, oldValues);
}
linkMap.put(linkName, entity);
}
If class enhancing is really required, it can be done through https://bytebuddy.net/#/ library.

Java: Override protected String [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I don't know Java.
Just need a quick fix if possible.
How to override protected String?
I have:
public class Something {
protected String changeMe = "this";
public String viewForm() {
...
return getForm();
}
public String getForm() {
return changeMe;
}
}
myfile:
public class MySomething extends Something {
public String viewForm() {
return super.viewForm();
}
}
How to use changeMe = "that" in class MySomething?
Thanks.

Actually, others have answered your question. In case, you are really new to Java struggling to figure it out, the simplest answer to your question is just put your above mentioned statement in the constructor of the derived class:
Solution one (actually bad solution):
public class MySomething extends Something {
public MySomething() {
changeMe = "that"
}
}
A better solution for your problem is to define a setter method in the class Something as follows (in case you have access to its source code):
public void setChangeMe(String newValue) {
changeMe = newValue;
}
and you can change the value by calling
Something s = new Something();
s.setChangeMe("that");

the word override is a hint for the compiler, with that you let it know that you're writing code that at your own way implements the method of a parent class or the interface.
having said that overriding a variable/attribute/field is a wrong use of the terminology, and makes not much sense
to answer your question: you can access toso the changeMe object because it is not defined as private... so you can change the value directly..
Example:
public static void main(String args[]) {
MySomething ms = new MySomething();
System.out.println(ms.changeMe);
ms.changeMe = "that";
System.out.println(ms.changeMe);
}

Best way to remove multiple if-else [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 6 years ago.
Improve this question
So the similar type of questions are answered elsewhere but here I am expecting the best way to omit if else chain for the given situation.
CURRENT CODE
private ViewModel getViewModel(Receipt receipt) {
String receiptType = receipt.type;
if(receiptType.equals("HOTEL")) {
return new HotelReceiptViewModel(receipt));
} else if(receiptType.equals("CAR")) {
return new CarReceiptViewModel(receipt));
}
.
.
.
} else if(receiptType.equals("LUNCH")) {
return new FoodReceiptViewModel(receipt));
}
}
where all the view models extend a class called ReceiptViewModel. e.g.
public class HotelReceiptViewModel extends ReceiptViewModel implements ViewModel {
public HotelReceiptViewModel(Receipt receipt) {
super(receipt);
this.receiptNumber = receipt.getDocumentNumber();
this.receiptHeading = "HOTEL";
}
}
There are currently 5 types of receipts and there will be 3-4 more types of receipts in future.
POSSIBLE SOLUTIONS
Use of HashMap
Use of Enum
Use Strategy Pattern or Command Pattern
Use of Reflection
Let's see pros and cons of each approach
1. Use of HashMap
private ReceiptViewModel getViewModel(Receipt receipt) {
Map<String, ReceiptViewModel> map = getViewModelsMap();
String receiptType = receipt.type;
ReceiptViewModel viewModel = map.get(receiptType);
if(viewModel != null) {
viewModel.setReceipt(receipt);
}
return viewModel;
}
private Map<String, ReceiptViewModel> getViewModelsMap() {
Map<String, ReceiptViewModel> map = new HashMap<String, ReceiptViewModel>();
map.add("HOTEL"), new HotelReceiptViewModel());
map.add("CAR"), new CarReceiptViewModel());
map.add("LUNCH"), new FoodReceiptViewModel());
}
and ReceiptViewModel classes will look like
public class HotelReceiptViewModel extends ReceiptViewModel implements ViewModel {
public HotelReceiptViewModel(Receipt receipt) {
super(receipt);
this.receiptNumber = receipt.getDocumentNumber();
this.receiptHeading = "HOTEL";
}
}
PROS
Faster, Easier, Extensible.
CONS
ReceiptViewModel object does not require an object of Receipt type in the constructor. Receipt is rather set using a setter, where all the logic of initializing the ReceiptViewModel class will move now.
2. Use of Enum
private ReceiptViewModel getViewModel(Receipt receipt) {
String receiptType = receipt.type;
ReceiptViewModel viewModel =
ReceiptViewModels.valueOf(receiptType).getReceiptViewModel(receipt);
return viewModel;
}
And Enum will look like
public enum ReceiptViewModels {
HOTEL(
ReceiptViewModel getReceiptViewModel(Receipt receipt) {
return new HotelReceiptViewModel(receipt);
}
),
CAR(
ReceiptViewModel getReceiptViewModel(Receipt receipt) {
return new CarReceiptViewModel(receipt);
}
),
.
.
.
LUNCH(
ReceiptViewModel getReceiptViewModel(Receipt receipt) {
return new FoodReceiptViewModel(receipt);
}
),
public abstract ReceiptViewModel getReceiptViewModel(Receipt receipt);
}
PROS
Fast, Probably Easy.
CONS
Size of Enum will keep on increasing as the receipt types increase, resulting in non-maintainable code.
ReceiptViewModels.valueOf(receiptType) expects a known receipt type. If a new receipt type comes as a response from server, it will result in an IllegalArgumentException
3. Use of Reflection
Class<? extends ReceiptViewModel> viewModel = Class.
forName(receiptType + name + "ReceiptViewModel").asSubclass(ReceiptViewModel.class);
ReceiptViewModel receiptViewModel = viewModel .newInstance();
CONS
1. Slower
Cannot be used when the class names are different. e.g. For LUNCH type the view model class name is FoodReceiptViewModel
Logic of getting values from receipt is moved to a setter instead of constructor as in case of HashMap
4. Use of Strategy Pattern or Template Pattern
PROS Easy to understand and faster than Reflection
CONS Probably an overkill. A new class will be added for each type of receipt.
Considering all the above points, which would be the best approach for my use case to remove the multiple if-else blocks?

I would use a switch, unless there is a reason to use something more complex.
private ViewModel getViewModel(Receipt receipt) {
switch(receipt.type) {
case "HOTEL": return new HotelReceiptViewModel(receipt);
case "CAR": return new CarReceiptViewModel(receipt);
case "LUNCH": return new FoodReceiptViewModel(receipt);
default:
throw new IllegalArgumentException("Unknown receipt type " + receipt.type);
}
I would claim this is the best solution as it is the simplest which meets you needs.

No behavior needed, no structure needed, no polymorphism needed, so I don't see interest to use design patterns such as strategy or to use a map which brings nothing but complexity in the need you describe.
You want a very simple state machine. So, "if else if" or "switch" is perfect .
Maybe out of the subject but with a private method, the code is not unitary testable.

I would make a new abstract method into your Receipt class. Something like
public <T extends ReceiptViewModel> T createModel()
And then would create subclasses of the Receipt class where each type would correspond to one subclass. Then each subclass will implement his own version of createModel returning the correct subclass of ReceiptViewModel. Your initial code will be as simple as
private ViewModel getViewModel(Receipt receipt) {
return receipt.createModel()
}

Serialization of a Map [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 a class that its like a wrapper for a map. It is a property list, mostly use for the sake of the name it looks like the following:
public class MyPropertyList implements Serializable
{
private static final long serialVersionUID = 7896123434L;
private LinkedHashMap<String,String> map;
public static final String key1 = "key1";
public static final String key2 = "key2";
//More key values
public MyPropertyList(){
map = new LinkedHashMap<String,String>();
}
public void addProperty(String key, String value){
map.put(key,value);
}
public LinkedHashMap<String,String> getMapping(){
return map;
}
public int getSize(){
return map.size;
}
//...Other delegated calls
}
It it a bad design? Does it present any issues? Is there a better design for that fulfills this purpose?

Use the Properties class from Java standar Library, which implements Serializable.

The code you have posted offers no additional functionality over LinkedHashMap, so any code which uses this might just as well use LinkedHashMap directly.

Design pattern to convert a class to another [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 4 years ago.
Improve this question
I have a class called GoogleWeather, I want to convert it to another class CustomWeather.
Is there any design pattern which helps you to convert classes?

In that case I'd use a Mapper class with a bunch of static methods:
public final class Mapper {
public static GoogleWeather from(CustomWeather customWeather) {
GoogleWeather weather = new GoogleWeather();
// set the properties based on customWeather
return weather;
}
public static CustomWeather from(GoogleWeather googleWeather) {
CustomWeather weather = new CustomWeather();
// set the properties based on googleWeather
return weather;
}
}
So you don't have dependencies between the classes.
Sample usage:
CustomWeather weather = Mapper.from(getGoogleWeather());

There is one critical decision to make:
Do you need the object that is generated by the conversion to reflect future changes to the source object?
If you do not need such functionality, then the simplest approach is to use a utility class with static methods that create a new object based on the fields of the source object, as mentioned in other answers.
On the other hand, if you need the converted object to reflect changes to the source object, you would probably need something along the lines of the Adapter design pattern:
public class GoogleWeather {
...
public int getTemperatureCelcius() {
...
}
...
}
public interface CustomWeather {
...
public int getTemperatureKelvin();
...
}
public class GoogleWeatherAdapter implements CustomWeather {
private GoogleWeather weather;
...
public int getTemperatureKelvin() {
return this.weather.getTemperatureCelcius() + 273;
}
...
}

Besides, You can also use new Java8 feature 'Function' from java.util.function'.
More detailed explanation is provided in http://www.leveluplunch.com/java/tutorials/016-transform-object-class-into-another-type-java8/ . Kindly have a look!