3 ms·

> In the attempt to make this move, the first step will be to find all the places in the code-base that make use of this public property and fix those so that t

by bootsz 8y ago

> In the attempt to make this move, the first step will be to find all the places in the code-base that make use of this public property and fix those so that they don’t do this anymore. If the tooling around the project is amazing, there will be some static code analysis to use; but most will end up having to grep the entire code-base Isn't "find all usages" a pretty basic feature in modern IDEs? If you're working in a single self-contained codebase this really isn't very hard to do. IMO a lot of the teaching around best practices in OO programming doesnt differentiate enough between things that matter in authoring libraries versus self-contained proprietary code. When everyone is committing to the same repo certain types of encapsulation and abstraction aren't always as critical as they're made out to be.

Jtsummers 8y ago
> When everyone is committing to the same repo certain types of encapsulation and abstraction aren't always as critical as they're made out to be. Until you want to refactor or reuse. We develop a lot of in-house tools for our rather esoteric systems and systems analysis. We start by writing specific solutions, then refactor as we find common elements across tools. Now we have several libraries that can be used by anyone to develop custom solutions to problems because we've factored out common elements into those libraries. Treating encapsulation and abstraction like they're unimportant would've resulted in a lot of extra work over the years.
- bootsz 8y ago
  It's definitely important. My point is simply questioning whether it's really critical to always get it right from day one. Certain types of refactoring like public -> private really aren't always that hard in a closed system. I've done it many times with a few clicks in my IDE. Of course the difficulty depends on the nature of the change and the type of abstraction you need modify; but to me the difference between public and private is pretty low on the list of things that create big headaches. Especially in Java where unless you're using immutable objects everywhere, hiding something behind a getter that performs no additional logic is often useless.
stcredzero 8y ago
> Isn't "find all usages" a pretty basic feature in modern IDEs? If you're working in a single self-contained codebase this really isn't very hard to do. Not all "find all usages" are created equal. Here, the language is very significant. In languages where there is more than one way to use something, this becomes more complicated, with more corner cases to keep in mind. In languages where there is only one way to do something, this is less complicated. > IMO a lot of the teaching around best practices in OO programming doesnt differentiate enough between things that matter in authoring libraries versus self-contained proprietary code. When everyone is committing to the same repo certain types of encapsulation and abstraction aren't always as critical as they're made out to be. This isn't a matter of library/proprietary code. This is a matter of scale.

by bootsz 8y ago

Jtsummers 8y ago

> When everyone is committing to the same repo certain types of encapsulation and abstraction aren't always as critical as they're made out to be. Until you want to refactor or reuse. We develop a lot of in-house tools for our rather esoteric systems and systems analysis. We start by writing specific solutions, then refactor as we find common elements across tools. Now we have several libraries that can be used by anyone to develop custom solutions to problems because we've factored out common elements into those libraries. Treating encapsulation and abstraction like they're unimportant would've resulted in a lot of extra work over the years.

bootsz 8y ago
It's definitely important. My point is simply questioning whether it's really critical to always get it right from day one. Certain types of refactoring like public -> private really aren't always that hard in a closed system. I've done it many times with a few clicks in my IDE. Of course the difficulty depends on the nature of the change and the type of abstraction you need modify; but to me the difference between public and private is pretty low on the list of things that create big headaches. Especially in Java where unless you're using immutable objects everywhere, hiding something behind a getter that performs no additional logic is often useless.

stcredzero 8y ago

> Isn't "find all usages" a pretty basic feature in modern IDEs? If you're working in a single self-contained codebase this really isn't very hard to do. Not all "find all usages" are created equal. Here, the language is very significant. In languages where there is more than one way to use something, this becomes more complicated, with more corner cases to keep in mind. In languages where there is only one way to do something, this is less complicated. > IMO a lot of the teaching around best practices in OO programming doesnt differentiate enough between things that matter in authoring libraries versus self-contained proprietary code. When everyone is committing to the same repo certain types of encapsulation and abstraction aren't always as critical as they're made out to be. This isn't a matter of library/proprietary code. This is a matter of scale.