4 ms·

In terms of readability and maintainability, one problem with OOP is the development process that tends to go with it, where you're asked to create upfront the

by hudon 4y ago

In terms of readability and maintainability, one problem with OOP is the development process that tends to go with it, where you're asked to create upfront the separation of concerns, before code has had a chance to run and breathe for a while. Most of the time, you end up being wrong on how things should be segregated, and your behavior ends up fragmented across a variety of objects, making it difficult to easily see the flow of your program. Actions related to a Widget end up not actually being neatly encapsulated in a Widget, and encapsulation is one of the major selling points of OOP. It's probably best to start off a solution with plain old data structures, and plain old functions (ie. procedural style). Build with that until right abstractions or separations emerge.

colordrops 4y ago
Also, within the context of an individual class, variables can be modified and accessed anywhere in the class, creating all the same problems as global variables.
- bostonsre 4y ago
  If the single responsibility principle is followed and cohesion is strong, it should help mitigate these concerns. Creating large uber classes can quickly become troublesome.
arinlen 4y ago
> Most of the time, you end up being wrong on how things should be segregated, and your behavior ends up fragmented across a variety of objects, making it difficult to easily see the flow of your program. This can only become a problem if you pay little to no attention to modularization, software architecture, and even encapsulation. The responsibility of a paradigm and a language is to allow a developer to freely express their concepts. The programming paradigm is not to blame if the developer chooses to express poorly thought-out ideas that are riddled with detrimental consequences.
- julienfr112 4y ago
  the problem is not about software development, it's about business logic that change, when a new client arrive and want new features, some feature where not usefull, other needed change ...
  - arinlen 4y ago
    > the problem is not about software development, it's about business logic that change, when a new client arrive and want new features, some feature where not usefull, other needed change ... You're giving the textbook example of problems created and solved by putting together a working software architecture. Books like Bob Martin's "Clean Architecture" refer explicitly to needs to accommodate changes to business and application layers, and the need to design components to accommodate changes, and the book is language-agnostic.
- hudon 4y ago
  I disagree. Consider the Brainfuck argument. You can totally blame Brainfuck and its “paradigm” for detrimental consequences. My point is it’s easier to modularize and encapsulate properly with procedural or functional paradigms because they don’t force you to do that work before you start solving problems. The dev flow is: solve problem, then modularize. With OOP, the flow is: modularize, then solve problem. I’m simplifying and of course you can architect correctly upfront, it’s just harder because you’re doing speculative generalization (akin to premature optimization).
  - arinlen 4y ago
    > I disagree. Consider the Brainfuck argument. You can totally blame Brainfuck and its “paradigm” for detrimental consequences. That's a poorly put-together red-herring. Brainfuck is not one of the leading production programming languages that has been used for decades to write all sorts of applications, from operating systems to web services and specially desktop applications, AAA games, and high-performance computing. Brainfuck is a gimmick "esoteric" programming language used as a challenge. > My point is it’s easier to modularize and encapsulate properly with procedural or functional paradigms because they don’t force you to do that work before you start solving problems. The thing is your point does not hold at all. It's trivial to modularize and encapsulate and even isolate components with C++. You only need to want to do it. If you don't want to modularize or encapsulate or isolate components then you get what you want. Don't blame the language for the software architecture you chose to adopt for your project.
alfiedotwtf 4y ago
This is the same reason why I think TDD is the wrong approach too. How do you test before you know what you're building? I've tried everything but my favored approach these days is just to stream of conscious psuedocode in main() to get the shape of what needs to happen, and then backfill until there's something working. Once I know what I want, only then do I break things up so that everything is in the right place. It seems to end well every time. tl;dr: bottom-up, and top-down are too extreme!
- thunky 4y ago
  > Once I know what I want, only then do I break things up so that everything is in the right place You could apply TDD at this point. Doesn't have to be before you write a single line of code.
  - alfiedotwtf 4y ago
    Yes, that would make sense... unfortunately companies I know that follow TDD religiously have taken the approach that tests drive design and development.

by hudon 4y ago

colordrops 4y ago

Also, within the context of an individual class, variables can be modified and accessed anywhere in the class, creating all the same problems as global variables.

bostonsre 4y ago
If the single responsibility principle is followed and cohesion is strong, it should help mitigate these concerns. Creating large uber classes can quickly become troublesome.

arinlen 4y ago

> Most of the time, you end up being wrong on how things should be segregated, and your behavior ends up fragmented across a variety of objects, making it difficult to easily see the flow of your program. This can only become a problem if you pay little to no attention to modularization, software architecture, and even encapsulation. The responsibility of a paradigm and a language is to allow a developer to freely express their concepts. The programming paradigm is not to blame if the developer chooses to express poorly thought-out ideas that are riddled with detrimental consequences.

julienfr112 4y ago
the problem is not about software development, it's about business logic that change, when a new client arrive and want new features, some feature where not usefull, other needed change ...
- arinlen 4y ago
  > the problem is not about software development, it's about business logic that change, when a new client arrive and want new features, some feature where not usefull, other needed change ... You're giving the textbook example of problems created and solved by putting together a working software architecture. Books like Bob Martin's "Clean Architecture" refer explicitly to needs to accommodate changes to business and application layers, and the need to design components to accommodate changes, and the book is language-agnostic.
hudon 4y ago
I disagree. Consider the Brainfuck argument. You can totally blame Brainfuck and its “paradigm” for detrimental consequences. My point is it’s easier to modularize and encapsulate properly with procedural or functional paradigms because they don’t force you to do that work before you start solving problems. The dev flow is: solve problem, then modularize. With OOP, the flow is: modularize, then solve problem. I’m simplifying and of course you can architect correctly upfront, it’s just harder because you’re doing speculative generalization (akin to premature optimization).
- arinlen 4y ago
  > I disagree. Consider the Brainfuck argument. You can totally blame Brainfuck and its “paradigm” for detrimental consequences. That's a poorly put-together red-herring. Brainfuck is not one of the leading production programming languages that has been used for decades to write all sorts of applications, from operating systems to web services and specially desktop applications, AAA games, and high-performance computing. Brainfuck is a gimmick "esoteric" programming language used as a challenge. > My point is it’s easier to modularize and encapsulate properly with procedural or functional paradigms because they don’t force you to do that work before you start solving problems. The thing is your point does not hold at all. It's trivial to modularize and encapsulate and even isolate components with C++. You only need to want to do it. If you don't want to modularize or encapsulate or isolate components then you get what you want. Don't blame the language for the software architecture you chose to adopt for your project.

alfiedotwtf 4y ago

This is the same reason why I think TDD is the wrong approach too. How do you test before you know what you're building? I've tried everything but my favored approach these days is just to stream of conscious psuedocode in main() to get the shape of what needs to happen, and then backfill until there's something working. Once I know what I want, only then do I break things up so that everything is in the right place. It seems to end well every time. tl;dr: bottom-up, and top-down are too extreme!

thunky 4y ago
> Once I know what I want, only then do I break things up so that everything is in the right place You could apply TDD at this point. Doesn't have to be before you write a single line of code.
- alfiedotwtf 4y ago
  Yes, that would make sense... unfortunately companies I know that follow TDD religiously have taken the approach that tests drive design and development.