The Old Joel on Software Forum: Part 4 (of 5)

Best Feature of OO

Just thought I'd run this idea past the developers here at JoS. The main reason I find OO useful is that I know where to find the code.

Let me make myself a little more clear. If I drop a file on my hard drive, I know where to find it later because of the logical structure of my directory tree. Similarly, I know where to find a bit of code in a huge program by the logical structure of my classes. In procedural code, stuff literally floats around anywhere - but in a well constructed OO program, I can intuitively know where to get at a bit of code just by thinking of the most logical place for it to go.

Don't get me wrong, all the other stuff about OO is useful (i.e. code reuse, encapsulation, etc., etc...) but I find it most useful that I know where to find the code.

Any thoughts?

anon
Monday, May 24, 2004

Procedural code can be organized as well as OO, and just because a program is written in an OO language does not make it well organized.

AMS
Monday, May 24, 2004

Anything can be well organized, even assembly language. But OO makes it easier and more likely to happen.

NoName
Monday, May 24, 2004

I agree with AMS. Procedural code is not necessarily spaghetti and OO code is not necessarily "clean."

I had the misfortune eariler in the year of helping a small hack shop company support a large, completely object oriented code base that was the essential definition of spaghetti. Everything had a non localized effect and no class was understandable by itself.

Bored Bystander
Monday, May 24, 2004

