3 ms·

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'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 layer). C++, if I remember correctly, had a lot of attributes you could assign to classes and types, to regulate access, but it's probably been around 20 years, since I've written C++.

ooterness 2y ago
AFAIK, the only C++ access specifiers are private, protected, and public. Hardly an "insane number".
- ChrisMarshallNY 2y ago
  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.
  - bluGill 2y ago
    The problem is these all assume you are not under attack. If you are an attacker you can ignore all that. The C++ ABI is known (not to be confused with defined!) on my systems, so if you have a pointer you can add an offset to find any private member and then modify it (even if const you can change it - though the code may not read the change). You can also call any private function from anywhere because how the function is name mangled can be figured out. These tricks are undefined behavior in the C++ standard, but they will work in any implementation if you know how your implementation works under the hood - they will not work on a different implementation, but you can make a different version for different implementations. The above tricks work for most languages, though the details are different for each.
mattgreenrocks 2y ago
I love how the comments are split along the lines of, "wait, some people don't do this?" and "this is a maintenance nightmare!" If you know, you know.
- ChrisMarshallNY 2y ago
  > this is a maintenance nightmare! Yeah, it's a pain to maintain, but it is damn secure.
  - mattgreenrocks 2y ago
    Assuming reasonable factoring, maintenance is only a problem when trying to seriously cheat the layers, eg your controller wants to modify the template engine’s internals for a single request. Better to just be honest about it by punching a hole in the abstraction that is appropriately named and using that.
    - ChrisMarshallNY 2y ago
      No cheating! For example, I stop creating SQL, after the first layer above the DB access layer. Everything above that, is a function-based abstraction, so there's no SQL, in most of the stack. Some layers are meant to introduce "replacement points," so you could swap out the SQL for a NoSQL solution, if you want. Most layers have a fair bit of validation and permission-checking, etc. But making sure that I stick to the rules for each layer can be a pain. I stick to them, anyway.
      - mattgreenrocks 2y ago
        Yes, this is the way. But I'm fine with short-term cheating when there's no other way because it sticks out a lot more: "wtf, why is the registration endpoint executing hand-written SQL but no other endpoint is?" The fact that it ends up looking conceptually ugly compared to everything else means it is harder to ignore, and people have to justify their sloppiness when getting it merged. > But making sure that I stick to the rules for each layer can be a pain. I stick to them, anyway. It can be. I've found you usually internalize the rules eventually and your mind naturally slots things where they need to go. Then you can aggressively add features/refactor because the surface area is much smaller. It's like learning to work with strong type systems versus fighting them.
marcosdumay 2y ago
> Layers, with each layer assigned a particular domain and API restriction Yeah, that's not a good way to do it. You can only keep adding layers if they are platonic. If they represent any real-world domain, they will interfere with each other, your abstraction will leak, and every change will require changing everywhere.
- ChrisMarshallNY 2y ago
  > Yeah, that's not a good way to do it. Works for me. I've been working this way for a lloooonnnnggg time. Of course, it requires strict Discipline, and does add complexity. If you stray outside the lines, you can make a fearful mess. I don't stray outside the lines, and it works great.

ooterness 2y ago

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

ChrisMarshallNY 2y ago
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.
- bluGill 2y ago
  The problem is these all assume you are not under attack. If you are an attacker you can ignore all that. The C++ ABI is known (not to be confused with defined!) on my systems, so if you have a pointer you can add an offset to find any private member and then modify it (even if const you can change it - though the code may not read the change). You can also call any private function from anywhere because how the function is name mangled can be figured out. These tricks are undefined behavior in the C++ standard, but they will work in any implementation if you know how your implementation works under the hood - they will not work on a different implementation, but you can make a different version for different implementations. The above tricks work for most languages, though the details are different for each.

mattgreenrocks 2y ago

I love how the comments are split along the lines of, "wait, some people don't do this?" and "this is a maintenance nightmare!" If you know, you know.

ChrisMarshallNY 2y ago
> this is a maintenance nightmare! Yeah, it's a pain to maintain, but it is damn secure.
- mattgreenrocks 2y ago
  Assuming reasonable factoring, maintenance is only a problem when trying to seriously cheat the layers, eg your controller wants to modify the template engine’s internals for a single request. Better to just be honest about it by punching a hole in the abstraction that is appropriately named and using that.
  - ChrisMarshallNY 2y ago
    No cheating! For example, I stop creating SQL, after the first layer above the DB access layer. Everything above that, is a function-based abstraction, so there's no SQL, in most of the stack. Some layers are meant to introduce "replacement points," so you could swap out the SQL for a NoSQL solution, if you want. Most layers have a fair bit of validation and permission-checking, etc. But making sure that I stick to the rules for each layer can be a pain. I stick to them, anyway.
    - mattgreenrocks 2y ago
      Yes, this is the way. But I'm fine with short-term cheating when there's no other way because it sticks out a lot more: "wtf, why is the registration endpoint executing hand-written SQL but no other endpoint is?" The fact that it ends up looking conceptually ugly compared to everything else means it is harder to ignore, and people have to justify their sloppiness when getting it merged. > But making sure that I stick to the rules for each layer can be a pain. I stick to them, anyway. It can be. I've found you usually internalize the rules eventually and your mind naturally slots things where they need to go. Then you can aggressively add features/refactor because the surface area is much smaller. It's like learning to work with strong type systems versus fighting them.

marcosdumay 2y ago

> Layers, with each layer assigned a particular domain and API restriction Yeah, that's not a good way to do it. You can only keep adding layers if they are platonic. If they represent any real-world domain, they will interfere with each other, your abstraction will leak, and every change will require changing everywhere.

ChrisMarshallNY 2y ago
> Yeah, that's not a good way to do it. Works for me. I've been working this way for a lloooonnnnggg time. Of course, it requires strict Discipline, and does add complexity. If you stray outside the lines, you can make a fearful mess. I don't stray outside the lines, and it works great.