OO Considered Harmful

[Richard Dalton .]

Hi,

Sorry this is a bit long.

The world has been slowly abandoning OO, and I didn't
notice.

The more I think about it the more obvious it is to me
that OO just is not suited to n-Tier development.
Perhaps you all new that and I'm a little late to the
party, but I am a bit shocked. Why isn't this causing
more discussion?

The world and it's mother is screaming for OO features in VB
and heralding OO and Component Based development as the
saviour of the industry. Yet the reality seems to be that OO
just isn't up to the job. Particularly from the Middle Tier
back. There may be hope on the client.

The are a few facts to back this up.

1. The old chestnut. Statelesness.
I'm not saying it's a bad thing. It's a fact of
life, you can't maintain state on the middle tier.
What I am saying is that when you remove statelessness
you cut a leg from under OO. after all if you have
to fully populate an objects properties, and then call
a method, and then kill the object, are you really
doing anything more than calling a procedure with
lots of parameters.

2. Object Hierarchies seem to be frowned upon.
The following link describes the ten most common
performance mistakes in DNA apps.

Instantiating Deep and Complex Object Hierarchies is
number one in the list of middle tier errors.

http://msdn.microsoft.com/library/te...namistakes.htm

also from the same article:

"Simply put, designing for the middle tier is not the same as
designing for a traditional object-oriented fat-client
application. The memory allocation associated with creating
objects can be costly, and freeing memory can be even more so,
because of the general practice of attempting to coalesce
adjacent free blocks into larger blocks."

Now think about the way n-tier development has actually
panned out.

The following link describes amongst other things the
Business and Workflow layers (The Middle Tier) of the Duwamish
Books App.

http://msdn.microsoft.com/library/techart/d3blldes.htm

It looks to me like the Business Logic Layer is one object,
with methods like 'GetCustomer', 'GetInventory',
and 'GetOrders'.

Folks, this isn't an object model. It's a module full of
functions. You could have written it in VB3 or QBasic.
or COBOL. (OK, I know you couldn't really write this DLL,
in those languages. I'm talking about the lack of OO
requirements rather than the technicalities.)

The article even refers to it as an API. I know
API is a generic term, but it has a definite meaning to
Windows programmers as being a collection of functions. NOT
OBJECTS.

The Data Access Layer provides a 'GetRecordset' method,
also very procedural, which is not surprising since all it has
to do is talk to stored PROCEDURES.

So, is OO dead? Perhaps it has a place in designing Fat
clients. But it certainly doesn't seem up to the job
of developing Middle Tiers.

Where does this leave UML?

And on the subject of UML, it's interesting that Use Cases
are basically a procedural view of the systems functionality.
No one seems to have found a way of modeling functionality
in OO terms.

BTW, I'm a big OO fan, and will miss it dearly.

-Richard

[chris]

for what its worth, i get the Djikstra reference, but you never actually asserted
anything about oo being harmful - you were simply hinting at its ineffectiveness.


also, i've noticed that most of the posts so far have been vb oriented.
if this is a forum primarily for vb architecture, then i apologize. i am
coming in with very little vb background. i spend all my time with c++.
(perhaps that could account for the difference of opinion?)

see comments below.

"Richard Dalton" . wrote:
>
>
>Hi,
>
> Sorry this is a bit long.
>
> The world has been slowly abandoning OO, and I didn't
> notice.

excuse me? sorry, but i dont see it. now maybe thats because i am involved
in systems software (routers) and not business applications, but i dont see
oo doing anything but gaining momentum.

>
> The more I think about it the more obvious it is to me
> that OO just is not suited to n-Tier development.
> Perhaps you all new that and I'm a little late to the
> party, but I am a bit shocked. Why isn't this causing
> more discussion?

ok....i can see that perhaps interfaces could be a forced fit for
ipc communications between various subsystems. however, all of the standard
techniques for reducing complexity and designing for change would still apply
WITHIN the various tiers/subsystems.

>
> The world and it's mother is screaming for OO features in VB
> and heralding OO and Component Based development as the
> saviour of the industry. Yet the reality seems to be that OO
> just isn't up to the job. Particularly from the Middle Tier
> back. There may be hope on the client.

what is the difference between managing complexity on the client
and managing it on the server? state? state is only part of the picture
when it comes to oo. programming to interfaces is not dependent on the existence
of state in the objects behaving
polymorphically. substantial benefits can still be realized by taking advantage
of dynamic binding.

