The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Is OOP over-rated?

I'm sure OOP has it's place. I am sure that in some narrow specializations, OOP is the only practical way to go.

But, sometimes I think that OOP is over-used, and over-rated. It seems to me that, very often, OOP is just an unneeded layer of complexity.

Or, maybe I'm just an old foogy?
walterbyrd
Tuesday, July 10, 2007
 
 
This thread is at least 10 years too late. The OOP battles are long over and people have moved on. If you want to join the current battles you need to discuss SOA, Web Services, REST, etc.

Two old battles that are making a comeback are static vs. dynamic PLs (this one is never really gone) and the merits of the functional approach (thanks to LINQ and others).
Dan Shappir Send private email
Wednesday, July 11, 2007
 
 
I still think the discussion is relevant as most developers I know aren't even aware that there is life outside of OO based languages.

Having recently started looking into Haskell and Erlang and other similar functional languages, I have to hope that in 10 years time we will have moved onto languages with their level of expressiveness and power and will look back on the years of OOP as an unfortunate cludge that we had to go through in order to learn what not to do.
Simon Collins Send private email
Wednesday, July 11, 2007
 
 
It's better to vote with the feet.

OOP is part of our productivity whether we like it or not. Remove OOP and we go back to the command-line of the old days, as GUI and so much more is dependent on OOP.

What does OOP provide? Organization of code and design. Encapsulation and modularization are just part of it.

Where is OOP lacking? In its overuse of XML for one thing, or in its overuse of static typing for another thing. On the other hand, the XML input, or the descriptive input allowed by XML and other markup variants (HTML) is great for creating standard interfaces and testing them. Imagine millions of different documents (XML files) all hitting your APIs in different ways. Somehow the downsides of using too much "markup" is offset in the final productivity sum.

And now there are these "annotation" features among others which are trying to push the envelope a little more. I think the "pre-processing" hooks are needed after all? :-) Count that for one more failure of OOP if you wish, though pre-processing hooks were used in the past by non-OOP systems as well.

Perhaps OOP is not to blame for the failings, though. As a matter of fact, I think we are "out-growing" OOP by now, with all these changes undergoing the major platforms out there (Java, .NET)...

So, let's say, you decide OOP sucks and you won't use it. Now you go and create your program process in another language. Are you going to use any GUI for you program? Remember, GUIs have been inherently OO since the beginning. Are you going to implement a new GUI which doesn't use OO? Are you going to create Web apps by creating HTML/XML as well? How is your program process going to connect to the program processes of other people which use OOP and everything else? Do I smell a Web service somewhere?

I think if you don't know of what you are running from, maybe running is not enough. For instance, the complexity of programming may have increased, but it's not OOP's fault necessarily.
Joao Pedrosa
Wednesday, July 11, 2007
 
 
"GUI and so much more is dependent on OOP."

I don't think this is true. GUIs are OO if you implement them in an OO language. If you don't, they're not. 

"Where is OOP lacking? In its overuse of XML for one thing, or in its overuse of static typing for another thing."

What does XML have to do with OOP? No OOP language I've encountered mandates the use of XML. Also, there are dynamically typed OOP languages out there if you want them (Ruby for example).

"And now there are these "annotation" features among others which are trying to push the envelope a little more."

I assume this refers to Java annotations? That's one language; again, use another if you don't like it.

"It's better to vote with the feet."

Agree with this. At the end of the day people will find new solutions if the existing ones are lacking, but OOP has a lot to offer. Having some structure imposed on your system is not a bad thing, at least not to my eyes. Use the best tool for the job, but don't be put off by blind "OOP sucks" 'arguments'.
Anon
Wednesday, July 11, 2007
 
 
I'd say it's better to vote with our brains ;-)

You don't remove OOP and go backwards. You replace it with something better like Haskell, Erlang, Clean or ideally some fusion of all their good points.

I think you are confused about what OOP is. As far as I am concerned XML and static typing are not defining differentiators of OOP. Neither is modularity or encapsulation given that most modern languages have them in some form.

The only real unique attribute of OOP is that OO languages enforce the  binding of program data to the code that operates on that data.

OO forces you to model your problem as a network of interconnected objects. And because these objects encapsulate your program data you effectively end up with either a hierarchical or network data model. This asymmetric model is well equipped to answer the specific questions that your current requirements demand but is not readily adaptable to answering wildly different questions which may arise as requirements evolve.

