Should I consider loosely-coupling for class methods as well? [duplicate]

Question

I'm a fan of Dependency Injection, however I don't know how much both public and private methods inside a class should be loosely-coupled.

Just to picture it better, when I have both projectId and userId as private properties in my class, and both of them have their own decent setter methods which will do the input validation also -- throwing an error in case of unexpected input, then isn't it better that all the class' methods relies on these properties instead of getting them via method arguments' and repeat the whole validation, etc. again?

In this case the methods will tightly-bind to the class itself -- and probably the constructor as well, but the advantage is that all the methods can easily rely on the setter methods and they will always assume also that the proper data is always available for me to process -- because the setter should have thrown an exception otherwise.

This seems quite helpful to me and I can make all the classes and libraries loosely-coupled in a way they don't depend to each other, however my question is, can a method inside a class be dependent on the class properties itself or not? Is it considered as a bad-practice?

Answer 1

If the methods of a class cannot depend on the variables of that class then who can? If all of your methods were completely decoupled from all other methods and variables, then all classes involved would be stateless and all methods might as well be static.

Of course there are always trade-offs when it comes to design, but I think it simply comes down to the idea of cohesion -- if your private properties increase the cohesion within the class (and if they are indeed always valid and ready to be consumed at all times), then yes, by all means use them, otherwise get rid of them.

(Whether or not you actually want to be using setters is another question entirely...)

Answer 2

can a method inside a class be dependent on the class properties itself or not? Is it considered as a bad-practice?

No, this is not bad practice. It is OK inside of a class to depend on common private methods and fields. This is just good Encapsulation. The class is the a structure that allows information hiding from the rest of the application components (other classes).

Loose Coupling usually refers to protecting classes from each others internal state.

I'll also add, that if this concerns you, then most likely, the class is doing too much. Following the Single Responsibility Principle (SRP) classes will naturally achieve high-cohesion and it won't smell like you have a lot of cross-dependency in a single class.

Hope this helps.

Answer 3

Design of Virtual Classes Many of the classes I have developed have ended up being non-final. By this, I mean that I included all of the functionality in the class that I originally intended but circumstances made it to my benefit to allow extending the class.

1) Lazy evaluation. If you use the getter method for an aggregate, then the values can be imported or calculated at the time they are needed and not before. This is often important for expensive queries, such as database operations.

2) Testability. One class I designed had some expensive operations wired into it. Since I was testing the control paths in one group of tests, I was able to subclass the class-under-test and tweak some parameters (1 pass instead of 400 passes) to make the tests less onerous.