>
> The are a few facts to back this up.
>
> 1. The old chestnut. Statelesness.
> I'm not saying it's a bad thing. It's a fact of
> life, you can't maintain state on the middle tier.
> What I am saying is that when you remove statelessness
> you cut a leg from under OO. after all if you have
> to fully populate an objects properties, and then call
> a method, and then kill the object, are you really
> doing anything more than calling a procedure with
> lots of parameters.
>
> 2. Object Hierarchies seem to be frowned upon.
> The following link describes the ten most common
> performance mistakes in DNA apps.
>
> Instantiating Deep and Complex Object Hierarchies is
> number one in the list of middle tier errors.

perhaps this is true. but deep and complex object hierarchies are not necessary
to realize the true benefits of oo. eliminating dependencies by developing
to interfaces is the biggest benefit. in other words, reduction of complexity
is what oo brings to the table. and any subsystem can benefit from reduction
of complexity.

>
> http://msdn.microsoft.com/library/te...namistakes.htm
>
>also from the same article:
>
> "Simply put, designing for the middle tier is not the same as
> designing for a traditional object-oriented fat-client
> application. The memory allocation associated with creating
> objects can be costly, and freeing memory can be even more so,
> because of the general practice of attempting to coalesce
> adjacent free blocks into larger blocks."

as can allocating and freeing any intrinsic data types. i'm not
sure what the point is here other than we must be mindful of memory management
issues with regard to frequently allocated objects (intrinsic or not!)

>
> Now think about the way n-tier development has actually
> panned out.
>
> The following link describes amongst other things the
> Business and Workflow layers (The Middle Tier) of the Duwamish
> Books App.
>
> http://msdn.microsoft.com/library/techart/d3blldes.htm
>
> It looks to me like the Business Logic Layer is one object,
> with methods like 'GetCustomer', 'GetInventory',
> and 'GetOrders'.
>
> Folks, this isn't an object model. It's a module full of
> functions. You could have written it in VB3 or QBasic.
> or COBOL. (OK, I know you couldn't really write this DLL,
> in those languages. I'm talking about the lack of OO
> requirements rather than the technicalities.)

you are absolutely right. to the outside world, the subsystem
looks like a single object. its a pattern known as facade (ref
the GOF book). however, if there is any significant complexity
within the subsystem (functionality that is not necessarily visible from
the outside), doubtless it can be mitigated to a large extent through the
dependency management techniques available in oo design - whether those internal
object designs are visible to external clients of the subsystem or not.

>
> The article even refers to it as an API. I know
> API is a generic term, but it has a definite meaning to
> Windows programmers as being a collection of functions. NOT
> OBJECTS.

the most important thing about an object is its publically exposed interface.
i dont see it as being a huge stretch to refer to that as the api of the
object. again - especially when the module is implementing the facade pattern.

>
> The Data Access Layer provides a 'GetRecordset' method,
> also very procedural, which is not surprising since all it has
> to do is talk to stored PROCEDURES.
>
> So, is OO dead? Perhaps it has a place in designing Fat
> clients. But it certainly doesn't seem up to the job
> of developing Middle Tiers.

in my opinion, oo has a place in any large system when dependency and complexity
management are an issue.

>
> Where does this leave UML?
>
> And on the subject of UML, it's interesting that Use Cases
> are basically a procedural view of the systems functionality.
> No one seems to have found a way of modeling functionality
> in OO terms.
>
> BTW, I'm a big OO fan, and will miss it dearly.
>
>-Richard
>
>
>

perhaps i am just coming from a different world. i have very little experience
with vb. and i dont care very much about dna or .net. i also do very little
business app development. instead i spend most of my time on systems software.
i do, however, design very large scale systems primarily for windows nt
in c++ and find the benefits of oo tremendous.

i dont see oo going away in my world.

-- Chris