This is one of the main reasons that the relational model of data was put forward by Codd to replace the existing hierarchical and network data models. In that way OO (and XML as well for that matter) is really a step backwards.

Finally, you don't need OO to create GUIs. Yes, they are probably one of only two or three problem domains that OO really maps nicely to but that doesn't mean that non OO languages can't provide nicer models for GUI description.
Simon Collins Send private email
Wednesday, July 11, 2007
 
 
"Or, maybe I'm just an old foogy? "

Yes. You are an old foogy. OOP doesn't have to be a cludge. There is just an awful lot of really bad OOP out there. Good OOP is actually quite pleasurable to work with.

The world is not black and white people. There are also shades of gray...
dood mcdoogle
Wednesday, July 11, 2007
 
 
Most GUI's I've run into -- X-Windows, and the Win32 API -- are written in 'C'.  True, there's OO 'frameworks' you can use -- MFC being one -- but mostly they're still 'C'.
AllanL5
Wednesday, July 11, 2007
 
 
>Good OOP is actually quite pleasurable to work with.

Compared to bad OOP or lower level languages maybe. But I challenge you (if you haven't already) to read up on Haskell and then come back and tell me that it isn't orders of magnitude more expressive and powerful than OO languages like Java.

It was a truly eye opening experience for me seeing how close the code that you generate in Haskell will generally map to the algorithm you have chosen If they could create a Haskell virtual machine that incorporated some of Erlang's strong features such as concurrency oriented programming, painless code reloading etc it would be a very powerful platform.
Simon Collins Send private email
Wednesday, July 11, 2007
 
 
> is just an unneeded layer of complexity.

What needed layer of complexity do you recommend instead?
son of parnas
Wednesday, July 11, 2007
 
 
I think of OOP as the third normal form of programming. If you do it right, you can put one piece of functionality in one piece of code.

Whether that's a good thing or not, just like the database third normal form, depends on the circumstances.
Steve Hirsch Send private email
Wednesday, July 11, 2007
 
 
I write CRUD apps. I don't need something "expressive that generally maps to the algorithm I've chosen".  ;)
screw you
Wednesday, July 11, 2007
 
 
"...the merits of the functional approach (thanks to LINQ and others)."

I'm confused. What does LINQ have to do with FP? This is a sincere question, not a smartass remark.
Greg Send private email
Wednesday, July 11, 2007
 
 
+1 for Screw You. CRUD isn't about algorithms. It's about shuffling data in and out of databases, and OO isn't necessarily the simplest or most expressive way to do that.
Greg Send private email
Wednesday, July 11, 2007
 
 
I've looked at FP every so often, but every example I've seen is "FP is so cool because look at how easy it is to calculate fibonacci numbers and Newton's method of root finding!"

I never need to do either of these. If I'm not doing math, how is FP "better"?
Chris Tavares Send private email
Wednesday, July 11, 2007
 
 
Chris' response reminded me of a question I've meant to ask.

What practical use is there for calculating fibonacci numbers anyway? I'm just curious if it's an academic exercise or is there something useful for this..
Tim Patterson Send private email
Wednesday, July 11, 2007
 
 
OOP is not overrated, not even close. I'm certainly sure we will one day look back on OO as antiquated but not overrated - OO was a giant leap forward for programming.

And it's hardly a layer of complexity, it's a layer of simplicity, that you think that suggests to me that you don't have a good understanding of OO.
Poutine
Wednesday, July 11, 2007
 
 
Our company just rewrote a complex application in java that was originally written in C/C++.  The application written in C++ was bug riddled, along with being thousands and *thousands* of lines of code. (Many confined to one class).

We spent a long time designing the new applicatino up front.  We made extensive use of AOP/Dependancy Injection, OO principles, and our own event framework.  We came away with a loosely coupled 20,000 lines of code that are easy to maintain and performant.  OOP is a smashing success if used correctly.
Anon Send private email
Wednesday, July 11, 2007
 
 
> We came away with a loosely coupled 20,000 lines of code that are easy to maintain and performant.

It will be interesting to see if those after you will think so too. Almost by definition something you create is easy to maintain because you know how it works.
son of parnas
Wednesday, July 11, 2007
 
 
> What does LINQ have to do with FP?

In order to implement LINQ MS had to introduce various FP capabilities into C# 3.0 such as lambda expressions, closures, type inference (not strictly FP, I know) and more. For more info see: http://msdn.microsoft.com/msdnmag/issues/07/06/CSharp30/default.aspx

The fact that nobody in this thread questions the benefits of OO over Procedural programming is a testament to the fact that this war is over. The benefits of FP is, as I wrote, belong to a new one.
Dan Shappir Send private email
Wednesday, July 11, 2007
 
 
SQL itself is usually either labeled as "functional" or "declarative", so this does apply to CRUD apps.  All ORMs are junk.  OODBMS's tried to replace RDBMS's and failed miserably.  The ultimate goal of LINQ is to make SQL and other stuff 'first class' instead of leaving it as a string which a compiler and other tools can't validate and/or leverage.

Every time I go on a rant about OO, it's more about the Java/Ruby style of OO, where everything needs to be an object, everything needs to be in a class heirarcy, you can't just write a damn function! What's wrong with multi-paradigm languages?
Grant Send private email
Wednesday, July 11, 2007
 
 
> you can't just write a damn function!

Is

class
{
  static void a_damn_function():
};

really that hard?
son of parnas
Wednesday, July 11, 2007
 
 
Ruby is multi-paradigm and is useful beyond preconceived markets due to that support.

Ruby has been used as a "shell" tool since the beginning, and many times one can create several files and not a single OO class.

In my own Web framework, my "pages" don't have a single class either, even though the Web framework itself and other libraries use OO. My "code-behind" does not have a class.

My ORM is very useful as well, even though I don't try to create a model with classes with it. A model is more like a bunch of related methods with a common authentication interface and some pre-defined methods which provide the basic functionality out of the box, so you can focus on what's "extra" instead. That's not completely RDBMS friendly, though, as there's a level of abstraction in the way, still. This buys me a potential support of multiple RDBMSs from the same code, even though it's not very practical anyway, so yeah, there are times one might not want any ORM whatsoever. LINQ is read-only as of yet, so it's not as if it's the cat's meow either.

Anyway, when it's about abstractions, there is leaking everywhere. You may try to stop the leaking in the database handling code, and it starts leaking in the front-end code, in the security code, in the user-interface code, everywhere else...
Joao Pedrosa
Wednesday, July 11, 2007
 
 
"The only real unique attribute of OOP is that OO languages enforce the  binding of program data to the code that operates on that data."

I don't know that I agree with this. OO systems often have a lot of "free data" moving through them, and most OO programming environments have some support for shuttling data around in record-like structures when necessary. Even Eiffel, well known for its stringent focus on objects, supports a record-like structure called a Tuple.

Similarly, most OO environments provide some mechanism for moving behavior around with both bound and unbound state. C# provides delegates and Eiffel has agents, for example.

Instead, I think the defining characteristic of OO is that the model of computation is based on the Abstract Data Type (ADT) concept.  This is different from the functional programming focus on stateless mathematical functions, or the procedural focus on the procedure (which mixes local state in with functions), or the rulebase/factbase/unification model used by rule systems, etc.

I think one of the reasons we see so much bloated, messy "OO" code is that people often think of objects as records with some functions attached (the data + code view), rather than understanding them as units of coherent behavior. The coherence comes because the objects allow you to organize, express, and strictly enforce logical constraints that exist in your system. To me, this seems orthogonal to the approach used to express the ADT behavior. 

I think OO is often overused and is sometimes overkill, but used correctly, it can be a powerful tool, fully compatible with other powerful tools like FP.
Franklin Send private email
Wednesday, July 11, 2007
 
 
> What's wrong with multi-paradigm languages?

Nothing, which is one reason why we have C++ and Javascript, arguably still the most popular PLs in the world today.
Dan Shappir Send private email
Wednesday, July 11, 2007
 
 
Dan Shappir,
Was it you who wanted to see responses
from people who absolutely dislike OO?
Object Hater
Wednesday, July 11, 2007
 
 
Object Hater - I don't understand your question.
(And BTW I think its a rather pathetic sig. but to each his own)
Dan Shappir Send private email
Wednesday, July 11, 2007
 
 
"I don't know that I agree with this. OO systems often have a lot of "free data" moving through them, and most OO programming environments have some support for shuttling data around in record-like structures when necessary. Even Eiffel, well known for its stringent focus on objects, supports a record-like structure called a Tuple."

Yes but what I meant is that that is not a defining attribute of OO as most languages have that. OO languages like Smalltalk and Java introduced a lot of nice concepts to mainstream programming such automatic memory management, garbage collection etc. but these do not define what it means to do OO.

The only really new and unique thing that OO introduces is the concept of separating your application data into separate objects linked together by references. I contend that that is a bad idea as I outlined earlier.

Wednesday, July 11, 2007
 
 
Here are some questions before you decide for yourself if oo is overrated or not:
- do you consistently apply class design and package design principles? (LCP, ISP, OCP, REP, CCP, CRP)?
- do you consistently apply design patterns like IoC, observer, class factory or builder, bridge, memento, strategy?
- do you build normal forms of object models?

If you answered yes to all of the above, with all answers based on years and years of experience plus a thorough understanding of the related theory, then your decision is well informed.

Otherwise, whatever people tell you, you don't really know the answer.
Dino Send private email
Wednesday, July 11, 2007
 
 
"We came away with a loosely coupled 20,000 lines of code that are easy to maintain and performant.  OOP is a smashing success if used correctly."

I think maintainability is a huge factor to consider. I'd be interested to see whether you are considering maintainability from the viewpoint of you going back to maintain your own code or someone externally coming in to maintain your code.

From what I've seen more powerful languages like Haskell and Erlang can significantly reduce line count while making the code easier to read (of course you can write hard to read code in any language but that's beside the point) and I think  code readability is one of the key factors that contribute to the maintainability of code.

