Would this case be considered an OO problem?

Question

Hi!
Suppose that some developers and programmers, say programmers of the group A, created the following interfaces:
public interface BankInformation {
  int getYearOfConstruction();
  //and other methods related to bank
public interface CompanyInformation {
  double getCompanyPrice();
  //and other methods related to company
public interface GovernmentInformation {
  Date getBeginningDate();
  Date getEndDate();
  //and other methods related to government
/* and other kinds of useful interfaces... */And others, say programmers of the group B, created the following very useful class (for the group B):
public class Informations {
  private String usefulInformation;
  public void setRelevantInformations(BankInformation bi) {
    int i = bi.getYearOfConstruction();
    String something = null;
    //etc...
    //doing something based on BankInformation...
    usefulInformation = something;
  public void setRelevantInformations(CompanyInformation ci) {
    double d = ci.getCompanyPrice();
    String something = null;
    //etc...
    //doing something based on CompanyInformation...
    usefulInformation = something;
  public void setRelevantInformations(GovernmentInformation gi) {
    Date initialDate = gi.getBeginningDate();
    Date endDate = gi.getEndDate();
    String something = null;
    //etc...
    //doing something based on GovernmentInformation...
    usefulInformation = something;
  //and other useful methods...
}Now both group A and B are implementing those interfaces, without any kind of design problems untill now:
/* here, classes that implement the interfaces */
public class BankOfBostonInfo implements BankInformation {
  public int getYearOfConstruction() {
  //and other things...
public class SantanderInfo implements BankInformation {
  public int getYearOfConstruction() {
  //and other things...
public class McDonaldsInfo implements CompanyInformation {
  public double getCompanyPrice() {
  //and other things...
public class MicrosoftInfo implements CompanyInformation {
  public double getCompanyPrice() {
  //and other things...
public class GeorgeBushInfo implements GovernmentInformation {
  public Date getBeginningDate() {
  public Date getEndDate() {
  //and other things...
public class BillClintonInfo implements GovernmentInformation {
  public Date getBeginningDate() {
  public Date getEndDate() {
   //and other things...
/* and other kinds of useful classes... */The problem happens now: other group of programmers, say group C, develop a class that implements all those interfaces (why not?), like below:
class AdministrativeInformations implements BankInformation, GovernmentInformation, CompanyInformation {
  public int getYearOfConstruction() {
  public double getCompanyPrice() {
  public Date getBeginningDate() {
  public Date getEndDate() {
  //and other useful things...
}Since it makes sense for group C, why not implement all those interfaces at the same time?
But, unfortunatelly, group C do not know about the Informations class, created by group B. And one day, group B will say to group C: "Hey, give us an instance of your AdministrativeInformations class, we need it!".
Group B will have a problem now, because when they use setRelevantInformations() method, which is the parameter they have to pass? They cannot pass an instance of AdministrativeInformations class, and they cannot cast, because setRelevantInformations() method works according to the parameter passed. Certainly, they cannot specify and cast to BankInformation, GovernmentInformation or CompanyInformation, because they simply are not able to decide which type of interface they have to consider.
And if group B decide to discuss about this problem with group C, to solve that, group C won't be able to help, because group C will say "this is a problem of group B, only. It is not our problem". Or group C could rewrite their AdministrativeInformations class, but obviously they would not like this idea.
Might this situation be considered a design problem, that could have been prevented, or is this situation just an unlucky OO problem, that might occur and nothing can be done to prevent that? I would like to read your comments.
Many thanks!!!

Answer 1

I'm going to hazard an answer here and suggest the problem lies with the original design of the "Informations" class. As itchyscratchy pointed out, the problem lies within the fact that the setRelevantInformations method is overloaded and, as a result, assumes that being a BankInformation (for example) is mutually exclusive with being a CompanyInformation.
I find myself asking what precisely it is that the setRelevantInformations(...) methods are doing with that data and I would resolve this issue in one of two ways. The first is to simply rename the methods ("setBankInformation(...)", "setCompanyInformation(...)", etc.); this presumes that the operation which is being performed is unique to the Informations class and doesn't really directly have anything to do with the BankInformation, CompanyInformation, or GovernmentInformation interfaces. The structure of the Informations class as is implies that being a BankInformation is exclusive with being a CompanyInformation. Even if this is not the case, calling setBankInformation is definitely exclusive (at any instant, anyway) with calling setCompanyInformation.
The solution I would prefer, however, would rely on the operation being performed by each of the setRelevantInformations(...) methods having something quite directly to do with the objects themselves: that is, that the operation and the object are somehow conceptually linked. For example, they seem to be producing a string in this snippet. In that case, I would make:
public interface BaseInformation {
    public String makeInformationString();
public interface BankInformation extends BaseInformation {
    int getYearOfConstruction();
public interface CompanyInformation extends BaseInformation {and so on. Then, I would modify the Informations class:
public class Informations {
    private String usefulInformation;
    public void setRelevantInfomation(BaseInformation bi) { ... }
}Whatever operation the setRelevantInformations(...) methods were performing have now been abstracted into a single method. Once again, this eliminates the need for overloading. And, of course, this would only be appropriate if the operation being performed (in this case, "makeInformationString") is somehow related to the interfaces themselves and not just to the Informations class.
In summary, it seems that abuse of overloading is the problem. I can't quite put my finger on exactly how the overloading has been abused in this case, but that's probably due to a combination between lack of specific information and lack of sleep. :)
Cheers!