Remove public methods from IdNumber that are not intended to be directly called

[asolntsev]

Describe the bug
It's rather a design issue, not a bug.
I don't like the fact that class net.datafaker.providers.base.IdNumber has all these public methods:

• validSvSeSsn()
• validEnZaSsn()
• inValidEnZaSsn()
• invalidSvSeSsn()
• validEsMXSsn()
• invalidEsMXSsn()
• validEstonianPersonalCode()
• invalidEstonianPersonalCode()
• validAlbanianPersonalCode()
• invalidAlbanianPersonalCode()
• validMoldovaPersonalCode()
• invalidMoldovaPersonalCode()
• validBulgarianPersonalCode()
• invalidBulgarianPersonalCode()

Problem 1:

I assume they are NOT intended to be explicitly called from client's code.
Instead, clients should generate corresponding ID numbers using locale/country:

  Faker faker = new Faker(new Locale("et", "EE"));
  String code = faker.idNumbers().valid();

Problem 2:

Having these methods as public makes it impossible to extend functionality of DataFaker. Like, when user adds a custom JAR to classpath that implements yet another language/country.

Expected behavior
It should be possible to add "yet another country" without adding any new public methods.
It should be enough just to add file "LANG.yml" and probably some (package-private) classes like BulgarianIdNumber.

Versions:

• Faker Version: 2.2.2

@bodiam @snuyanzin thoughts?

[kingthorin]

If that's the intent then I'm in agreement. I haven't been working on the project long enough to know.

[bodiam]

Makes sense. I don't think we have a super clear agreement about what is our public api vs our more internal. What would you propose to limit the visibility of these methods? Make them package protected? Or something else?

[asolntsev]

I think we don't need these methods at all.
What I suggest:

1. Remove public methods from IdNumber class:
   • public String validMacedonianPersonalCode()
   • public String invalidMacedonianPersonalCode()
   • etc.
2. Load all classes like MacedonianIdNumber as service providers (a built-in mechanism in Java). Every provider knows what country it's responsible for.

I can submit a minimal pull request to demonstrate this approach.

[snuyanzin]

yes that probably makes sense

why it was done in current way - probably nobody knows since it was done in javafaker first and those contributors are not active in both communities...

I can submit a minimal pull request to demonstrate this approach.

yes,go ahead

The only thing to note since they are public for a long time then first need to mark as deprecated and then remove later

[snuyanzin]

@asolntsev may be for future: I would suggest squashing commits while merging since it will simplify navigation through commits history
All the highlights could be done in commit message

[asolntsev]

@snuyanzin Thanks. Yes, in this case I should squash all commits.
But generally it's not always a good idea. Independent changes should stay in separate commits.

[snuyanzin]

yep, in generic case it depends on the context

[kingthorin]

For my two cents it's the overall contribution that matters to the project not the individual bits of work/correction. So I'm in favour of squash and merge or using amending commits.