Wednesday, July 11, 2007
 
 
"I write CRUD apps. I don't need something "expressive that generally maps to the algorithm I've chosen".  ;)"

It was a poor choice of word on my part really. I should have just said that the code corresponds more to how you would think the problem through and I think that is important regardless of what you're programming.

Although if you're just doing CRUD without any business rules then a programming language is overkill. Just use a database and a tool to let you generate forms to CRUD the DB.

My guess though is that most CRUD apps will involve some business rules and in that case good FP languages will let you code those rules much more clearly.

PS the last two comments have been me. Forgot that I was posting from a different place :(
Simon Collins Send private email
Wednesday, July 11, 2007
 
 
In response to the questions of maintenance, my team is has already handed off our platform to 'application developers' and its a joy to watch them use it and be productive. 

When I say loosely coupled, I meant it.  I'm gonna credit AOP as much as I credit OOP on this project, as we've already gone back and done some major refactoring of core pieces for numerous reasons. 

Sure, we are bound to have some 'gotchas', as I'm not claiming this is the best written system *ever*. 

My point was, the new OOP system is much easier to read modify/maintain then the old monolithic C system.

So far though, people not involved in the design and implementation of the framework have had an easy time using it.
Anon Send private email
Wednesday, July 11, 2007
 
 
"My point was, the new OOP system is much easier to read modify/maintain then the old monolithic C system. "

No doubt. Anything short of assembler would be easier to read and maintain than monolithic C code.

The question is would a language like Erlang or Haskell be even easier for them to read and maintain (assuming a similar level of familiarity with the language and framework)? I think it would.

Things like loose coupling, separation of concerns (AOP) etc aren't really confined to OO so I'm not sure that any benefits from them can truly be attributed to OO modelling. They are general design principles that transcend the particular programming language or system and I'd almost argue that OO actually makes it harder to do some of these things over FP.
Simon Collins Send private email
Wednesday, July 11, 2007
 
 
Hi Simon,

Maybe I'm being dense...

"The only really new and unique thing that OO introduces is the concept of separating your application data into separate objects linked together by references. I contend that that is a bad idea as I outlined earlier."

How is what you are saying here different than say, how a linked list or binary tree might be implemented in Pascal or C? We call them structs/records and pointers instead of objects and references, but the concepts are still fundamentally the same, no?

I think I'm not getting the point you are making...
Franklin Send private email
Wednesday, July 11, 2007
 
 
"Things like loose coupling, separation of concerns (AOP) etc aren't really confined to OO so I'm not sure that any benefits from them can truly be attributed to OO modelling. They are general design principles that transcend the particular programming language or system and I'd almost argue that OO actually makes it harder to do some of these things over FP. "

I'm not sure I understand.  I don't know Erlang or Haskel, so I couldn't say wether or not its possible to develop an easy to maintain, loosely coupled system or not, but my point wasn't that those traits are exclusive to OO.

OO languages are really just a featureset of 'fundamental concepts' that all relate to the idea of seperation of concerns/loose coupling, I don't see how it makes those concepts 'harder'.

I'm not here to say that OO is *better* then functional programming, as I have such limited experience with them, but in terms of being able to easily design and maintain a very complex system, I don't see how it fails.
Anon Send private email
Wednesday, July 11, 2007
 
 
Franklin said:

"How is what you are saying here different than say, how a linked list or binary tree might be implemented in Pascal or C?"

Sorry, I wasn't very clear - wrote it quickly and only had three hours sleep last night :)

It's really a difference in layers of abstraction. In Pascal or C you'd ideally hide the fact that you were using a linked list behind an abstract interface so that you can switch implementations if need be (to say an array list). So these are implementation layer data models rather than logical layer data models.

In OO the whole idea is that you model your problem domain as sets of interconnected objects that invoke methods on (or send messages to) each other. This is logical layer data modelling - you map your conceptual model of the problem domain onto this set of objects. It is independent of the way stuff is actually implemented at lower levels.

This is the same distinction that you can make with relational databases. At the logical layer you map your conceptual model of the problem domain onto a set of relations (or tables in SQL speak).

At the implementation layer the DBMS is free to use whatever data structures (linked lists, trees etc) to implement your logical model. Your code should not have to be aware at all of these underlying data structures. The relational model used at the logical layer is a much more powerful model for it to work with.

The relational model of data is also a much better way to model data than the the network model that OO gives you, for reasons that I'll outline in a post below. A programming language that has built in support for the relational model of data would be much more powerful than any OO language can hope to be.

Sorry for the long post. Hope that helps clarifies things. It's the first time I've really expressed these ideas in writing so it needs refining. It all makes sense in my head :)
Simon Collins Send private email
Thursday, July 12, 2007
 
 
"GUIs are OO if you implement them in an OO language. If you don't, they're not."