[Marc D'Aoust]

Object Oriented Programming is hardly dead .. just displaced.

In a distributed, component based system, interaction between component may
not be "object oriented", but the internal implementation of components can
be.

If you consider components (business components, as we define them) to be
reusable pieces of business logic, them it makes sense to think of them in a
black box/white box view. From a black box point of view, what you see is an
exposed interface(s) with function such as getEmployee, or processPay. From
a white box view, the internals of the component might be object oriented,
with objects maintaining state just long enough for the processing to be
completed and then being released.

I do agree with that the "end-to-end" object oriented application has no
future in distributed system. What does work is a highbrid of component
based architecture and object oriented technology.

At OSTnet we've developed the middleware, technology, process and tools to
enable us to do just that type of development. We've designed a highbrid
process based on UP, OPEN, Catalysis and OOSE and use technology like XML,
SOAP, and XSL to enables us to develop these component/object highbrid
systems efficiently.

As for UML, it's alive and well, and will not go away any time soon.
Remember that UML can easily be extended using stereotypes. Packages can be
stereotypes as "Subsystems", "Business Components" and "Facades", and can
contain classes which represent the object oriented internals.

For more information see books like:

- Business Component Factory, by Peter Herzum and Oliver Simms, from Wiley
- Software Reuse, by Ivar Jacobson et. al., from Addison Wesley

- Objects, Components, and Frameworks with UML, The Catalysis Approach, by
Desmond Francis D'Souza and Alan Cameron Wills, from Addison Wesley.

--
Marc D'Aoust
Vice-President, Research and Development
OSTnet OpenSource Technologies Inc

mailto:marc@ostnet.com

OSTnet develops software and subcontracts much of the work to registered
developers over the Internet. Members of www.ostnet.com are free to view all
company projects open for tender (in the Projects section of the Developer
Home) and can apply to work on these projects. We prequalify all of our
members to determine their level and areas of expertise. Please feel free to
sign up at your leisure and write the exams in order to qualify yourself for
OSTnet projects.


<Richard Dalton .> wrote in message news:3a41067e$1@news.devx.com...
>
>
> Hi,
>
> Sorry this is a bit long.
>
> The world has been slowly abandoning OO, and I didn't
> notice.
>
> The more I think about it the more obvious it is to me
> that OO just is not suited to n-Tier development.
> Perhaps you all new that and I'm a little late to the
> party, but I am a bit shocked. Why isn't this causing
> more discussion?
>
> The world and it's mother is screaming for OO features in VB
> and heralding OO and Component Based development as the
> saviour of the industry. Yet the reality seems to be that OO
> just isn't up to the job. Particularly from the Middle Tier
> back. There may be hope on the client.
>
> The are a few facts to back this up.
>
> 1. The old chestnut. Statelesness.
> I'm not saying it's a bad thing. It's a fact of
> life, you can't maintain state on the middle tier.
> What I am saying is that when you remove statelessness
> you cut a leg from under OO. after all if you have
> to fully populate an objects properties, and then call
> a method, and then kill the object, are you really
> doing anything more than calling a procedure with
> lots of parameters.
>
> 2. Object Hierarchies seem to be frowned upon.
> The following link describes the ten most common
> performance mistakes in DNA apps.
>
> Instantiating Deep and Complex Object Hierarchies is
> number one in the list of middle tier errors.
>
> http://msdn.microsoft.com/library/te...namistakes.htm
>
> also from the same article:
>
> "Simply put, designing for the middle tier is not the same as
> designing for a traditional object-oriented fat-client
> application. The memory allocation associated with creating
> objects can be costly, and freeing memory can be even more so,
> because of the general practice of attempting to coalesce
> adjacent free blocks into larger blocks."
>
> Now think about the way n-tier development has actually
> panned out.
>
> The following link describes amongst other things the
> Business and Workflow layers (The Middle Tier) of the Duwamish
> Books App.
>
> http://msdn.microsoft.com/library/techart/d3blldes.htm
>
> It looks to me like the Business Logic Layer is one object,
> with methods like 'GetCustomer', 'GetInventory',
> and 'GetOrders'.
>
> Folks, this isn't an object model. It's a module full of
> functions. You could have written it in VB3 or QBasic.
> or COBOL. (OK, I know you couldn't really write this DLL,
> in those languages. I'm talking about the lack of OO
> requirements rather than the technicalities.)
>
> The article even refers to it as an API. I know
> API is a generic term, but it has a definite meaning to
> Windows programmers as being a collection of functions. NOT
> OBJECTS.
>
> The Data Access Layer provides a 'GetRecordset' method,
> also very procedural, which is not surprising since all it has
> to do is talk to stored PROCEDURES.
>
> So, is OO dead? Perhaps it has a place in designing Fat
> clients. But it certainly doesn't seem up to the job
> of developing Middle Tiers.
>
> Where does this leave UML?
>
> And on the subject of UML, it's interesting that Use Cases
> are basically a procedural view of the systems functionality.
> No one seems to have found a way of modeling functionality
> in OO terms.
>
> BTW, I'm a big OO fan, and will miss it dearly.
>
> -Richard
>
>
>

[Richard Dalton .]

"chris" <chofstaedter@padcomusa.com> wrote:
>for what its worth, i get the Djikstra reference, but you never >actually
asserted anything about oo being harmful - you were >simply hinting at its
ineffectiveness.

Yes, sorry. Djikstra was asserting that Goto was dangerous.
I was simply pointing out that OO seems to be very unsuited to middleware
development.

>also, i've noticed that most of the posts so far have been vb >oriented.
if this is a forum primarily for vb architecture, >then i apologize.

I think that may be that the posters including me have
a VB background. But no the board should be about
architecture. Ideally it should be language independant.

>however, all of the standard techniques for reducing
>complexity and designing for change would still apply
>WITHIN the various tiers/subsystems.

Interesting point. I think what you are suggesting is a
number of object oriented sub sustems with essentially
procedural interfaces.

>> and heralding OO and Component Based development as the
>> saviour of the industry. Yet the reality seems to be that OO
>> just isn't up to the job. Particularly from the Middle Tier
>> back. There may be hope on the client.
>
>what is the difference between managing complexity on the >client and managing
it on the server? state? state is only >part of the picture

As I see it, there's more freedom to maintain and manipulate
objects on the client. You're not sharing your processor
with countless other users, so even if OO has a performance
problem you can get away with it.

Essentially I think the trade off between performance and
OO purity can fall a little closer to OO purity on the
client, but on the server performance is king.

>when it comes to oo. programming to interfaces is not >dependent on the
existence of state in the objects behaving
>polymorphically. substantial benefits can still be realized by >taking
advantage of dynamic binding.

Agreed, interfaces and polymorphism kick proverbial ***.
Again I have to point out I love OO. I just don't see
a whole lot of it in DNA. I see tiers that are full of
funtions. Yes I take the point about the internal structure
of the Tiers.

>> "Simply put, designing for the middle tier is not the same
>> as designing for a traditional object-oriented fat-client
>> application. The memory allocation associated with creating
>> objects can be costly, and freeing memory can be even more
>> so, because of the general practice of attempting to
>> coalesce adjacent free blocks into larger blocks."

>as can allocating and freeing any intrinsic data types.
>i'm not sure what the point is here other than we must be >mindful of memory
management issues with regard to frequently >allocated objects (intrinsic
or not!)

Well from what I can see instntiating Objects is particularly
painfull. At least until the object has been pooled.
We're not just talking about a few seconds wait here.

>> Folks, this isn't an object model. It's a module full of
>> functions. You could have written it in VB3 or QBasic.
>> or COBOL. (OK, I know you couldn't really write this DLL,
>> in those languages. I'm talking about the lack of OO
>> requirements rather than the technicalities.)
>
>you are absolutely right. to the outside world, the subsystem
>looks like a single object. its a pattern known as facade (ref
>the GOF book).

Yes, you're right. It's a great example of the Facade Pattern.
I guess I always liked the idea of an object model which
had object that I could instantiate and manipulate.
I like the idea of being able to manipulate software objects
that reflect the problem domain.

My Ideal n-Tier architecture would be an object model like
the one I just described, which I could access from various
Clients (Web, VB/Delphi/VC++, VBA App).

I had the crazy idea that each tier should expose an object
model, not simply a collection of routines.

Perhaps I can create a frontline collection of objects that
my client apps can manipulate, but all tiers behind that would
expose a facade. I must admit this is different to what I imagined, and
it's different to what many books on the
subject propose. Most books have the concept of objects
which mirror each other on the various tiers, and pass object
state between them.

>the most important thing about an object is its publically >exposed interface.
i dont see it as being a huge stretch to >refer to that as the api of the
object. again - especially >when the module is implementing the facade pattern.

Yes, I wasn't questioning the suitability of the term. I
just thought it was indicative of the mindset. The term API
for windows developers evokes thoughts of the Windows API.
At least it does for me. But it's a perfectly suitable
term even for a fully Object Oriented interface.

>> So, is OO dead? Perhaps it has a place in designing Fat
>> clients. But it certainly doesn't seem up to the job
>> of developing Middle Tiers.
>
>in my opinion, oo has a place in any large system when >dependency and complexity
management are an issue.

What about when performance is an issue, and resources
are at a premium? I don't know the answer to this.
But these seem to be the factors driving middleware thinking.


-Richard

[Pierre G. Boutquin]

Yes, you are correct pure OO, as you found out, doesn't scale at internet
levels. When you need to support 10,000 concurrent users, you need to be
careful with server resources. Pure OO lacks the concept of network trip and
per client cost.

<p/>

[chris]

>>> and heralding OO and Component Based development as the
>>> saviour of the industry. Yet the reality seems to be that OO
>>> just isn't up to the job. Particularly from the Middle Tier
>>> back. There may be hope on the client.
>>
>>what is the difference between managing complexity on the >client and managing
>it on the server? state? state is only >part of the picture
>
>As I see it, there's more freedom to maintain and manipulate
>objects on the client. You're not sharing your processor
>with countless other users, so even if OO has a performance
>problem you can get away with it.

this is really an issue of the nature of the class structure. if the designer
is intent on creating a per user / task / transaction object on a large scale
server, then yes - there will be scalability problems. but this is the same
with all such servers. for example, a common first mistake among developers
designing their first socket server is to spawn
a thread per request. this obviously creates scalability problems. a better
alternative is to use a thread pool. the same issues apply to objects modeling
transaction systems or any other high volume server. the class structure
should support high volume processing (i.e. avoid churning object lifetimes).

>
>Essentially I think the trade off between performance and
>OO purity can fall a little closer to OO purity on the
>client, but on the server performance is king.

agreed. but to assume oo design results in lesser performance characteristics
is an invalid assumption. a class is state and behavior. in a non-oo approach
you still have state and behavior - its just packaged differently. what
we are saying here is that we cant afford to re-instantiate the state over
and over again on a performance critical server - whether that state is packaged
in a structure or an object. yes, absolutely true. but a good design (oo
or not) will take that into account. again, oo design is about dependency
management - not about modelling the "physical world" of the problem domain.
there is nothing about oo design that says we have to re-create objects
that represent each transaction/user/task.

>>> "Simply put, designing for the middle tier is not the same
>>> as designing for a traditional object-oriented fat-client
>>> application. The memory allocation associated with creating
>>> objects can be costly, and freeing memory can be even more
>>> so, because of the general practice of attempting to
>>> coalesce adjacent free blocks into larger blocks."
>
>>as can allocating and freeing any intrinsic data types.
>>i'm not sure what the point is here other than we must be >mindful of memory
>management issues with regard to frequently >allocated objects (intrinsic
>or not!)
>
>Well from what I can see instntiating Objects is particularly
>painfull. At least until the object has been pooled.
>We're not just talking about a few seconds wait here.

again i refer to the fact that on a performance critical server, designing
a per task/user/transaction object is a bad design - and not necessarily
implied by oo.

>>> So, is OO dead? Perhaps it has a place in designing Fat
>>> clients. But it certainly doesn't seem up to the job
>>> of developing Middle Tiers.
>>
>>in my opinion, oo has a place in any large system when >dependency and
complexity
>management are an issue.
>
>What about when performance is an issue, and resources
>are at a premium? I don't know the answer to this.
>But these seem to be the factors driving middleware thinking.

when performance is an issue (as on a server tier) the object design of the
server most likely should not mimic the object design on the client. server
tiers should avoid per task object instantiation.

i am beginning to see that the disconnect is the feeling that it is necessary
to design the server with a per-task object. absolutely not. but that doesnt
mean that the complexity inherent in such a server subsystem cant provide
substantial benefits.

-- Chris

[chris]

"Pierre G. Boutquin" <boutquin@home.com> wrote:
>Yes, you are correct pure OO, as you found out, doesn't scale at internet
>levels. When you need to support 10,000 concurrent users, you need to be
>careful with server resources. Pure OO lacks the concept of network trip
and
>per client cost.
>
><p/>
>
>

i disagree. some oo designs may lack those concepts, but that doesnt imply
that there is no way to design an oo system that do take such issues into
account.

i think the problem may be the commonly held notion that oo designs must
somehow match the "physical world" of the problem domain. not so. "pure
oo design" (as you say) is about managing dependencies.

for example, if you are truly interested in high performance and very scalable
oo design patterns for distributed systems, i would refer you to the patterns
laid out by the "Adaptive Computing Environment" managed by Doug Schmidt.

http://128.252.165.3/~schmidt/ACE-papers.html

-- Chris

[Pierre G. Boutquin]

"chris" <chofstaedter@padcomusa.com> wrote in message
news:3a420ddf$1@news.devx.com...
> i think the problem may be the commonly held notion that oo designs must
> somehow match the "physical world" of the problem domain. not so. "pure
> oo design" (as you say) is about managing dependencies.

We're making academic distinctions here.

IMO, pure OO keeps the data and methods associated with an entity (which may
or may not match a physical entity) in one programming structure. However,
this leads to fat entities which aren't always appropriate as they have a
high per instance cost. To achieve scalibility, sometimes one needs to
resort to thin, stateless entities. This, IMO again, isn't pure OO, but a
compromise, not unlike denormaling a relational design.

Most of this is now common knowledge and documented in many fine books, such
as D. Schmidt's book.

<Pierre />

[Thomas Eyde]

The most "pure" OO environment I have encountered is the implementation of
XP (Extreme Programming) in the Smalltalk community. Smalltalk does only
have objects, it is impossible to program anything without them.

And XP favours lean and mean classes. I fail to see how OO leads to fat
entities. Yes I see the danger, but that is more a design issue than OO
itself.

In an N-tier architecture you need small classes for scaleability; OO can do
that. You also need a mechanism to save network roundtrips. A stremaing
class would do the job.

/Thomas

"Pierre G. Boutquin" <boutquin@home.com> wrote in message
news:3a442262$1@news.devx.com...
>
> IMO, pure OO keeps the data and methods associated with an entity (which
may
> or may not match a physical entity) in one programming structure. However,
> this leads to fat entities which aren't always appropriate as they have a
> high per instance cost. To achieve scalibility, sometimes one needs to
> resort to thin, stateless entities. This, IMO again, isn't pure OO, but a
> compromise, not unlike denormaling a relational design.

[Richard Dalton .]

"chris" <chofstaedter@padcomusa.com> wrote:
>agreed. but to assume oo design results in lesser performance >characteristics
is an invalid assumption.

I guess just like there's good and bad programming practices,
there are good and bad OO practices. OO in and of itself won't
give you performance or make it impossible to achieve
performance. But unless you use the right flavour of OO you will
hit problems.

I think the idea behind my original post was that the Basic
Vanilla flavoured OO doesn't really work well in a distributed
n-tier, web architecture. We need to use a different flavour.
I just don't hear a lot of people talking about what exactly
that other flavour entails.

Of course the idea of optimizing code for speed is something of
a lost art in the business world. When you are building a small
VB app that will run on machines like we have today, you don't
need to think about performance so much. However if you are
building a scalable web app little performance issues are
magnified to the point that they become a serious problem.

Perhaps the web will get programmers back to what they used to be
able to do. Squeeze every last ounce of performance out of the
equipment and tools that they have.

Interestingly though, when programmers of old wanted to
squeeze performance out of their machines they often did
it by ignoring practices that made code easy to work with. They
would code routines inline rather than call procedures, they
would unroll loops, etc.

Perhaps the modern equivalent would be to shun OO coding
techniques, and regress to procedural code. That was my
initial point.

Incidently, I refer to the programmers of old as "They" because
while "they" were unrolling loops, I was writing Basic code on a
Sinclair spectrum, and not optimizing any of it.

-Richard

(darin) Maybe you've read some of the articles talking about the way that
you have to build n tier systems (stateless methods, etc etc). Then you
compare that with SOAP (running a stateless method call through an HTTP
send, response sequence) and you start to see that the whole component model
has only one place, internal to a single machine.

I spent almost a year trying to make DCOM, then MTS work for a project. It
wasn't stable, anytime we changed a single method signature, it broke dang
near everything, etc, etc.

The web doesn't have these kinds of problems.

I finally broke down, bought a good set of TCPIP tools (Dart) and coded up
the exact same stuff, using a very HTTP oriented send/response type
architecture (it would be relatively easy to make it really look like HTTP,
I just haven't yet). It took 2 weeks.

We've had this system up for months now, I can any method siguature I want,
whenever I want and I never break the client side. Further, this design
works easily over the internet and through firewalls (I've got complete
control over what ports are in use without a lot of nasty registry hacks).
By using an ActiveX exe server and they right layout, it's even
multithreaded, and I've got complete control over the thread pooling, object
lifetime, etc.

Is it as fast as DCOM or MTS. Not quite. But then I haven't spent any time
making it fast yet, only making sure it works reliably.

Sorry, I'm rambling. In the end, I thing the whole OO paradigm is flawed
with respect to the web. It's just not the right thing. Send-response style
messaging is, but as with many things, if you don't write it yourself,
you're at the mercy of whatever (often lame) decisions that went into the
products you're using.




> I think the idea behind my original post was that the Basic
> Vanilla flavoured OO doesn't really work well in a distributed
> n-tier, web architecture. We need to use a different flavour.
> I just don't hear a lot of people talking about what exactly
> that other flavour entails.

[news.devx.com]

Richard - if it has anything to do with VB - your comments are right on.
However - I would strongly suggest you dig out your VS cd sets and pop in
CD1 and install Visual FoxPro - it's an oop-ish kinda development
environment that you could learn to love....
mondo regards [Bill]
<Richard Dalton .> wrote in message news:3a41067e$1@news.devx.com...
>
>
> Hi,
>
> Sorry this is a bit long.
>
> The world has been slowly abandoning OO, and I didn't
> notice.
[snipped for brevity]

[David K.]

"Richard Dalton" . wrote:
>

> The world and it's mother is screaming for OO features in VB
> and heralding OO and Component Based development as the
> saviour of the industry. Yet the reality seems to be that OO
> just isn't up to the job. Particularly from the Middle Tier
> back. There may be hope on the client.
>

As you pointed out, OO isn't the silver bullet that some people make it out
to be. I think that OO has been hyped up so much that when it inevitably
doesn't live up to expectations, people are disappointed.

> The are a few facts to back this up.
>
> 1. The old chestnut. Statelesness.
> I'm not saying it's a bad thing. It's a fact of
> life, you can't maintain state on the middle tier.
> What I am saying is that when you remove statelessness
> you cut a leg from under OO. after all if you have
> to fully populate an objects properties, and then call
> a method, and then kill the object, are you really
> doing anything more than calling a procedure with
> lots of parameters.
>

You're right. Objects are defined as being state plus behavior. If you
were to remove state then an object loses part of what makes it an object.
However, I think you are wrong when you say that you can't maintain state
on the middle tier.

First of all, you are assuming that the middle tier is a web server that
is serving up pages to a browser front end. There is nothing that says that
this is the only middle tier configuration. There are other ways to tie
the middle tier to the presentation layer.

Second, even if you are using a web server to serve up HTML, it is possible
to maintain state between pages. ASP, for instance, gives you a "Session"
object which allows you to track page requests for a given session. I believe
Java servlets and JSP have a similar setup.

Third, even if you couldn't maintain state between pages, you sill may want
your object to maintain its state within a page. This is much messier if
you used straight procedures since you would need to passs around a "state
variable" to all of the procedures.

Fourth, if you are using ASP, it's better to offload your logic into COM
objects since A. the COM object is compiled rather than interpreted. and
B. you could reuse the COM object in another ASP page or with a "fat-client"
presentation layer.


> 2. Object Hierarchies seem to be frowned upon.
> The following link describes the ten most common
> performance mistakes in DNA apps.
>
> Instantiating Deep and Complex Object Hierarchies is
> number one in the list of middle tier errors.
>
> http://msdn.microsoft.com/library/te...namistakes.htm
>
>also from the same article:
>
> "Simply put, designing for the middle tier is not the same as
> designing for a traditional object-oriented fat-client
> application. The memory allocation associated with creating
> objects can be costly, and freeing memory can be even more so,
> because of the general practice of attempting to coalesce
> adjacent free blocks into larger blocks."
>

I think this issue would come up whether or not your allocating memory via
an object or just allocating ints and floats on the fly. In fact, it might
be better to allocate the memory in the object since ASP only allows you
to create variant variables which, by their nature, are heavier than a straight
int or float.

When you implement a web server middle tier with a thin client, by its nature,
you are doing a lot of work on the server which would have been done on the
client machine in a "fat-client" situation. Rather than executing the logic
on hundreds or thousands of client machines, that logic is all done on a
single server machine. This puts a premium on performance on the web server
above else! Because ASP is interpreted script it isn't high performance.
Anything that you do, whether it's creating objects or calling procedures,
needs to be kept to a minimum in the ASP script. That being said, putting
your code into COM objects is still better because of some of the reasons
listed above.

> Now think about the way n-tier development has actually
> panned out.
>
> The following link describes amongst other things the
> Business and Workflow layers (The Middle Tier) of the Duwamish
> Books App.
>
> http://msdn.microsoft.com/library/techart/d3blldes.htm
>
> It looks to me like the Business Logic Layer is one object,
> with methods like 'GetCustomer', 'GetInventory',
> and 'GetOrders'.
>
> Folks, this isn't an object model. It's a module full of
> functions. You could have written it in VB3 or QBasic.
> or COBOL. (OK, I know you couldn't really write this DLL,
> in those languages. I'm talking about the lack of OO
> requirements rather than the technicalities.)
>

I agree with you. That doesn't look like a good use of objects.

> The article even refers to it as an API. I know
> API is a generic term, but it has a definite meaning to
> Windows programmers as being a collection of functions. NOT
> OBJECTS.
>

Good point, although you may be nit picking here. :-)


> The Data Access Layer provides a 'GetRecordset' method,
> also very procedural, which is not surprising since all it has
> to do is talk to stored PROCEDURES.
>
> So, is OO dead? Perhaps it has a place in designing Fat
> clients. But it certainly doesn't seem up to the job
> of developing Middle Tiers.
>

One other thing that I should point out is that the Windows DNA model makes
HEAVY use of objects. ASP uses objects (session, request, response). You
communicate with the data tier through ADO which is an object model. Your
business logic goes into COM objects that can be called from ASP. If you
are using a browser presentation layer, you can manipulate the browser with
DHTML, another object model. If you have a "fat-client" presentation layer
you use Windows objects, button objects, etc, and these UI objects can communicate
with the same business objects you are calling from the ASP.

> Where does this leave UML?
>
> And on the subject of UML, it's interesting that Use Cases
> are basically a procedural view of the systems functionality.
> No one seems to have found a way of modeling functionality
> in OO terms.
>

That's a good point too. It's interesting how natural it is to write down
instructions in procedure form, and how unnatural it is to write them in
"object" form. When was the last time you saw a recipe that looked like:
"Egg.CrackOpen, Egg.EmptyContentsInBowl".


> BTW, I'm a big OO fan, and will miss it dearly.
>

Don't throw away your Booch book just yet!!

>-Richard
>
>

Thanks for an interesting post!

David K.
>

[Dave Kraft]

> Second, even if you are using a web server to serve up HTML, it is
possible
> to maintain state between pages. ASP, for instance, gives you a "Session"
> object which allows you to track page requests for a given session. I
believe
> Java servlets and JSP have a similar setup.
Almost every book and speaker I've read/heard say that the Session object is
evil, that it should be avoided at all costs because you can't use it if you
have multiple servers in a web farm. I try to stay away from it as much as
possible.

Just my 2 cents...

Dave Kraft
Web Developer
TSR Solutions, Inc.
www.tsrnet.com

[Richard Dalton .]

Before reading this, here's a few specific questions:

1. How would you rate the design of Duwamish Online?

2. Does it represent a good model which should be followed
by web developers?

3. What factors do you think most drove the design?
(Performance, Maintainability, Evolution from previous
design.


Now on with the post


"David K." <davidk@nospam.com> wrote:
> I think that OO has been hyped up so much that when it
> inevitably doesn't live up to expectations, people are
> disappointed.

Hype! In the IT industry!
Surely you jest.

>First of all, you are assuming that the middle tier is a web >server that
is serving up pages to a browser front end. There >is nothing that says
that this is the only middle tier >configuration.

Yes you are right. I was leveling my sights on the Web type
apps because that's what everyone seems to be focusing on
as the future. Having said that, browser based apps are
not my biggest concern at the moment.

I bought into the theory of a layer of business objects
onto which we could build any presentation layer.
(Browser, Fat App, VBA, Whatever...)

But for this to work you have to code for the thinnest of these
i.e the Browsser. No point creating an architecture for
FAT Clients and then expecting to stick a browser on the front.

That's where my interest in Browser apps comes from.

>Second, even if you are using a web server to serve up HTML, it
>is possible to maintain state between pages. ASP, for
>instance, gives you a "Session" object which allows you to
>track page requests for a given session.

Intuitively it seems to me that the more "state" you keep per
session, the less sessions you can have.
Same old State Vs Scaleability debate.

Also session variables are effectively Global variables. Not the most Object
Oriented of concepts.

>Third, even if you couldn't maintain state between pages, you >sill may
want your object to maintain its state within a page. >This is much messier
if you used straight procedures since you >would need to passs around a "state
>variable" to all of the procedures.

Yes that's a good point. It means objects become useful ways
of grouping properties. i.e structs. Again though we are back to something
that was quite common in procedural programming.

>Fourth, if you are using ASP, it's better to offload your logic
>into COM objects since A. the COM object is compiled rather
>than interpreted. and B. you could reuse the COM object in
>another ASP page or with a "fat-client" presentation layer.

Absolutely. I detest putting code in ASP pages. In fact
I resent almost every line I write unless it is to do with
formatting or displaying text.

My knowledge of DNA is limited to what I can glean from the Microsoft site
(mainly reading about Duwamish), but in DNA you do move as much logic as
possible from the ASP to COM objects.

My question is how do you represent that logic in COM objects.
Intuitively I would go for lots of objects which model the real
world to some extent. But what I am seeing is fewer objects
which do little more than expose methods (often unrelated).


>> The article even refers to it as an API. I know
>> API is a generic term, but it has a definite meaning to
>> Windows programmers as being a collection of functions. NOT
>> OBJECTS.
>>
>
>Good point, although you may be nit picking here. :-)

Yeah, you're probably right.


>One other thing that I should point out is that the Windows DNA
>model makes HEAVY use of objects. ASP uses objects (session,
>request, response). You communicate with the data tier through
>ADO which is an object model. Your business logic goes into
>COM objects that can be called from ASP. If you are using a
>browser presentation layer, you can manipulate the browser with
>DHTML, another object model. If you have a "fat-client"
>presentation layer you use Windows objects, button objects,
>etc, and these UI objects can communicate with the same
>business objects you are calling from the ASP.

That's a good point. You can't avoid objects even if you wanted
to, and that will be all the more true in a .Net world.

Interestingly though, I don't think any of the object models
that microsoft provides are cross process. I'm probably
wrong about this, but the list you gave is dominated by
Statefull objects. Could that be the core of the problem.

The reality is that statelessness other problems with OO
arise because we want to break the object and have it run
in two different places. We're asking objects to scale to
a new dimension. Maybe OO as we know it isn't suited to this
new dimension and we need to rewrite the cook book.


>Don't throw away your Booch book just yet!!

Rumbaugh actually. ;-)


-Richard