OO Considered Harmful


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 3 123 LastLast
Results 1 to 15 of 34

Thread: OO Considered Harmful

  1. #1
    Richard Dalton . Guest

    OO Considered Harmful



    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




  2. #2
    chris Guest

    Re: OO Considered Harmful


    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


  3. #3
    Marc D'Aoust Guest

    Re: OO Considered Harmful

    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
    >
    >
    >




  4. #4
    Richard Dalton . Guest

    Re: OO Considered Harmful


    "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

  5. #5
    Pierre G. Boutquin Guest

    Re: OO Considered Harmful

    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/>



  6. #6
    chris Guest

    Re: OO Considered Harmful


    >>> 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

  7. #7
    chris Guest

    Re: OO Considered Harmful


    "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

  8. #8
    Pierre G. Boutquin Guest

    Re: OO Considered Harmful

    "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 />



  9. #9
    Thomas Eyde Guest

    Re: OO Considered Harmful

    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.





  10. #10
    Richard Dalton . Guest

    Re: OO Considered Harmful


    "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


  11. #11
    Guest

    Re: OO Considered Harmful

    (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.





  12. #12
    news.devx.com Guest

    Re: OO Considered Harmful

    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]



  13. #13
    David K. Guest

    Re: OO Considered Harmful


    "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.
    >



  14. #14
    Dave Kraft Guest

    Re: OO Considered Harmful

    > 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



  15. #15
    Richard Dalton . Guest

    Re: OO Considered Harmful



    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center