Can you give an example of a GUI that is not object oriented?  Win32 API doesn't count.  It is implemented in C and you have to pass HWNDs around instead of relying on the compiler to do it for you with "this", but the underlying concept is OO nevertheless.
Jeff Zanooda Send private email
Thursday, July 12, 2007
 
 
"A programming language that has built in support for the relational model of data would be much more powerful than any OO language can hope to be."

Yes! Exactly! +100,000 !!!!
Greg Send private email
Thursday, July 12, 2007
 
 
"A programming language that has built in support for the relational model of data would be much more powerful than any OO language can hope to be."

Yes, if you are programming databases. Lots of us aren't.
DJ Clayworth
Thursday, July 12, 2007
 
 
OOP is a tool in your toolbox.  Just like SOA, Perl, Ruby, .Net, Java, SQL, Forms, HTML, etc.

The key is knowing when a tool is the right tool for the job.

And just because someone writes a line of code doesn't mean they're programming, and just because they use the keyword "class" somewhere doesn't mean they're doing OOP.
Another Anonymous Coward
Thursday, July 12, 2007
 
 
>>I don't know that I agree with this. OO systems often have a lot of "free data" moving through them, and most OO programming environments have some support for shuttling data around in record-like structures when necessary.<<

Yeah, but if you don't use any OO features, are you *really* doing OO programming? Just using a language that supports OO, is not necessarily OO programming. Or, that is how it seems to me.
walterbyrd
Thursday, July 12, 2007
 
 
Sorry walter, I wasn't suggesting that you should design your systems to avoid OO features.  Just commenting that most systems have some data floating around in them, unconnected to the notion of "object," at least temporarily. Many OO platforms support such things (often by providing a means to create a degenerate, record-like class with little or no behavior).

I ws trying to draw the distinction between data and state, but reading it over, I see I've done a poor job of it.  Perhaps I'll take another crack at it later :)
Franklin Send private email
Thursday, July 12, 2007
 
 
"A programming language that has built in support for the relational model of data would be much more powerful than any OO language can hope to be."

Like Visual FoxPro..... OO with Xbase\In Line SQL..

Nothing compairs to it for DB Apps. Nothing.

RIP. 2007
FoxPro Guy
Friday, July 13, 2007
 
 
"Nothing compairs to it for DB Apps. Nothing."

Other than MS Access. 

RIP ???? (under going slow painful death)
AltShift
Friday, July 13, 2007
 
 
Designing software in an OO way is just as useful today as it ever was. OO concepts such as abstraction, implementation hiding, polymorphism and encapsulation are here to stay and influence everyday design decisions whether an OO or a non OO language is being used.

I personally think that OOP is great because it lets you design interfaces, validate implementations at compile time and seamlessly incorporate all of the principles mentioned above into your everyday coding using design patterns.

But even if OOP languages are not your cup-of-tea the design principles are unfortunately under-rated and not over-rated.
Yoni Rapoport Send private email
Friday, July 13, 2007
 
 
"Nothing compairs to it for DB Apps. Nothing."

Yeah that's why it's so popular for db apps today. Foxpro is a really horrible programming language and a ghastly ide. But if you tell a foxpro guy that they;ll say "oh but it is like totally OO". Foxpro having OO is like putting sunglasses on a turd.
invader zim
Friday, July 13, 2007
 
 
"implemented in C and you have to pass HWNDs around instead of relying on the compiler to do it for you with this"

Neat observation. One of the inventors of Simula, precursor to Smalltalk and all of OO, said the only new thing he thought they did was move data from the stack to the heap. I think that and inheritance are about all OO added to the world. We could do interfaces and abstractions in other languages, and most OO principals are just old wine in new bottles, good design precepts that would serve us well in any language.

I'd have to see a language that mirrors relational concepts to have much opinion about it, but as of now I think about databases less than most anything else so it doesn't sound interesting. Much of my data comes and goes through other sources and sinks.
Stan James Send private email
Friday, July 13, 2007
 
 
I think that OOP is highly overrated.  It is just one tool in my toolbox.  One nice thing though is that having an implicity "this" pointer enables making new types by renaming old types.  For example, you have class A defined somewhere, then the line:

class B = A;

would make a type B that behaves identically to be.  However if you instead use only free functions they no longer work for B.  With a mix of member and free functions you get to control which aspects of B and A are shared, and which are independant.  I found this out while working on my new programming language which does not have an implicit "this" pointer.
Tom C
Friday, July 13, 2007
 
 
We DO have a language that mirrors relational concepts: it's called SQL.

And you know what - it turns out to be pretty anemic for anything but manipulating data in tables.

Saturday, July 14, 2007
 
 
"We DO have a language that mirrors relational concepts: it's called SQL."

Did you know that the word "relational" does not occur in the SQL standard?  SQL is not particularly relational, and some of the later changes have made it less so.

Sincerely,

Gene Wirchenko
Gene Wirchenko Send private email
Monday, July 16, 2007
 
 
"SQL is not particularly relational, and some of the later changes have made it less so."

OK, so what is the definion of a "relational programming language"? If we discuss something, maybe we should at least try to have the topic defined.

BTW, "relation" as in RDBMS is not a relationship between two relations (tables).
Wojtek Send private email
Monday, July 16, 2007
 
 
Gene, sql is an implementation of the relational algebra - ie any relational expression has a corresponding statement in sql.
Dino Send private email
Monday, July 16, 2007
 
 
"Gene, sql is an implementation of the relational algebra - ie any relational expression has a corresponding statement in sql."

I think a number of the relational heavyweights would probably disagree with you.

Sincerely,

Gene Wirchenko
Gene Wirchenko Send private email
Monday, July 16, 2007
 
 
I like how theres no *actual* discussion, just a discussion of what would be discussed. Wonderful.
Anon Send private email
Monday, July 16, 2007
 
 
@Gene
They can disagree on many things except "any relational expression has a corresponding statement in sql". The reciprocal is not true.

Bottom line, SQL is relational.
Dino Send private email
Monday, July 16, 2007
 
 
"I personally think that OOP is great because it lets you design interfaces, validate implementations at compile time and seamlessly incorporate all of the principles mentioned above into your everyday coding using design patterns."

