re: Why Java Interfaces Are Terrible VIEW POST

re: That would be duck typing, which describes Go's type system but not Java's. This is why I should read more about language fundamentals. : ) And ...

I'm actually not sure if dual constructors would be the best course of action for what you're trying to do (unless I'm severely misinterpreting either of you two). I would personally either just use a mocking framework to automatically make a generic mock class that implements AmazonDynamoDB (which is similar to what you were attempting to do, OR just make a mock class yourself that implements it, and use your IDE or a lot of copy/pasting to basically implement all the methods you don't care about as stubs (i.e. "return null").

Dual constructors basically means: have a constructor that takes the real AmazonDynamoDB, and a constructor that takes the fake one. But then you have to basically implement code in the class you're testing, that reacts differently to whether you're using the real or fake one, and that kinda spits in the face of both polymorphism and mocking.

@forstmeier this is also good advice, look into mock frameworks like Mockito. I don't know if there's anything more current.

My thoughts exactly with the dual constructors when I realized I couldn't set the inputs of the constructors to the same attribute within the class; creating "test vs prod" switches raises red flags for me.

You can set them to the same attribute if they both inherit from/implement that attribute. For example, you could make your attribute an AmazonDynamoDB, and have a constructor that takes the real one, and a constructor that takes the fake one, and have them both set the same attribute to what they're given.

HOWEVER, this is more or less useless, because you could just make your constructor take an AmazonDynamoDB as well, and pass either type into that constructor.

code of conduct - report abuse