4 ms·

I think we only need to count entities we need to keep in mind _simultaneously_. For example, a hypothetical File object can have dozens of methods, but to open

I think we only need to count entities we need to keep in mind _simultaneously_. For example, a hypothetical File object can have dozens of methods, but to open it I only need one: File.open("..."). Internally, File may contain a dozen of variables, all of which may be updated by this call. But I don't need to know about any of them due to encapsulation. If I did, I'd be unable to write this code. OOP (when done properly) enables us to focus at any time on a sub-part of the system containing five entities or less, so that we can understand that particular slice of the system. The slice can be very low-level (a private helper function of the smallest class), or very high-level (invoking a large subsystem through a facade interface, http://en.wikipedia.org/wiki/Facade_pattern http://en.wikipedia.org/wiki/Facade_pattern). A typical REST API would be a good example of the latter. I like benefits of the functional programming too, but I think functional and OOP work together rather than being in contradiction to each other.

grncdr 14y ago
> I like benefits of the functional programming too, but I think functional and OOP work together rather than being in contradiction to each other. Oh absolutely, I was responding to the statement of "all being lost" without OO more than making a serious argument for the opposite extreme ;)
- kalininalex 14y ago
  Ah, sorry, poor wording :) I meant to apply "all being lost" to encapsulation in general, not OOP specifically.
grannyg00se 14y ago
"OOP (when done properly) enables us to focus at any time on a sub-part of the system containing five entities or less" ... "I like benefits of the functional programming too, but ..." Your response makes it sound as though you believe OOP is the magic that allows encapsulation or modularization. Functional programming also enables us to focus at any time on a sub-part of the system. You don't need OOP for that. In fact, you don't even need functional programming for that. For example, you could get by with nothing more than subroutines and functions (whether they be first class or not).
- kalininalex 14y ago
  That's true, functions can work quite well for smaller apps, and/or apps specifically suited for that style. But there are many apps that have complex internal states. Subroutines and functions don't say anything about how to deal with it. This state ends up being global variables, which is a big issue. I once worked on a complex desktop app written with functions and global data. It was nearly impossible to modify it, or understand what it does. A click on a button could execute 1,000 lines of code modifying dozens of variables, resulting in effects throughout the application. Debugging a seemingly simple issue could take an inordinate amount of time. We had to re-factor the entire app into OOP and model-view design to stabilize it and move forward. The app had about 30,000 lines of code. So, based on this experience, I'd say it's too large for the functional style. When I start a new project I often don't know how large it'll get, so the safest approach is to default to OOP. If the functional approach will prove more appropriate down the road, it should be relatively easy to integrate functional design in those parts of the app where it's required.

grncdr 14y ago

> I like benefits of the functional programming too, but I think functional and OOP work together rather than being in contradiction to each other. Oh absolutely, I was responding to the statement of "all being lost" without OO more than making a serious argument for the opposite extreme ;)

kalininalex 14y ago
Ah, sorry, poor wording :) I meant to apply "all being lost" to encapsulation in general, not OOP specifically.

grannyg00se 14y ago

"OOP (when done properly) enables us to focus at any time on a sub-part of the system containing five entities or less" ... "I like benefits of the functional programming too, but ..." Your response makes it sound as though you believe OOP is the magic that allows encapsulation or modularization. Functional programming also enables us to focus at any time on a sub-part of the system. You don't need OOP for that. In fact, you don't even need functional programming for that. For example, you could get by with nothing more than subroutines and functions (whether they be first class or not).

kalininalex 14y ago
That's true, functions can work quite well for smaller apps, and/or apps specifically suited for that style. But there are many apps that have complex internal states. Subroutines and functions don't say anything about how to deal with it. This state ends up being global variables, which is a big issue. I once worked on a complex desktop app written with functions and global data. It was nearly impossible to modify it, or understand what it does. A click on a button could execute 1,000 lines of code modifying dozens of variables, resulting in effects throughout the application. Debugging a seemingly simple issue could take an inordinate amount of time. We had to re-factor the entire app into OOP and model-view design to stabilize it and move forward. The app had about 30,000 lines of code. So, based on this experience, I'd say it's too large for the functional style. When I start a new project I often don't know how large it'll get, so the safest approach is to default to OOP. If the functional approach will prove more appropriate down the road, it should be relatively easy to integrate functional design in those parts of the app where it's required.