Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Firewalling your code

lackofimagination.org

Post reply on HN
Print view View original

21–30 of 82 posts

Re: Firewalling your code

#21

Post by ChrisMarshallNY »

ooterness wrote: post #20
ChrisMarshallNY wrote: post #19

I've worked like this for decades. Layers, with each layer assigned a particular domain and API restriction (for example, I have a multi-layer backend, and, if I want to access the database directly, I need to implement that at the very lowest layer, and then set up a "tunnel" of access to the top-layer exposed API, through the intervening layers, applying whatever access control and filters are appropriate for each…

AFAIK, the only C++ access specifiers are private, protected, and public. Hardly an "insane number".

What about "friend"? Do they still have that?

But you have a point. It's a bit overblown, and I'll tamp down the rhetoric.

Re: Firewalling your code

#22

Post by xnorswap »

So now when you want to use a dependency, you have to update that dependency?

Isn't that a maintenance headache which doesn't really stop people doing that anyway?

I understand the desire for this, having long and messy dependency chains can completely grind large changes to a halt. I'm currently dealing with a .net solution of ~300 projects with a dependency tree that's better described as a dependency web.

But this feels like the wrong solution. Better isolation can be achieved by proper packaging and leveraging of private package repositories.

Re: Firewalling your code

#23

Post by tpetry »

eithed wrote: post #13

We're using similar approach in PHP application by facilitating https://github.com/spaze/phpstan-disallowed-calls In essence we have defined within each domain: a) Public folder with code that other domains can use b) domain folders (src and infra) with code that only given domain can use. This way developers know not to change public contracts for a (or if they do change them they do understand they're changing publ…

Letting a static analyzer do these checks is a sane approach! The runtime detection of code files is really weird and would fail with bundling etc.

Re: Firewalling your code

#24

Post by actionfromafar »

wokwokwok wrote: post #15

It’s probably over the top, although I respect the intent. The quickest way to destroy “velocity” is by introducing dependencies between implementation details with no barriers in code. The more constraints you have to satisfy when you make changes, the more effort it is to make the changes (provably); and thus, the more time it takes, destroying velocity. That said, doing this as described is probably overly dramati…

Do you mean that if the constraints are visible when you change the code, it's better? But "hidden" constraints which will manifest only under specific conditions under runtime are bad.

Re: Firewalling your code

#25

Post by eithed »

tpetry wrote: post #23
eithed wrote: post #13

We're using similar approach in PHP application by facilitating https://github.com/spaze/phpstan-disallowed-calls In essence we have defined within each domain: a) Public folder with code that other domains can use b) domain folders (src and infra) with code that only given domain can use. This way developers know not to change public contracts for a (or if they do change them they do understand they're changing publ…

Letting a static analyzer do these checks is a sane approach! The runtime detection of code files is really weird and would fail with bundling etc.

Yes :) but given that OP does the checks at runtime thought I'd give that disclaimer

Re: Firewalling your code

#26

Post by matsemann »

This is basically what java modules do, right? From java 9 and onwards.

You have public stuff within your module, that other packages in the module can use. But another module cannot use it without you declaring it as part of your actual public facing API. I don't see people use it much in application code, though. Often just a single module where people can call everything.

Re: Firewalling your code

#27

Post by breckenedge »

_cenw wrote: post #5

Always feels like you're in a dysfunctional place when you have to program this defensively. I had an acquaintance who was writing library code for a few dozen data engineers in python, and she had to resort to locking down private methods by checking the call stack after engineers repeatedly got hold of private objects, or objects that are only there sometimes (e.g. when not running clustered). I adopted a similar s…

Were these leaky abstractions built on top of other libs?

Re: Firewalling your code

#28

Post by renox »

HumblyTossed wrote: post #16

[flagged]

Except that any coding 'rule' not enforced by a tool is likely to be ignored once a team is big enough. We have such kind of checker at work, it is a good thing provided you can add (justified) exceptions

Re: Firewalling your code

#30

Post by mightybyte »

I think the general concept here is putting in place restrictions on what code can do in service of making software more reliable and maintainable. The analogy I like to use is construction. If buildings were built like software, you'd see things like a light switch in the penthouse accidentally flushing a toilet in the basement. Bugs like that don't typically happen in construction because the laws of physics impose serious limitations on how physical objects can interact with each other. The best tools I have found to create meaningful limitations on code are a modern strong static type system with type inference and pure functions...i.e. being able to delineate which functions have side effects and which don't. These two features combine nicely to allow you to create systems where the type system gives you fine-grained control over the type of side effects that you allow. It's really powerful and allows the enforcement of all kinds of useful code invariants.
Post reply on HN