Timeline for Can access modifiers be completely replaced with programming to interfaces?
Current License: CC BY-SA 4.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 21, 2022 at 6:58 | comment | added | whatsisname | If subclassing is an antipattern to you then maybe you should avoid all OOP entirely. | |
| Oct 20, 2022 at 7:05 | comment | added | Steve | @GregBurghardt, interpreting things within the OP's terms, I assume there would be no facility to cast to a class, and no such thing as a "non-interface member". | |
| Oct 19, 2022 at 17:49 | answer | added | candied_orange | timeline score: 2 | |
| Oct 19, 2022 at 15:16 | comment | added | Doc Brown | @OndrejBozek: subclassing is not an antipattern - where did you get this nonsense from? Subclassing in cases where composition could be used sensibly instead is an antipattern. | |
| Oct 19, 2022 at 13:49 | answer | added | Greg Burghardt | timeline score: 3 | |
| Oct 19, 2022 at 13:40 | comment | added | Greg Burghardt | Don't forget that you can cast an interface to a concrete class, which would allow you to access non-interface members. I really need to stress the importance of @Caleth's comment about private being the most important access modifier. See data/information hiding and encapsulation. Casting an interface to a class allows you to circumvent data hiding and encapsulation, but access modifiers enforce this at the compiler level. | |
| Oct 19, 2022 at 11:40 | history | edited | Ondrej Bozek | CC BY-SA 4.0 | edited tags |
| Oct 19, 2022 at 11:23 | comment | added | Filip Milovanović | "Composition over inheritance" says to prefer composition, not to never do inheritance or consider subclassing an antipattern. Sure, subclassing shouldn't be overused as a way to model things (in the "if your only tool is a hammer, everything looks like a nail" fashion), but it can work in tandem with composition and interfaces. | |
| Oct 19, 2022 at 11:22 | comment | added | Laiv | From this point of view Access modifiers seems redundant and limited. Well, beneath the interface there's an implementation which might have several components working together, each of which with limited access to each the other. The alternative is interface implementations with hundreds LoC. So basically, most of the modifiers focus on keeping encapsulation within a boundary. Boundaries within boundaries. | |
| Oct 19, 2022 at 9:45 | comment | added | Caleth | But I suppose that anything not mentioned in an interface is implicitly private in your scheme | |
| Oct 19, 2022 at 9:43 | comment | added | Caleth | "The private access modifier seems especially contra-productive" private is the most important access modifier. You don't need to directly test private code. You test the reachable private code, as part of testing the public interface, and it's perfectly fine for any unreachable private code to have undefined behaviour. | |
| Oct 19, 2022 at 9:26 | comment | added | Ondrej Bozek | @Caleth good point but I would consider subclassing/class inheritance an antipattern. (en.wikipedia.org/wiki/Composition_over_inheritance) | |
| Oct 19, 2022 at 9:22 | history | edited | Ondrej Bozek | CC BY-SA 4.0 | added 7 characters in body |
| Oct 19, 2022 at 9:12 | comment | added | Caleth | You still need private, to be able to hide implementation details from things that subclass you, unless you remove subclassing. | |
| Oct 19, 2022 at 9:10 | comment | added | Steve | Problems can always be "handled in a different way". The alternative to access modifiers would be more overheads in terms of the explicit definition of more interfaces (and some system for controlling access to these). And the amount of overhead a company like (say) Microsoft is willing to bear in writing general-purpose software and APIs for the entire world, is different from the amount of overhead a business with one staff member will bear in making use of Microsoft's platform. | |
| Oct 19, 2022 at 9:06 | review | Close votes | |||
| Oct 24, 2022 at 3:08 | |||||
| Oct 19, 2022 at 9:02 | history | edited | Ondrej Bozek | CC BY-SA 4.0 | edited body |
| S Oct 19, 2022 at 8:50 | review | First questions | |||
| Oct 19, 2022 at 15:05 | |||||
| S Oct 19, 2022 at 8:50 | history | asked | Ondrej Bozek | CC BY-SA 4.0 |