I have the following class:
public class A {
private String a;
private Long b;
private Date c;
//getters, setters, constructors
}
And I need to be able to export it as an excel with different templates.
For example, one excel has the following headers:
a b c
Another excel has the following template:
b a c
And another template could look like this:
b a
What would be a good way to design the code so that I could format the A object according to one template or another? Is there a particular design pattern I can look at?
I think you can use Adapter pattern, you need to make different adapter for different templates.
Bind your object with the adapter and some logic in adapter will assign value from your passed object to the template where you want to fill the values.
By making adapter you can make new format without making change in existing format, this will make code more maintainable and separate.
This is just a rough idea which concept can be apply here, you still have scope of making many modification in it.
Adapter Interface
public interface Adapter {
}
Adapter class
public class Format2Adapter implements Adapter {
private Long title;
String subtitle;
public void fillTemplate(Core c){
title = c.getB();
}
}
Format2Adapter class
public class Format2Adapter implements Adapter {
private Long title;
String subtitle;
public void fillTemplate(Core c){
title = c.getB();
}
}
Business Object class
import java.util.Date;
public class Core {
private String a;
private Long b;
private Date c;
public String getA() {
return a;
}
public void setA(String a) {
this.a = a;
}
public Long getB() {
return b;
}
public void setB(Long b) {
this.b = b;
}
public Date getC() {
return c;
}
public void setC(Date c) {
this.c = c;
}
// getters, setters, constructors
}
There are a lot of design patterns you can use, however, from first glance (this is also a matter of personal taste), it seems that the Strategy design pattern would be a perfect fit.
What I would do, is implement all of the different templates as different export strategies, that will implement a base interface (or extend a base subclass in case there's some common functionality):
public interface ExportStrategy {
public void export(A a);
}
The subclasses might implement different strategies:
public class ABCExportStrategy {
...
}
public class BACExportStrategy {
...
}
etc.
The A class, then becomes:
public class A {
// all the code you wrote in the question body goes here ...
public void export(ExportStrategy strategy) {
strategy.export(this);
}
}
Or, alternatively, you can have the strategy be a state of the A class:
public class A {
// all the code you wrote in the question body goes here ...
private ExportStrategy strategy;
// setter for the strategy
public void export() {
strategy.export(this);
}
}
KISS:
public class A {
private String a;
private Long b;
private Date c;
//getters, setters, constructors
public void ExportData(Template template){
switch (template.type){
case t1:
formatT1();
break;
case c2:
formatT2();
break;
default:
defaultBehavious();
}
}
Related
what do you think would be the best way to manage settings knowing that I have no use for them to be stored in a file.
Is a simple POJO like below with getters and setters enough?
public class Settings {
private int setting1;
private boolean setting2;
private String setting3;
public Settings() {
// Some default values in constructor
setting1 = 12;
setting2 = false;
setting3 = "A setting";
}
public int getSetting1() {
return setting1;
}
public void setSetting1(int setting1) {
this.setting1 = setting1;
}
public boolean isSetting2() {
return setting2;
}
public void setSetting2(boolean setting2) {
this.setting2 = setting2;
}
public String getSetting3() {
return setting3;
}
public void setSetting3(String setting3) {
this.setting3 = setting3;
}
}
Should I use something more advanced? Like a class that would capture the type of the parameter in question like Setting<Integer> setting1 = new Setting(12); ?
I thank you in advance for your answers.
Keep it simple.
Here's an immutable class that does everything you need. No more, no less:
public final class Settings {
public final int setting1;
public final boolean setting2;
public String setting3;
public Settings(int setting1, boolean setting2, String setting3) {
this.setting1 = setting1;
this.setting2 = setting2;
this.setting3 = setting3;
}
}
If you expect to compare Settings objects, then implement hashCode and equals.
Everything else is just ceremony until you actually need it.
If you are using Java 14, then save some key-strokes by using records:
public record Settings(int setting1, boolean setting2, String setting3) {}
If you can get the job done with your Setting class, I don't see any reason why you need to make it complex.
Getters and setters are introduce mutability. Its better you can create this class more immutable fashion. You can achieve this many ways. Here is two ways,
Builder Pattern
Create a static factory method instead of constructor (Static factory method pattern)
I'm learning SOLID principles with Java and I'm trying to implement two classes with this. My problem is about ISP. I have some methods that is present in one class but not in the other and I also have to refer both classes with the same interface.
This is the first class:
public final class Complex implements Number {
#Override
public String polarForm() {
//This class needs to implement this method
}
#Override
public String rectangularForm() {
//This class needs to implement this method
}
}
Here is the second one:
public final class Real implements Number {
#Override
public String polarForm() {
//This class does not need this method!
}
#Override
public String rectangularForm() {
//This class does not need this method!
}
}
Finally I have to refer to the classes something like this:
public static void main(String[] args) {
Number c = new Complex();
Number r = new Real();
Number n = c.add(r);
System.out.println(c.polarForm());
System.out.println(n);
}
How can I refer to both classes with the same interface without implementing unnecessary methods?
An alternate solution to approach this problem would be to use Composition instead of Inhertiance in conjunction to the interface segregation principle.
Number class
public class Number {
private RectangleForm rectangleForm;
private PolarForm polarForm;
private BigDecimal value;
public Number(RectangleForm rectangleForm, PolarForm polarForm,BigDecimal value) {
this.rectangleForm = rectangleForm;
this.polarForm = polarForm;
this.value = value;
}
public String polarForm() {
return polarForm.transform(this.value);
}
public String rectangleForm() {
return rectangleForm.transform(this.value);
}
//other methods such as add and subtract
}
PolarForm interface
public interface PolarForm {
public String transform(BigDecimal number);
}
RectangularForm interface
public interface RectangleForm {
public String transform(BigDecimal number);
}
RectangleForm implementation for real numbers
public class RectangleFormReal implements RectangleForm {
#Override
public String transform(BigDecimal number) {
String transformed = "";
//transfromed = logic to transform to rectangle form
return transformed;
}
}
PolarForm implementation for Real numbers
public class PolarFormReal implements PolarForm {
#Override
public String transform(BigDecimal number) {
//return the number as is without any transformation
return number.toString();
}
}
Putting the pieces together
public class NumberTest {
public static void main(String[] args) {
RectangleForm rf = new RectangleFormReal();
PolarForm pf = new PolarFormReal();
Number number = new Number(rf, pf,new BigDecimal(10));
String rectangleForm = number.rectangleForm();
String polarForm = number.polarForm();
}
}
You can create the PolarFormComplex and RectangleFormComplex implementations and wire theNumber instance in a similar fashion. The advantage of this approach is that your code will always rely on the interface of the Number class (by interface I mean the public APIs) and you can chose the transformation strategy by injecting the corresponding PolarForm or RectangleForm instances into your Number instance at compile time as shown above or at runtime (via a factory)
Break your Number interface (or base class) into multiple interfaces. The standard operations (add, subtract, etc) are in one; let's say INumber. polarForm and rectangularForm are part of another; let's say IComplex.
Real would implement INumber; Complex would implement INumber and Icomplex. You could then treat both as INumber.
If necessary, you could also create another interface that implements both.
So, here is an typical implementation of Memento pattern (skipped getters and setters).
public class Employee {
private String name;
private String phone;
public EmployeeMemento save() {
return new EmployeeMemento(name, phone);
}
public void revert(EmployeeMemento memento) {
this.name = memento.getName();
this.phone = memento.getPhone();
}
}
public class EmployeeMemento {
private final String name;
private final String phone;
public EmployeeMemento(String name, String phone) {
this.name = name;
this.phone = phone;
}
}
public class Caretaker {
private Stack<EmployeeMemento> history;
public Caretaker() {
history = new Stack<>();
}
public void save(Employee employee) {
history.push(employee.save());
}
public void revert(Employee employee) {
employee.revert(history.pop());
}
}
All implementations of this pattern that I found are more or less equal to the one above. But there are some problems about this kind of implementation, that I don't like:
It's possible to triger both employee.revert() and caretaker.revert(employee). I would like to have only one access point.
If we want to change EmployeeMemento, we have to make changes in Employee class also (because of revert method).
Is there a way to overcome this?
Or maybe I pay too much attention, and this details are not so important?
1) Note that Caretaker is supposed to take care of holding Mementos, not necessarily take care of Undo/Redo. If you look at the various implementations on Internet (For example here), you'll see that Caretaker does not have revert() but usually something like getMemento(). So the class that takes care of Undoing, is someone else which calls getMemento() on Caretaker and then revert() on Subject.
Even if you want Caretaker to take care of Undoing, note that employee.revert() is a method that's solely created to be used by caretaker.revert(), because in this design, no one else has access to Mementos. You can reduce it's visibility to be visible by only Caretaker. (If this was C++, it would be easily done by use of friend, but in Java you have to be creative and use package visibility or some other way.)
2) In Memento pattern, a class and its Memento are tightly coupled. Actually it's only the class itself that has access to Memento's internals and no one else should see how Memento is composed. So it does not matter if a change to class, propagates to its Memento.
Then again If you want to isolate changes, you can be creative again. For example instead of duplicating name and phone in both Class and its Memento, you could extract another class which contains these fields (let's say by the name of State) and then use this State in both the original class and its Memento. This way, when you have changes to state of the class, you need only to modify State.
Side note: It's better to define Memento as a nested static class inside the Subject.
So my design, that addresses your issues, would be something like this:
public class Employee {
private State state;
public Memento save() {
return new Memento(state);
}
public void revert(Memento memento) {
this.state = memento.state;
}
public static class Memento {
private final State state;
public Memento(State state) {
this.state = state;
}
}
public static class State {
private String name;
private String phone;
}
}
public class Caretaker {
private Stack<Employee.Memento> history;
public Caretaker() {
history = new Stack<>();
}
public void addMemento(Employee.Memento memento) {
history.push(memento);
}
public Employee.Memento getMemento() {
return history.pop();
}
}
public class UndoHandler {
Employee employee;
Caretaker caretaker;
public void snapshot() {
caretaker.save(employee.save());
}
public void undo() {
employee.revert(caretaker.getMemento());
}
}
I'm not sure if a class object to transfer data will be more efficient than an object array.
My goal is to know which option is the most efficient and which option is the best practice.
Consider this is a web application served to thousands of users.
Here the two sample cases:
A)
Model.java
public class Model {
public Contact getContact(long id)
{
// some logic
return new Contact(...);
}
}
Contact.java
public class Contact
{
private long id;
private String name;
private String surname;
private String email;
private int session;
private byte[] avatar;
// Constructor
public Contact(long id, String name, ...)
// Getters and Setters
}
B)
Model.java
public class Model {
public Object[] getContact(long id)
{
// some logic
Object[] myReturningContact = new Object[n];
myReturningContact[0] = rs.getLong("id");
// ...
myReturningContact[n] = rs.getBytes("avatar");
return myReturningContact;
}
}
SomeController.java
public class SomeController
{
public void someAction()
{
// Option A
this.setSomeTextTo(contact.getName());
// Option B
this.setSomeTextTo(String.valueOf(returningObject[n]));
}
}
Option A is best practice, unless you have a speed requirement that it can't meet, and Option B can.
Note that Option A will probably be a little faster if you make your fields public and final and don't use getters.
Also note that if you have many primitive fields, the cost of boxing and unboxing will slow down Option B, as may String.valueOf on Strings
In preparing for an interview, someone mentioned knowing how to make a class/method in java read-only. I've been doing a bit of searching, but haven't found anything really concrete.
Maybe this question is simpler to answer than I'm making it out to be, but what would be a way to make a class or method read-only in java?
The following code will ensure that your class is always READ ONLY, but if you find any loop hole, please post it here.
import java.io.Serializable;
final public class ImmutableClass implements Cloneable,Serializable {
private static final long serialVersionUID = 6488148163144293060L;
private static volatile ImmutableClass instance;
private ImmutableClass() {
// no-op
System.out.println("instance created : " + this.hashCode());
}
/**
* Lazy Instantiation
*
* #return
*/
public static ImmutableClass getInstance() {
if (instance == null) {
synchronized (ImmutableClass.class) {
System.out.println("aquired lock");
if (instance == null) {
instance = new ImmutableClass() {
};
}
System.out.println("released lock");
}
}
return instance;
}
public Object readResolve() {
System.out.println("readResolve()");
return getInstance();
}
#Override
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
}
The Read-only class means, we are talking about "IMMUTABLE" concept.
The following example depicts the same:
public class ImmutableString {
static String upcase(String s) {
return s.toUpperCase(); // here local variable s vanishes
// it return the value to a new String object
}
public static void main(String[] args) {
String s = new String("abc");
System.out.println(s); //abc
String s1 = upcase(s);
System.out.println(s1); //ABC
System.out.println(s); //abc
}
}
Lets Say you want a read only version of an object,
case 1: if your class contains fields which are not pointers to any other objects eg:
public class Person{
private String name;
//Getters n Setters
}
in this case, you can return a copy of this class, write a constructor that accepts Person, any one who wants to get a Person object will have a copy of this object so any Setter operations wont effect the original object(Strings are immutable)
Case 2: in case your object contains a pointer to another object or list or map
in this case make classes implement an interface which has only read-only methods(Getters) and wherever you are returning the object, change it to return this interface, so client will have access to only read-only methods
eg:
class Person implements ReadOnly{
String name;
.. assume pointers also in here
// Getter n Setters
public PersonReadOnly(){
return this;
}
}
interface PersonReadOnly {
public String getName();
}
Simple rule: Don't have any public fields and No public setter methods.
For example, see class below:
final class AReadOnlyClass
{
private int anInt;
public int GetAnInt()
{
return anInt;
}
}