I rather like interfaces (Java, C#). In the C++ world interfaces are the inheritance of only pure virtual methods.

A few months ago I wrote several classes each with IsDeletable, Delete, IsDeleted methods etc. All had different implemenations. It meant I could each of these classes as nodes in a tree. The event handler for the Delete button was easy. I could delete all the different node types with exactly the same code.

Interfaces rock!!!!

Savage
Monday, May 24, 2004

Some OO fundamentalists discovered that case (or switch) statements can be modeled by inheritance, and thus decreed that if one is writing true OO programs, one should never use the case statement.

In effect, the path through the code is now determined at runtime, and the maintainer must now look at all classes that are derived from the base class whose virtual method is being called to find out what is happening.

Just an example where "knowing where the code is" does not improve by following object oriented principles.

Big B
Monday, May 24, 2004

Haha this is turning more into 'what sucks the most about OOP'.

My pet hate is people who write pointless dummy classes that need to be instantiated, when all they really need them for is a namespace for functions. Things like (in C++, but I see similar things in Java that are equally annoying):

m = new MathObject();

double a = m.sin(2*m.Pi);
double b = m.sqrt(45);

or whatever.

Should be:

double a = Math::sin(2*Math::Pi);

Using static methods. Because no data is associated with a 'MathObject', and you will never, ever need more than one 'MathObject' instantiated at a time. It's just a namespace for functions.

In general I find the whole tendency to require someone to instantiate an instance of some fancy-sounding class out of a design patterns book every five lines of code in order to get something done equally irritating. But maybe that's just me.

Matt
Monday, May 24, 2004

In a well-constructed procedural program you may know where the code is, for the same reason as you know where it is in OO. For example, a procedural function like "ke_mutex_init()" could correspond to:

namespace Kernel
{
class Mutex
{
void init();
}
}

> If I drop a file on my hard drive, I know where to find it later because of the logical structure of my directory tree. Similarly, I know where to find a bit of code in a huge program by the logical structure of my classes.

In either case, the function might be found in a ./kernel/mutex subdirectory.

Some say that OO supports (in its language features), and also teaches, what were formerly only "good practice" in procedural programming: it turns "good practice" into "common practice".

Christopher Wells
Monday, May 24, 2004

Name scoping - which effectively provides better and useful IDE integration, like Intellisense.

Green Pajamas
Monday, May 24, 2004

I don't know the origins, but the OOP community was linked with patterns:
"This group, like many others concerned with patterns, focuses on objects and object-oriented programming. The idea is that behavior in object-oriented programs comes largely from configurations of objects and classes sending messages to one another according to protocols."
- Richard Gabriel, _Patterns of Software_ [1]

Here Gabriel (author of Worse is Better) is talking about a group Kent Beck apparently led, which discussed how to solve various problems in flexible ways.

Metaobject protocols are interesting too. One was a good case study on how to engineer difficult but powerful systems.

But I don't use OOP that much, just really as data abstraction... Part of an ensemble.

[1] Christopher Alexander wrote the foreword. Now gratis online.
http://www.dreamsongs.com/NewFiles/PatternsOfSoftware.pdf
Joel argues the software patterns movement never took off. Well, the thing about ideas ahead of their time is that they're ahead of their time. Look at the eXtreme Programming movement -- that community beautifully executed the McPattern -- write zillions of books with pictures and package it as a silver bullet to the mainstream.

Tayssir John Gabbour
Monday, May 24, 2004

anon, you're touting features of modularity, not OOP per se. While OOP kinda forces you to write modular programs, you can do that in any decent procedural language.

Take Perl, for example. A program can be very nicely organized using modules in hierarchycal namespaces and directories, and have absolutely nothing to do with OOP.

Egor
Monday, May 24, 2004

> In general I find the whole tendency to require someone to
> instantiate an instance of some fancy-sounding class out of
> a design patterns book every five lines of code in order to
> get something done equally irritating.

I dunno. I don't mind calling methods on a Factory object when it's the only way to get things done, for example. I like to think of design patterns as building a new, richer language on top of the base language; and writing code in the richer language can be quite rewarding.

Michael Eisenberg
Monday, May 24, 2004

"The main reason I find OO useful is that I know where to find the code."

I think that's an advantage of namespaces in general, not something unique - or automatic - to OO. A good module system will provide the same organisational benefits, while inheritance, delegation, mixins, dynamic slot addition, etc. all help to confound it. Methods don't even have to physically exist within the classes upon which they operate - e.g. see Dylan, a class-based OO language that separates data-bearing classes from the [multi]methods that operate upon them, leaving modules to provide any spatial association you require.

has
Monday, May 24, 2004

Yes I know these things can be done well, in which case it's a delight to use them, but in a lot of cases I'd rather they weren't used at all than done badly.. hm.

Matt
Monday, May 24, 2004

I'm a big fan of enscapsulation. Having public methods with private implementations makes my code a lot more comprehensible.

And, yes, I'm aware that you can write modular code without OO.

Julian
Tuesday, May 25, 2004

"I like to think of design patterns as building a new, richer language on top of the base language; and writing code in the richer language can be quite rewarding. "

Mike, I understand you completely here. But look at it this way - how rewarding will it be for the next guy who is expected to work with your new rich language, if there are no comprehensive references to that new language, no newsgroups discussing it, no shelves of books at the tech book store explaining its nuances and tradeoffs?

What I am suggesting is that unless you are prepared to document your new language absolutely thoroughly, you are creating a maintenance nightmare that may be rightly considered spaghetti to anyone who does not have access to the books and resources that would be necessary to support it.

It is no different than the linguistic genius who invents his own language and then writes beautiful poetry in it. It is hard enough for anyone other than himself to understand, but, given his chice to create his own new expressive language that can exrpess the subtle things he requires, if he does not provide dictionaries and grammars, he is basically speaking to himself and himself alone.

This is where the pattern movement is today, and if you read the previously noted preface by Alexander, Alexander does not see that these patterns benefit any user or are any more than mental masturbation of invisble architecture fetishists worshiping at the altar of obese design opaquity.

Dennis Atkins
Tuesday, May 25, 2004

Patterns are well documented instances of common software engineering practices. I read the GoF book shortly after it came out and thought it was really cool. I talked to several more experienced developers about it. They didn't see the big deal - they had already been applying many of the ideas for years. The pattern movement is about documenting ideas that already exist.

As for newsgroups:
comp.software.patterns

PLEASE PLEASE don't tell me you're trying to make Alexander an authority on software development!! Just because he wrote a book on architecture patterns doesn't mean he is qualified to discuss their usefulness in software. That's like saying Charles Schultz would have given useful critiques of Snoop Dogg's rap music.

NathanJ
Tuesday, May 25, 2004

Yep, good way of putting it. People try to implement their own little domain specific languages out of weird and wonderful combinations of abstract-sounding classes and what have you. Especially in C++ where you can overload operators in extremely strange ways. I think in languages like C++ and Java trying to be too clever with these things just pushes the language features further than they were intended, or are good for, and ends up looking very ugly/inelegant and hard to decipher, to anybody except you.

If you really want to build a higher-level domain specific language ontop of the base you're given, use something like Scheme or one of the other LISP variants that's really designed to be extensible in a powerful way. And design your extensions carefully so they make sense to others.

If you don't quite want to go that far but still want to tinker around with classes to build something on a higer level than plain C++/Java type OOP code, try one of the more dynamic languages with OOP features like Python, where you can do clever things with Metaclasses and avoid some of the cludges required in C++...

-Matt who hasn't touched C++ for about 4 years and is glad of this

Matt
Tuesday, May 25, 2004

But that's precisely the role of a pattern *language*--to identify the types of richer structures that programmers frequently need to use, and create a way to talk about them so that other programmers will understand later.

I was responding to the question of whether it's worthwhile to go through some syntactical gyrations to do something cool and powerful. In my opinion, yes. Of *course* you're going to have to document your rich framework, but if you've designed the framework well it will make life easier, not harder.

Michael Eisenberg
Tuesday, May 25, 2004

The best (or 'the feature' if you wish) feature of OO is that it enforces the clean separation needed when having tens of programmers on the same code, or when merging code from different organizations. You may also find inheritance of use when it is a natural fit for your problem, such as MUD or GUI components.

Jonas B.
Wednesday, May 26, 2004