4 ms·

My experience shows that almost all GoF design patterns, except singleton, are not useful at all in writing modern C++ software. The singleton is really just a

My experience shows that almost all GoF design patterns, except singleton, are not useful at all in writing modern C++ software. The singleton is really just about a language trick, it hardly means anything more than a global variable fit into C++'s class hierarchy. I've been writing C++ in the past 1.5 years. All I have saw is design patterns being used forcefully and awkwardly. And there has not been a single instance where a pattern is used and improves the overall quality. Such practices result into closely coupled class webs, which is hostile to testing, extremely difficult to understand and change; the worst, they easily causes circular dependency, which was once considered a norm in C++ code. They also result into overengineerred interfaces, which gradually morphed into a "DoEverything" interface, like DoEverything(ActionOptions, RuntimeEnvironment). ActionOptions literally captures every options you can have on anything; and RuntimeEnvironment includes all data for the action to happen. IMHO, C++ code is about as good as it can be, when it manages to achieve 2 things: 1. DAG in translation unit dependency. 2. Predominantly prefer composition to inheritance. Plus, class access control (private/protected), and anonymous namespace should not be used to hide your implementation. That makes writing tests way too troublesome. And TBH, no one wants to abuse implementation details, unless the interface is bad or no comprehensive tests.

novembermike 10y ago
I never really got the whole public/private thing. If you want to only expose certain functionalities, that's what the interface does. Making things private just hides things that are potentially nice hooks for testing or whatever.
- khedoros1 10y ago
  The assumption is that your public members are your interface. Anything private is an internal implementation detail, possibly subject to future change or replacement. Thorough testing of the public methods should end up calling all of the private methods. Of course, that's a best case scenario. In C++ at least, it'd be an option to make a testing class that's a friend of the class it tests. Then you could test the private members individually.
  - justicezyx 10y ago
    I think almost all modern languages end up with granting (unit) testing code free access to everything. The idea of testing only the public interface is about an unique snow flake only meaningful in C++ design, and was never a viable practice at all. Otherwise, I'd say at least one other language follow the similar approach...
    - khedoros1 10y ago
      Are you just complaining about a lack of introspection to get around access controls? Friend classes are better for encapsulation than introspection is.
- zvrba 10y ago
  > I never really got the whole public/private thing. It's about encapsulation and class invariants. Public methods must preserve them, private methods can break them temporarily. You get a prepackaged component and you're prevented from introducing bugs into the component from the outside of the component. Take std::vector, for example. By keeping implementation details (pointer to element storage and element count) private, you prevent users of the class to accidentally shoot themselves in the foot by, say, changing the element count directly. You could use interfaces, but for that you have to use virtual functions: Objects have to be created dynamically and you have to handle pointers or references instead of values.
  - novembermike 10y ago
    I understand what it's used for, i just feel like there's a more elegant way to do it.
closeparen 10y ago
>They also result into overengineerred interfaces, which gradually morphed into a "DoEverything" interface, like DoEverything(ActionOptions, RuntimeEnvironment). ActionOptions literally captures every options you can have on anything; and RuntimeEnvironment includes all data for the action to happen. Also known as a function on the IO monad. The people who were writing that might have a good time with Haskell.

novembermike 10y ago

I never really got the whole public/private thing. If you want to only expose certain functionalities, that's what the interface does. Making things private just hides things that are potentially nice hooks for testing or whatever.

khedoros1 10y ago
The assumption is that your public members are your interface. Anything private is an internal implementation detail, possibly subject to future change or replacement. Thorough testing of the public methods should end up calling all of the private methods. Of course, that's a best case scenario. In C++ at least, it'd be an option to make a testing class that's a friend of the class it tests. Then you could test the private members individually.
- justicezyx 10y ago
  I think almost all modern languages end up with granting (unit) testing code free access to everything. The idea of testing only the public interface is about an unique snow flake only meaningful in C++ design, and was never a viable practice at all. Otherwise, I'd say at least one other language follow the similar approach...
  - khedoros1 10y ago
    Are you just complaining about a lack of introspection to get around access controls? Friend classes are better for encapsulation than introspection is.
zvrba 10y ago
> I never really got the whole public/private thing. It's about encapsulation and class invariants. Public methods must preserve them, private methods can break them temporarily. You get a prepackaged component and you're prevented from introducing bugs into the component from the outside of the component. Take std::vector, for example. By keeping implementation details (pointer to element storage and element count) private, you prevent users of the class to accidentally shoot themselves in the foot by, say, changing the element count directly. You could use interfaces, but for that you have to use virtual functions: Objects have to be created dynamically and you have to handle pointers or references instead of values.
- novembermike 10y ago
  I understand what it's used for, i just feel like there's a more elegant way to do it.

closeparen 10y ago

>They also result into overengineerred interfaces, which gradually morphed into a "DoEverything" interface, like DoEverything(ActionOptions, RuntimeEnvironment). ActionOptions literally captures every options you can have on anything; and RuntimeEnvironment includes all data for the action to happen. Also known as a function on the IO monad. The people who were writing that might have a good time with Haskell.