Procedural vs. OO in Notes/Domino Java

In a comment to my “Is the lack of Java adoption *still* the Achilles’ heel of IBM?” post, Charles Ross has an interesting comment (emphasis *not* mine).

“I tend to learn by stealing and modifying/refactoring code. This is one kind of reuse. Most of the Java examples you find in the Lotus venues (LDD, Notes help, Sandbox, magazines etc) are not object oriented – not even structured. You can actually find more Lotuscript object oriented samples than Java ones. And at least in LS, the use of Subroutines is common practice in the Lotus templates. That’s good stuff to steal.

That lack of Domino Java source examples is a sore point. One OO thing I worked with was I mapped the Headfirst design patterns Ducks classes (Strategy pattern example) into a Notes Library and agent. Not quite coding, but educational.

So what we need is some nice Domino application classes to steal, basically.”

Something to think about… Maybe it’s because code in Java is so convoluted and hard to read due to the way the program flow may not be obvious that it’s easier to post Java snippets than full “programs”. Maybe this means that the posted code doesn’t lend itself to easy “stealing”. Hmm…

2 thoughts on “Procedural vs. OO in Notes/Domino Java”

  1. It is an interesting point, but I would content that the real issue is the unit of theft, not the actual amount of theft, which is in question, and the unit of theft is largely determined by the faith or trust we have in the source.

    Let us take the example of a junk yard full of cars.  If I were to walk up to a car in this junk yard with the intent to steal, I would tend to look for a good steering wheel or an undamaged hubcap.  My unit of theft would not be a whole car, because my faith in the source is very low.  If, on the other hand, I were to walk down a street in London and saw a nice car parked in front of a posh hotel, I would not steal the steering wheel or hubcap, but I’d take the whole thing.  My unit of theft would be higher because my trust and faith in the likelihood of the car working would be much higher.

    So, how does this apply to code?  Well, if I go to sourceforge or a site like that and see an XML parser that has been downloaded and used by many people, I am not likely to look for a smart bit of code in the middle, I am likely to take the whole parser and tune it up as I like.  My unit of theft is determined by my faith in the other people who have used the code.  But if I am going into a set of Java examples, my faith is low, so I seek a smaller unit of theft, perhaps not much bigger than a snippet.

    If we want to entice the larcenous code mongers of the world to steal and use more Domino code, whether Java or LotusScript or whatever, we need to do more than have clean code.  We need to increase the faith in the larger unit of theft.  If an entire script library or package engenders respect and trust, it will be taken wholesale, not just a hubcap at a  time.


  2. Is sample code for usage of a api the proper place to learn object oriented programming?

    I think not. Its more for stealing information about the usage of the single methods.

    You learn about OO in other places.

    The idea of OO (for me at least) is the creation of subsystems targeted at a certain, well defined task (jargon: high cohesion). Those subsystems are as self-contained as possible (low coupling). They do not depend on other parts of the system. Well. Of course, they may depend on other more lower level subsystems, but they don’t depend on subsystem on their own abstraction level. And. Oh no things get complicated here.

     Example: I have the task to connect to a Business-News Webservice from Lotus Notes.

    Webservices are all about: sending a xml-document to a server and receive a xml document in return.

    I will start with 2 subsystems.

    One for managing the sending and receiving of the xml to the server.

    Another for managing the parsing the xml data.

    The subsystem which manages the sending/receiving of the xml calls the one for managing the parsing of the xml data.

    It sends the xml out, receives the returning xml and then calls the subsystem for managing the parsing of the xml data.

    Both subsystems may contain quite a few methods in classes, but most can only be called from inside the subsystem (no public modifier).

    They may only contain 1 method to be accessed from the outside world.

    This garanties that – except for the public method – I may change whatever I like in the subsystem without creating side effects on other parts of the code. That folcloristic fear of "never touch a running system" is minimized.

    Now has this wonderfull OO stuff much to do with Api documentation (or even with java as a programming language)? I think not. Its quite separated.

    There are other sources to learn OO:

    – existing projects. For example Domingo. Download the source code and look how they structured their code.

    – books which describe OO programming, often targeted to a certain development stack like JSF-Spring-Hibernate or some such.

    For example most books about Swing show us nearly nothing about OO programmin. They just show how to use the huge amount of interfaces, classes and method in the swing library. An exception is the book from Scott Delap, which mostly concentrates on employing OO principles to Swing programming to make the poor project more maintainable by using OO principles.

    I think we do not need a new documentation, but some tutorials and sample apps, which specifically concentrate on the blessings of OO in the world of Lotus Notes.

    OO is not difficult, but it takes some times to grasp the advantages it offers.

    The understanding of OO has its own history. There are quite a few dangerous ideas flying around, like

    – OO models the real world or

    – OO is all about reusing code by subclassing.

    Both ideas have a high potential as an inspiration for very convuluted code.

    Not every java code is necesarily OO. For example the traditional role of Session Beans in J2EE application was fully structural.

    regards Axel


Comments are closed.