Is the opportunity for creating objects limited and often exagerated to the detriment of software at

[thechaosengine]

Hi everyone,

I've been having some discussions with collegues of mine as to what
constitutes an OO design. I don't have a very strong view but was wondering
what everyone else thinks. The two opposing view fell like this:

View 1
In order to be making OO software you should be instantiating lots of
objects and using static methods as little as possible. The people in this
camp believe that if you use static methods, even if those methods are named
after an "object" eg User, then you are essentially programming
procedurally.

For these people, you are only doing the OO thing when objects are getting
instantiated. They arent against static methods per'se, but avoid using them
where possible.

View 2
The notion that you have to instantiate an object in order to be working in
an object oriented manner is bollocks. A lot of the time, especially when it
comes to data access and testing business ruls it just isnt necessary to
instantiate an object. For example, to update a user's address, you could
instantiate an object with the new data and save it from there, or you could
call a static UpdateAddress method.

This camp isnt against instantiating objects. They do it when its useful to
deal with a collection of "things", like a group of users, or permissions or
projects etc, however they find that the opportunity for creating objects is
limited and often exagerated to the detriment of efficiency and perhaps
execution performance.

I'm somewhere in the middle of these two opinions but I've begun to notice
that a lot of the time, business layer classes, even though named after real
world entities, often consist of nothing more than groups of static methods
and little else. Often these classes don't even incorporate constructors.

What do you lot think?


Thanks all

TCE

 

[Nicholas Paldino [.NET/C# MVP]]

Personally, I find view 1 to be pretty extremist, and shy away from it.
I don't think that view 2 is that much better, but it's definitely much
better than the first.

The universe in general has things in it that are static, or for the
sake of argument, things that will be static throughout our lifetime, and
the lifetime of our programs. To that end, I have no problems defining
static operations.

To me instances imply uniqueness, but there are some things that don't
require it (depending on the perspective and the model). It all depends on
the space you are working in. You can always expand the space to transform
ubiquitous things into things that are less so, but if you have to do that,
then perhaps you haven't modelled it correctly.

For example, say you have a type that represents the sky (named Sky).
Do you really need instances of Sky? For most spaces, no (unless you are
NASA). To do otherwise just muddies (is that a word) the code. It's not
natural for me to think that you can have more than one instance of sky, in
almost any space, and there are other things that you can make that same
assumption on as well in your own spaces. To do otherwise just incurs
overhead (in readability, in object construction, in maintinence) that you
do not need.

Hope this helps.

 

[Dmitriy Lapshin [C# / .NET MVP]]

Camp #1 is probably unaware of the Singleton design pattern Actually, an
object with static methods and a Singleton object are pretty similar - in
both cases, only one instance exists. The only difference is that with a
Singleton object you have a 'real' instance of the object.

In general, static objects and/or singletons are appropriate for so called
facades or services - these types of objects usually rather act as a group
of functions rather than represent a business entity.

I think you can find really sound explanations on the Microsoft Patterns and
Practices website.

 

[thechaosengine]

For example, say you have a type that represents the sky (named Sky).

Do you really need instances of Sky?

This is a fair comment, but perhaps not the most accurate in terms at
getting at the root of the disagreement. A better example would be a class
that you could reasonably expect your system to have to deal with several
of. For example, a user, or a project, or a company.

What the two camps disagree on is whether you should go to the trouble of
making a user object or a company object in order to change a back end state
system (read database), or should you forget about objects all together for
the most part, and use static methods to do must of the stuff you need.

Camp 2 really tend to use object instances only as a convienient wrapper for
related information when they want to make that information available to the
outside world in some way. Often, the methods that do business operations on
these convienient wrappers-of-data are completely static and might not even
be declared in the same class as the object that it will operate on.

For example, several "Best Practice" applications that I've been working
with recently, use instantiated entity classes such as CompanyInfo or
UserInfo as nothing more than variable holders.

The design of these applications are characterised by:

- Entity Classes in the "Business Info" Layer
- A business layer that contains classes called things like UserBL,
CompanyBL and so on, that contain all static methods to operate on the
classes from the Business Info layer
- A data layer that contains classes called things like UserDB, CompanyDB
and so on, that again contain all static methods that are called from the
Business Layer and may or may not take instances on the "Info" classes in
order to perform actions on the data store.

Some people believe that the characteristics that I described above are the
OO equivilent of heresey but these examples come straight from Microsoft!

So I'm wondering what developers generally feel about the subject of object
instantiation.

Many thanks for your thoughts so far gentlemen

Kindest Regards

tce

Personally, I find view 1 to be pretty extremist, and shy away from it.
I don't think that view 2 is that much better, but it's definitely much
better than the first.

The universe in general has things in it that are static, or for the
sake of argument, things that will be static throughout our lifetime, and
the lifetime of our programs. To that end, I have no problems defining
static operations.

To me instances imply uniqueness, but there are some things that don't
require it (depending on the perspective and the model). It all depends
on the space you are working in. You can always expand the space to
transform ubiquitous things into things that are less so, but if you have
to do that, then perhaps you haven't modelled it correctly.

For example, say you have a type that represents the sky (named Sky).
Do you really need instances of Sky? For most spaces, no (unless you are
NASA). To do otherwise just muddies (is that a word) the code. It's not
natural for me to think that you can have more than one instance of sky,
in almost any space, and there are other things that you can make that
same assumption on as well in your own spaces. To do otherwise just
incurs overhead (in readability, in object construction, in maintinence)
that you do not need.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi everyone,

I've been having some discussions with collegues of mine as to what
constitutes an OO design. I don't have a very strong view but was
wondering what everyone else thinks. The two opposing view fell like
this:

View 1
In order to be making OO software you should be instantiating lots of
objects and using static methods as little as possible. The people in
this camp believe that if you use static methods, even if those methods
are named after an "object" eg User, then you are essentially programming
procedurally.

For these people, you are only doing the OO thing when objects are
getting instantiated. They arent against static methods per'se, but avoid
using them where possible.

View 2
The notion that you have to instantiate an object in order to be working
in an object oriented manner is bollocks. A lot of the time, especially
when it comes to data access and testing business ruls it just isnt
necessary to instantiate an object. For example, to update a user's
address, you could instantiate an object with the new data and save it
from there, or you could call a static UpdateAddress method.

This camp isnt against instantiating objects. They do it when its useful
to deal with a collection of "things", like a group of users, or
permissions or projects etc, however they find that the opportunity for
creating objects is limited and often exagerated to the detriment of
efficiency and perhaps execution performance.

I'm somewhere in the middle of these two opinions but I've begun to
notice that a lot of the time, business layer classes, even though named
after real world entities, often consist of nothing more than groups of
static methods and little else. Often these classes don't even
incorporate constructors.

What do you lot think?


Thanks all

TCE

 

[Mike Newton]

Camp number 1 has a problem, since it's impossible to get by without a
static method somewhere. In order to execute an application, you need a
static method that represents a singleton: the application itself...
main(). There has to be a first instance of execution that loads those
first objects.

Camp number 2 isn't exactly my style either, since following code that
is sometimes OO, sometimes not is difficult. If you ever happen to look
at the IBuySpy portal, you'll see that it's designed in this way. It
has an entire database class that is filled with static methods. I know
generally where to look for a method, but these types of classes get
large quickly.

It is a matter of organization and legibility to me. I try to
encapsulate all of my data in an object, and use a static method in
those classes to load an instance of one. Ie:

public class X{
public X(){
}

public static X LoadX(){
}
}

So if data is needed, the code that handles the creation and assignment
of that data is kept with the class itself. Submission to the database
should be handled by a Save() method.

I find that this is the best way for me to work, having done both
procedural and mostly static designed stuff. Everything is in it's
place, and if I see an object somewhere in my code, then I know where to
look for it's definition.

I think it's clearer to say:
private X someX = X.LoadX(loadParams);

than to say
private X someX = MyDBClass.LoadX(loadParams);
or
private X someX = new X(loadParams);

Sure, the load function could be handled in the constructor, but I think
that constructors should be used to create new objects, not to load
pre-existing ones. I guess it's just the keyword "new" that bothers me.

Mike

 

[Nicholas Paldino [.NET/C# MVP]]

I actually agree slightly with the so-called heretics =)

I mean, in the end, it's all a moot point, because if the software that
you write works, is easily maintainable, upgradable, stable, etc, etc, then
who cares if it is OO or not?

Right now, I really like the idea of passing typed data sets through the
layers, and having the objects handle verification, persistence, etc, etc.
Granted, they could be static, but I use objects because I want to put them
into COM+ through enterprise services. It's not the ideal OO design, but
the flexibility of DataSets is a wonderful thing, and I find it makes things
much easier in every layer.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

For example, say you have a type that represents the sky (named Sky).
Do you really need instances of Sky?

This is a fair comment, but perhaps not the most accurate in terms at
getting at the root of the disagreement. A better example would be a class
that you could reasonably expect your system to have to deal with several
of. For example, a user, or a project, or a company.

What the two camps disagree on is whether you should go to the trouble of
making a user object or a company object in order to change a back end
state system (read database), or should you forget about objects all
together for the most part, and use static methods to do must of the stuff
you need.

Camp 2 really tend to use object instances only as a convienient wrapper
for related information when they want to make that information available
to the outside world in some way. Often, the methods that do business
operations on these convienient wrappers-of-data are completely static and
might not even be declared in the same class as the object that it will
operate on.

For example, several "Best Practice" applications that I've been working
with recently, use instantiated entity classes such as CompanyInfo or
UserInfo as nothing more than variable holders.

The design of these applications are characterised by:

- Entity Classes in the "Business Info" Layer
- A business layer that contains classes called things like UserBL,
CompanyBL and so on, that contain all static methods to operate on the
classes from the Business Info layer
- A data layer that contains classes called things like UserDB, CompanyDB
and so on, that again contain all static methods that are called from the
Business Layer and may or may not take instances on the "Info" classes in
order to perform actions on the data store.

Some people believe that the characteristics that I described above are
the OO equivilent of heresey but these examples come straight from
Microsoft!

So I'm wondering what developers generally feel about the subject of
object instantiation.

Many thanks for your thoughts so far gentlemen

Kindest Regards

tce

Personally, I find view 1 to be pretty extremist, and shy away from
it. I don't think that view 2 is that much better, but it's definitely
much better than the first.

The universe in general has things in it that are static, or for the
sake of argument, things that will be static throughout our lifetime, and
the lifetime of our programs. To that end, I have no problems defining
static operations.

To me instances imply uniqueness, but there are some things that don't
require it (depending on the perspective and the model). It all depends
on the space you are working in. You can always expand the space to
transform ubiquitous things into things that are less so, but if you have
to do that, then perhaps you haven't modelled it correctly.

For example, say you have a type that represents the sky (named Sky).
Do you really need instances of Sky? For most spaces, no (unless you are
NASA). To do otherwise just muddies (is that a word) the code. It's not
natural for me to think that you can have more than one instance of sky,
in almost any space, and there are other things that you can make that
same assumption on as well in your own spaces. To do otherwise just
incurs overhead (in readability, in object construction, in maintinence)
that you do not need.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi everyone,

I've been having some discussions with collegues of mine as to what
constitutes an OO design. I don't have a very strong view but was
wondering what everyone else thinks. The two opposing view fell like
this:

View 1
In order to be making OO software you should be instantiating lots of
objects and using static methods as little as possible. The people in
this camp believe that if you use static methods, even if those methods
are named after an "object" eg User, then you are essentially
programming procedurally.

For these people, you are only doing the OO thing when objects are
getting instantiated. They arent against static methods per'se, but
avoid using them where possible.

View 2
The notion that you have to instantiate an object in order to be working
in an object oriented manner is bollocks. A lot of the time, especially
when it comes to data access and testing business ruls it just isnt
necessary to instantiate an object. For example, to update a user's
address, you could instantiate an object with the new data and save it
from there, or you could call a static UpdateAddress method.

This camp isnt against instantiating objects. They do it when its useful
to deal with a collection of "things", like a group of users, or
permissions or projects etc, however they find that the opportunity for
creating objects is limited and often exagerated to the detriment of
efficiency and perhaps execution performance.

I'm somewhere in the middle of these two opinions but I've begun to
notice that a lot of the time, business layer classes, even though named
after real world entities, often consist of nothing more than groups of
static methods and little else. Often these classes don't even
incorporate constructors.

What do you lot think?


Thanks all

TCE

 

[Bruce Wood]

First, let me dispense with the "efficiency" argument. People who argue
that you shouldn't use objects because they waste cycles, particularly
when in the next breath they talk about how to handle database back
ends, are blowing smoke. The difference in execution speed and resource
usage for an application that uses objects versus one that largely uses
static methods, when both of them are building queries and heading off
across networks to large database is squat. Nada. Niente. It makes no
difference whatsoever.

If you're doing massive amounts of ray tracing or monitoring a
patient's vital signs, and you talk about whether object instantiation
is worth the CPU hit, I'll listen to you. If you're talking about
optimizing cycles in an app that spends 0.5% of its time in the CPU...
forget it.

That said, what object-versus-procedural arguments come down to in the
end are legibility and maintenance. Which constructs are best applied
in which situations so that the code is easy to understand, and stands
the test of time when the inevitable requirements changes come rolling
down the pipe? This is what it's all about, not CPU cycles or lines of
code. If something is difficult to understand, and every new
requirement that comes down the pipe causes massive headaches and major
re-engineering, then it's a bad solution. If it's readable and new
requirements fit in easily, then it's a good solution. (Yes, sometimes
these two things are at odds. That's what keeps us employed.

Given this, some non-technical and practical considerations come into
the mix. Namely:

What is everyone used to? If everyone in your shop has read the Gang of
Four (Gamma, Helm, Johnson, and Vlissides), then using their design
patterns is a smart thing to do, since everyone looking at your code
will immediately understand what it is you're trying to do. If you have
a shop full of procedural programmers, you may be better off limiting
your use of objects, particularly things foreign to procedural
programmers such as fancy inheritance tricks.

Where does the language help you? Where does it make things difficult?
A good division between objects and statics in Smalltalk may be an
awful solution in C#. The two languages are different and offer you
different strengths. Learn to use the tool and take advantage of its
strengths.

For example, in C#, fully static classes are problematic. You can't
inherit from them in any meaningful way, which means that you can't
describe generic behaviour, which means that you may have missed out on
an opportunity for a clearer design. For example, if your "xxxDB"
classes are all static, then you can't have any sort of meaningful
"DataBaseHandlerParent" class from which they all inherit, which means
that if there is common functionality you either have to code it in
every class, or have a "DBHelper" static class filled with static
helper methods. It's cleaner, easier to maintain, and easier to
understand to use objects instead and take advantage of inheritance.

You also can't pass static classes around. If you make something static
and want to pass it to a method in order to do some operation with it,
you're stuck.

For my part, I say that there's nothing nasty about statics. Use them
where they fit cleanly into your design. However, just because there's
"only one of something" doesn't mean that it should be static. Often it
means that it should be a singleton. Why? Well, how sure are you that
you will never need to pass this thing as an argument? If your answer
is, "I think I might have to," then you need a singleton, not a static
class.

In the end it comes down to experience. Always judge your designs based
on how well they stand up to maintenance. If some system is a nightmare
to maintain, ask yourself why: what did you do in the design that makes
it so difficult to maintain? Screwing up designs is how you learn. "I
used too many objects; won't do that again." Or, "I'm constantly having
to change static classes into singletons and ripple the changes through
my code; I should have used singletons from the start." Learn from your
own mistakes, and listen to people who talk about their own design
mistakes, why they didn't work, and what worked better the next time.

And don't listen to people who ramble on about saving CPU cycles in
business apps unless they're telling the one about the nasty, piggish
app that ran like treacle and sucked CPU resources until they
discovered that....

 

[Tom Dacon]

I think that the answer lies, as it almost always does, somewhere in the
middle, with a little of both extremes sprinkled in to season the dish.
Here's my take on it.

The fundamental pillars that define an object-oriented programming
environment are inheritance, encapsulation, and polymorphism. If the
language that you're using offer those three features, it's a platform in
which you're doing object-oriented programming if you take advantage of
those features to solve your problem. Notice that nothing in the preceding
sentences mention static methods, methodless classes, or any of the other
things you can build with the language. Those features exist to allow you to
model 'real-life' objects in meaningful and useful ways.

Smalltalk, thought by some to be the holy grail of object-oriented
languages, had static members (not by that name, of course) and no one
thought that the feature detracted from its object-oriented purity. The
feature supplied functionality that made sense, and the designers supplied
the static members when they made sense for particular classes. But it was
sparsely implemented.

One of the things that's happened in the last five or ten years or so has
been the rise of web applications, which have considerably different needs
than the desktop applications that used to be the norm. Highly stateful
objects that encapsulate lots of functionality and hang around for long
lifetimes were appropriate for that kind of application. You could do really
intensively object-oriented designs, with rich class hierarchies and
powerful classes that paid for their resource consumption with rich
functionality, closely modeled on the real-world objects that they
represented. If that's the kind of app you develop, good for you. Use the
force, Luke.

On the other hand, a web application, in order to scale well, needs to come
to life, accomplish some task in the minimum time necessary, and then
discard whatever resources it needed for the task, with minimum expense for
the transaction. For an application like this, a class ends up being little
more than a container for procedural code. In its degenerate realization, a
static method happens to be the least expensive way to present the
functionality. When carried to the extreme, implementations like this make
little or no real use of the object-oriented aspects of the programming
language. In VB6-speak, it's like making all your functions and subroutines
global. You could just as easily have done it in C or Fortran, for all the
leverage you're getting out of the object-oriented language.

Nevertheless, the performance demands on web apps are real. To paraphrase
Ted Pattison, who said something like this in a Developmentor class I took
once: If what you care about more than performance is reusability,
maintainability, flexibility, and extensibility; you're a classic
object-oriented programmer; if what you care about is scalability and
performance, you minimize the design of your classes so that they don't get
in the way of your performance needs. (that's a rather extreme paraphrasing,
but I think I got his point across).

Not only does current web development tend to code procedurally, it also
pretty much abandons the n-tier architecture. These days, the datasets and
data readers go right out into the presentation tier, compressing the
valuable (in my opinion) n-tier architecture to the two-tier model that was
so disparaged some years ago. Of course the developers of such applications
would *never* admit that they're doing old-style procedural programming in
the two-tier model.

A couple of specific points:

There's nothing wrong with objects that have properties but no methods, if
they properly model some problem domain object. If it bothers you to use a
class here, consider a struct but think about whether it'll always be happy
living on the stack instead of the heap.

If an object has no state information to retain during its lifetime, it
doesn't make any sense to make it instantiable. In that case, the methods
should all be static. But then, you have to ask, is it really an object? Or
is it just a gathering point for a collection of methods that kind of
'belong together'? And if so, is that all right, or are there better places
for the methods? OO design is an iterative process, and refactoring should
always be in the back of your mind.

And finally, all of the features of languages like C# and VB.Net have their
place. My own personal background has been highly object-oriented but I've
adapted to the realities of web application development, and in my long
journey I think I've discovered a useful application of just about every
feature that the two languages offer. And I just go ahead and use the
feature without apology if it does the job.

I've tried to keep my bias toward classic OO out of my comments above, but I
doubt that I've been successful. If that bothers anyone, so be it.

Tom Dacon
Dacon Software Consulting

 

[thechaosengine]

Thanks everyone who shared their thoughts.

I think like most peoples point of view I tend to fall somewhere in the
middle.

I do definately have a good deal of sympathy with Tom when he's talking
about the difference's in design between web and standalone apps.

Maybe the fact that I've only really been looking at web apps is the reason
that I seem to be noticing so many people using class after class of static
methods

Thanks again everyone

Kindest Regards