• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Liutauras Vilda
Sheriffs:
  • Paul Clapham
  • Jeanne Boyarsky
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
Bartenders:
  • Jesse Duncan
  • Frits Walraven
  • Mikalai Zaikin

brittle coupling

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
can anyone plz explain me what is meant by 'brittle coupling' ?
thanx in advance
regards
vasan
 
mister krabs
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
From the IBM DeveloperWorks web site:
A new architectural approach
Traditional systems architectures incorporate relatively brittle coupling between various components in the system. The bulk of IT systems, including Web-oriented systems, can be characterized as tightly coupled applications and subsystems. IBM CICS transactions, databases, reports, and so on are built with tight coupling, using data structures (database records, flat files).
Monolithic systems like these are sensitive to change. A change in the output of one of the subsystems will often cause the whole system to break. A switch to a new implementation of a subsystem will also often cause old, statically bound collaborations (which unintentionally relied on the side effects of the old implementation) to break down. This situation is manageable to a certain extent through skills and numbers of people. As scale, demand, volume, and rate of business change increase, this brittleness becomes exposed. Any significant change in any one of these aspects will cause the brittleness of the systems to become a crisis: unavailable or unresponsive Web sites, lack of speed to market with new products and services, inability to rapidly shift to new business opportunities, or competitive threats. IT organizations will not be able to cope with changes because of the coupling; the dynamics of the Web makes management of these brittle architectures untenable.
We need to replace the current models of application design with a more flexible architecture, yielding systems that are more amenable to change.
 
Rancher
Posts: 1449
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If your classes/components know too much about each other then when you make a change to one you break code all over the place.
John
 
Ranch Hand
Posts: 532
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sounds like another term for tightly coupled to me.
 
vasan dinesh
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hai All!
thanx for the valuable expalnations. i had this doubt regarding this question posted in ibm mock exam for OOAD
Question no diagrams needed for this question)
In design #1, the Catalog object has a getProducts() method, which returns a collection object, such as a Dictionary or array, containing all the Products the company sells. In design #2, the Catalog object has a getProductNumbered(anIdentifier) method, which returns the Product with the specified unique identifier. Considering the objects returned, which of the following BEST characterizes the two designs?

a) Both designs maintain the objects' encapsulation and reduce coupling by accessing state data via methods only and not directly.

b) Both designs break the objects' encapsulation, adding brittle coupling.

c) Design #1 breaks the encapsulation of the Catalog, adding brittle coupling. Design #2 maintains the encapsulation of the Catalog, making future design changes easier.

i feel choice 'a' is right
i am not sure how the design 1 adds brittle coupling.
can anyone throw more light on this plz
thanx
vasan
 
Ranch Hand
Posts: 111
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is a challenge question. The problem is the objective is not very clear. What's the purpose of the get method. Most of time, a class should provide both methods as they are used for different purposes.
"Considering the objects returned", as asked in the question, I tend to think c is the correct one. Why? because getProducts() return a collection then there is a strong coupling among the objects in the collection.
How do you think? Thanks.
Laojar
 
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Laojar,
What you're saying seems to make sense, but I'm still waiting for the light to come on.
------------------
David Roberts, SCJP2
 
pie. tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic