OOP alone doesn't solve the expression problem.
It's easier to start with FP and extend it with OOP concepts.
So no, it doesn't.
Name:
Anonymous2012-08-08 15:47
>>3 function pointers
ahahahahahahahahahahahahahahahahahahahahahahahaahahahahahahahahahahahahahahahahahahahahhhhhhhhhhhhaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaahhhhhhhhhahahahahhahahahahahahahahahahahahahah
Name:
Anonymous2012-08-08 16:14
Dynamic OOP can be used to compute factorials[1]. Static OOP is basically syntactic sugar for records and procedure pointers.
The only useful properties of OOP systems are their namespacing and scoping capabilities. But of course, those aren't exactly exclusive to OOP.
Name:
Anonymous2012-08-08 17:45
What do you mean by OOP?
Do you mean abstract data types?
Or, do you mean hierarchical data types?
Both perhaps?
Name:
Anonymous2012-08-08 18:00
>>9
Abstract data types are not restricted to OOP methodologies. So no on that. I'm not sure what you mean by hierarchical data types, nevertheless I'd probably consider the following to be OOP: -
OOP is good for managing resources cleanly (like RAII), manipulating data in related groups, and encouraging code reuse. There is a good reason for its popularity.
>>10,13
Java taught many wrong lessons. Many people believe that encapsulation is “hiding” attributes with private and defining accessor methods (get/set).
A basic definition of OOP: just another variant of black box abstraction, in which each piece of software (object) holds both state (data) and behaviour (code), and communicate by message passing. The whole fuss is the confusion between what it is and how it is implemented, and that's all folks!
>>11
No. But it's okay with some sort of name aliasing.
>>15
Everyone has a different definition of OOP, none of which are wrong or right. Even yours doesn't cover every possible definition of OOP out there.
OOP features in a language just make it easier to create structures and work with data in them.
The downside is that it makes it too easy, to the point where you get multi-megabyte object instances and inheritance hierarchies 6 levels deep and 20 wide.
(Our C++ decompiler has no trouble recreating the hierarchy and all the classes, but now we face the same difficulty the original programmers of the application must've faced when they took a step back to see how everything fit together and thought to themselves, "how did we end up writing all this?")
Name:
Anonymous2012-08-09 6:13
"encapsulating data" you can do with a c header file or haskell module also, so that is not a oop thing, it is not even something i would say oop is better then haskell or c at.
>>4
This is correct, try to use functional concepts, like first class functions which can make lots of problems easier, like callbacks and doing gui menu code. Then you can often get rid of large gui inheritance chains and replace with a class that accepts a first class function on the items.
The majority of inheritance i use if for data classes classes.
I have a meta object that contains a data class, then a list of behavior classes that can work on the data class. The the system is organised by the meta objects. (Unity3d GameObjects) using Boo.
All of these scripts are organised in their own folder based on aspect, example data holders, database or different "business logic" aspects. And if you choose to implement this with the c# partial class keyword or similar functionality this means that you can essentially plug in or plug out functionality from the program without breaking code.
Like all database code is in its own folder and all these classes use partial class of existing core classes and some extra utility class.
Look up Multidimensional separation of concerns, its like aspect oriented but beefed up and useful.
The dynamic dispatch i use is by thinking of typeclasses and not oop, which usually mean interfaces in a oop langauge.
Name:
Anonymous2012-08-09 13:39
You can do dumbed-down OOP in C. Observe...
typedef struct {
int x;
int y;
} vector_2d;
long int vector_2d_dot_product(vector_2d *const v1, vector_2d *const v2) {
long int ret = 0;
ret += v1->x * v2->x;
ret += v1->y * v2->y;
return ret;
}
//or something more conventional...
typedef struct {
int hit_points;
int health;
int ammo_left;
vector_2d current_path;
} player;
void player_replace_path(player *const this, const vector_2d new_path) {
this->current_path.x = new_path.x;
this->current_path.y = new_path.y;
//sepples implicitly passes `this`, so if you want to do OOP
//in C you have to explicitly qualify like in JS
}
>>15 Java taught many wrong lessons. Many people believe that encapsulation is “hiding” attributes with private and defining accessor methods (get/set).
I thought this was the actual definition of encapsulation.
If that's not the real definition, what is it?
Name:
Anonymous2012-08-09 16:11
hiding attributes has no real purpose... why not declare everything public and declare private stuff with a "__" prefix by convention?
Name:
Anonymous2012-08-09 16:15
OOP is a philosophy, a way of thinking. It has nothing to do with structures, inheritance, overloading, code reliability, or many other concepts taught in schools. OOP is about how data is manipulated, and who has ownership of data. It is about messaging, signals, callbacks and closures.
To make long stories short, here is an example. Say you have a distributed network, and an object exists in one of the nodes. Say it needs to communicate with another object located in a different node. Issuing a simple method usually results in transmitting a message and will cost 1 credit. A method with a return value requires the other object to transit a message too, so that is 2 credits. But accessing a (member) field requires the object to be located in the same node. As this is not the case, it must be serialised, transmitted, deserialised, and perhaps have an owner attached. Cost 100 credits.
That is why you have methods to set and get members. To avoid accessing them directly. Another advantage with the messages is that they can be queued. That there is some message queue handler (the object owner) who performs all operations on the member fields. By doing so you do not need to lock or sync data operations.
OOP is all about communication. Not about the structure.
Writing a program in an OOP friendly language does not imply that the program is OOP. Just as you can write an OOP program in a language that is not designed for, like C, it just requires more effort.
>>22,23
Object attributes don't need to match its interface. You can make a Rectangle by composing two Points, with Rectangle.setWidth(double x) just translating one of those Points on x axis. How it is done? Just a typed object graph which is dumped into a database and periodically go through expensive mutation flows.
The concept of having classes open for extension, but closed for modification is horrible in the most common “OOP” languages: you have to plan ahead carefully or it will be impossible to extend it, and you just get a lot of “design patterns” requiring a rigid “private” interface as the extension point. Alternatively, you could use JVM reflection capabilities for runtime class-loading, proxies and much more, and that was good. As a personal experience with Java [~5 years], extending class hierarchies was painful [when I didn't control their source code].
At some point, as every Java programmer does, I had contact with python, ruby and groovy, and they all were much more extensible than java, thanks to the so criticized duck-typing, absence of encapsulation primitives and mutable environments! How crazy was that! But I could see how easy it was to add logging, DB access, localization, unit conversions and much BS that was, at best, consuming a lot of time.
But no one believed me, even when I wrote an app mixing scala, groovy and their custom J2EE java code to show nice widgets and animated fireworks. Addicted by the enterprise sugar, they like to think they're using {any combination of enterprise buzzwords here}. Maybe they never will understand the appeal of different paradigms. What did I do? Don't care about others anymore. Let them play in their kindergarten.
“Read SICP” is a good advice, too bad that most people will not try to get the best view and just probably think “good, just not practical”.
Name:
Anonymous2012-08-09 17:46
>>24
Use OOP just on networked systems, like Linus kernel.
>>1
I guess that OOP tries to solve the, as I call it, 'Global State Problem' (which isn't really a problem but a lot of people consider it to be) -- by encapsulating data and code into objects and modules and therefore being mostly only of cosmetical use to the programmer. Also, contrary to most people, I wouldn't call it a 'paradigm', as it doesn't make coders think different about algorithms and stuff. So yes, you already got the points of what OOP is about in your question already.
I somehow get the impression that this post makes me a hipster... Does it?
Name:
Anonymous2012-08-11 16:56
I'm not sure what problem OOP set out to solve, but on its way it created so much more problems I now have to deal with frameworks that probably have more than a thousand classes and interfaces in it. Most of which don't really seem to do much of anything and have names such as "AbstractService", "DependencyInjectionConsumer", "ContentFactoryController" and "ContentFactoryControllerFactory", etc... OOP seems to try to solve every design challenge by adding more classes / design patterns to make the code more customizable and complex.
In the end, it often gets hard to see the forest for the trees and this slows down development. (Think UML.) I think the bulk of most programs can be written in a procedural style, which is generally cleaner and easier to follow.
Name:
Anonymous2012-08-11 18:05
>>38
One of the benefits of abstraction and using interfaces to deal with code is the possibility for that code to be reusable outside of that one application. Less abstract and more transparent code tends to be application specific but abstract (OO) code could possibly work across multiple applications.
When you're working in an enterprise and you have multiple projects to work on, it's handy to be able to piece together OO code like toy bricks rather than copy pasting code from other projects and changing them to fit.
if many components implement the same functionality through the same interface they can be interchanged arbitrarily. You have to do modifications in the sense that you have to bring each component to implement a particular interface, but after that, they can all be used arbitrarily. It is like making n implementing of a single interface and using it in m applications, as opposed to making n implementations of each of the m applications, for a total of nm files created with copy paste.
Name:
Anonymous2012-08-11 19:36
the biggest issue with oop is that at least 80% of oop programmers never fucking do it right because their only course in oop was one semester of java.
Name:
Anonymous2012-08-13 6:34
Generalization and abstraction are The
plea of the hypocrite, scoundrel, and
knave.