4 ms·

Can we acknowledge yet that the concept of classes as tiny programs with tiny APIs and private implementations has failed? Admittedly, my opinion is mainly bas

Can we acknowledge yet that the concept of classes as tiny programs with tiny APIs and private implementations has failed? Admittedly, my opinion is mainly based around working mostly in C++, but every codebase I work in of significant age is a knitted castle of interlocking classes with poorly thought out accessors and private variables. While the vision of carefully encapsulating implementation details is nice, in practice the discipline required to do so seems unachievable. Instead of using private members, if I want an interface I explicitly make an abstract base class interface and inherit from it. This has two advantages: (1) unit tests are simpler when I can poke/prod the concrete internals because they're public. (2) I can make an "include" directory with the interfaces in it when I want to distribute a shared library and those interfaces will be more concise and less likely to leak all sorts of implementation details in the headers.

lamontcg 4y ago
> Can we acknowledge yet that the concept of classes as tiny programs with tiny APIs and private implementations has failed? I lived the past 10 years in a ruby codebase where since effectively everything was public, we didn't mark enough stuff private and you can always YOLO monkeypatch or call things with `send(:method)` there was zero effective encapsulation. And that pretty much crippled the product because now everything could be a public API so you can't change some shitty little helper to clean the code up somewhere because someone might have written code against that, in their private codebase that you have no visibility at all into. Every change becomes a potentially breaking change, because you have no idea how someone else's codebase might or might have fucked you by digging into your codebase. Rejecting encapsulation is literally the dumbest post-OO take, and I have the scars to prove it. Good fences make good neighbors and all that.
300bps 4y ago
Can we acknowledge yet that the concept of classes as tiny programs with tiny APIs has failed? [...] mainly based around working mostly in C++ Speaking as a C# developer, I think the concept of classes as tiny programs with tiny APIs works very well.
- CoolGuySteve 4y ago
  It's been a decade since I used C# but the corporate design pattern culture of that language back then turned me off of it forever. Everything looked like this: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... Maybe it's better now but the Java/C# practice of shoveling largely empty classes around with an IDE isn't something I'd point to as a good example.
  - Jtsummers 4y ago
    I've worked with C# off and on for over a decade, and never encountered anything close to that. Maybe the trick was that I was working with competent people. Now the Fortran code I've encountered, that's the stuff of nightmares (to be fair to Fortran I've also encountered good code, but there seems to be a generation of embedded developers who have no formal programming training that all adopted a style of Fortran inspired by Cthulhu).
  - schmookeeg 4y ago
    Wow, what a repo. I can't even tell if the author is serious or this is some tinderbox-dry satire, bravo either way. I'm sad that I've worked with plenty of codebases that look exactly like that and I twitched a little bit browsing around. :)
    - jacquesm 4y ago
      You can see the exact equivalent in the Java world.
    - bathtub365 4y ago
      From the readme: > Although this project is intended as satire, we take openness and inclusivity very seriously. To that end we have adopted the following code of conduct.
  - 300bps 4y ago
    It's been a decade since I used C# Well the last time I regularly used C++ was Borland C++ 3.1 from 1992. I'm not sure you'd be interested in my opinions on the language from 30 years ago.
jacquesm 4y ago
No. I think that compared to the giant hairballs of absolutely unmanageable spaghetti classes when done right have made larger scale projects tractable to mere mortals and have significantly improved software maintenance. Classes done wrong (hundreds or even thousands of classes that all do almost nothing) are a terrible anti-pattern and should be avoided. The exact same thing goes for services. And in fact for any tool used in a really bad way.
polotics 4y ago
Sad to see this earnest post down-voted. Maybe you had to be more precise about the poor thought out nature of what you saw. In my experience you are right, in as much as developers whose notions of design only go so far as creating many small classes do not think enough about design...
kaba0 4y ago
No, it didn’t fail. People are just bad at architecturing their programs and/or there is not enough time for technical debt. While not much difference in C++ specifically, but having a distinction between a class that encapsulates state and a record/struct that is nothing but plain old data is essential in my opinion. Both are useful for different problems.

lamontcg 4y ago

> Can we acknowledge yet that the concept of classes as tiny programs with tiny APIs and private implementations has failed? I lived the past 10 years in a ruby codebase where since effectively everything was public, we didn't mark enough stuff private and you can always YOLO monkeypatch or call things with `send(:method)` there was zero effective encapsulation. And that pretty much crippled the product because now everything could be a public API so you can't change some shitty little helper to clean the code up somewhere because someone might have written code against that, in their private codebase that you have no visibility at all into. Every change becomes a potentially breaking change, because you have no idea how someone else's codebase might or might have fucked you by digging into your codebase. Rejecting encapsulation is literally the dumbest post-OO take, and I have the scars to prove it. Good fences make good neighbors and all that.

300bps 4y ago

Can we acknowledge yet that the concept of classes as tiny programs with tiny APIs has failed? [...] mainly based around working mostly in C++ Speaking as a C# developer, I think the concept of classes as tiny programs with tiny APIs works very well.

CoolGuySteve 4y ago
It's been a decade since I used C# but the corporate design pattern culture of that language back then turned me off of it forever. Everything looked like this: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... Maybe it's better now but the Java/C# practice of shoveling largely empty classes around with an IDE isn't something I'd point to as a good example.
- Jtsummers 4y ago
  I've worked with C# off and on for over a decade, and never encountered anything close to that. Maybe the trick was that I was working with competent people. Now the Fortran code I've encountered, that's the stuff of nightmares (to be fair to Fortran I've also encountered good code, but there seems to be a generation of embedded developers who have no formal programming training that all adopted a style of Fortran inspired by Cthulhu).
- schmookeeg 4y ago
  Wow, what a repo. I can't even tell if the author is serious or this is some tinderbox-dry satire, bravo either way. I'm sad that I've worked with plenty of codebases that look exactly like that and I twitched a little bit browsing around. :)
  - jacquesm 4y ago
    You can see the exact equivalent in the Java world.
  - bathtub365 4y ago
    From the readme: > Although this project is intended as satire, we take openness and inclusivity very seriously. To that end we have adopted the following code of conduct.
- 300bps 4y ago
  It's been a decade since I used C# Well the last time I regularly used C++ was Borland C++ 3.1 from 1992. I'm not sure you'd be interested in my opinions on the language from 30 years ago.

jacquesm 4y ago

No. I think that compared to the giant hairballs of absolutely unmanageable spaghetti classes when done right have made larger scale projects tractable to mere mortals and have significantly improved software maintenance. Classes done wrong (hundreds or even thousands of classes that all do almost nothing) are a terrible anti-pattern and should be avoided. The exact same thing goes for services. And in fact for any tool used in a really bad way.

polotics 4y ago

Sad to see this earnest post down-voted. Maybe you had to be more precise about the poor thought out nature of what you saw. In my experience you are right, in as much as developers whose notions of design only go so far as creating many small classes do not think enough about design...

kaba0 4y ago

No, it didn’t fail. People are just bad at architecturing their programs and/or there is not enough time for technical debt. While not much difference in C++ specifically, but having a distinction between a class that encapsulates state and a record/struct that is nothing but plain old data is essential in my opinion. Both are useful for different problems.