Loading ...
Sorry, an error occurred while loading the content.
 

Improving “Service Access” for better Agile programming

Expand Messages
  • chiluvuri1
    I have been working on unique processes for past few years, mainly focusing on minimizing dependencies between the parts in the applications. At this time, it
    Message 1 of 18 , Oct 27, 2006
      I have been working on unique processes for past few years,
      mainly focusing on minimizing dependencies between the parts in the
      applications. At this time, it is purely academic research, but may
      turn into products some time in the future.

      I think, the software applications are complex NOT because
      individual Parts (e.g. Objects, Modules or subsystems) are complex,
      but the interactions between them are nearly impossible to track,
      document or comprehend. These untraceable inter-dependencies grow
      exponentially with size of the software application and they are
      nearly impossible to comprehend, hence increases the complexity
      exponentially.

      I think, the complexity of an application can be expressed as
      a function of sum of the dependencies of each part in the
      application. I think, only way we can control the complexity is by
      minimizing the dependencies between the parts in the application.

      I think, I have found a way to accomplish that for building
      next generation graphics intensive online applications. I think,
      these processes compliment Agile programming.
      http://www.cbsdf.com/service-access/3D-Board.htm
      http://www.cbsdf.com/ps_blog/service-access.htm
      http://www.cbsdf.com/technologies/misc-docs/Dependencies-OOP-Vs-
      LC_Parts.htm
      http://www.cbsdf.com/technologies/misc-docs/physical-encapsulation.htm

      I greatly appreciate non-inflammatory academic inputs on the
      process, in the Agile programming perspective. I have been working on
      these processes for several years and the website has many examples
      to prove that the processes work. But, I have very little experience
      in Aglie processes, so your suggestions are well come.

      Best Regards,
      Raju
    • Charlie Poole
      Hello Raju, ... Interesting stuff, but I m curious why you chose this list if you only want academic input. Or perhaps I just don t understand what you mean.
      Message 2 of 18 , Oct 27, 2006
        Hello Raju,

        > I greatly appreciate non-inflammatory academic inputs
        > on the process, in the Agile programming perspective.

        Interesting stuff, but I'm curious why you chose this list
        if you only want "academic" input. Or perhaps I just don't
        understand what you mean.


        Charlie
      • geoffrey_slinker
        Raju, Thank you for your post. You have spent a lot of time working on these ideas. Because you have spent so much time your understanding of the problem you
        Message 3 of 18 , Oct 27, 2006
          Raju,

          Thank you for your post. You have spent a lot of time working on these
          ideas. Because you have spent so much time your understanding of the
          problem you describe and your focus on this problem puts you on a
          level higher than mine.

          "In Component Based Software development you state:
          In OOP, developer is neither explicitly designs nor aware of the
          existence of "loosely coupled" component. Each component is build
          using many Objects, where the Object usually tightly coupled with
          neighboring Objects and often hard to trace its dependencies/coupling.
          Therefore, to remove a component, he often needs to employee trail and
          error to trace dependencies for each of the Objects."

          In my opinion (IMO) overly coupled or irrational dependencies are not
          a function of Object Oriented or Procedural. It is the results of a
          person, a human being, that has made a choice. Further training and
          experience could improve this person's ability to recognize irrational
          dependencies and how dependencies affect the cost of changing software.

          Does your system eliminate the ability for a person to improperly
          couple components?

          You state:
          "If the Object is referred in more than one file, then the Object ends
          up with more irrational-dependencies. If you aggregate all the
          dependencies of all the Objects, you get the total dependency of the
          component. This dependency grows exponentially, if the component has
          many subcomponents, and these subcomponents in turn have subcomponents
          of their own and so on. This explains why it is practically impossible
          to replace a large component in large systems. On the other hand, each
          "Loosely coupled" part would have dependency of about 5 lines of
          "readily identifiable" code."

          If an object or a data structure is passed along from one method to
          another and it goes deeper and deeper into the system you have deep
          coupling. Object or data structure. This isn't a problem that is
          exclusive to OOP.

          You state:
          " If we (software engineers) need to make a modification, we need to
          waste 9 to 25 times on tasks that could be avoided, if we had avoided
          the untraceable spaghetti code. If we avoided the spaghetti code in
          the first place, we could have reduced the cost of the software
          application by more than 50%. This is equivalent, to building more
          reliable and long lasting light bulb at less than 50% of the cost,
          which consumes 10% of the power."

          Avoiding spaghetti code, monolithic routines that are huge, global
          variables, go-to's, etc., are all things that developers should do.

          Does your system make it impossible to develop spaghetti code?
          Components are made of code, so what is is that would stop me from
          making a component that is spaghetti? What would stop me from making a
          component that is one big black box but it would have been better to
          make it of many subcomponents? At what level is the "view" coarse
          enough or fine enough?

          You state:
          "Service provider usually determines factors or form of the artificial
          dependency. For example, a software component vendor may build and
          sell a reusable-shopping cart (e.g. An Invoice Table or Spreadsheet)
          for online mall. It may provide services, such as, add an item to the
          Invoice (i.e. Shopping cart), when visitor purchases an item from an
          online catalog. The Invoice needs the item's data (e.g. Price,
          Discounts, Description and/or Size), which is a real dependency.

          The Shopping cart may define one or more data formats to communicate
          the data, such as, an XML-Schema and a Data-object (or
          record/structure). Then, an interacting component (e.g. shopping item
          in the online-catalog) must send its data in one of the supported
          formats, to properly add the item to the shopping cart. If the
          shopping-item sends a data string that contains all the data pieces
          separated by comma, the service request fails because the shopping
          cart cannot properly understand the no-compliant data format."

          So, we use Webservices, SOAP, and WSDL's to address the "format"
          problem. Even though I do a lot of Webservice development it is just
          another way to push the problem around. For instance with a webservice
          I can "get" the WSDL and generate proxy classes that define the
          interface into the system. The parameters are usually "built in types"
          or you can give hints to the serializer on how to break up your
          object/structure. But ultimately it is a pure data transfer, no OO
          stuff here. The proxy doesn't have any behavior, just data, and the
          underpinnings to send the data via soap to the service.

          There are methods for extending webservices with versioning and the
          such, but the coupling to the interface still exists. If you add a
          parameter to a webservice it isn't has hard to support as it is when
          you remove a parameter.

          Your analogies to the automotive industry, lightbulbs, etc.., are
          informative but I feel that Software development has been around long
          enough that we can speak in terms of software development and do not
          need to rely on manufacturing analogies so much. I would like to see
          more software examples personally.

          You state:
          "While coding, even after full design, many nagging thoughts often
          linger in our minds, such as: Does it really user need? Did I get this
          requirement right? Is there any better way to do? May be some users
          need it differently? Should I implement both and let them choose using
          a flag or configuration-file?

          One thing always happened to me that, as soon as, I have finished the
          full module or soon after first demo to the user or in the design
          review, I can see many other improvement I can do to make it far
          better, only if I can go back and do it again.

          All the pondering and nagging thought during the weeks, while we
          design and develop various parts of the application, would certainly
          give any one lot of insights and far better picture on user needs,
          potential work flow processes and of course software design. For
          example, these factors certainly allow us to have far more intelligent
          conversation with the user and fellow developers. I cannot understate
          to usefulness of leveraging this expertise to iteratively refine the
          software."

          You asked how your ideas compare to Agile development. The above
          statements cover important aspects of Agile development.

          Iterative development is key. Shortening the time between a customer's
          request to seeing running code is key.

          Your statement about pondering and nagging thought during weeks...
          that tells me that you are too far removed from your customer. Shorten
          this time.


          I personally believe that experimentation is a good way to figure out
          things and to progress incrementally in an iterative fashion.

          http://en.wikipedia.org/wiki/Software_Scouting_and_Reconnaissance

          As for your complaints against OOP I would suggest some comparisons to
          Inversion of Control, Dependency Injection, how virtual methods are
          used with the Open/Closed principle, interfaces and pure abstract
          classes and other various OO and Procedural techniques. I am not
          saying you are wrong or right I just don't see enough evidence that
          shows that OO is part of the problem.

          Thanks for sharing,

          Geoff Slinker

          http://digerati-illuminatus.blogspot.com/
        • chiluvuri1
          Geoff Slinker: I enjoyed reading very insightful comments and analysis. Let me explain, a basic limitation of OOP or traditional programming paradigm, which
          Message 4 of 18 , Oct 29, 2006
            Geoff Slinker:

            I enjoyed reading very insightful comments and analysis. Let
            me explain, a basic limitation of OOP or traditional programming
            paradigm, which preventing us from "minimizing coupling". The XML
            based languages (e.g. SVG, X3D, Vista/XAML, Adobe's MXML/Flex and
            even DHTML/Ajax) have unique characteristics, which can overcome that
            limitation.

            To understand this part, the application is the webpage.
            Server side Java is just a factory, which generate the product: the
            webpage. Due to historical reasons, we are calling it webpage, but we
            will be creating complex WebPages containing 2D/3D components, which
            will be more complex than the desktop applications. If you build a
            real-time battle-field simulation, where do the fighter-jets fly?
            They fly in the client; hence, we think the WebPage is the
            application. Some people may disagree, but for this discussion,
            please accept the WebPage is the application.

            One of the basic requirements for the "Loosely coupled"
            components are:
            The "loosely coupled" components are included in the application. The
            basic requirement for the "loosely coupled" component is that it must
            be a portable code block. Furthermore, we must be able to combine
            them not manually, but programmatically to build larger and larger
            components. This resultant component must be a again portable code
            block.

            To be a plug-n-play part, one must be able to remove any part
            with very little possible effort. The MOST IMPORTANT requirement is
            that: when I remove a part, all its subcomponents and their
            subcomponents must effectively be removed. This can be accomplished,
            if the part physically-encapsulates all its subcomponents.

            This physical hierarchical-encapsulation of subcomponents is
            not possible for the OOP. Where as in the XML, each subcomponent is a
            node in the DOM-tree for respective container component.

            Hence, I think, Java is not very good language to
            implement "Loosely coupled" parts. The XML (e.g. SVG, DHTML or XAML)
            is perfect language. Of course, as I said in one of the pages, one
            may create "loosely coupled" parts in Java, if we make some changes
            to the Java language compilers. It is bit hard and awkward to create
            such component hierarchy, which is also again portable block of code,
            in Java programming alone with out the "GENERATIVE INDIRECTION".

            If you look at the interactions at "Component" (e.g. shopping-
            cart and shopping-items) level, they often very simple and intuitive.
            In fact they closely mirror the design document and requirements. If
            that is the case, why cannot a business analyst employ a CASE tool to
            assemble the application from the parts? Of course, it is possible,
            if all the custom parts are available (they must be custom created to
            predefined interfaces). Until we can implement such CASE tools we
            must live with manual coding to generate the 5 or so line of coupling
            code. http://www.cbsdf.com/ps_blog/super-distribution.htm

            The figures#15-17 in the following webpage highlights the
            difference between the OOP and CBSDF. Please think, what is the
            effort needed to replace any one of the there components:
            http://www.cbsdf.com/technologies/misc-docs/CF-LC-Figures.htm

            This is one of my Objectives: since we are writing code that
            writes the application, why cannot we embed generic processes to
            detect broken interfaces. This is one of the advantages of
            the "GENERATIVE INDIRECTION" that we can automate many repetitive
            tasks by employing generic tools (This offers huge benefits, but I
            haven't yet made any progress here).

            Often, to comprehend the difference one must experience the
            difference. If possible, next time, when you are building an OOP
            application, see if you can build the large and larger components by
            physically encapsulating respective subcomponents. I am not asking
            you to implement that way, just spend few hours and try to do that
            way. Then compare that, how we can do this in CBSDF:
            http://cbsdf.com/misc_docs/Can-u-prove.htm (Please note that the
            three city-hierarchies is the important proof). You know that most
            real commercials products need several man years of effort. If one
            has trouble implementing such simple few GUI components, how could
            any one implement large GUI applications?

            P.S: I have also made changes to: http://www.cbsdf.com/service-
            access/3D-Board.htm

            What do you think?

            Best Regards,
            Raju

            --- In extremeprogramming@yahoogroups.com, "geoffrey_slinker"
            <geoffrey_slinker@...> wrote:
            >
            > Raju,
            >
            > Thank you for your post. You have spent a lot of time working on
            these
            > ideas. Because you have spent so much time your understanding of the
            > problem you describe and your focus on this problem puts you on a
            > level higher than mine.
            >
            > "In Component Based Software development you state:
            > In OOP, developer is neither explicitly designs nor aware of the
            > existence of "loosely coupled" component. Each component is build
            > using many Objects, where the Object usually tightly coupled with
            > neighboring Objects and often hard to trace its
            dependencies/coupling.
            > Therefore, to remove a component, he often needs to employee trail
            and
            > error to trace dependencies for each of the Objects."
            >
            > In my opinion (IMO) overly coupled or irrational dependencies are
            not
            > a function of Object Oriented or Procedural. It is the results of a
            > person, a human being, that has made a choice. Further training and
            > experience could improve this person's ability to recognize
            irrational
            > dependencies and how dependencies affect the cost of changing
            software.
            >
            > Does your system eliminate the ability for a person to improperly
            > couple components?
            >
            > You state:
            > "If the Object is referred in more than one file, then the Object
            ends
            > up with more irrational-dependencies. If you aggregate all the
            > dependencies of all the Objects, you get the total dependency of the
            > component. This dependency grows exponentially, if the component has
            > many subcomponents, and these subcomponents in turn have
            subcomponents
            > of their own and so on. This explains why it is practically
            impossible
            > to replace a large component in large systems. On the other hand,
            each
            > "Loosely coupled" part would have dependency of about 5 lines of
            > "readily identifiable" code."
            >
            > If an object or a data structure is passed along from one method to
            > another and it goes deeper and deeper into the system you have deep
            > coupling. Object or data structure. This isn't a problem that is
            > exclusive to OOP.
            >
            > You state:
            > " If we (software engineers) need to make a modification, we need to
            > waste 9 to 25 times on tasks that could be avoided, if we had
            avoided
            > the untraceable spaghetti code. If we avoided the spaghetti code in
            > the first place, we could have reduced the cost of the software
            > application by more than 50%. This is equivalent, to building more
            > reliable and long lasting light bulb at less than 50% of the cost,
            > which consumes 10% of the power."
            >
            > Avoiding spaghetti code, monolithic routines that are huge, global
            > variables, go-to's, etc., are all things that developers should do.
            >
            > Does your system make it impossible to develop spaghetti code?
            > Components are made of code, so what is is that would stop me from
            > making a component that is spaghetti? What would stop me from
            making a
            > component that is one big black box but it would have been better to
            > make it of many subcomponents? At what level is the "view" coarse
            > enough or fine enough?
            >
            > You state:
            > "Service provider usually determines factors or form of the
            artificial
            > dependency. For example, a software component vendor may build and
            > sell a reusable-shopping cart (e.g. An Invoice Table or Spreadsheet)
            > for online mall. It may provide services, such as, add an item to
            the
            > Invoice (i.e. Shopping cart), when visitor purchases an item from an
            > online catalog. The Invoice needs the item's data (e.g. Price,
            > Discounts, Description and/or Size), which is a real dependency.
            >
            > The Shopping cart may define one or more data formats to communicate
            > the data, such as, an XML-Schema and a Data-object (or
            > record/structure). Then, an interacting component (e.g. shopping
            item
            > in the online-catalog) must send its data in one of the supported
            > formats, to properly add the item to the shopping cart. If the
            > shopping-item sends a data string that contains all the data pieces
            > separated by comma, the service request fails because the shopping
            > cart cannot properly understand the no-compliant data format."
            >
            > So, we use Webservices, SOAP, and WSDL's to address the "format"
            > problem. Even though I do a lot of Webservice development it is just
            > another way to push the problem around. For instance with a
            webservice
            > I can "get" the WSDL and generate proxy classes that define the
            > interface into the system. The parameters are usually "built in
            types"
            > or you can give hints to the serializer on how to break up your
            > object/structure. But ultimately it is a pure data transfer, no OO
            > stuff here. The proxy doesn't have any behavior, just data, and the
            > underpinnings to send the data via soap to the service.
            >
            > There are methods for extending webservices with versioning and the
            > such, but the coupling to the interface still exists. If you add a
            > parameter to a webservice it isn't has hard to support as it is when
            > you remove a parameter.
            >
            > Your analogies to the automotive industry, lightbulbs, etc.., are
            > informative but I feel that Software development has been around
            long
            > enough that we can speak in terms of software development and do not
            > need to rely on manufacturing analogies so much. I would like to see
            > more software examples personally.
            >
            > You state:
            > "While coding, even after full design, many nagging thoughts often
            > linger in our minds, such as: Does it really user need? Did I get
            this
            > requirement right? Is there any better way to do? May be some users
            > need it differently? Should I implement both and let them choose
            using
            > a flag or configuration-file?
            >
            > One thing always happened to me that, as soon as, I have finished
            the
            > full module or soon after first demo to the user or in the design
            > review, I can see many other improvement I can do to make it far
            > better, only if I can go back and do it again.
            >
            > All the pondering and nagging thought during the weeks, while we
            > design and develop various parts of the application, would certainly
            > give any one lot of insights and far better picture on user needs,
            > potential work flow processes and of course software design. For
            > example, these factors certainly allow us to have far more
            intelligent
            > conversation with the user and fellow developers. I cannot
            understate
            > to usefulness of leveraging this expertise to iteratively refine the
            > software."
            >
            > You asked how your ideas compare to Agile development. The above
            > statements cover important aspects of Agile development.
            >
            > Iterative development is key. Shortening the time between a
            customer's
            > request to seeing running code is key.
            >
            > Your statement about pondering and nagging thought during weeks...
            > that tells me that you are too far removed from your customer.
            Shorten
            > this time.
            >
            >
            > I personally believe that experimentation is a good way to figure
            out
            > things and to progress incrementally in an iterative fashion.
            >
            > http://en.wikipedia.org/wiki/Software_Scouting_and_Reconnaissance
            >
            > As for your complaints against OOP I would suggest some comparisons
            to
            > Inversion of Control, Dependency Injection, how virtual methods are
            > used with the Open/Closed principle, interfaces and pure abstract
            > classes and other various OO and Procedural techniques. I am not
            > saying you are wrong or right I just don't see enough evidence that
            > shows that OO is part of the problem.
            >
            > Thanks for sharing,
            >
            > Geoff Slinker
            >
            > http://digerati-illuminatus.blogspot.com/
            >
          • chiluvuri1
            Charlie: I am still working on improving the process and like to get Agile programmers perspective. Best Regards, Raju
            Message 5 of 18 , Oct 29, 2006
              Charlie:

              I am still working on improving the process and like to get Agile
              programmers perspective.

              Best Regards,
              Raju

              --- In extremeprogramming@yahoogroups.com, "Charlie Poole" <xp@...>
              wrote:
              >
              > Hello Raju,
              >
              > > I greatly appreciate non-inflammatory academic inputs
              > > on the process, in the Agile programming perspective.
              >
              > Interesting stuff, but I'm curious why you chose this list
              > if you only want "academic" input. Or perhaps I just don't
              > understand what you mean.
              >
              >
              > Charlie
              >
            • Willem Bogaerts
              ... OOP does not enforce coupling. In fact, some of the OO principles are specially targeted at too-tight-cloupled systems. ... With the fear that you might
              Message 6 of 18 , Oct 29, 2006
                > ... Let
                > me explain, a basic limitation of OOP or traditional programming
                > paradigm, which preventing us from "minimizing coupling".

                OOP does not enforce coupling. In fact, some of the OO principles are
                specially targeted at too-tight-cloupled systems.

                > The XML
                > based languages (e.g. SVG, X3D, Vista/XAML, Adobe's MXML/Flex and
                > even DHTML/Ajax) have unique characteristics, which can overcome that
                > limitation.

                With the fear that you might see this as a flame: This sentence would
                score high in a game of buzzword bingo. Most of these abbreviations are
                poorly supported or specially designed to circumvene standards. If I
                recall correctly, the X3D company took over the VRML consortium to
                replace VRML with their own "standard". Especially in reducing coupling,
                you can learn a lot from VRML's event structure.
                XML is not magic, and it is not the answer to the question of Life,
                Universe and Everything. It can be very graciously written and parsed by
                object structures, but that is the least used characteristic of XML.
                It's just a data format. Nothing unique about that.

                > To understand this part, the application is the webpage.
                > Server side Java is just a factory, which generate the product: the
                > webpage. Due to historical reasons, we are calling it webpage, but we
                > will be creating complex WebPages containing 2D/3D components, which
                > will be more complex than the desktop applications. If you build a
                > real-time battle-field simulation, where do the fighter-jets fly?

                In your mind, off course. Or on your screen.

                > They fly in the client; hence, we think the WebPage is the
                > application.

                And suddenly we have a client-server application. Is that necessary? and
                if it is, we should probably take other clients into account. This means
                that only the server can determine the flight characteristics, because
                it connects to multiple clients.

                > Some people may disagree, but for this discussion,
                > please accept the WebPage is the application.

                Only for a very broad definition of "WebPage". If we battle against each
                other using clients, the application resides on the server.

                > One of the basic requirements for the "Loosely coupled"
                > components are:
                > The "loosely coupled" components are included in the application. The
                > basic requirement for the "loosely coupled" component is that it must
                > be a portable code block.

                Funny you say that. The buzzword line is full of hardly supported
                formats and systems, so they are not portable at all. And if you
                hardwire even the fine-grained components of the clients to a server,
                then you have a real coupling problem. The only thing I see is an overly
                tight coupled situation, not a loosely coupled one.

                > Furthermore, we must be able to combine
                > them not manually, but programmatically to build larger and larger
                > components. This resultant component must be a again portable code
                > block.

                Then how would you do that? You can update the server or call other
                parts from the server, but updating a plugin / dependency to the client
                is not going to be easy and it is certainly not nice.

                > To be a plug-n-play part, one must be able to remove any part
                > with very little possible effort. The MOST IMPORTANT requirement is
                > that: when I remove a part, all its subcomponents and their
                > subcomponents must effectively be removed. This can be accomplished,
                > if the part physically-encapsulates all its subcomponents.

                So if you use a subcomponent as well, you have a problem? Libraries have
                dependencies as well. If I share a library into my code (using my source
                code control system), it contains everything I need, or uses other
                libraries and contains just the enhancement of those. When I remove it,
                it is gone. It was just a link anyway. Off course, all _references_ to
                that library are harder to remove. And I want to be able to decide for
                myself how to remove them, so this should not be done automatically.

                > This physical hierarchical-encapsulation of subcomponents is
                > not possible for the OOP.

                Why not? I do that all the time. Any decent source code control system
                will help, but even that is not necessary.

                > Where as in the XML, each subcomponent is a
                > node in the DOM-tree for respective container component.

                Lots of object structures are tree-shaped as well. There's really no
                difference.

                > Hence, I think, Java is not very good language to
                > implement "Loosely coupled" parts. The XML (e.g. SVG, DHTML or XAML)
                > is perfect language.

                It's a format. Not a programming language.

                > Of course, as I said in one of the pages, one
                > may create "loosely coupled" parts in Java, if we make some changes
                > to the Java language compilers. It is bit hard and awkward to create
                > such component hierarchy, which is also again portable block of code,
                > in Java programming alone with out the "GENERATIVE INDIRECTION".

                You can create loosely coupled object structures without messing with
                the compiler. If you mean that you want to be able to run all sorts of
                code from different remote sources, then you just create other system
                dependencies. Especially webservices can be a great pain. They can
                change interface, go off-line and do all sorts of nasty things without
                you having any control over it. That is not what I call "Loose
                coupling". On the contrary.

                > If you look at the interactions at "Component" (e.g. shopping-
                > cart and shopping-items) level, they often very simple and intuitive.
                > In fact they closely mirror the design document and requirements. If
                > that is the case, why cannot a business analyst employ a CASE tool to
                > assemble the application from the parts?

                Because the hard and interesting parts are not in the business analyst's
                scope? The business analyst leaves the details to a programmer. That's why.

                > Of course, it is possible,
                > if all the custom parts are available (they must be custom created to
                > predefined interfaces). Until we can implement such CASE tools we
                > must live with manual coding to generate the 5 or so line of coupling
                > code. http://www.cbsdf.com/ps_blog/super-distribution.htm
                >
                > The figures#15-17 in the following webpage highlights the
                > difference between the OOP and CBSDF. Please think, what is the
                > effort needed to replace any one of the there components:
                > http://www.cbsdf.com/technologies/misc-docs/CF-LC-Figures.htm
                >
                > This is one of my Objectives: since we are writing code that
                > writes the application, why cannot we embed generic processes to
                > detect broken interfaces. This is one of the advantages of
                > the "GENERATIVE INDIRECTION" that we can automate many repetitive
                > tasks by employing generic tools (This offers huge benefits, but I
                > haven't yet made any progress here).

                Wait a minute. You compile a program to... compile itself at _runtime_.
                If your program is compiled, it should not be bothered with interfaces.
                Broken interfaces do not compile. Only if your application depends on
                another system that it has no control over, it has to do those things.
                This is where you feel the pain of tight coupling to the unknown.

                > Often, to comprehend the difference one must experience the
                > difference. If possible, next time, when you are building an OOP
                > application, see if you can build the large and larger components by
                > physically encapsulating respective subcomponents. I am not asking
                > you to implement that way, just spend few hours and try to do that
                > way. Then compare that, how we can do this in CBSDF:
                > http://cbsdf.com/misc_docs/Can-u-prove.htm (Please note that the
                > three city-hierarchies is the important proof). You know that most
                > real commercials products need several man years of effort. If one
                > has trouble implementing such simple few GUI components, how could
                > any one implement large GUI applications?

                I do not have the luxury of being able to install all kinds of plugins
                on clients. My application should just work. Even without javascript
                enabled on the client. And especially with reasonable security settings.
                So while I do use javascript, it is just to make things run more
                smoothly. Just like a 747 has powered controls, but can be flown by hand
                if necessary.

                A few last questions though: If you have so many dependencies on other
                systems, how on earth are you going to write unit tests for them? Do you
                have special tests to see what browser dependencies there are, and do
                you offer alternatives for non-supported plugin dependencies?
                And, if you want to check the interfaces at runtime, do you run the
                remote system's unit tests at runtime as well? And what do you do if
                they fail?


                Best regards,
                Willem Bogaerts
              • chiluvuri1
                Bogaerts, Each and every aspect of your questions was addressed in our website. I cannot repeat all that here again. If you like to know the answers, please
                Message 7 of 18 , Oct 29, 2006
                  Bogaerts,

                  Each and every aspect of your questions was addressed in our
                  website. I cannot repeat all that here again. If you like to
                  know the answers, please review the website. I am not asking you to
                  read all that, but it would be nice, if you take time to see if the
                  answers to all the questions are already provided.

                  I have said it is academic, so I don't have to use main
                  stream programming languages. Having said that, Vector Based graphics
                  languages are likely going to be main stream soon after the release
                  of Vista. Vista is big endorsement, since biggest vendor for
                  traditional GUI technologies abandoned that in favor of XAML/WPF/E,
                  an XML based graphics language.

                  Based on your questions, I don't think you have read any of
                  the information in our web site. Just saying XML based languages,
                  don't make it buzz word. It is inflammatory. All of your stamens are
                  argumentative, and I don't want to go into arguments.

                  Only time will tell who is right. If I am right, some people
                  use our GUI-API to build 2D/3D online GUI application, which quickly
                  leads to the proof for the CBSDF. I have spent years to make sure
                  that I am absolutely right. But time may prove me wrong (and my
                  effort since 1999 and nearly fulltime since 2003 goes down the
                  drain).

                  If I am right, software developers could cut software cost by
                  70%. We could see great looking GUI application in our web browsers.

                  So you and I disagree, as gentlemen may do. It would be
                  helpful, if you could try to see in others perspective before
                  criticizing with sound bites, if it doesn't make sense in your
                  perspective. It is a complex problem, which requires hard work to
                  validate. Perhaps, if you try to duplicate, some of the DHTML or SVG
                  component hierarchy examples in our web site, in VC++ or UNIX/Motif,
                  you would know the limitations of OOP.

                  Regards,
                  Raju

                  --- In extremeprogramming@yahoogroups.com, Willem Bogaerts <w-p@...>
                  wrote:
                  >
                  > > ... Let
                  > > me explain, a basic limitation of OOP or traditional programming
                  > > paradigm, which preventing us from "minimizing coupling".
                  >
                  > OOP does not enforce coupling. In fact, some of the OO principles
                  are
                  > specially targeted at too-tight-cloupled systems.
                  >
                  > > The XML
                  > > based languages (e.g. SVG, X3D, Vista/XAML, Adobe's MXML/Flex and
                  > > even DHTML/Ajax) have unique characteristics, which can overcome
                  that
                  > > limitation.
                  >
                  > With the fear that you might see this as a flame: This sentence
                  would
                  > score high in a game of buzzword bingo. Most of these abbreviations
                  are
                  > poorly supported or specially designed to circumvene standards. If
                  I
                  > recall correctly, the X3D company took over the VRML consortium to
                  > replace VRML with their own "standard". Especially in reducing
                  coupling,
                  > you can learn a lot from VRML's event structure.
                  > XML is not magic, and it is not the answer to the question of Life,
                  > Universe and Everything. It can be very graciously written and
                  parsed by
                  > object structures, but that is the least used characteristic of
                  XML.
                  > It's just a data format. Nothing unique about that.
                  >
                  > > To understand this part, the application is the webpage.
                  > > Server side Java is just a factory, which generate the product:
                  the
                  > > webpage. Due to historical reasons, we are calling it webpage,
                  but we
                  > > will be creating complex WebPages containing 2D/3D components,
                  which
                  > > will be more complex than the desktop applications. If you build
                  a
                  > > real-time battle-field simulation, where do the fighter-jets fly?
                  >
                  > In your mind, off course. Or on your screen.
                  >
                  > > They fly in the client; hence, we think the WebPage is the
                  > > application.
                  >
                  > And suddenly we have a client-server application. Is that
                  necessary? and
                  > if it is, we should probably take other clients into account. This
                  means
                  > that only the server can determine the flight characteristics,
                  because
                  > it connects to multiple clients.
                  >
                  > > Some people may disagree, but for this discussion,
                  > > please accept the WebPage is the application.
                  >
                  > Only for a very broad definition of "WebPage". If we battle against
                  each
                  > other using clients, the application resides on the server.
                  >
                  > > One of the basic requirements for the "Loosely coupled"
                  > > components are:
                  > > The "loosely coupled" components are included in the application.
                  The
                  > > basic requirement for the "loosely coupled" component is that it
                  must
                  > > be a portable code block.
                  >
                  > Funny you say that. The buzzword line is full of hardly supported
                  > formats and systems, so they are not portable at all. And if you
                  > hardwire even the fine-grained components of the clients to a
                  server,
                  > then you have a real coupling problem. The only thing I see is an
                  overly
                  > tight coupled situation, not a loosely coupled one.
                  >
                  > > Furthermore, we must be able to combine
                  > > them not manually, but programmatically to build larger and
                  larger
                  > > components. This resultant component must be a again portable
                  code
                  > > block.
                  >
                  > Then how would you do that? You can update the server or call other
                  > parts from the server, but updating a plugin / dependency to the
                  client
                  > is not going to be easy and it is certainly not nice.
                  >
                  > > To be a plug-n-play part, one must be able to remove any part
                  > > with very little possible effort. The MOST IMPORTANT requirement
                  is
                  > > that: when I remove a part, all its subcomponents and their
                  > > subcomponents must effectively be removed. This can be
                  accomplished,
                  > > if the part physically-encapsulates all its subcomponents.
                  >
                  > So if you use a subcomponent as well, you have a problem? Libraries
                  have
                  > dependencies as well. If I share a library into my code (using my
                  source
                  > code control system), it contains everything I need, or uses other
                  > libraries and contains just the enhancement of those. When I remove
                  it,
                  > it is gone. It was just a link anyway. Off course, all _references_
                  to
                  > that library are harder to remove. And I want to be able to decide
                  for
                  > myself how to remove them, so this should not be done automatically.
                  >
                  > > This physical hierarchical-encapsulation of subcomponents is
                  > > not possible for the OOP.
                  >
                  > Why not? I do that all the time. Any decent source code control
                  system
                  > will help, but even that is not necessary.
                  >
                  > > Where as in the XML, each subcomponent is a
                  > > node in the DOM-tree for respective container component.
                  >
                  > Lots of object structures are tree-shaped as well. There's really
                  no
                  > difference.
                  >
                  > > Hence, I think, Java is not very good language to
                  > > implement "Loosely coupled" parts. The XML (e.g. SVG, DHTML or
                  XAML)
                  > > is perfect language.
                  >
                  > It's a format. Not a programming language.
                  >
                  > > Of course, as I said in one of the pages, one
                  > > may create "loosely coupled" parts in Java, if we make some
                  changes
                  > > to the Java language compilers. It is bit hard and awkward to
                  create
                  > > such component hierarchy, which is also again portable block of
                  code,
                  > > in Java programming alone with out the "GENERATIVE INDIRECTION".
                  >
                  > You can create loosely coupled object structures without messing
                  with
                  > the compiler. If you mean that you want to be able to run all sorts
                  of
                  > code from different remote sources, then you just create other
                  system
                  > dependencies. Especially webservices can be a great pain. They can
                  > change interface, go off-line and do all sorts of nasty things
                  without
                  > you having any control over it. That is not what I call "Loose
                  > coupling". On the contrary.
                  >
                  > > If you look at the interactions at "Component" (e.g. shopping-
                  > > cart and shopping-items) level, they often very simple and
                  intuitive.
                  > > In fact they closely mirror the design document and requirements.
                  If
                  > > that is the case, why cannot a business analyst employ a CASE
                  tool to
                  > > assemble the application from the parts?
                  >
                  > Because the hard and interesting parts are not in the business
                  analyst's
                  > scope? The business analyst leaves the details to a programmer.
                  That's why.
                  >
                  > > Of course, it is possible,
                  > > if all the custom parts are available (they must be custom
                  created to
                  > > predefined interfaces). Until we can implement such CASE tools we
                  > > must live with manual coding to generate the 5 or so line of
                  coupling
                  > > code. http://www.cbsdf.com/ps_blog/super-distribution.htm
                  > >
                  > > The figures#15-17 in the following webpage highlights the
                  > > difference between the OOP and CBSDF. Please think, what is the
                  > > effort needed to replace any one of the there components:
                  > > http://www.cbsdf.com/technologies/misc-docs/CF-LC-Figures.htm
                  > >
                  > > This is one of my Objectives: since we are writing code that
                  > > writes the application, why cannot we embed generic processes to
                  > > detect broken interfaces. This is one of the advantages of
                  > > the "GENERATIVE INDIRECTION" that we can automate many repetitive
                  > > tasks by employing generic tools (This offers huge benefits, but
                  I
                  > > haven't yet made any progress here).
                  >
                  > Wait a minute. You compile a program to... compile itself at
                  _runtime_.
                  > If your program is compiled, it should not be bothered with
                  interfaces.
                  > Broken interfaces do not compile. Only if your application depends
                  on
                  > another system that it has no control over, it has to do those
                  things.
                  > This is where you feel the pain of tight coupling to the unknown.
                  >
                  > > Often, to comprehend the difference one must experience the
                  > > difference. If possible, next time, when you are building an OOP
                  > > application, see if you can build the large and larger components
                  by
                  > > physically encapsulating respective subcomponents. I am not
                  asking
                  > > you to implement that way, just spend few hours and try to do
                  that
                  > > way. Then compare that, how we can do this in CBSDF:
                  > > http://cbsdf.com/misc_docs/Can-u-prove.htm (Please note that the
                  > > three city-hierarchies is the important proof). You know that
                  most
                  > > real commercials products need several man years of effort. If
                  one
                  > > has trouble implementing such simple few GUI components, how
                  could
                  > > any one implement large GUI applications?
                  >
                  > I do not have the luxury of being able to install all kinds of
                  plugins
                  > on clients. My application should just work. Even without
                  javascript
                  > enabled on the client. And especially with reasonable security
                  settings.
                  > So while I do use javascript, it is just to make things run more
                  > smoothly. Just like a 747 has powered controls, but can be flown by
                  hand
                  > if necessary.
                  >
                  > A few last questions though: If you have so many dependencies on
                  other
                  > systems, how on earth are you going to write unit tests for them?
                  Do you
                  > have special tests to see what browser dependencies there are, and
                  do
                  > you offer alternatives for non-supported plugin dependencies?
                  > And, if you want to check the interfaces at runtime, do you run the
                  > remote system's unit tests at runtime as well? And what do you do
                  if
                  > they fail?
                  >
                  >
                  > Best regards,
                  > Willem Bogaerts
                  >
                • geoffrey_slinker
                  ... Have you contrasted this physical hierarchical-encapsulation with Java s nested class or C# s inner class? Following is a snippet from the Java tutorial
                  Message 8 of 18 , Oct 30, 2006
                    --- In extremeprogramming@yahoogroups.com, "chiluvuri1"
                    <chiluvuri1@...> wrote:

                    > The "loosely coupled" components are included in the application. The
                    > basic requirement for the "loosely coupled" component is that it must
                    > be a portable code block. Furthermore, we must be able to combine
                    > them not manually, but programmatically to build larger and larger
                    > components. This resultant component must be a again portable code
                    > block.
                    >
                    > To be a plug-n-play part, one must be able to remove any part
                    > with very little possible effort. The MOST IMPORTANT requirement is
                    > that: when I remove a part, all its subcomponents and their
                    > subcomponents must effectively be removed. This can be accomplished,
                    > if the part physically-encapsulates all its subcomponents.
                    >
                    > This physical hierarchical-encapsulation of subcomponents is
                    > not possible for the OOP. Where as in the XML, each subcomponent is a
                    > node in the DOM-tree for respective container component.

                    Have you contrasted this physical hierarchical-encapsulation with
                    Java's nested class or C#'s inner class? Following is a snippet from
                    the Java tutorial concerning nested classes:

                    <q>
                    There are several compelling reasons for using nested classes, among them:

                    * It is a way of logically grouping classes that are only used in
                    one place.
                    * It increases encapsulation.
                    * Nested classes can lead to more readable and maintainable code.

                    Logical grouping of classes—If a class is useful to only one other
                    class, then it is logical to embed it in that class and keep the two
                    together. Nesting such "helper classes" makes their package more
                    streamlined.

                    Increased encapsulation—Consider two top-level classes, A and B, where
                    B needs access to members of A that would otherwise be declared
                    private. By hiding class B within class A, A's members can be declared
                    private and B can access them. In addition, B itself can be hidden
                    from the outside world.

                    More readable, maintainable code—Nesting small classes within
                    top-level classes places the code closer to where it is used.
                    </q>

                    I believe this will meet your requirement of encapsulation. As for
                    coupling it seems that any hierarchical organization imposes coupling.

                    >
                    > Hence, I think, Java is not very good language to
                    > implement "Loosely coupled" parts. The XML (e.g. SVG, DHTML or XAML)
                    > is perfect language. Of course, as I said in one of the pages, one
                    > may create "loosely coupled" parts in Java, if we make some changes
                    > to the Java language compilers. It is bit hard and awkward to create
                    > such component hierarchy, which is also again portable block of code,
                    > in Java programming alone with out the "GENERATIVE INDIRECTION".
                    >

                    In C# you can have inner classes. Also you have the keyword partial.
                    If the outer and inner class is declared partial you can put the
                    implementation of the inner class in a separate file.

                    > If you look at the interactions at "Component" (e.g. shopping-
                    > cart and shopping-items) level, they often very simple and intuitive.
                    > In fact they closely mirror the design document and requirements. If
                    > that is the case, why cannot a business analyst employ a CASE tool to
                    > assemble the application from the parts? Of course, it is possible,
                    > if all the custom parts are available (they must be custom created to
                    > predefined interfaces). Until we can implement such CASE tools we
                    > must live with manual coding to generate the 5 or so line of coupling
                    > code. http://www.cbsdf.com/ps_blog/super-distribution.htm

                    In your example from the above link you state:
                    " Please let me ask you a question. Please assume a large number of
                    CFs for basic images (i.e. components) are available, how long it
                    would take to build hierarchy of larger and larger images? We have
                    given few examples above. Does it take more than few minutes to build
                    each CF for a larger component?"

                    The example of drawing a stock chart (which I have done plenty of and
                    even invented new charting types:
                    http://home.att.net/~geoffrey.slinker/maverick/VolumeBars.html)I feel
                    I could use "the painters algorithm", table-driven techniques, and
                    inversion of control to build a very flexible system to build custom
                    charts for individual users. My point is that your documents aren't
                    getting to the point in such a way that I can clearly see advantages
                    at this time. Clearly this is complex and you have put much work into
                    it. I am not sure I can be of much use unless I spend lots of time on
                    this issue.

                    >
                    > The figures#15-17 in the following webpage highlights the
                    > difference between the OOP and CBSDF. Please think, what is the
                    > effort needed to replace any one of the there components:
                    > http://www.cbsdf.com/technologies/misc-docs/CF-LC-Figures.htm

                    Clearly the system you show in figure #15 is not desirable. I feel
                    with Inversion of Control and a the use of a Supervising Controller
                    and a Passive view may work just fine. Can you help me see the
                    difference? (http://www.martinfowler.com/eaaDev/ModelViewPresenter.html)


                    >
                    > This is one of my Objectives: since we are writing code that
                    > writes the application, why cannot we embed generic processes to
                    > detect broken interfaces. This is one of the advantages of
                    > the "GENERATIVE INDIRECTION" that we can automate many repetitive
                    > tasks by employing generic tools (This offers huge benefits, but I
                    > haven't yet made any progress here).

                    >
                    > Often, to comprehend the difference one must experience the
                    > difference. If possible, next time, when you are building an OOP
                    > application, see if you can build the large and larger components by
                    > physically encapsulating respective subcomponents. I am not asking
                    > you to implement that way, just spend few hours and try to do that
                    > way.

                    I can do that.

                    > Then compare that, how we can do this in CBSDF:
                    > http://cbsdf.com/misc_docs/Can-u-prove.htm (Please note that the
                    > three city-hierarchies is the important proof). You know that most
                    > real commercials products need several man years of effort. If one
                    > has trouble implementing such simple few GUI components, how could
                    > any one implement large GUI applications?

                    FYI: I noticed this when I went to install the SVG plug-in: Please
                    note that Adobe has announced that it will discontinue support for
                    Adobe SVG Viewer on January 1, 2008.


                    >
                    > P.S: I have also made changes to: http://www.cbsdf.com/service-
                    > access/3D-Board.htm
                    >
                    > What do you think?

                    This is what I think I have learned.

                    CBSDF is concerned with coupling, web-applications, and customization.
                    IMO it is similar to service oriented architectures which are
                    currently NOT object oriented and are based on procedures, data, and
                    data transformation (data driven).

                    Also, through the use of factories CBSDF is a code generator or
                    basically a "late binding" mechanism. This late binding is the essence
                    of loss coupling and allows dynamic assembly of components at runtime.

                    That is what I think your lessons describe. I may be wrong.

                    Thanks,
                    Geoff
                  • chiluvuri1
                    Geoffrey: It is bit hard to explain, but let me try. Please forget you are a software developer. Please assume, you are setting up a product factory, where the
                    Message 9 of 18 , Oct 30, 2006
                      Geoffrey:

                      It is bit hard to explain, but let me try. Please forget you
                      are a software developer. Please assume, you are setting up a product
                      factory, where the product is automatically assembles on the fly,
                      which consists of only plug-n-play parts.

                      Only task the automated factory does is, plugs-in each part
                      at appropriate location and creates simple connections between the
                      parts, so that they can collaborate with each other. The factory
                      cannot do any harder task. Hence, you must design the parts, so that
                      they are easy to plug-in with simple interfaces. For certain reasons
                      that I cannot explain here, I don't want to make the factor any more
                      complex.

                      Now assume, the web application server is the factory and the
                      web page is the product. Hence, the webpage is basically

                      My only objective is control complexity. To do that some of
                      the requirements are:
                      1). No software module/class can be larger than 500 lines of code.
                      2). One must only need very little system knowledge (I call
                      it "peripheral knowledge") to refine the 500 lines module (in
                      complete isolation). For example, if you are an automobile battery
                      maker, you are 100% free to refine it in full isolation to improve
                      its performance, as long as its interfaces are not changed (e.g. 12V-
                      DC/90AH).
                      3). However, in the software interfaces often need to be changed. For
                      example, let's take Shopping-cart and Shopping-items. Each of the
                      shopping items makes a call to the service function of the Invoice,
                      when user double clicks on it and passes a message. This function
                      call creates online of coupling between the components.

                      For example:
                      Invoice.Add_Item(ItemData, call_back_func_to_item);

                      It would be nice, if we could use generic tool to detect
                      broken interfaces. Lets us assume, we have updated the Invoice to
                      show more information, which needs us to update the items to provide
                      additional pieces of data. For example we may use interface version
                      to do that.
                      Invoice.Add_Item(Version_num, ItemData,
                      call_back_func_to_item);

                      If inadvertently one of the Shopping-items were not updated
                      to the latest interface, the Invoice component can detect that. This
                      can avoid some bugs. This is simples method, but we can employ
                      generic Tools which can make it nearly impossible for such bugs to
                      slip through undetected. I cannot discuss all of them here, but let
                      me give you one more example. If I am the designer of the Invoice-
                      table, I may need XML-message and provide XML-schema.
                      Invoice.Add_Item(Version_num, XML_Data_Str,
                      call_back_func_to_item);

                      The Invoice may call the generic tool to validate the
                      XML_Data_Str against the XML-schema. It will generate bur report.
                      This is jus one additional line of code, since the tool is generic-
                      API.

                      Unfortunately, this bug will not be detected until, one
                      clicks on the item while testing. So we can employ some other
                      techniques, which can detect bugs with out even explicit testing,
                      which I cannot discuss here.

                      OK, let's go back to our most important requirement: no
                      component must be complex and need more than 500 lines of code. Often
                      complex products would have complex parts. For example, Hard-drive is
                      a complex part for computers. Likewise, Jet engines are complex parts
                      for Jet-fighters.

                      Then we need to set up a simple component-factory (no more
                      than 500 lines) that takes its subcomponents and assemble them to
                      build the complex part, and so on. Many prototype components in the
                      web site clearly prove that it is possible to decompose any larger
                      part into smaller "loosely coupled" parts.
                      http://cbsdf.com/technologies/software-irony.htm

                      For example, what if our shopping items are very complex,
                      which needs popup windows containing check-boxes, drill downs to
                      select many options such as, color, size, model and style. Also pre-
                      install non-standard or optional accessories/parts. The website
                      demonstrates many GUI components, which clear proves that, such GUI-
                      API can be created.

                      You said:
                      > Have you contrasted this physical hierarchical-encapsulation
                      > with Java's nested class or C#'s inner class? Following
                      > is a snippet from the Java tutorial concerning nested classes:

                      This breaks my important requirements, the size limit of 500
                      lines and coupling limit of less than 7 lines of code (for each
                      module). I am not saying any thing wrong with your idea. But, I
                      wanted to solve a very interesting puzzle, which could improve
                      software developers' productivity. This puzzle requires me to satisfy
                      certain requirements. I think, I have solved the puzzle for online
                      GUI applications.

                      I don't know, if online GUI applications will ever become
                      popular, but if they become popular we have a solution to build them.
                      If you still think, I am sane and like to know more:
                      http://www.cbsdf.com/technologies/ironic-2D-web.htm

                      The factory paradigm, I believe, unlimited possibilities for
                      automation of various tasks involved in creating the application. I
                      can see so many high potential processes, which I am still working on.

                      Best Regards,
                      Raju

                      "All problems in computer science can be solved by another level of
                      indirection" --- Butler Lampson


                      --- In extremeprogramming@yahoogroups.com, "geoffrey_slinker"
                      <geoffrey_slinker@...> wrote:
                      >
                      > --- In extremeprogramming@yahoogroups.com, "chiluvuri1"
                      > <chiluvuri1@> wrote:
                      >
                      > > The "loosely coupled" components are included in the application.
                      The
                      > > basic requirement for the "loosely coupled" component is that it
                      must
                      > > be a portable code block. Furthermore, we must be able to combine
                      > > them not manually, but programmatically to build larger and
                      larger
                      > > components. This resultant component must be a again portable
                      code
                      > > block.
                      > >
                      > > To be a plug-n-play part, one must be able to remove any part
                      > > with very little possible effort. The MOST IMPORTANT requirement
                      is
                      > > that: when I remove a part, all its subcomponents and their
                      > > subcomponents must effectively be removed. This can be
                      accomplished,
                      > > if the part physically-encapsulates all its subcomponents.
                      > >
                      > > This physical hierarchical-encapsulation of subcomponents is
                      > > not possible for the OOP. Where as in the XML, each subcomponent
                      is a
                      > > node in the DOM-tree for respective container component.
                      >
                      > Have you contrasted this physical hierarchical-encapsulation with
                      > Java's nested class or C#'s inner class? Following is a snippet from
                      > the Java tutorial concerning nested classes:
                      >
                      > <q>
                      > There are several compelling reasons for using nested classes,
                      among them:
                      >
                      > * It is a way of logically grouping classes that are only used
                      in
                      > one place.
                      > * It increases encapsulation.
                      > * Nested classes can lead to more readable and maintainable
                      code.
                      >
                      > Logical grouping of classes—If a class is useful to only one other
                      > class, then it is logical to embed it in that class and keep the two
                      > together. Nesting such "helper classes" makes their package more
                      > streamlined.
                      >
                      > Increased encapsulation—Consider two top-level classes, A and B,
                      where
                      > B needs access to members of A that would otherwise be declared
                      > private. By hiding class B within class A, A's members can be
                      declared
                      > private and B can access them. In addition, B itself can be hidden
                      > from the outside world.
                      >
                      > More readable, maintainable code—Nesting small classes within
                      > top-level classes places the code closer to where it is used.
                      > </q>
                      >
                      > I believe this will meet your requirement of encapsulation. As for
                      > coupling it seems that any hierarchical organization imposes
                      coupling.
                      >
                    • Ron Jeffries
                      Hello, chiluvuri1. On Tuesday, October 31, 2006, at 2:26:49 AM, ... Would someone please remind me what this discussion has to do with Extreme Programming? I
                      Message 10 of 18 , Oct 31, 2006
                        Hello, chiluvuri1. On Tuesday, October 31, 2006, at 2:26:49 AM,
                        you wrote:

                        > It is bit hard to explain, but let me try. Please forget you
                        > are a software developer. Please assume, you are setting up a product
                        > factory, where the product is automatically assembles on the fly,
                        > which consists of only plug-n-play parts.

                        Would someone please remind me what this discussion has to do with
                        Extreme Programming? I seem to have lost the thread.

                        Ron Jeffries
                        www.XProgramming.com
                        I know we always like to say it'll be easier to do it now than it
                        will be to do it later. Not likely. I plan to be smarter later than
                        I am now, so I think it'll be just as easy later, maybe even easier.
                        Why pay now when we can pay later?
                      • geoffrey_slinker
                        ... It is very loosely coupled to Agile. :-) I make me laugh. In my first post I tried to tie it to his agile question. I include it here for reference. Geoff
                        Message 11 of 18 , Oct 31, 2006
                          --- In extremeprogramming@yahoogroups.com, Ron Jeffries
                          <ronjeffries@...> wrote:
                          >
                          > Hello, chiluvuri1. On Tuesday, October 31, 2006, at 2:26:49 AM,
                          > you wrote:
                          >
                          > > It is bit hard to explain, but let me try. Please forget you
                          > > are a software developer. Please assume, you are setting up a product
                          > > factory, where the product is automatically assembles on the fly,
                          > > which consists of only plug-n-play parts.
                          >
                          > Would someone please remind me what this discussion has to do with
                          > Extreme Programming? I seem to have lost the thread.
                          >

                          It is very loosely coupled to Agile. :-) I make me laugh.

                          In my first post I tried to tie it to his agile question. I include it
                          here for reference.


                          Geoff Slinker
                          http://digerati-illuminatus.blogspot.com/

                          -------
                          Speaking to Raju
                          You state:
                          "While coding, even after full design, many nagging thoughts often
                          linger in our minds, such as: Does it really user need? Did I get this
                          requirement right? Is there any better way to do? May be some users
                          need it differently? Should I implement both and let them choose using
                          a flag or configuration-file?

                          One thing always happened to me that, as soon as, I have finished the
                          full module or soon after first demo to the user or in the design
                          review, I can see many other improvement I can do to make it far
                          better, only if I can go back and do it again.

                          All the pondering and nagging thought during the weeks, while we
                          design and develop various parts of the application, would certainly
                          give any one lot of insights and far better picture on user needs,
                          potential work flow processes and of course software design. For
                          example, these factors certainly allow us to have far more intelligent
                          conversation with the user and fellow developers. I cannot understate
                          to usefulness of leveraging this expertise to iteratively refine the
                          software."

                          You asked how your ideas compare to Agile development. The above
                          statements cover important aspects of Agile development.

                          Iterative development is key. Shortening the time between a customer's
                          request to seeing running code is key.

                          Your statement about pondering and nagging thought during weeks...
                          that tells me that you are too far removed from your customer. Shorten
                          this time.


                          I personally believe that experimentation is a good way to figure out
                          things and to progress incrementally in an iterative fashion.

                          http://en.wikipedia.org/wiki/Software_Scouting_and_Reconnaissance

                          As for your complaints against OOP I would suggest some comparisons to
                          Inversion of Control, Dependency Injection, how virtual methods are
                          used with the Open/Closed principle, interfaces and pure abstract
                          classes and other various OO and Procedural techniques. I am not
                          saying you are wrong or right I just don't see enough evidence that
                          shows that OO is part of the problem.

                          Thanks for sharing,

                          Geoff Slinker

                          http://digerati-illuminatus.blogspot.com/
                        • chiluvuri1
                          Jeffries: I have posted here, because I believe it is also a form of extreme programming for the emerging XML based programming languages such as Vista/XAML
                          Message 12 of 18 , Nov 1, 2006
                            Jeffries:

                            I have posted here, because I believe it is also a form of
                            extreme programming for the emerging XML based programming languages
                            such as Vista/XAML and Adobe's MXML/Flex 2. (They are not buzz words,
                            many people are making living on MXML/Flash and all the browsers
                            supporting VML or SVG).

                            I assumed extreme programming is not a closed religion, where
                            no new processes can be proposed. Who decides which one goes in to
                            extreme programming and which one is not. Is there any rule that
                            extreme programming must conform to certain closed religious
                            guidelines?

                            I hope, extreme programming is open to new programming
                            languages and processes. I hope this group allows academic discussion
                            to extend it, when new processes are found, that uses new
                            capabilities for emerging languages, when they are discovered.

                            If you read newly added material to the following webpage,
                            which clearly shows that XML based graphic languages have an
                            interesting and useful capability for extreme programming:
                            http://www.cbsdf.com/service-access/3D-Board.htm

                            Please understand, I am not positing speculative processes.
                            If you see the web site, you would know that I have put many years of
                            effort to design that. I spend years to make sure that they work.

                            I hope I am not wrong in assuming that extreme programming is
                            open to academic discussion and to change, when new processes are
                            found.

                            Best Regards,
                            Raju


                            --- In extremeprogramming@yahoogroups.com, Ron Jeffries
                            <ronjeffries@...> wrote:
                            >
                            > Hello, chiluvuri1. On Tuesday, October 31, 2006, at 2:26:49 AM,
                            > you wrote:
                            >
                            > > It is bit hard to explain, but let me try. Please forget
                            you
                            > > are a software developer. Please assume, you are setting up a
                            product
                            > > factory, where the product is automatically assembles on the fly,
                            > > which consists of only plug-n-play parts.
                            >
                            > Would someone please remind me what this discussion has to do with
                            > Extreme Programming? I seem to have lost the thread.
                            >
                            > Ron Jeffries
                            > www.XProgramming.com
                            > I know we always like to say it'll be easier to do it now than it
                            > will be to do it later. Not likely. I plan to be smarter later than
                            > I am now, so I think it'll be just as easy later, maybe even easier.
                            > Why pay now when we can pay later?
                            >
                          • Ron Jeffries
                            Hello, Raju. When you re finished accusing us of operating a closed religion and such, could you please relate your new XML-based programming language to Agile
                            Message 13 of 18 , Nov 1, 2006
                              Hello, Raju. When you're finished accusing us of operating a closed
                              religion and such, could you please relate your new XML-based
                              programming language to Agile and XP principles and practices?

                              In particular I'd be interested in hearing how you plan to address:

                              Communicating with humans using the code, since XML is a good
                              language for computers, but not so good for humans;

                              Test-driven development in XML programming;

                              Refactoring;

                              and whichever other XP and Agile practices and values seem to you
                              most appropriate to discuss.

                              Thanks,

                              Ron

                              On Wednesday, November 1, 2006, at 10:44:34 PM, you wrote:

                              > I have posted here, because I believe it is also a form of
                              > extreme programming for the emerging XML based programming languages
                              > such as Vista/XAML and Adobe's MXML/Flex 2. (They are not buzz words,
                              > many people are making living on MXML/Flash and all the browsers
                              > supporting VML or SVG).

                              > I assumed extreme programming is not a closed religion, where
                              > no new processes can be proposed. Who decides which one goes in to
                              > extreme programming and which one is not. Is there any rule that
                              > extreme programming must conform to certain closed religious
                              > guidelines?

                              > I hope, extreme programming is open to new programming
                              > languages and processes. I hope this group allows academic discussion
                              > to extend it, when new processes are found, that uses new
                              > capabilities for emerging languages, when they are discovered.

                              > If you read newly added material to the following webpage,
                              > which clearly shows that XML based graphic languages have an
                              > interesting and useful capability for extreme programming:
                              > http://www.cbsdf.com/service-access/3D-Board.htm

                              > Please understand, I am not positing speculative processes.
                              > If you see the web site, you would know that I have put many years of
                              > effort to design that. I spend years to make sure that they work.

                              > I hope I am not wrong in assuming that extreme programming is
                              > open to academic discussion and to change, when new processes are
                              > found.



                              Ron Jeffries
                              www.XProgramming.com
                              The rules are ways of thinking, not ways to avoid thinking.
                            • chiluvuri1
                              Jeffries: I am not accusing any one of any closed religion. I am just saying, that I posted here because, I believe the processes would also a form of extreme
                              Message 14 of 18 , Nov 2, 2006
                                Jeffries:

                                I am not accusing any one of any closed religion. I am just
                                saying, that I posted here because, I believe the processes would
                                also a form of extreme programming.

                                You made very valid point:
                                > Communicating with humans using the code, since XML is a
                                > good language for computers, but not so good for humans;

                                I couldn't agree more. Also let me also add, XML based
                                languages are designed for generation, usually by using programmable
                                languages such as Java/C#. They (Java/C#) are certainly good for
                                humans, or at least better than XML languages. Unfortunately it is
                                hard to build "loosely coupled" parts in Java as explained.

                                Unfortunately many developers are increasingly needed to
                                build online applications, hence need to write XML based graphics
                                languages. Please don't forget DHTML/Ajax and MXML/Flash also XML
                                based languages.

                                Many of us cannot wish them away and has to deal with them.
                                Accommodating XML languages, I feel, is helpful for the XP. I hope,
                                there is nothing wrong in academic discussion.

                                Hence like to present better programming patterns which could
                                minimize dependencies between parts, hence make the work needed for
                                both TDD and refractoring simpler. Don't you think, the CF pattern
                                presented at the end can do that?
                                http://www.cbsdf.com/service-access/CBSDF-Objectives.htm

                                I felt, XP not only includes guidelines for practicing it but
                                also need better programming patterns. Please remember that they are
                                not methodologies as on may expect, but just I felt useful
                                programming patterns for extreme programming and just like to see
                                academic feedback.

                                Forgive me, if I misunderstood XP or my post feels like
                                argumentative, which I wish to avoid.

                                Best Regards,
                                Raju

                                --- In extremeprogramming@yahoogroups.com, Ron Jeffries
                                <ronjeffries@...> wrote:
                                >
                                > Hello, Raju. When you're finished accusing us of operating a closed
                                > religion and such, could you please relate your new XML-based
                                > programming language to Agile and XP principles and practices?
                                >
                                > In particular I'd be interested in hearing how you plan to address:
                                >
                                > Communicating with humans using the code, since XML is a good
                                > language for computers, but not so good for humans;
                                >
                                > Test-driven development in XML programming;
                                >
                                > Refactoring;
                                >
                                > and whichever other XP and Agile practices and values seem to you
                                > most appropriate to discuss.
                                >
                                > Thanks,
                                >
                                > Ron
                              • Sammy Larbi
                                Raju, I do not recall the original post, and I haven t kept up with this thread, so I don t know where you got the idea that XP-practitioners and advocates
                                Message 15 of 18 , Nov 2, 2006
                                  Raju,

                                  I do not recall the original post, and I haven't kept up with this
                                  thread, so I don't know where you got the idea that XP-practitioners and
                                  advocates were religious zealots who no longer think, preferring instead
                                  to follow blindly their perfect, one-true-religion. I had been reading,
                                  and occasionally posting, on this list for several months now, and to be
                                  sure, I have on rares occasions seen advice here that seems so dogmatic
                                  as to be absurd when applied to a particular situation. However, that
                                  is far from the norm. In fact, I have not seen such a group as a whole
                                  which is open to discussing new ideas and learning from others as this
                                  one is.

                                  But, as I see it, it is not the job of the Agile community to make the
                                  "XML-based languages" community more agile. It is something we must
                                  learn for ourselves, with the guidance of, and standing on the shoulders
                                  of these giants who have come before us. I am, among others to be sure,
                                  trying to do that in my spare time, and bring it to our community.

                                  Ron,

                                  When I first read "XML-based languages," my first thought "how absurd."
                                  Then I realized, I used one daily. So, I'd like to address some of the
                                  issues you raised below. My experience in "xml-based languages" comes
                                  exclusively from Coldfusion, so I will keep my comments related to that
                                  language.

                                  Ron Jeffries wrote, On 11/1/2006 10:17 PM:
                                  > Hello, Raju. When you're finished accusing us of operating a closed
                                  > religion and such, could you please relate your new XML-based
                                  > programming language to Agile and XP principles and practices?
                                  >
                                  > In particular I'd be interested in hearing how you plan to address:
                                  >
                                  > Communicating with humans using the code, since XML is a good
                                  > language for computers, but not so good for humans;
                                  >
                                  >
                                  Now, this is certainly true for long reams of data, which span perhaps
                                  several thousand lines in a file. It is certainly easy to get lost in
                                  the structure. But when we are writing code, if we follow good design
                                  practices, we likely wouldn't be writing that many lines of code in a
                                  file, much less in a function. Therefore, it is not as hard to read as
                                  one might think when the term XML is used. Further, even if you do
                                  encounter that monster method, it is no harder to read (or perhaps, not
                                  significantly so) than the same monster method in another language.

                                  In particular, a newcomer may have an easier time figuring out what is
                                  going on in Coldfusion than Ruby, where concise elegant code seems to be
                                  more a part of the objective than in many other languages. But, as a
                                  newcomer to Ruby, I recall being absolutely confused by the idea of
                                  closures. Further, some method names are so short as to be obfuscating
                                  their purpose. But I still love Ruby - it just takes becoming more
                                  familiar with the language to be able to see the benefits gained in
                                  communication. The same is true, I think, for CF.

                                  Certainly the XML creates much more clutter than we need. I've gotten
                                  sick of it at times. But, it does have it's advantages for
                                  communication with humans. For instance, when you /must/ mix some code
                                  and HTML, I find it much easier to understand what is going on than
                                  using the <% put several lines of script here %> that .NET, Java, and
                                  Rails all use. Of course, that is only making it easier to follow the
                                  flow in a document whose flow, by its nature of being XML, is likely
                                  harder to read than it could be. I am not at all familiar with
                                  Vista/XAML, but at least with the Adobe products Raju mentioned, and
                                  Coldfusion (which is also Adobe, but he did not mention it) - these are
                                  made for web development. So, this ease of reading when mixed with HTML
                                  can be an advantage.

                                  Finally, (again, at least in the case of Coldfusion), its dynamic typing
                                  and its "very high level" nature, more than make up for the extra
                                  clutter, when compared with Java or .NET (at least the C#, VB, ASP
                                  varieties). These all "get in your way," so to speak, while CF does
                                  not. It is not as nice as Rails when comparing among the choices with
                                  web development, but it really approaches it. This relates to
                                  communication in that you have to explain less to see the point, so to
                                  speak, and in most cases. I say "most" cases because, for instance,
                                  instantiating an object in CF is quite painful, even when compared to
                                  Java). But for the most part, the dynamic typing and it being VHL, as I
                                  mention, enhance communication when compared to more "traditional"
                                  languages, because of the brevity you gain.


                                  > Test-driven development in XML programming;
                                  >
                                  >

                                  Our community is still new to "Agile," so we do not have many of the
                                  same tools that help you in other languages. However, while it took
                                  quite some time, there are now at least two unit-testing frameworks
                                  available for CF, so we are getting on that path. In fact, I use TDD at
                                  work, though I am not as good at it yet as I may someday be.

                                  > Refactoring;
                                  >
                                  We can refactor any time we want (by hand =) ), but I don't know yet of
                                  any tool that will help us the way you see in the IDEs of more
                                  languages more established in the Agile community. However, there is an
                                  Eclipse plugin someone has begun developing, and I've had on my "to-do"
                                  list for a while to join it and add some refactoring support in. Being
                                  in school and working, and having other personal projects, I haven't yet
                                  got that far down in the list of priorities, but I'm hoping someday
                                  within the next couple of months that I can start familiarizing myself
                                  with the project. Then, maybe by the end of next summer, we may have
                                  something to help us in this regard.


                                  > and whichever other XP and Agile practices and values seem to you
                                  > most appropriate to discuss.
                                  >
                                  >

                                  The way I see it, most of XP/Agile can be applied to any language.
                                  There is nothing about an XML based language that says we cannot value
                                  (to quote the Manifesto):

                                  Individuals and interactions over processes and tools
                                  Working software over comprehensive documentation
                                  Customer collaboration over contract negotiation
                                  Responding to change over following a plan

                                  In fact, scanning the what is XP page on your site
                                  (http://www.xprogramming.com/xpmag/whatisxp.htm), I am not seeing a
                                  core practice that cannot be done. It is just up to us to do them.

                                  Ours is starting to mature to the point where we are finally getting
                                  some tools that really aid in responding to change (such as the TDD and
                                  refactoring you mentioned). We are starting to see TDD articles in the
                                  relevant publications. As I see it, however, it is not a fault of the
                                  languages themselves that we were slow to come to the table, but about
                                  the maturity of the community behind the language. I think these Agile
                                  principles span over just about any modern way of programming I could
                                  think of - excepting the punch cards we use in the office upstairs =).
                                  I find them hard to communicate with, even when I read what I punched
                                  after letting it sit for only 5 minutes.

                                  If you would like to raise other issues, I'd be glad to respond to them.

                                  Regards,

                                  Sam


                                  > Thanks,
                                  >
                                  > Ron
                                  >
                                  > On Wednesday, November 1, 2006, at 10:44:34 PM, you wrote:
                                  >
                                  >
                                  >> I have posted here, because I believe it is also a form of
                                  >> extreme programming for the emerging XML based programming languages
                                  >> such as Vista/XAML and Adobe's MXML/Flex 2. (They are not buzz words,
                                  >> many people are making living on MXML/Flash and all the browsers
                                  >> supporting VML or SVG).
                                  >>
                                  >
                                  >
                                  >> I assumed extreme programming is not a closed religion, where
                                  >> no new processes can be proposed. Who decides which one goes in to
                                  >> extreme programming and which one is not. Is there any rule that
                                  >> extreme programming must conform to certain closed religious
                                  >> guidelines?
                                  >>
                                  >
                                  >
                                  >> I hope, extreme programming is open to new programming
                                  >> languages and processes. I hope this group allows academic discussion
                                  >> to extend it, when new processes are found, that uses new
                                  >> capabilities for emerging languages, when they are discovered.
                                  >>
                                  >
                                  >
                                  >> If you read newly added material to the following webpage,
                                  >> which clearly shows that XML based graphic languages have an
                                  >> interesting and useful capability for extreme programming:
                                  >> http://www.cbsdf.com/service-access/3D-Board.htm
                                  >>
                                  >
                                  >
                                  >> Please understand, I am not positing speculative processes.
                                  >> If you see the web site, you would know that I have put many years of
                                  >> effort to design that. I spend years to make sure that they work.
                                  >>
                                  >
                                  >
                                  >> I hope I am not wrong in assuming that extreme programming is
                                  >> open to academic discussion and to change, when new processes are
                                  >> found.
                                  >>
                                  >
                                  >
                                  >
                                  > Ron Jeffries
                                  > www.XProgramming.com
                                  > The rules are ways of thinking, not ways to avoid thinking.
                                  >
                                  >
                                  >
                                  > To Post a message, send it to: extremeprogramming@...
                                  >
                                  > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                                  >
                                  > ad-free courtesy of objectmentor.com
                                  > Yahoo! Groups Links
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                • Ron Jeffries
                                  Hello, Sammy. On Thursday, November 2, 2006, at 10:01:03 AM, you ... I produce my entire web site in XML. Much of my content consists of programs in various
                                  Message 16 of 18 , Nov 2, 2006
                                    Hello, Sammy. On Thursday, November 2, 2006, at 10:01:03 AM, you
                                    wrote:

                                    > Therefore, it is not as hard to read as
                                    > one might think when the term XML is used. Further, even if you do
                                    > encounter that monster method, it is no harder to read (or perhaps, not
                                    > significantly so) than the same monster method in another language.

                                    I produce my entire web site in XML. Much of my content consists of
                                    programs in various programming languages. I perceive a very
                                    significant difference in readability between the two.

                                    Ron Jeffries
                                    www.XProgramming.com
                                    Know what I pray for? The strength to change what I can, the inability to
                                    accept what I can't and the incapacity to tell the difference. --Calvin and Hobbes
                                  • Ron Jeffries
                                    Hello, Sammy. On Thursday, November 2, 2006, at 10:01:03 AM, you ... No doubt all of XP can be done in most any situation. I was -- and am -- asking Raju to
                                    Message 17 of 18 , Nov 2, 2006
                                      Hello, Sammy. On Thursday, November 2, 2006, at 10:01:03 AM, you
                                      wrote:

                                      > The way I see it, most of XP/Agile can be applied to any language.
                                      > There is nothing about an XML based language that says we cannot value
                                      > (to quote the Manifesto):

                                      > Individuals and interactions over processes and tools
                                      > Working software over comprehensive documentation
                                      > Customer collaboration over contract negotiation
                                      > Responding to change over following a plan

                                      > In fact, scanning the what is XP page on your site
                                      > (http://www.xprogramming.com/xpmag/whatisxp.htm), I am not seeing a
                                      > core practice that cannot be done. It is just up to us to do them.

                                      No doubt all of XP can be done in most any situation. I was -- and
                                      am -- asking Raju to relate his posting to our topic here, which to
                                      my way of thinking he was not doing.

                                      Ron Jeffries
                                      www.XProgramming.com
                                      Testing quality into a program is like spinning straw into gold.
                                      -- George Cameron.
                                    • Sammy Larbi
                                      Hi Ron, ... For me, the difference is not so striking, I guess. Though it is noticeable, given that I can develop a web application several times faster using
                                      Message 18 of 18 , Nov 3, 2006
                                        Hi Ron,

                                        Ron Jeffries wrote, On 11/2/2006 8:43 PM:
                                        > Hello, Sammy. On Thursday, November 2, 2006, at 10:01:03 AM, you
                                        > wrote:
                                        >
                                        >
                                        >> Therefore, it is not as hard to read as
                                        >> one might think when the term XML is used. Further, even if you do
                                        >> encounter that monster method, it is no harder to read (or perhaps, not
                                        >> significantly so) than the same monster method in another language.
                                        >>
                                        >
                                        > I produce my entire web site in XML. Much of my content consists of
                                        > programs in various programming languages. I perceive a very
                                        > significant difference in readability between the two.
                                        >
                                        >

                                        For me, the difference is not so striking, I guess. Though it is
                                        noticeable, given that I can develop a web application several times
                                        faster using it than most alternatives, I'll gladly accept what is for
                                        me, the minor inconvenience.

                                        -Sam
                                      Your message has been successfully submitted and would be delivered to recipients shortly.