The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot

The Old Forum

Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

whats this called?

when a class doesn't represent an object but is instead a collection of methods which operate on an item of data....

e.g. very simple example

you have a User class, which has a constructor (id, password)

there are methods such as
User.Validate() - validates user/pass
User.Delete() - deletes user
User.NewPassword() - sets new password etc...


you have a class called UserUtils
with methods such as

UserUtils.Validate(id, password)
UserUtils.NewPassword(id, newpassword)

I'm not just talking about libraries, consider an app which is written almost entirely using the second style ... it uses objects but it's not object orientated (or is it?).
Thursday, September 23, 2004
Off hand it looks like someone new to OO (with a Procedural background) using objects in a procedural manner.

In generale, having one object act as a conduit to another is an example of delegataion (facade?).  Might be necessary where you have a Foo, need it to be a Bar, so create FooBar that implements the Bar interface on top of the a Foo.

clear as mud?

Thursday, September 23, 2004
not necessary, poor programming.  If Foo needs a Bar interface, then the Bar interface should be implemented by Foo, not a wrapper.
muppet Send private email
Thursday, September 23, 2004
Yes, it is an Object.

An Object in the OO parlance is an entity that holds data, and the operations on that data, in a single entity.  Thus anything that has 'private' data, and public methods to operate on that data IS an object.

We can now begin to argue about the 'Quality' of that Object -- too Procedural, what Pattern it implements, etc.  It's still an Object.

One of the things that slows adoption of OO techniques are these 'religious' wars that try to place a 'higher' definition on what an Object is.  The argument of "He's just a Procedural programmer using Objects" is part of this war.  It's typically used by someone who disagrees with a particular implementation -- whether they really understand the implementation or not.

OO still needs some of the insights learned in Procedural programming.  Minimize data coupling (ie keep interfaces simple), maximize functional cohesion (ie collect in an Object those Methods that operate on its data).  OO gives the programmer more powerful constructs to implement these insights.
Thursday, September 23, 2004
It's generally called a utility class, sometimes a utility class pattern, and is a legitimate construct to group related functions.
Dennis Forbes Send private email
Thursday, September 23, 2004
generally there are two approaches:

1. you delete the user from a collection of users.

2. your 'user' is an iterator into a collection of users with prev-next etc.

1.5 your 'user' is a user_collection::iterator.

Look at the stl stuff.

It is the difference between doing dir.delete(file) and file.delete.  Think about it.  (And, as in the example of files (think hard links), can a user be in more than one collection (= group..)?)
i like i
Thursday, September 23, 2004
>object orientated

Pet Peeve:  It's "object oriented".  There's no such word as "orientate".

Any chance you're British?
Pedantic SOB
Thursday, September 23, 2004
"Object-oriented" is a vague, generally unqualified thing.  Yet people feel very strongly about it -- but it's still a "I can't explain it but I know it when I see it" sort of thing.

Really, the difference between your two examples is "formal semantics."  That is, the first example has an implicit "id" parameter (or a pointer to the data that represents that object) while in the second example it's explicit.

So for most people, "object-orientation" means having the syntactic sugar necessary to formalize some of these techniques of encapsulating complex data, defining polymorphic functions on a class of data, and composing classes to create new classes.  However, I think that in a certain sense it's not about the syntax (the syntax just makes it easier to read and write the stuff).  You can write "object-oriented" code in the assembly language of your processor.
Kalani Send private email
Thursday, September 23, 2004
Pedantic:  Sorry, orientate is a word:
Thursday, September 23, 2004
Hey, this looks exactly like a module/namespace in Python/Ocam'l/perl.

like this:

import os
d = os.getcwd()
os.system(('rm -rf %s' % d))
Thursday, September 23, 2004
thanks for the responses

replying to a few points:

I didn't mean the example to be taken too literally - it was the first thing that came to my head ...

1) the guys writing this style are very experienced - I wouldn't interpret it as if they were new to ood/oop

2) AllanL5 - "An Object in the OO parlance is an entity that holds data, and the operations on that data, in a single entity." - the UserUtils style doesn't necessarily hold data about the user - thats why all method calls require you to explicitly state which user you want the method to operate on ... I guess it could hold other data internally - eg a database connection or something.

3) British yup
Results suggest it's in American English too ...

object orientated design = 52900
object oriented design = 3,240,000

which is interesting ... I suppose ... in a way ...
Thursday, September 23, 2004
It is "object oriented" no matter what part of the world you're in. It's an unfortunate terminology. Many people (typically beginners) get it wrong, in part because "oriented" is a very rarely used word.

