4 ms·
> defining modules based on a flowchart, instead of modules that hide design decisions ok - "modules that hide design decisions" implies OOP. In thirty years,
by mistrial9 2y ago
> defining modules based on a flowchart, instead of modules that hide design decisions
ok - "modules that hide design decisions" implies OOP. In thirty years, OOP got applied to build giant systems, some that went too far. There has been backlash against OOP for real reasons, perhaps also ignorant reasons too.
Flowchart coding is straight from "structured programming" an advance from the single line of execution ASM style that sometimes created unintuitive and needlessly-complicated execution flow. IMHO there is nothing wrong with structured programming, or actually OOP when used appropriately.
- whstl 2y ago> ok - "modules that hide design decisions" implies OOP It doesn't. Implementation/design decision hiding also exists in procedural, functional and in other paradigms.
- mistrial9 2y agoI didn't say "it demands OOP" I said "implies OOP" .. what you say is true also
- rramadass 2y ago> "modules that hide design decisions" implies OOP. No; it is the other way around. OOD/OOP implies information hiding/encapsulation.
- augustk 2y agoNo, "modules that hide design decisions" implies modular programming. I think schools should teach modular programming before object-oriented programming. Then this confusion wouldn't arise so often. For a small modular programming language (which also supports OOP), have a look at Oberon: https://www.miasap.se/obnc/oberon-report.html https://www.miasap.se/obnc/oberon-report.html
- jimbob45 2y agoAs a hammer to be used on every single problem, OOP is unbearable. As a tool used when appropriate, OOP is delightful and I get very mad when languages think that they are above implementing it.