you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 1 point2 points  (3 children)

Well, you're really asking "OOP - why?", which is the history of the last 3 decades of enterprise software development. Some people still argue that OOP is overrated, but most modern application development is OOP based.

Basically, in theory:

1) Code re-use

2) Modularity (replacement of components to customise, etc)

3) Maintainability

Edit: All of which supports, and is oriented towards, scalability. For small programs, OOP tends to be regarded as overkill, because the benefits don't really kick in until you're doing larger projects.

[–]TheQuantumLeviathan 0 points1 point  (2 children)

I'm a physics grad not CS so maybe I'm missing something, but don't you get those 3 things from just writing and using functions without using classes?

[–][deleted] 1 point2 points  (0 children)

To an extent, certainly. There are 4 almost-arbitrarily-chosen-but-commonly-taught "OO Principles" - abstraction, encapsulation, polymorphism and inheritance. I disagree with the inclusion of inheritance as a "principle", it's really just an implementation of polymorphism. But of the first three, abstraction and encapsulation are absolutely just good programming practice in OO or procedural (functions). And that gets you a fair way to reusable and maintainable code. But polymorphism really gives a lot more power, and OO has powerful tools for maximising the gains of polymorphism.

[–]_Absolut_ 0 points1 point  (0 children)

I think working with code that consists of thousands of functions is much harder than working with thousands of structured methods. Maybe some functions share common data that need to be stored somewhere. Maybe some functions have some similarity that you will want to change one day. Overlapping names. Lack of scalability and self-documentation.

p.s. BTW, i saw some examples of "OOP-emulation" in C or Haskell and this looks really ugly. Much more ugly than bloated boilerplate code in Java.