4

For example if I have a constant, like generated password size, then where should I put that constant if the random password generator is implemented in the infrastructure? I guess this should be a domain service, but I guess I cannot put the constant in the service interface. Or can I?

I ended up with this:

namespace Example\domain;

interface iRandomPasswordService {

    const RANDOM_PASSWORD_SIZE = 6;

    public function getPassword();

}

namespace Example\infrastructure;

use Example\domain\iRandomPasswordService;
use Example\domain\Password;
use JUserHelper;

class RandomPasswordService implements iRandomPasswordService {

    public function getPassword(){
        $randomPassword = JUserHelper::genRandomPassword(self::RANDOM_PASSWORD_SIZE);
        return new Password($randomPassword);
    }

}

I hate PHP and Joomla too, don't mention it. I am waiting for an approval or a better idea. :-)

  • 1
    Depends on your use case. Do all password generators share the same length settings? If so, placing the constant in the interface is completely fine. Is it only RandomPasswordService specific? Then it belongs to RandomPasswordService. Is it configurable? Maybe a configuration file is better. – Andy Feb 16 '17 at 13:03
  • @DavidPacker I don't really want to configure it. I just want to put into the domain, so if somebody is looking for it, then they can find it. Or if I replace the implementation I don't want to copy the size from the old implementation. I wouldn't say it is implementation specific, I want a 6 chars long password currently, 36^6 or 62^6 is more than enough security for this not so secure site. There are much easier ways to hack it than brute forcing these passwords, but its not my site, so I don't care much. – inf3rno Feb 16 '17 at 13:16
2

I think there are two acceptable places storing the length for generated passwords could occur at, which one is better depends on how much you control of password generation/authentication service and your actual app.

  1. Password length is sealed in the generation app itself because its really a concern for that service to manage that all password it creates are long enough to be secure.
  2. Desired password length is passed to the service by the app, and the app stores in in a constants/config file with other authentication/security related values. I wouldn't store this value on the interface because if it changes then you have to update the interface and everywhere that uses the interface.

I would prefer option 1 unless I couldn't modify the generation service itself because it keeps all user authentication concerns within the service you chose to manage them.

  • Actually the authentication is done by Joomla. I am just injecting a few (~300) new users with my code. I have only the names and ages, which is not much. – inf3rno Feb 16 '17 at 13:27
1

I do not believe that constants should be put in an interface. The purpose of an interface is to define what you must define in each implementation. I would put it in the service or whatever the implementing class is.

  • Then why is it possible to do so? :D – inf3rno Feb 16 '17 at 13:19
  • I found there is a constant interface antipattern en.wikipedia.org/wiki/Constant_interface but that is different from this. I can accept this if you elaborate your answer. – inf3rno Feb 16 '17 at 13:24
  • I opened a new question to decide this: stackoverflow.com/questions/42275609/… – inf3rno Feb 16 '17 at 13:41
  • 1
    "Then why is it possible to do so?" That is kind of another topic all together. Who knows why people who make languages allow us to do the things they allow us to do. There are reasons why it isn't a good practice though. And those are arguably more important than the intent of the language architect. – unflores Feb 16 '17 at 14:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.