Which buzzword is your favorite? I like "seamlessly".

Yes, OOP is over-rated and unnecessary most of the time. Functional/procedural code runs faster and can be designed faster. It's also less complex and can be just as modular as any OOP design. How is "DB->connect();" any better than "db_connect();"?

There are some cases where it makes sense and might seem "better". Graphical interfaces and games come to mind. The DOM is also good for working with HTML/XML documents. Any of that can be done procedurally, of course, but "objects" may feel more natural.
Travis Estill Send private email
Tuesday, July 17, 2007
 
 
"A programming language that has built in support for the relational model of data would be much more powerful than any OO language can hope to be."

Not sure exactly what you mean by "support for the relational model", but Oracle's PL/SQL kicks ass because it lives in the database along with the data. Forget about all the extra work you have to do in VB, Java and C# (managing connection strings, building command objects and adding parameter objects, etc, etc) just to execute a simple SQL command. In PL/SQL, the integration with SQL is seamless (at least approaching 100% seamless with each new release of Oracle).

In the context of database-centric applications, LINQ is just  a kludge for C# to reduce the amount of code you have to type  to execute an SQL statement, except that you have to learn a new query syntax and you don't have any control over the generated SQL statement...
OracleGuy
Tuesday, July 17, 2007
 
 
"How is "DB->connect();" any better than "db_connect();"?"

How about

foreach(Database db in this.Databases) {
  db.connect();
}

assuming the members of the Databases collection might be all sorts of different kinds of database: SQL Server, Oracle, GemStone, whatever.

Do you think your procedural/functional equivalent is going to be be less complex that what is shown above?
Skeptical Send private email
Tuesday, July 17, 2007
 
 
"Which buzzword is your favorite? I like "seamlessly"."

Hey Travis, don't confuse buzz words with words that have more than 2 syllables. I know it can be somewhat confusing.

Tuesday, July 17, 2007
 
 
"managing connection strings, building command objects and adding parameter objects, etc, etc)"

Huh? NOBODY does this anymore. It's a solved problem and the solution is the DAL and projects like subsonic (if you don't want to write your own DAL).

With subsonic (+many others) the database integration is also totally seamless, but you actually get to program in c# instead of some crappy high maintenance sql sproc, so what's your point?

Tuesday, July 17, 2007
 
 
foreach ($databases as $db)
  {
  db_connect($db);
  }

Where $databases is an array of integer constants (e.g., ORACLE).
Travis Estill Send private email
Tuesday, July 17, 2007
 
 
Let me see if I understand you correctly, Travis. You think that db_connect(int) method you are using in the loop is going to run faster, be easier to design, less complex, and just as modular as the OO version I mentioned above? Including all of the variations on DB type and whatnot?

I call bullsh*t.

What's really going to happen is that you are going to reproduce the functional equivalent of polymorphism in your own code rather than using a language where you can leverage it directly.  The end result will be more brittle, longer, and more difficult for client code to use.
Skeptical Send private email
Tuesday, July 17, 2007
 
 
Here's mine:

db_connect($db);
db_get_user_email($username, $db);
db_get_user_password($username, $db);

And yours:

$db->connect();
$db->get_user_email($username);
$db->get_user_password($username);

Tell me what's so much better about your version? My way requires a switch construct and an array/list of information on each database (database names, credentials, etc.) Yours requires "polymorphism", which is really just a switch construct in disguise.

I call straw-man!
Travis Estill Send private email
Tuesday, July 17, 2007
 
 
I'm with Skeptical on this.

"How is "DB->connect();" any better than "db_connect();"?"

It's better if DB is used as an abstraction and its implementation remains unknown to the current context - making it eligible for reuse and easier to maintain.
Yoni Rapoport
Tuesday, July 17, 2007
 
 
Travis,

Maintainability is in part the ability to add new capabilities or change existing ones by making the smallest changes to the existing code.

Now let's assume these three code lines are enclosed in a function which accepts $db. The OO solution would allow you to use that function for a new database without changing existing code. The procedural solution would force you to change your switch statement for every new database.
This example may be too simple to show it but the latter option is far more bug prone and less maintainable (at least in my opinion).
Yoni Rapoport
Tuesday, July 17, 2007
 
 
"Yours requires "polymorphism", which is really just a switch construct in disguise."

