3

This question already has an answer here:

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?

marked as duplicate by Telastyn, user40980, amon, Kilian Foth, Dynamic Mar 5 '14 at 21:12

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    @gnat I appreciate your comment, but that's not about DI at all. They're talking about the getter and setter methods. I think my question is a bit different or am I missing something there? – Mahdi Feb 28 '14 at 12:01
  • answers in dupe question (see also questions linked to it) explain that decoupling private properties via setters is a bad idea. I'd add that when this idea starts looking not so bad to you, it's likely time to consider Extract Class – gnat Feb 28 '14 at 12:09
  • 1
    This is not a duplicate and the linked question does not full address this question. – Martin Spamer Jun 20 '18 at 17:46
6

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...)

  • Well, even tho what you're saying sounds quite true, but I'm not yet really sure if that's the way to go or not. I might update the question to add a bit of extra info. I also appreciate your recommendation about getters and setters, however I'm not following you in this case. Encapsulation is a great tool, if you know how to deal with it, and of course your tools are just as smart as you are. – Mahdi Feb 28 '14 at 17:07
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.

  • Thanks, it was indeed helpful. SRP has been implemented very well, I just wanted to make sure that I'm not doing anything that might bite me back later on. – Mahdi Feb 28 '14 at 16:53
0

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.

  • Thanks for the answer, but unfortunately I didn't finally get what was your point. I really appreciate if you make it a bit cleaner. – Mahdi Feb 28 '14 at 16:58

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