0

So I don't know if this is a good approach or not:


class A {

    B b;

    A() {
        this.b = new B(this);
    }
}


class B {
    A a;

    //* Requires the A object as a parameter */
    B(A a) {
        this.a = a;
    }
}

The reason I did this is that the class B must hold the A object in order to operate (Think of the class A as a "holder" for class B)

However, this leads to many issue, I am not sure if this is an anti-pattern or not, but when I'm doing Unit Testing class A, it would be hard for me to mock or omit object B as there's no dependency injection.

I don't think I can implement the dependency injection pattern here as the B object NEEDS object A to operate, so passing it in as a parameters to the constructor would not work.

The only solution I have thought of is to make a setUp method, like so:

// In the A class
public void setUp(B b) {
    this.b = b;
}

This would successfully separate the testing and the actual application from themselves, while adhering to the dependency injection pattern. Though, I am not 100% sure with this approach.

I am just not sure if this approach is ideal or not.

Edit: The post that was linked to this "duplicate" one does not directly pertain to my problem. The one that was referenced got a StackOverflowError, while mine does not, furthermore, that post's constructor does not include any parameters.

To further clarify my existing issue: my A class is the ClientClass, and the B is the AccountController class. The AccountController handles all of the accounts of the CLIENT, and each client has one AccountController, it handles things such as logging in and out, account creation and deletion, and track the current account. Other classes reference the ClientClass object to also get the AccountController, I did this mainly for readability.

Shadow504
  • 33
  • 1
  • 5
  • @HovercraftFullOfEels I'd say the best approach is don't write classes like that in the first place. A and B both depending on each other is highly indicative of the wrong design. They are tightly coupled. – Michael Nov 15 '22 at 13:16
  • @Michael: I agree that one should always strive for a high level of cohesion and low level of coupling, but sometimes the design is not your choice, and you have to make do with what is given to you. – Hovercraft Full Of Eels Nov 15 '22 at 13:20
  • @Michael While I do want to achieve what you have stated, my current system relies heavily on the holder class A, and I don't think it is sensible to individually pass in the B object into other methods' parameters (There are many more objects like this, and the B object is just an example). Furthermore, the B object is a direct component of A, you can think of it as attaching a part to a bigger one (Somewhat similar to public inner class ? ). I don't know how to make the said classes loosely coupled, sadly. – Shadow504 Nov 15 '22 at 13:35
  • Shadow, pertinent to @Michael's comment, please see [this answer](https://stackoverflow.com/a/36909439/). – Hovercraft Full Of Eels Nov 15 '22 at 13:36
  • @Shadow504 "B object is a direct component of A". That's fine. That's just composition. A car has an engine. An engine doesn't also have a car. – Michael Nov 15 '22 at 13:42
  • Currently having a hard time as I see no way to handle this issue. To give a more in-depth context, the actual classes's are: Client (A), AccountController (B), so basically each clients should have multiple accounts, and the AccountController is there to handle those accounts. Now, other classes access the AccountController formally by a setter in the Client class, the AccountController is in a separate package (People said that this is a bad design). Merging is a huge no-no, inner classes may affect readability, and interfaces don't work as these classes have little to no relation – Shadow504 Nov 15 '22 at 14:21
  • @Shadow504 What is an "AccountController", and why does a Client have one (or more)? Shouldn't a `Client` (A) have multiple `Account`s (C)? – Michael Nov 15 '22 at 14:24
  • @Michael It is there to handle all of the accounts (Creation, Deletion, etc... ). Now that I think of it, it should probably be grouped into the same package as the client, as the AccountController is simply there to neatly control the accounts. But the issue still persists – Shadow504 Nov 15 '22 at 14:26
  • I still don't really understand the problem, but even if a client has multiple accounts, it obvious does not need ALL accounts, which AccountController is providing. AccountController (B) should have all Accounts (C). Client (A) should have N Accounts (C). Client should not have AccountController. – Michael Nov 15 '22 at 14:28

0 Answers0