Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

OOp

Name: Anonymous 2010-08-26 13:18

So I'm trying to learn OOp. I learned about all the features (inheritance, polymorphism and so on). I have two simple questions:

When is it advisable to instantiate objects instead of just using static methods? I always seem to diverge to imperative programming using only very few OOp features.

Don't OOp programs need a lot more of memory and processing power?

Thanks!

Name: Anonymous 2010-08-27 7:14

>>1
Don't OOp programs need a lot more of memory and processing power?
The short answer is no. OOP is merely one form of abstraction. When you delegate processing to distinct entities and allow them to determine how the processing is done, your software scales far better because experts can find increasingly better ways to handle data in general.

The best de-facto example are the std::sort, std::stable_sort, std::shuffle, etc. All they do is efficiently iterate and replace the data in the proper order. They use the most efficient algorithms available to do this. You can define your own custom comparison as well. These will generally perform just as well or better than any custom sort you could write on your own and they don't care what types they're sorting.

Supposing some expert found a way to parallelize it - for the sake of example, we'll suppose he finds a way to make it run on n machines - he could modify the sort backend and suddenly, every program that used that sort would be far better.

That's the goal of abstraction: To allow experts to find the optimal solution. OOP is merely one way of attempting abstraction: You can give these functions an object that derives from whatever, or implements whatever interface.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List