Well, they all boil down to stuff like

CMP AX, 0
BNE $D2
LDA $D080

or even 01101101 11101011 01000010 ...

or even http://tinyurl.com/2a35rb

so I guess it's worthless talking about any kind of distinction between having to build a switch construct by hand (over and over) or relying one that's an implicit part of the semantics of the language you're using, right?

But, in order to avoid any more claims of straw men, let me get back onto the main subject.  How is your "integer-constant" oriented version of affairs able to "run faster, be easier to design, less complex, and just as modular as" the OO-version?  You've as much as admitted they under the covers they are identical, except that with one implementation you had to build a switch statement that the other implementation provided for free.  What am I missing?
Skeptical Send private email
Tuesday, July 17, 2007
 
 
Run faster? Maybe. It's a small example. Lower level programming always has the potential to win the day with speed.

Easier to design? Even for this example, yes. In the time it takes you to bang out all those base and inherited classes you need (and done correctly), I bet I could whip up a function with a switch block faster.

Less complex? Doubtful for this example. But "protected abstract virtual base pure virtual private destructors" can be slightly difficult to understand. OO can get pretty complex.

Just as modular? Yes. Let's say we both want to add support for oracle databases in our programs. Here's what I would do:

1. Define ORACLE constant (these constants are stored in a single file that can be shared among programs).
2. Add new "case" to the switch block in my "db_connect" function that will handle oracle connections.

Your way of doing it might be this:

1. Create new class called "Oracle" that's extended from your base "Database" class.

Those two procedures are nearly the same in difficulty and can both produce clean, modular code.

The OO idea certainly doesn't give you switch statements for "free", though. You still have to plan the design and decide how to best name the inherited classes.
Travis Estill Send private email
Tuesday, July 17, 2007
 
 
"The end result will be more brittle, longer, and more difficult for client code to use."

But doesn't that describe everything in PHP, the language Travis is using for examples?
PHP Hax0r
Tuesday, July 17, 2007
 
 
The first bit of stuff seemed more oriented around opinion than anything with substance, so I'll let it pass and just disagree.

"1. Define ORACLE constant (these constants are stored in a single file that can be shared among programs).
2. Add new "case" to the switch block in my "db_connect" function that will handle oracle connections."

What about the mods you have to make to your get_email and get_password functions?  Easy enough to forget if the language doesn't give you a way identify the things which have to vary together, and cause them to actually vary together.

What about having to replace code in existing clients in order to add the new functionality.  Not too modular in that sense, is it?

"The OO idea certainly doesn't give you switch statements for "free", though. You still have to plan the design and decide how to best name the inherited classes."

I don't think anyone claimed anything was free.  I know I didn't.
Skeptical Send private email
Wednesday, July 18, 2007
 
 
The thing to remember is that FORM FOLLOWS FUNCTION.  If your  program needs to keep track of lots of data pertaining to diffferent business objects, like a game, then OO is for you.  If your program is strictly for doing one thing, such as search, then FP is for you.

Incidentally, I think Joel slams too much on Java.  It's just another OO language.  Yes, Map-Reduce is easier in a functional language, but that doesn't make FP a panacea by any means.
Object Oriented
Wednesday, July 18, 2007
 
 
"Easier to design? Even for this example, yes. In the time it takes you to bang out all those base and inherited classes you need (and done correctly), I bet I could whip up a function with a switch block faster."

When has that ever mattered.  "banging out" classes is never the bottleneck when it comes to completing a project on time.  Design and debugging is where the time goes.


Have you ever worked on a big app? Do you know how difficult it is to work with code (not to mention debug) things with large switch statements?  That was one of the main reasons we moved away from C.
Anon Send private email
Thursday, July 19, 2007
 
 
The reason OOP is overrated is *because* of the horrific use of inheritance, which is *exactly* what's being suggested above.

All you have to do is use inheritance (generally one of the tightest couplings you have).  Is that all, really?  That sounds about as simple as stating, all you have to do is build a DAL.

I think it's a lot simpler to say than it is to do.

OOP is no panacea, not anymore than modular programming was, function programming, aspect oriented programming, inversion of control, and any of the other acronyms you can come up with.
me
Sunday, July 22, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz