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?
Don't OOp programs need a lot more of memory and processing power?
Yes
Name:
Anonymous2010-08-26 14:08
When is it advisable to instantiate objects instead of just using static methods?
An object that is instantiated is expected to exist for quite a while, retaining and perhaps updating specific information that the program will use more than once.
A static method is good for doing something and not having to worry about it, something that does not require specific knowledge of a specific thing but rather just knowledge of the class of things. Consider java.lang.Math: it contains nothing but static methods designed to manipulate number primitives. These methods take input, do something with it, then output the result and have no other long-lasting affects. Even if you could instantiate a java.lang.Math object, the function of these methods would be irrelevant to the state of that object.
Don't OOp programs need a lot more of memory and processing power?
Yes, but don't fret too much about that. Your processor has more than enough power to go around for most programs. A program that's "too big" in memory is usually due to an implementation problem - bad implementation - and that is not restricted to only OOP programming.
Do programs utilizing structures need a lot more of memory and processing power?
That's what I read it as.
You can do the same things as you do in your high-level language in a mid (C) or low-level language (assembly), however while such features are cheap (require little LoC) in high-level languages, they may require a lot more work/baggage in lower level ones, however if you attempted to do the exact same thing in a low-level language, you'd still reach similar CPU/memory requirements as the high-level language, except it would usually take a lot more LoC to do.
Name:
Anonymous2010-08-26 19:12
Here's my advice. Don't fall into the same trap as most other novices when the attempt to program in the OO paradigm, and that trap is trying to force everything into class hierarchies using inheritance.
You should favor composition over inheritance.
Name:
Anonymous2010-08-26 19:16
| Don't OOp programs need a lot more of memory and processing power?
Not necessarily. I can write object-oriented C++ that is as fast or faster than the same program written procedurally in C, and that use the same amount of memory or less. That's because I understand how C and C++ compilers generate code, and I can avoid using the language and library features that are a bit slower or cause bloat.
Name:
Anonymous2010-08-26 19:22
Object-oriented programming aren't mutually exclusive imperative programming. I believe you're confusing imperative programming with procedural programming. In fact, most object oriented languages are imperative. Imperative languages are languages where statements cause changes in program state, and statements may also have non-obvious side-effects. Variables/objects in imperative programs can be mutable. That's what imperative means.
Name:
Anonymous2010-08-26 22:54
>>1
From the tone of your babble, it seems like you're confusing OOP with the half-assed implementation of it you've found in some half-assed language. If you want to see some "classic" OOP, download Squeak Smalltalk and investigate the system's structure. It's good because it's not Ctarded, and because the whole system is easy to inspect with its built-in GUI.
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.
If you're just using static methods, why are you creating objects at all? An object is an implicit (or in some systems, explicit) data parameter to the method. If there's no instance-specific data to be passed, there shouldn't be an object.
Don't OOp programs need a lot more of memory and processing power?
No. Every program has to perform operations on data. When you're writing an object-oriented program, you may find yourself using features like virtual methods, which of course require a bit more computation per-call than a simple function call, but you're not increasing the processing power required for the program, because you would have had to perform that dispatch somehow anyway. Similarly, while all objects require some storage space, so does any data.
Yes, but that's just one of the reasons for which OOP sucks.
Name:
Anonymous2010-08-27 0:10
I always seem to diverge to imperative programming using only very few OOp features.
What are some problems you've tried to solve with OOP, and how did you end up solving them? Maybe we can suggest more OO solutions.
Well I was trying to make my first real program. The goal I set in mind was an AI for the board game Go.
How would one go about using OOp for something like this? Would it be more efficient to use a couple of arrays and a function to act as AI?
Name:
Anonymous2010-08-27 6:14
>>13
I wouldn't spend much time stressing over OOP performance versus whatever your previous language of choice is. From this dicussion, I would guess that it's C. So if you're thinking of switching to C++ as your OOP choice, I'd be surprised if you could notice a performance difference at all, aside from whatever inefficiency you introduce simply because you're new to the idea.
Neither C nor C++ is interpreted, neither is garbage collected, both are pretty close to "bare metal." I'm not one to sing the praises of C++, but if you're going to worry about whether or not you should use it, performance really isn't the deciding factor.
Name:
Anonymous2010-08-27 7:00
Don't OOp programs need a lot more of memory and processing power?
Not necessarily, but the design of these languages makes it a lot easier to create otherwise unthinkable objects of objects inheriting from objects that themselves create objects, etc. I find it a lot better to use objects when you would've used a C struct anyway, and to treat the methods and inheritance as just an extra convenience.
Case in point: recently worked on a product with a rather trivial function but had TWENTY-LEVEL-DEEP inheritance hierarchies and FACTORIES AND SINGLETONS EVERYWHERE. A nightmare to write and follow, but "it's good OOP design", they said.
>>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.
>>19
You're still an idiot. What >>16 explicitly said was that he considered three particular things to be good examples, not a whole language. As for the question of C++ being OO, who gives a shit? OO means whatever the person saying it wants it to mean.
It's the most accessible abstraction mechanism to someone using C++ and it's very widely used in general, making it a good example. I can't think of a better usable example in Python, Java, etc., and Python's OOP model is quite broken.
You could easily come up with a better one in Lisp/Scheme because you can pass functions around as first-class types and I suppose you could probably find a decent one using C#, given that it supports closures, but I don't expect that someone new to OOP would find those as accessible or common.
>>21
So, to, the C++ example is the best example of abstraction, not because it is the best example of abstraction, but because, in your world, C++ is the most accessible language which implements rudimentary forms of abstraction.
>>22
Let me see if this helps. BestDE-FACTO example [of abstraction BestDE-FACTO example [of abstraction BestDE-FACTO example [of abstraction BestDE-FACTO example [of abstraction BestDE-FACTO example [of abstraction
>>23
Well, please, tell me what you think the best DE JURE example [of abstraction] would be, so I can better understand your use of the otherwise nonsensical DE-FACTO there.
>>13
It would be better to try solving a problem you know how to solve already. When you're more familiar with the structure of the problem, you'll be more able to analyze it in OO terms.
How would one go about using OOp for something like this?
It would probably only be useful in the AI itself, if at all. The board itself is so simple to simulate that you wouln't need objects for pieces, and since you're not likely to be running multiple go games in the same program, making a board object would probably be wasted time. You might use some standard library objects in a language like C++ that lacks usable data structures otherwise.
Would it be more efficient to use a couple of arrays and a function to act as AI?
Not more efficient. Don't confuse write-time constructs with run-time constructs. An object is more involved to write than a struct is, but that doesn't mean it compiles to more code.
>>13
GNU Go is C. I don't think the source is available for other popular bots like Crazystone and Mogo, but it would surprise me if they relied particularly heavily on OOP.
Name:
Anonymous2010-08-28 4:22
This is a better discussion than half the shit on the front page, and that's unfortunate. >>24
The best de jure example of abstraction is probably programming languages themselves. Experts determine the best way to execute code for some arbitrary set of constraints and then provide the means to turn an arbitrary set of syntax elements into the executable code, allowing developers to better handle their problem.
Name:
Anonymous2010-08-29 17:08
>>28 de jure example of abstraction
Just stop. This is nonsense. I guess maybe you think all Latin phrases are interchangeable, but they're not.
Name:
Anonymous2010-08-29 17:48
>>29
This is an English textboard. People who speak English abuse other languages like they were harlots. Therefore, Latin phrases are interchangeable. Q.E.D.
>>30 People who speak English abuse other languages like they were harlots.
Of course they do, the English language is just one big abuse of dozens of others.