Nevertheless, that is what it is called, so please get it right to avoid annoying the pedants out there (or displaying your ignorance when going for interviews)
Chris Welsh Send private email
Thursday, September 23, 2004
A good place that I've seen this done is in J2EE, where it's called a DAO (See also: Martin Fowler's Patterns of Enterprise Application Architecture).

The idea is that you separate the data access code from the entity so that you are able to return lists of the entity.

The entity object (now stripped of it's db code) is then termed a DTO (Data Transfer Object), and is used to hold your entities data (duh), as well as pass it between layers (if it has some serialization abilities).

But this is done for a specific purpose.  If someone has done this "just because", then that's not a good reason.  Utility classes aside.
example Send private email
Thursday, September 23, 2004
If it doesn't hold data, doesn't that essentially make it a static class, whether it's actually coded that way or not?
NetFreak Send private email
Thursday, September 23, 2004
I'd say this is good design.

It reflects that users don't actually validate themselves. So having a utility class that knows how to validate users is, in my opinion, the best choice.

It helps keep your objects stable, because you do not need to change it for every additional operation on them. New operations needed? Create a utility class that can perform the requested operations, or extend an existing utility class if the operations are related.
Practical Geezer
Thursday, September 23, 2004
In addition, I would hesitate to make password a property of user. Basically because a password really is not an intrinsic property of users. I mean, your not born with them, are you?
And it would imply users always have one, not 0, not 2.

I'd be more inclined to create a User Manager or Password Manager that kept track of the user's and their password or passwords.

It would make your user class more portable. And the information you keep for or about users more flexible.

Whether you need that kind of portability or flexibility depends on your situation, but I find that usually the extra class(es) and extra work associated is quite minimal.
Practical Geezer
Thursday, September 23, 2004
"when a class doesn't represent an object but is instead a collection of methods which operate on an item of data...."

Wouldn't you make this a static class with static methods?
Thursday, September 23, 2004
Both object oriented and object orientated can be used, but they would mean different things.

An oriented entity is one aligned with a particular notion, location or subject.  So discussion about the use of objects in software would be object oriented.

To orientate is to move something into alignment (originally towards the east only), metaphorically or physically.  So if one were talking about converting code from a procedural corpus to an object oriented one it would become object orientated.
Simon Lucy Send private email
Thursday, September 23, 2004
Simon, you may well be correct in a grammatic sense, but I've certainly never heard that somewhat bizarre justification fro the validity of "object orientated" before. Remember, OOP = "Obect Oriented Programming", a single concept, hence moving from a procedural to an OOP alignment would surely be "OOP orientated" which is way too clumsy for me
Chris Welsh Send private email
Thursday, September 23, 2004

Aha, the second example has NO private data, so it does not meet the 'private data' requirement.  Still, I would agree 'Utility Class' would describe it.

Concievably, you could have a local object instantiate one 'kind' of Verifier.  You could have several 'kinds' of Verifier 'Utility Classes', and only instantiate the appropriate one(s) when needed.
Thursday, September 23, 2004
It is OOP
FlipFlop Send private email
Thursday, September 23, 2004
So do you *have* to pack these inside a class? :)

Put these procedures inside a namespace and you're happy. No instantiation too.
Alex Send private email
Thursday, September 23, 2004
If its operations without a specific data , than it could be an ADT (Abstract Data Type)

Actually, if you know the developer(s) than why not ask them

Than post their response here so we can argue over how wrong they are! 9^) Just kidding

Any particualr reason your concerned with this code, and the way its written? 

Thursday, September 23, 2004
Interestingly this stateless type of "object" has come back into favour. For instance webservices.
Dennis Forbes Send private email
Thursday, September 23, 2004
"object orientated" is just wrong.

Kind of like saying "Dogtown and Z Boys" but pronouncing it "Dogtown and 'zed' boys", it's just not right, even if it is 'correct'.
Thursday, September 23, 2004
"Any particualr reason your concerned with this code, and the way its written?"

I think their 'overuse' makes an application (ie the one I'm working on) look a little clumsy.

I can't really give any further examples withut pasting 100's of lines of code here (which I can't really do...).
Thursday, September 23, 2004
First of all, this should be in the "Design of Software" forum.  (We need more posts over there!)

Second, netfreak got it right.  Utility methods would be placed in a class where all the methods are static. I'd refer to this as a "static class" (although in java you can't designate a class itself as static ).  I use this quite often to hold my SQL related methods that deal with particular Object typtes.
Thursday, September 23, 2004
<<So do you *have* to pack these inside a class? :)

Put these procedures inside a namespace and you're happy. No instantiation too. >>

Alex,  not all languages require you to instantiate an object before using methods of the class--Perl and PHP come to mind (although, last I checked, Perl classes are simply namespaces anyway, not sure how PHP is implemented) and Java will let you do that with public static methods.
arcturius Send private email
Thursday, September 23, 2004
Reverse inheritance?
I am Jack's object oriented ordination
Thursday, September 23, 2004
Back to origin question

I will prefer prevent using static method as much as possible... there is some side effect you are not expected, like, are you sure it thread safe? static method easier to have thread problem.

You may take a look at
Carfield Yim
Friday, September 24, 2004
In the C++ realm, Scott Meyers has an article making a detailed argument similar to Practical Geezer's, entitled "How Non-Member Functions Improve Encapsulation":

In his Effective C++ series and in Herb Sutter's Exceptional C++ series, some attention is given to making interfaces "complete and minimal".  Defining operations as free functions using public interfaces means less code touching the internals of your class, decreasing the impact of implementation changes.

I find thinking this way also helps me separate concerns into manageable chunks, resulting in an absence of monolithic objects, functions, and subsytems.  Then it's a piece of cake to mix and match pieces and parts to do what I need without juggling excess complexity.  The trick is to determine where the point of diminishing returns is in terms of too much granularity and not enough.
Mike Bland Send private email
Friday, September 24, 2004

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

Other recent topics Other recent topics
Powered by FogBugz