2

Suppose I have a member function void A::foo(B const &b) where a class B instance is just a bunch of data. Would it not be better to remove the dependency between class A and class B by rewriting the member function like void A::foo(int var1, double var2, double var3)? Or could this modification be classified as a Primitive Obsession?

Martin Maat
  • 18,218
  • 3
  • 30
  • 57
  • Wether a class or method depends on a primitive type or a custom value type, it still has the same number of dependencies. Replacing custom value types with primitives is a step in the wrong direction and definitely an example of primitive obsession. – Rik D Jul 30 '22 at 09:52
  • 1
    this is a pattern, and one of the good ones. see this question: https://softwareengineering.stackexchange.com/questions/318226/should-we-avoid-custom-objects-as-parameters – devnull Jul 30 '22 at 12:30

2 Answers2

3

It depends on which way the dependency goes. You do not want some library to depend on types in your application, this would defeat the purpose of having a library. But as long as the richer type's definition is in the library itself, this would just be regarded as strong typing, which is a good thing.

Martin Maat
  • 18,218
  • 3
  • 30
  • 57
  • Good point! What would be your recommendations if both class A and class B are not library types but application types? – maksim_volodin Jul 30 '22 at 10:50
  • 1
    As long as they are in the same module there is no issue. If not, you would have to ask yourself whether it is OK for module A to depend on module B or not. You may want to introduce module C that serves both A and B so A and B can stay independent of each other. Or you may want to keep everything in the same module. It all depends on what purpose you have in mind for each module. – Martin Maat Jul 30 '22 at 11:11
1

Use a type like a struct if it is already available, and it matches the logic of the parameters. You wouldn’t use a random unrelated struct containing an Int and a double to replace two parameters.

gnasher729
  • 42,090
  • 4
  • 59
  • 119