0

I don't know if this question belongs here or softwareengineering.stackexchange. I have a service named car:

public interface CarSerivce{ Car create(String model);}

Now I want to have two capabilities, create and create random. Creating a random car does not need a model and the service should select one available random model. So effectively this could be the implementations:

@Service
public class CarServiceImpl implements CarService{
    public Car create(String name){...}
}

//This one cannot implement the interface
@Service
public class RandomCarServiceImpl{ public Car create(){...}}

One solution is to externalize creating a random name by the class that uses the service and passing it to the service. But it is not an option because this example is contrived and the real one needs a rather sophisticated random generation algorithm for many parameters, not just one. My second idea is to have one implementation with two methods, create(String name) and createRandom() (or just an overloaded create with no parameter). This works fine and this way I can put all creation codes inside create method and call it from createRandom method. Since it is about selecting the strategy (just like strategy design pattern) I was wondering if there is a better solution to this.

Hessam
  • 1,377
  • 1
  • 23
  • 45
  • So effectively this could be the implementations: -> no, it couldn't, since this doesn't implement the method from the interface in your Random.. service. Since it doesn't, don't let it implement the interface. – Stultuske Apr 06 '21 at 06:26
  • @Stultuske oops you are right. I edited the question – Hessam Apr 06 '21 at 06:31
  • look at it this way, you will have your class "implement a method", meaning: force it to provide the functionality described in the interface. Then, you don't provide that functionality ... There is not really any (good) use to implement it, is there? – Stultuske Apr 06 '21 at 06:37
  • Who would you want to select the strategy here? If it is the client then providing different services would be the way to go (the client needs to know about the strategies). If the server should select the strategy then you basically need a client-facing API that looks the same for all strategies. – Thomas Apr 06 '21 at 06:39
  • @Stultuske you are right again. Maybe I should think of separating services or a service that provides both functionalities. – Hessam Apr 06 '21 at 06:47
  • @Thomas Client and server are internally managed but you are right. In the second scenario, I could consider passing "random" as the client needs a random car which is pretty ugly in my opinion. The first scenario that the client is strategy aware is probably the way I should go. It comes down to either having two separate services or one service with both functionalities. – Hessam Apr 06 '21 at 06:51
  • 1
    If the client should be aware of the strategies then yes, you could use 2 separate services or one that does both. Which you select depends on other factors as well, e.g. how much shared code there is (could be externalized though), whether other clients should only be able to see one set of functionality etc. As an alternative you could also think about a single service that gets a strategy passed as a parameter (i.e. an object that contains logic as well and which is selected and initialized by the client) but that might not fit your needs. – Thomas Apr 06 '21 at 07:14
  • @Thomas Thanks, that's a thorough explanation – Hessam Apr 06 '21 at 07:29

0 Answers0