I have a SaveSettings network operation in my application.
I am using an adapter so that I can be free to plug in another networking library in the future and not change any of my code.
public interface SaveSettingsOnServerAdapter {
void saveSettings(User user, OnSaveSettingsOnServerListener listener);
}
public class SaveSettingsOnServerAdapterImpl implements SaveSettingsOnServerAdapter {
private static final String API_USER_SESSION_HEADER = "Cookie";
private static final String API_SAVE_SETTINGS_PATH = "user/{user_id}/update";
private static final String API_SAVE_SETTINGS_USER_ID_PATH_PARAMETER = "user_id";
private static final String API_SAVE_SETTINGS_SYNC_WITH_CALENDAR_PARAMETER = "sync_with_calendar";
private static final String API_SAVE_SETTINGS_USE_MOBILE_NETWORK_PARAMETER = "use_mobile_network";
#Override
void saveSettings(User user, OnSaveSettingsOnServerListener listener) {
// Some implementation here, in my case - RETROFIT
}
}
My gut feeling tells me that those details outlined in the constants defined in the Implementation class are independent of whatever networking library I choose to use for the networking, so they should be part of the abstraction, right?
If so, should I declare SaveSettingsOnNetworkAdapter abstract and insert them there? And then SaveSettingsOnNetworkAdapterImpl extend it instead of implement it? Is it a problem to extend an abstract class instead of implementing an interface when employing the Adapter pattern?
Downgrading an interface to an abstract class isn't unproblematic. You force all future implementations to extend that class and only that class, whereas currently you can attach the interface to almost anything.
Plus, the parameters may be constant (as far as you can tell now) but is it really the responsibility of a SaveSettingsOnServerAdapter to keep & define them?
They are required in there for sure. But requirements can be provided by other places as well. The most versatile / abstract solution to that is to define another interface that provides the values and to add the dependency to that interface to the constructor of every SaveSettingsOnServerAdapter implementation.
If you don't like to repeat that constructor, that would be a good place to make an abstract class that implements SaveSettingsOnServerAdapterImpl and covers the common code to deal with the external interface.
But it's up to you. Whether you want more encapsulation and to which degree you want that depends on what you're working on. In a tiny tool that isn't going to change is pointless since abstractions aim to make change easy. And more abstraction also means more code and more code means more places that can break.
public interface ServerConfiguration {
String getHeader();
String getPath();
...
}
public enum DefaultServerConfiguration implements ServerConfiguration {
INSTANCE;
private static final String API_USER_SESSION_HEADER = "Cookie";
private static final String API_SAVE_SETTINGS_PATH = "user/{user_id}/update";
...
#Override
public String getHeader() {
return API_SAVE_SETTINGS_PATH;
}
#Override
public String getPath() {
return API_SAVE_SETTINGS_PATH;
}
...
}
public class SaveSettingsOnServerAdapterImpl implements SaveSettingsOnServerAdapter {
private final ServerConfiguration config;
public SaveSettingsOnServerAdapterImpl(ServerConfiguration config) {
this.config = config;
}
#Override
void saveSettings(User user, OnSaveSettingsOnServerListener listener) {
new Request().withHeader(config.getHeader());
}
}
public class UserOfAllThis {
new SaveSettingsOnServerAdapterImpl(DefaultServerConfiguration.INSTANCE);
}
The idea of abstraction is to make your code more generic. This should hide implementation as much as possible. Adding constants to the abstract layer will reveal some implementation details. The best way will probably be to add the constants to the implementation class or create a new class with these constants.
Related
Let's say that I have an interface IMazeRoom
This interface has a function getAdjacentRooms()
Furthermore, Mazerooms have to be instanciated as IMazeRoom room1 etc.
(All of the above cannot be changed)
Let's say these classes are implementing the interface:
TrapRoom, FreeRoom, MobRoom, TreasureRoom
I want to the following functions/variables to be used in all of those subclasses
Players[] playersInRoom, setSize(), isAdditionValid(Player p)
I want to use inheritence with the three functions/variable above without modifying the interface, or duplicating the code throughout the four subclasses.
What I have tried so far
Making an abstract interface MazeRoom which implements IMazeroom, and is implemented by the four subclasses. This does not work as a constraint of this project is that the rooms have to be instantiated as IMazeroom room and doing this would lead to instantiation Mazeroom room If I wanted to use the new functions meantioned above. Also IMazeRooms cannot be modified.
Ideas
I could probably just use another interface with the functions I want to include, which would be implemented by IMazeroom, but this seems weird as this constraint should be here to teach me something, and I do not see the value in just using another interface. Furthermore, using another interface would not really cut down on code duplication, I am looking for something more like a abstract class
(The above is a completely different example from my homework task, as I want to attemp the task on my own)
Edit: Since we cannot change the interface, you can use a DefaultRoom class that implements IMazeRoom.
public class DefaultRoom implements IMazeRoom {
protected Players[] playersInRoom;
/* your standard method implementations */
public boolean isAddtionValid(Player p) {
...
}
}
public interface IMazeRoom {
...
}
Since you have to instantiate it via IMazeRoom myIMazeRoomObject = new DefaultRoom(), as long as you know which kind of Room you are handling, you can simply cast it back:
try {
DefaultRoom myRoom = (DefaultRoom) myIMazeRoomObject;
} catch(ClassCastException ex) {
// we didn't get a DefaultRoom object and now we have to handle that
}
Sidenote: The important thing to note is, that the interface only implements the necessary method getAdjacentRoom, as such it only constitutes information to some (arbitrary) layout that relies on getAdjacentRooms().
Your secondary constraints (immutable interface + instantiation) make it necessary to circumvent something that shouldn't happen with proper OO architecture.
You can seperate the common concrete implemetation into a abstact class and keep the interface.
Rough example based on "I am not allowed to change the interface though":
IMazeRoom:
public interface IMazeRoom {
Set<IMazeRoom> getAdjacentRooms();
}
Common concrete implemetation:
public abstract class CommonRoom {
private final int size;
private final Set<Player> playersInRoom;
private final Set<IMazeRoom> adjacentRooms;
protected CommonRoom(int size, Set<Player> playersInRoom, Set<IMazeRoom> adjacentRooms) {
this.size = size;
this.playersInRoom = playersInRoom;
this.adjacentRooms = adjacentRooms;
}
public int getSize() {
return size;
}
public Set<Player> getPlayersInRoom() {
return playersInRoom;
}
public Set<IMazeRoom> getAdjacentRooms() {
return adjacentRooms;
}
public boolean isAdditionValid(Player player) {
// Some kind of implementation returning true or false...
return !playersInRoom.contains(player);
}
}
TrapRoom:
public class TrapRoom extends CommonRoom implements IMazeRoom {
public TrapRoom(int size, Set<Player> playersInRoom, Set<IMazeRoom> adjacentRooms) {
super(size, playersInRoom, adjacentRooms);
}
}
TreasureRoom:
public class TreasureRoom extends CommonRoom implements IMazeRoom {
public TreasureRoom(int size, Set<Player> playersInRoom, Set<IMazeRoom> adjacentRooms) {
super(size, playersInRoom, adjacentRooms);
}
}
... same implementation as TreasureRoom for additional rooms.
Comment: Now all rooms are treated as IMazeRoom...
I have an enum from a common Library (it cannot be changed) as a field from a Class.
I need to use that enum values as a switch-case in order to do something accordingly (for example save some data to a database).
This is for a Java 11 micro-service using Spring as a framework.
What I did before knowing the enum has to stay immutable, I avoided an ugly switch case with an overridden abstract function inside the enum like this:
public enum InvoiceStatus {
DRAFT {
#Override public void action(InputMessage inputMessage) {
invoiceFileService.draft(inputMessage);
}
},
VALID {
#Override public void action(InputMessage inputMessage) {
invoiceFileService.valid(eiInvoiceFileMessage);
}
},
NOT_VALID {
#Override public void action(InputMessage inputMessage) {
invoiceFileService.notValid(eiInvoiceFileMessage);
}
};
//+20 more values...
#Autowired
InvoiceFileService invoiceFileService;
public abstract void action(InputMessage inputMessage);
}
and I simply called the enum like this, so with different values from the enum the called function from the service would be different without writing a long switch-case.
invoice.getStatus().action(inputMessage);
Now the new requirement needs the enum to live inside a common library so it can refer to InvoiceFileService class which will be only local to my project.
I tried different options like HashMaps but the code went ugly and un-maintainable.
Is there a clean way to extend the simple enum (with only values definition) and add to it the abstract function to do stuff? maybe java 8 added some new way to do this.
You could create a wrapper enum.
public enum WrappedInvoiceStatus {
DRAFT(InvoiceStatus.DRAFT, this::someAction),
// other values
private WrappedInvoiceStatus(InvoiceStatus status, Action action) {
this.status = status;
this.action = action;
}
private interface Action { // can be one of Java default functional interfaces as well
void doSomething(InputMessage msg);
}
private void someAction(InputMessage msg) {
// behavior
}
// some plumbing required
}
Basically I’m suggesting using wrapping and lambda expressions or method references. The world of functional programming takes some getting used to. Not everyone is a fan. Your mileage may vary.
As others already said, you can not extend the enum at runtime.
But an enum can implement an interface.
So the basic idea is:
You make an interface with the action as sole abstract method:
public interface InvoiceAction {
void action(InputMessage message);
}
Your enum implements that interface
public enum InvoiceStatus implements InvoiceAction {
// ... no other changes needed
}
In all the cases where you only need to use the actual action, change InvoiceStatus to InvoiceAction. This is the most risky change. Make sure to recompile all code.
Because InvoiceAction only has one abstract method, it's a functional interface, and can be implemented with a lambda expression:
invoice.setStatus(msg -> ...);
This change is probably the most invasive change, but it might be the right thing to do - if you need a different action next time, you won't have the same problem as today.
Enum type is not extendable and implicitly final as specified in JLS:-
An enum declaration is implicitly final unless it contains at least one enum constant that has a class body (§8.9.1).
Hence a class could not extends an enum type. However you could use wrapper or adapter pattern to add additional behaviours/fields of the enum. For example:-
#Service
public class SimpleInvoiceFileService implements InvoiceFileService{
private final InvoiceStatus invoiceStatus;
public SimpleInvoiceFileService(InvoiceStatus status){
invoiceStatus = status;
}
#Override
public void draft(InputMessage input){
this.invoiceStatus.action(input);
}
#Override
public void valid(InputMessage input){
this.invoiceStatus.action(input);
}
// Add more methods to InvoiceFileService interface
// as required and override them here.
}
JLS Reference:-
https://docs.oracle.com/javase/specs/jls/se11/html/jls-8.html#jls-8.9
public interface IHashStorage<T> {
public static final float INITIAL_LOAD_FACTOR = 0.7f;
public static final int INITIAL_CAPACITY = 149;
}
I have the code above which needs to be translated in c#. The only solution that seems to be proper is to make it an abstract class.From what I found it's safer to use readonly than const:
public abstract class IHashStorage<T>
{
private readonly float INITIAL_LOAD_FACTOR = (float)0.7;
private readonly int INITIAL_CAPACITY = 149;
}
The project in Java is using the Decorator pattern and Proxy, the transformation from java to c# can possibly require to use more abstract classes(currently in java there are only interfaces used)?I know theoretically the difference between them but practically in c# I used abstract classes more.I'm not that familiar with java and I would like to know your advice about how to find the best solution to finish this task, I mean the main points to keep in mind when converting the code.
I would define an interface with a get property.
then, make my base class implement it and set the default values
and then, extend the base class for every java class that implements the java interface.
something along these lines:
public interface IHashStorage<T>
{
float InitialLoadFactor { get; }
int InitialCapacity { get; }
}
public class HashStorageBase<T> : IHashStorage<T>
{
private readonly float _initialLoadFactor = 0.7f;
private readonly int _initialCapacity = 149;
public float InitialLoadFactor
{
get { return _initialLoadFactor; }
}
public int InitialCapacity
{
get { return _initialCapacity; }
}
}
public class HashStorage1<T> : HashStorageBase<T>
{
...
}
As I imply in my comment, there is no way to attach fields (or any other implementation details) to an interface in C#. You have two options besides making this an abstract class:
Make the fields into (probably read-only) properties on the interface, which will force all implementations to specify them.
Make the fields into custom attributes defined on the interface and/or the implementions.
I am creating an API of a list of checking functions. There is an object passed in as an argument to be checked.
The object is like below:
public class People{
private String name;
private String address;
private int age;
private String job;
public getter() ...
public setter() ...
}
I create a class including a list of checking function to make sure the provided information is valid or not. For example:
public class checkingFunctions {
public static boolean checkName(People ppl){
perform the name checking function;
}
public static boolean checkAge(People ppl){
perform the age checking function;
}
}
I know the above way works as an API so that other people can call checkingFunctions.checkName(ppl). But is this the correct way to build the API that will be exposed to others as jar file ? I was thinking to create an interface of checkingFunctions like below:
public interface ICheckingFunctions {
boolean checkName(People);
boolean checkAge(People);
}
And let the checkingFunctions class to implement it, like
public class checkingFunctions implements ICheckingFunctions {
}
BUt it won't compile because the checkName and checkAge can not be declared as static if it is overriding a superclass method.
Or should I just use the interface and let it implement the interface, but remove the static from all checking method. So, if others want to use my API, they just instantiate the interface, and use instance.checkName() to call method ? is that a good way ?
I am wondering whether there there exists an industry standard or design pattern standard to create such an interface so that others can call it.
Thanks a lot.
How to design such an API very much depends on how your API is intended to be used.
If it for example turns out, that your People class is best implemented as a final class, and you want to make sure, that it is always checked in the same consistent way, then providing a number of public static check... methods is certainly a reasonable way to go.
If on the other hand you do not know in advance how your People class should be checked, then I'd consider providing an ICheckingFunctions interface that declares the necessary check... methods. But if you go this route, you will perhaps also need to provide a way for the user to change the actually used implementation of ICheckingFunctions.
You should also consider, that while using an interface is certainly much more flexible and extensible, it is also more work to maintain and it could also provide a possible security risk - e.g. if you allow users to change the used ICheckingFunction, then you no longer have control of how your People class is checked.
One possible way to implement such an API using an interface is allowing users to register/unregister the used ICheckingFunction in your class. A very naive implementation could look like this:
public final class CheckingFunctions {
private static ICheckingFunctions checkFunction;
public static void registerCheckFunction(ICheckingFunctions checkFunction) {
CheckingFunctions.checkFunction = checkFunction;
}
public static boolean checkName(People ppl){
return checkFunction.checkName(ppl);
}
public static boolean checkAge(People ppl){
return checkFunction.checkAge(ppl);
}
}
This is of course just a minimal example. In an actual API you would have to decide quite a lot of additional details. For example:
Is there only ever a single ICheckingFunctions instance available? If there may be more registered ICheckingFunctions - how do you choose which of these functions are used?
Who is allowed to register/unregister an ICheckingFunctions instance?
May the ICheckingFunctions be called from different threads?
etc.
You must also consider in which environment your API is going to be used. If you for example want to support usage of your API in an OSGI environment, then you could e.g. supply your ICheckingFunctions as an OSGI service.
Last but not least I would consider the following: May your users subclass the People class? If yes, then it would perhaps be a good idea to make the ICheckingFunctions interface generic, and allow registrations of implementations for different classes. Here again a very naive example of this approach:
public final class CheckingFunctions {
public interface ICheckingFunctions<T extends People> {
boolean checkName(T p);
boolean checkAge(T p);
}
private static Map<Class<?>,ICheckingFunctions<?>> checkFunctions = new ConcurrentHashMap<>();
public static <T extends People> void registerCheckFunction(ICheckingFunctions<T> checkFunction, Class<T> c) {
checkFunctions.put(c, checkFunction);
}
private static <T extends People> ICheckingFunctions<T> getRegisteredCheckFunction(Class<T> c){
ICheckingFunctions<T> checkFunction = (ICheckingFunctions<T>) checkFunctions.get(c);
if (checkFunction == null) {
// provide some reasonable default?
throw new IllegalStateException();
}
return checkFunction;
}
public static <T extends People> boolean checkName(T ppl, Class<T> c){
return getRegisteredCheckFunction(c).checkName(ppl);
}
public static <T extends People> boolean checkAge(T ppl, Class<T> c){
return getRegisteredCheckFunction(c).checkAge(ppl);
}
}
I know that it isn't possible to extend enum in Java, but I am trying to find an elegant solution for the below
I am trying to model enums (or classes) which will contain http end points of various web services across regions, say I have service A and B, each will have 4 region specific end points in US, EU, JP or CN. (This is basically for some seperate debug code that I am writing, in production the end points will be picked from configuration)
I was hoping to do something like this (not compliant java code).
public enum IEndPoint {
NA_END_POINT,
EU_END_POINT,
JP_END_POINT,
CN_END_POINT,
}
public enum ServiceAEndPoint extends IEndPoint {
NA_END_POINT("http://A.com/");
EU_END_POINT("http://A-eu.com/");
JP_END_POINT("http://A-jp.com/");
CN_END_POINT("http://A-cn.com/");
}
I could do this using interfaces where I have a method for each region, but in my opinion the enum way is more expressive, is there any better way I could model this ? What I am looking for is if there is any better way to model the inheritence relation and also having the expressive power of enumerations.
ServiceAEndPoint.NA_END_POINT
vs
serviceAEndPoint.getNAEndPoint()
I'm assuming that you will also want a ServiceBEndPoint enum (and similar). In which case I don't think your model really makes that much sense.
IEndPoint is really an enumeration of the kind of environments/regions where a service might be running. It is not an enumeration of the services themselves. Each individual service (A, B or whatever) will have different addresses for each of the regions.
Therefore I would stick with just the IEndPoint enum, and then in some service-specific code have a lookup map that will give you the address for a given end-point. Something like this:
public enum IEndPoint {
NA_END_POINT,
EU_END_POINT,
JP_END_POINT,
CN_END_POINT,
}
public class ServiceABroker {
private static final Map<IEndPoint, String> addressesByEndPoint;
static {
addressesByEndPoint = new EnumMap<>();
addressesByEndPoint.put(NA_END_POINT, "http://A.com/");
addressesByEndPoint.put(EU_END_POINT, "http://A-eu.com/");
addressesByEndPoint.put(JP_END_POINT, "http://A-jp.com/");
addressesByEndPoint.put(CN_END_POINT, "http://A-cn.com/");
}
public String getAddressForEndPoint(IEndPoint ep) {
return addressesByEndPoint.get(ep);
}
}
If these are static final constants, then just put them in an interface. Name the interface something like IServiceAEndPointKeys, where the keys part is a convention.
Here's where I consider enums to be more appropriate and useful:
Example 1: File type. An enum containing jpg, pdf etc.
Example 2: Column definitions. If I have a table with 3 columns, I would write an enum declaring ID, Name, Description (for example), each one having parameters like column header name, column width and column ID.
Im not sure I understand you question, but you can add methods to an enum for example you could do something like the following:
public enum ServiceAEndPoint{
NA_END_POINT("http://A.com/");
EU_END_POINT("http://A-eu.com/");
JP_END_POINT("http://A-jp.com/");
CN_END_POINT("http://A-cn.com/");
private final String url;
private EndPoint(String url){
this.url=url;
}
public String getURL(){
return url;
}
}
Enums cannot be extended in such a manner, mostly because enums cannot be sub-classed or the constraints they must adhere to will not be possible to impose.
Instead leverage interfaces, like so
public interface IEndPoint;
public enum DefaultEndPoints implements IEndPoint {
NA_END_POINT,
EU_END_POINT,
JP_END_POINT,
CN_END_POINT,
}
public enum DefaultServiceEndPoints implements IEndPoint {
NA_END_POINT("http://A.com/");
EU_END_POINT("http://A-eu.com/");
JP_END_POINT("http://A-jp.com/");
CN_END_POINT("http://A-cn.com/");
}
public void doSomething(IEndPoint endpoint) {
...
}
The reason why one can't subclass in the manner you wish is related to the contract that enums will be both equal via .equals(object) and via ==. If you could subclass, would this make sense?
if ( (DefaultEndPoints)JP_END_POINT == (DefaultServiceEndPoints)JP_END_POINT) {
}
if you say "yes" then I would expect to be able to do this
DefaultEndPoint someEndpoint = DefaultServiceEndPoints.JP_END_POINT;
which would leave a door open for error, as there is no guarantee that a enum entry in one enum declaration is in the other enum declaration.
Could it be different? Perhaps, but it isn't, and changing it would definately introduce a lot of complications that would have to be thoroughly thought out (or it would open avenues to work around Java's strong static-type checking).
You may want to consider something like this:
public abstract class EndpointFactory {
public abstract String getNAEndPoint();
public abstract String getEUEndPoint();
}
public class ServiceAEndpointFactory extends EndpointFactory {
public static final String NA_END_POINT = "http://A.com/";
public static final String EU_END_POINT = "http://A-eu.com/";
public String getNAEndPoint() {
return ServiceAEndpointFactory.NA_END_POINT;
}
public String getEUEndPoint() {
return ServiceAEndpointFactory.EU_END_POINT;
}
}
public class ServiceBEndpointFactory extends EndpointFactory {
public static final String NA_END_POINT = "http://B.com/";
public static final String EU_END_POINT = "http://B-eu.com/";
public String getNAEndPoint() {
return ServiceAEndpointFactory.NA_END_POINT;
}
public String getEUEndPoint() {
return ServiceAEndpointFactory.EU_END_POINT;
}
}
Then you can refer to your strings directly like this:
ServiceAEndpointFactory.NA_END_POINT;
Or, you can use the base object if the type of service is not known until execution:
EndpointFactory ef1 = new ServiceAEndpointFactory();
String ep = ef1.getNAEndPoint();
The drawback of this is the redefinition of the get*Endpoint() functions in each sub-class. You could eliminate that by moving the static final variables to be not static in the base class and putting the getter/setter in the base class only one time. However, the drawback of that is you are not able to reference the values without instantiating an object (which essentially emulates what I find valuable with ENUMs).
How does a pattern like this appeal to you? I let the enum implement an interface and implement the interface in a Debug set and a Release set. The release set can then derive the property name from the enum name - which is neat.
public interface HasURL {
public String getURL();
}
public enum DebugEndPoints implements HasURL {
NA,
EU,
JP,
CN;
#Override
public String getURL() {
// Force debug to go to the same one always.
return "http://Debug.com/";
}
}
public enum NormalEndPoints implements HasURL {
NA,
EU,
JP,
CN;
final String url;
NormalEndPoints () {
// Grab the configured property connected to my name.
this.url = getProperty(this.name());
}
#Override
public String getURL() {
return url;
}
}