4 ms·

> To clarify, I'm only talking about code in the same project that everyone has access to. I'm not talking about defining an API for other people to use that do

> To clarify, I'm only talking about code in the same project that everyone has access to. I'm not talking about defining an API for other people to use that don't have access to the code, like when you make a library. A lot of people are ignoring this part of the question. The primary usefulness of object-oriented programming is scope control. Dependencies kill teams, and scope control helps them survive. The more I limit the scope of something, the easier for someone else to understand it and make necessary changes. Imagine a language without scope control: When people try to understand how something works and what might break it, they have to consider all possible points of entry, which becomes every variable & function in your class. Java programmers often pitch fits about "getters" and "setters", insisting that every variable be private and guarded by a public method. In your context, you might find this to be kind of silly since we're mostly just moving scope control around instead of limiting it, but good luck fighting that battle (I'm not going to try). At any rate, I still would not use this kind of annoyance as an excuse to wave off scope control as nothing but bureaucratic boilerplate. It has real value when used pragmatically.

robalni 4y ago
> Dependencies kill teams Do you mean that when you have structured the organization so that each class is worked on by at most one team, you want to reduce the number of dependencies between classes in order to reduce the number of dependencies between teams? > they have to consider all possible points of entry So is this basically what I mentioned, that you want to reduce the number of places you have to look in when you want to find all uses of it?
- kerblang 4y ago
  To the first question: By "dependencies kill teams" I mean all the forms of dependencies: Database dependencies, web service dependencies, library dependencies, across teams, across organizations, and so on. Arguably internal dependencies inside a program are the least lethal. You are largely doing others the favor of implicit documentation by using scope control, a guaranteed statement of "This is never used outside this file". They might be able to figure as much out by grepping, remove & recompile, or IDE-based tools. "Greppability" is often part of the solution when dealing with database & http dependencies. As for the second question, basically, yes.

robalni 4y ago

> Dependencies kill teams Do you mean that when you have structured the organization so that each class is worked on by at most one team, you want to reduce the number of dependencies between classes in order to reduce the number of dependencies between teams? > they have to consider all possible points of entry So is this basically what I mentioned, that you want to reduce the number of places you have to look in when you want to find all uses of it?

kerblang 4y ago
To the first question: By "dependencies kill teams" I mean all the forms of dependencies: Database dependencies, web service dependencies, library dependencies, across teams, across organizations, and so on. Arguably internal dependencies inside a program are the least lethal. You are largely doing others the favor of implicit documentation by using scope control, a guaranteed statement of "This is never used outside this file". They might be able to figure as much out by grepping, remove & recompile, or IDE-based tools. "Greppability" is often part of the solution when dealing with database & http dependencies. As for the second question, basically, yes.