Page 2 of 2 FirstFirst 12
Results 21 to 34 of 34
  1. #21
    curmudgeon is offline Senior Member
    Join Date
    May 2010
    Posts
    436
    Rep Power
    5

    Default

    Quote Originally Posted by buffalo View Post
    Reply to Toll: You make some good points about separating logic, data and I/O to simplify maintenance. I see these points as arguments against object-oriented programing, since objects are intended to encapsulate logic, data and I/O. However, Java is a prime example of an OO language. So I think that your points would be better accomodated with a procedural language, e.g. C, using specific subroutines (or macros) to do logic and I/O and perhaps struts (or arrays) for data.
    I disagree with everything you have stated above. Please read a book on OOPs such as Booch's book before making grand pronouncements about what is and what isn't OOPs.
    Last edited by curmudgeon; 05-25-2010 at 11:14 PM.

  2. #22
    buffalo is offline Member
    Join Date
    May 2010
    Posts
    19
    Rep Power
    0

    Default

    Reply to Curmudgeon: What happened? I was going to respond to a previous comment and it has been changed. Anyway, on your suggestion, I searched for Booch and found that he is a proponent of Unified Modeling Language (UML) and Rational Unified Process (RUP) both of which I have little appreciation. I just don't see how they help to write a program. Rather than appeal to authority (such as Booch) I rather appeal to logic.
    1) Java is object oriented
    2) Objects encapsulate data with methods
    3) If a class contains methods and no data or vice versa then it is either not an object or is a degenerate object
    4) Therefore the proper use of Java is to combine data and methods in each class

  3. #23
    curmudgeon is offline Senior Member
    Join Date
    May 2010
    Posts
    436
    Rep Power
    5

    Default

    Where has Tolls said anything bout not to have data with methods? Much of OOPs consists of extension by composition (check Wikipedia on this) where objects contain other objects. So yes, you have business logic encapsulated (read up on this!) in its own class, and then GUI logic in its class and tie the two together with controls, but in all classes you have data or state and logic. Again, nothing Tolls has stated goes against the principles of object oriented programming and in fact quite the opposite.
    Last edited by curmudgeon; 05-25-2010 at 11:59 PM.

  4. #24
    buffalo is offline Member
    Join Date
    May 2010
    Posts
    19
    Rep Power
    0

    Default

    Reply to curmudgeon: You just introduced a new and interesting concept "composition". If that is your purpose for OOP than I see the merit and perhaps that might be somehow represented with UML.

    For the record, Tolls did say
    But you would still be mixing data, display, and logic into one class. And that is poor design.
    There's no zealotry involved, ....
    To which you said "amen".

  5. #25
    curmudgeon is offline Senior Member
    Join Date
    May 2010
    Posts
    436
    Rep Power
    5

    Default

    What Tolls stated was:
    But you would still be mixing data, display, and logic into one class. And that is poor design.
    Which means mixing unorganized naked data, plus a whole mess of unrelated code together is poor design. Separating the data out so that it resides in its own class, for instance the Element class in Fubarable's example, so that the data now has organization and sits with code that is built specifically to hold it and manage it, and then including objects of this class in other classes that interact with GUI still allows mixing data and code, but allows one to do so so that the interactions between disparate portions of the program are much more carefully controlled and are much easier to manage. One of the goals of any programming paradigm is to reduce complexity, and one of the ways that OOPs does this is by encapsulation -- by separating out logical portions of a program into self-contained entities with fewer and more manageable communcations.

    As an example of the benefits of this organization, try to see what it would take to add a single new Element into the OP's program, a non-OOP program where everything is combined into one class. To do this, one would have to change the "b21" JButton to handle this new element and shift the buttons above this by one number including their magic number actionCommand. In other words, change this:
    Java Code:
        b20 = new JButton("Calcuim");
        b20.setVerticalTextPosition(AbstractButton.CENTER);
        b20.setHorizontalTextPosition(AbstractButton.LEADING);
        b20.setEnabled(true);
        b20.addActionListener(this);
        b20.setActionCommand("20");
    
        b21 = new JButton("Atomic Mass");
        b21.setVerticalTextPosition(AbstractButton.CENTER);
        b21.setHorizontalTextPosition(AbstractButton.LEADING);
        b21.setEnabled(true);
        b21.addActionListener(this);
        b21.setActionCommand("21");

    to this:
    Java Code:
        b20 = new JButton("Calcuim");
        b20.setVerticalTextPosition(AbstractButton.CENTER);
        b20.setHorizontalTextPosition(AbstractButton.LEADING);
        b20.setEnabled(true);
        b20.addActionListener(this);
        b20.setActionCommand("20");
    
        b21 = new JButton("Scandium");
        b21.setVerticalTextPosition(AbstractButton.CENTER);
        b21.setHorizontalTextPosition(AbstractButton.LEADING);
        b21.setEnabled(true);
        b21.addActionListener(this);
        b21.setActionCommand("21");
    
        b22 = new JButton("Atomic Mass");
        b22.setVerticalTextPosition(AbstractButton.CENTER);
        b22.setHorizontalTextPosition(AbstractButton.LEADING);
        b22.setEnabled(true);
        b22.addActionListener(this);
        b22.setActionCommand("22");

    Then you'd have to add your new JButton to the JPanel, changing this:
    Java Code:
        add(b18);
        add(b19);
        add(b20);
    
      }// buttons for each element

    to this:
    Java Code:
        add(b18);
        add(b19);
        add(b20);
        add(b21);
      }// buttons for each element

    Then you have to add another else if statement to the huge one in the actionPerformed method to include information about the new element, changing this:
    Java Code:
        else if ("21".equals(e.getActionCommand())) {
    
          JFrame a = new JFrame("Calcium");
          a.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
          aj = new JPanel();
    
          a.add(aj);
          aj.add(b21);
          aj.add(b22);
          aj.add(b23);
          aj.add(b24);
    
          a.pack();
          a.setSize(400, 200);
          a.setLocation(400, 0);
          a.setVisible(true);
          a.setTitle("Choose what you want to know about Calcium:");
    
        }
    
      }

    to this:
    Java Code:
        else if ("20".equals(e.getActionCommand())) {
    
          JFrame a = new JFrame("Calcium");
          a.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
          aj = new JPanel();
    
          a.add(aj);
          aj.add(b22);
          aj.add(b23);
          aj.add(b24);
          aj.add(b25);
    
          a.pack();
          a.setSize(400, 200);
          a.setLocation(400, 0);
          a.setVisible(true);
          a.setTitle("Choose what you want to know about Calcium:");
    
        }
    
        else if ("21".equals(e.getActionCommand())) {
    
          JFrame a = new JFrame("Scandium");
          a.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
          aj = new JPanel();
    
          a.add(aj);
          aj.add(b22);
          aj.add(b23);
          aj.add(b24);
          aj.add(b25);
    
          a.pack();
          a.setSize(400, 200);
          a.setLocation(400, 0);
          a.setVisible(true);
          a.setTitle("Choose what you want to know about Scandium:");
    
        }
      }

    And lord help you if you mess up changing one of the button variable names in one of the many blocks of repetitive code present. And what the heck are you going to do if you wanted to add 3 new elements?

    On the other hand, using some OOPs techniques, as in Fubarables code, if you want to add four more Elements including buttons for that element with proper button behavior, all you have to do is change this:
    Java Code:
      public static final Element[] ELEMENTS = {
        new Element("Hydrogen", "H", 1, 1.01),
        new Element("Helium", "He", 2, 4.00), 
        new Element("Lithium", "Li", 3, 6.94),
        new Element("Beryllium", "Be", 4, 9.01), 
        new Element("Boron", "B", 5, 10.81),
        new Element("Carbon", "C", 6, 12.01), 
        new Element("Nitrogen", "N", 7, 14.01),
        new Element("Oxygen", "O", 8, 16.00), 
        new Element("Fluorine", "F", 9, 19.00),
        new Element("Neon", "Ne", 10, 20.18), 
        new Element("Sodium", "Na", 11, 22.99),
        new Element("Magnesium", "Mg", 12, 24.31), 
        new Element("Aluminum", "Al", 13, 26.99),
        new Element("Silicon", "Si", 14, 28.09), 
        new Element("Phosphorus", "P", 15, 30.97),
        new Element("Sulfur", "S", 16, 32.06)
      };

    to this:
    Java Code:
      public static final Element[] ELEMENTS = {
        new Element("Hydrogen", "H", 1, 1.01),
        new Element("Helium", "He", 2, 4.00), 
        new Element("Lithium", "Li", 3, 6.94),
        new Element("Beryllium", "Be", 4, 9.01), 
        new Element("Boron", "B", 5, 10.81),
        new Element("Carbon", "C", 6, 12.01), 
        new Element("Nitrogen", "N", 7, 14.01),
        new Element("Oxygen", "O", 8, 16.00), 
        new Element("Fluorine", "F", 9, 19.00),
        new Element("Neon", "Ne", 10, 20.18), 
        new Element("Sodium", "Na", 11, 22.99),
        new Element("Magnesium", "Mg", 12, 24.31), 
        new Element("Aluminum", "Al", 13, 26.99),
        new Element("Silicon", "Si", 14, 28.09), 
        new Element("Phosphorus", "P", 15, 30.97),
        new Element("Sulfur", "S", 16, 32.06),
    
        // added:
        new Element("Chlorine", "Cl", 17, 35.45),
        new Element("Argon", "Ar", 18, 39.95),
        new Element("Potassium", "K", 19, 39.10),
        new Element("Calcium", "Ca", 20, 40.08)
      };
    This is allowed because the idea of what an element is -- it has a name, a symbol, an atomic number and atomic weight -- are all encapsulated in the Element class. And the rest of the program is designed to be able to deal with as many Element objects as necessary (well, not quite infinite). And also the chances of messing up are reduced umpteen-fold.

    So in short, sure, mix data and code, but do so intelligently and with separation and encapsulation of physical and logical entities, and you'll be on your way to OOPs programming.

  6. #26
    buffalo is offline Member
    Join Date
    May 2010
    Posts
    19
    Rep Power
    0

    Default

    reply to curmudgeon: Good illustration, it sure drives home your point in a convincing way. I see your point about mixing unrelated data with logic. I intepretted Tolls comment as refering to any data.

  7. #27
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    12,006
    Rep Power
    20

    Default

    It does encapsulate the logic, though. Especially if you extend (or wrap) rather than simply provide some form of pass through business logic.

    What extending/wrapping does is it allows you to separate the persistent data that, say, a db layer is interested in from the business logic that it isn't...but still, on the business layer, have an encapsulated class that contains the data and the logic.

    Even a passthrough provides this to some extent, though is not as objectified.

    So what you get is a db layer/mapping type who can do their stuff, and test it, without any concern about the intricacies of the business layer above it. So you get separation of responsibilities (display, business and db layers) as the encapsulation of data and logic in your business classes. Arguably you can also wrap them further up the chain to cover the display side of things, but I have no idea if that's a common thing or not since I don't generally do Swing stuff.

  8. #28
    buffalo is offline Member
    Join Date
    May 2010
    Posts
    19
    Rep Power
    0

    Default

    reply to Tolls: so what you are describing is a layered approach in which unprocessed data is encapsulated in the lowest layer and is further processed by each succeeding higher layer - right? This then allows the lower layers to be developed independently from the higher layers. That does seem to be an attractive approach.

    But here is my long-standing problem with that: Suppose at some point a change is made in a higher-layer algorithm which causes the form of the data in the lower layers to be ackward to use (or worse impossible to use because information was lost). This situation would necessitate the higher layer to access the raw data directly, which invalidates the whole layered approach. If OOP can resolve this problem then I'll become a convert.

  9. #29
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    12,006
    Rep Power
    20

    Default

    That pretty much describes the development standar for the past decade or more.
    Layered software.

    As for changes, no it doesn't invalidate it as an approach. If you need something from a layer that doesn't currently exist you extend it. You are frequently (and it's a lot of what I do as a contractor) adding functionality to a system, even in the early development stage (agile, if you like).

    If you have a business change that involves additional data then that is, by necessity, reflected all the way down the system. But you do it in the same way you wrote the system on the first place...putting the relevant bits in the relevant layers.

    Why is that a problem?

    However, if you have a business change that only involves a change of validation, or calculation, then you only have to affect the business layer, and test those changes...not the whole shebang.

  10. #30
    buffalo is offline Member
    Join Date
    May 2010
    Posts
    19
    Rep Power
    0

    Default

    reply to Tolls:
    Why is that a problem?
    Its a problem because the layers are getting in your way rather than helping.

    Suppose the added functionality is rather trivial requiring access to a single item of "raw" data. The "layered" approach involves extending every intermediate layer to simply pass thru the item, which doesn't seem too bad until you consider that each such extended layer now has to be tested and validated. So much for software reuse!

    BTW doesn't all this layering impact execution efficiency?

    Maybe its possible to automate such layer extension with a sophisticated IDE. And maybe a smart compiler could "unwrap" the layers to optimize program efficiency? Maybe that's already being done?

  11. #31
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    12,006
    Rep Power
    20

    Default

    That "raw data" is presumably part of the model already then, in which case you only have to make it available to the business logic. Which begs the question of why it isn't already available...because there's no point having it in the model if nothing's using it.

    If it's new data then whatever strategy you use will involve writing code that spans the front and back ends...requiring retesting. Essentially if you change it then it needs testing, so no strategy is going to change that.

    And I think you may be taking my description of layers a little too literally. Layers does not necessarily mean a separate server/app/whatever. All the layers can be in a single app. For example, the db access layer and the business logic layer are usually part of the same bit of code.

    As for efficiency, that's a red herring. Code maintainability is the name of the game, and has been (outside of embedded systems) for over a decade...possibly two. And separation of responsibility is one of the keys for that. Funnily enough, code that's maintainable also tends to work better, and is easier to bug fix.

  12. #32
    buffalo is offline Member
    Join Date
    May 2010
    Posts
    19
    Rep Power
    0

    Default

    To Tolls:

    You might have misunderstood my use case so let me clarify. The raw data originates in the db layer, which is implemented as a class. The db layer processes the raw data and makes the result available to the next higher layer (also a class). Each successive layer further processes it on up to the business layer (also a class). New functionally of the business layer requires some raw data in addition to processed data, which I assume in keeping with the layered approach is accessed through the chain of layers by extending each layer. Each such extended layer now has to be tested, whereas without layers only the new business code needs to be tested.

    Regarding the red herring, efficiency can not be separated and is almost always important on any system other than a home computer (which are hopelessly inefficient). On a server, which is not an embedded system, there is a great deal of contention for CPU time and any savings for each app will possibly avoid the need for the acquistion of additional servers.

  13. #33
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    12,006
    Rep Power
    20

    Default

    Then you are misunderstanding the general structure of an app.
    You rarely have more than 3 layers of Java.
    Usually:
    - the bit that interacts with the db (taking an object and persisting it, or reading the db and building an object).
    - the bit that does the work (which is done on the objects created by the db layer or the front end).
    - the bit that does the display (whether Swing or the Servlet/JSP layer).

    That's it.

    Servers, CPUs, disks are cheap in comparison to developer costs. Any efficiency gains by munging together disparate layers of code will be insignificant compared to the cost of maintaining it. Believe me, I've had to work on such messes before now. They tend to be fragile, inflexible, and plain ugly...and they get uglier as more fixes and changes are done to them.

  14. #34
    buffalo is offline Member
    Join Date
    May 2010
    Posts
    19
    Rep Power
    0

    Default

    reply to Tolls: Ok, with three layers our points might be converging. I was going to the extreme with a large number of layers to illustrate a point. If the working layer is adjacent to the db layer then data access is almost direct and my point becomes irrelevant.

    This 3-layer pattern reminds me back in the mid 1990's of the model-view-controller architecture. There are differences, however, your working layer is shared between the model and controller and your display layer is shared between the view and controller. Anyway, I guess if one is committed to using an OO language like Java, then your three layer pattern is likely to be as good or better than any other.

    Our discussion about efficiency is too far out of scope to resolve in this thread.

Page 2 of 2 FirstFirst 12

Similar Threads

  1. java method to select from diffrent table
    By waboke in forum New To Java
    Replies: 2
    Last Post: 04-24-2010, 01:58 PM
  2. Add diffrent components in jtable
    By anilkumar_vist in forum Advanced Java
    Replies: 1
    Last Post: 11-23-2009, 05:03 AM
  3. log4j - multiple logs with diffrent contents
    By ld09 in forum Java Applets
    Replies: 0
    Last Post: 10-08-2009, 11:36 AM
  4. diffrent page redirection in struts.
    By rakesh_n_mehta in forum Web Frameworks
    Replies: 0
    Last Post: 12-11-2008, 06:34 AM
  5. Problems implementing Java string methods
    By everlast88az in forum New To Java
    Replies: 8
    Last Post: 11-06-2008, 04:17 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •