Why architecture with OO methods?

OO methods provide a set of techniques for analyzing, decomposing, and modularizing software system architectures. In general, OO methods are characterized by structuring the system architecture on the basis of its objects (and classes of objects) rather than the actions it performs

Main purpose of these design concepts is to manage software system complexity by improving software quality factors. This provides the following benefits

  • Helps to focus on large-scale system design
  • Separation of design concerns
  • Can identify good domain-specific architectures
  • Design abstraction
  • Have a common language
    • Managerial basis for cost estimation & process mgmt
    • Reuse
    • Consistency and dependency analysis
    • Technical basis for design



Answer this question

Why architecture with OO methods?

  • Lucky_123

    In Juval Lowy's Programming .Net Components he calls OO techniques for reuse white box and component oriented resuse black box with a preference for black box. This text also recommends flat object hierarchies with an emphasis on interfaces as the primary unit of development rather than objects. I'm just gettting started on this style of programming so I can't speak from experience as the pro/con of this.

  • Tony Held

    I find OO to be at the bottom of the process ladder I consider using when implementing a development process.  It has its place, but needs a lot of other techniques to make it valuable in architecture...

    My thoughts are here on a similar topic, you will notice I associate OO with developing by the seat of you pants in the diagram.

    Nothing is wrong with OO and it's an absolute necessary tool, but it creates havoc without the techniques it encapsulates being harnessed and controlled by a process.


  • Czeslaw

    And they make coffee too.

    In my experience, OO is too close to the code to "Help focus on large-sclae system design". It may help separate design concerns at a single package level, beyond that you're getting into component orientation. OO will not help "identify good domain-specific architectures" - rather, if you have a well factored architecture, OO can help you design certain domain-specific parts of it.

    I don't won't to nitpick, so I'll stop there.

    OO is just a tool.

    It's a good tool.

    But it's not the only tool.



  • HouZhenYu

    I am totally agreed with you.

     

    But when I started thinking implementation some concept it’s true I need the tool and others; but in reverse way I have to consider my capacity, tools etc. when I am thinking.

     

    Isn’t one complement to the other

  • Why architecture with OO methods?