declarative control — enterprise design pattern

justification: reduce source change, which can introduce bugs

justification: reduce test effort

justification: Maintain users’, bosses’ and colleagues’ confidence. Confidence that the source didn’t change, so existing functionalities aren’t affected.

justification: slightly Better man-day estimate compared to hacking source code

justification: Adaptble, Flexible

justification: more readable than source code

justification: something of a high-level documentation, well-structured

Examples: DD, spring config file, struts config file, hibernate config file.

I feel this is a habit (unit test is another habit). Initially it’s not easy to apply this idea. A lot of times you feel “not applicable here”, only to witness others applying it here. Easier to justify for component-based, inter-dependent modules. Other projects may find declarative control an overkill, and may opt for a properties file.

Q: Alternative to declarative?
A: The information must move into some place, usually source code. How about a properties file?

Q: is this a design pattern?
A: Purists to avoid the term. For OO and non-OO

Decorator pattern keywords

#1 key phrase: — uses decorators. P100 [[ head first design patterns ]]

hasa AND isa — at the same time. MyDecorator instance both HAS-A and IS-A MyDecoratee

Adding features — decorating, while adhering to original interface ie IS-A. often adds non-private[1] fields and methods to fulfill the duty of decoration.

Onion — “decoratee” could be abstract or concrete (onion) or an
interface. This onion is very similar if not the same as the RAM-onion
described in other blog posts. P89 [[ head first design patterns ]]

collections Synchronized view — of HashMap is adapter or decorator? I
would say Decorator — interface not changed.

complexity — Compared to straight HAS-A or IS-A, Decoration adds
complexity^flexibility. Due to the added complexity, decorate only
when warranted.

[1] Private /memebers/ are insigificant in this and many patterns.
Private members are invisible to other objects.

Strategy pattern keywords

#1 keyword:
family — of algo


Beating polymorphism — Changing/choosing algo among a family of “sister methods” normally uses polymorphism. Strategy is an alternative to polymorphism.

sister methods — interchangeable

same signature — interchangeable

setter — algo-setter

compose — the system with algo objects

HAS-A — strategy pattern

IS-A — polymorphism

It’s often a good idea to add fields (besides methods) into algo objects to make them more like objects. Any one of these fields will help.
– description of the algo
– name of the algo, a bit more readable than the classname.
– category
– a list of client object types ie “who can use this algo”
– platform supported
– version, date, author

binary predictions@next Perl environment

true binary predictions = predictions that can be clearly proved right or proved wrong, never ambiguous or “outcome unknown”. Here are a few almost-binary predictions on the Perl systems in the next company. Let’s verify them 3 months into the job.

BP: Adaptability — to frequent change is one fo the biggest pains, if not the #1. Current Adaptability level isn’t state of the art.

BP: Speed — to market is likely to be the #1 metric. This depends on Adaptability.

BP: modularity, decoupling — between modules is an absolute must for Adaptability and Speed. As a large dev team, they need modularity.

P: perl module dev — Perl module is the standard solution to modular development in large teams. I’m expected to understand and use perl modules.

P: OO — Expertise with OO perl modules, designs, best-practices … is perhaps not insignificant to my role, my job performance, entire-team performance.
– > I believe OO can help Adaptability-to-change, Speed-to-market,

BP: creating Perl classes — within first month, I am not expected to do so for production systems.

P: parsing — biz rules are likely to change often. As far as parsing is concerned, Flexibility could be the #1 Speed factor, leading to fast and reliable implementations.

BP: data volume — is a non-trivial challenge for the perl scripts. Perl Modules, best-practices, designs to solve this problem will receive their attention.

P: Untuned SQL — but functional. Once found, they need remedy, and will not be ignored or accepted. Not a Binary Prediction, because some unimportant queries will definitely be accepted even if untuned.

P: test coverage — many existing non-trivial perl scripts will not have reliable test coverage written for them, but not sure if reliable test coverage is feasible

P: readability — is a non-trivial headache, even if long-tolerated, but not sure how much improvement is feasible.

BP: DB access — in this environment is a standardized and optimized routine that i don’t need to try and improve.

BP: basic XML API — in this place is a standardized and optimized routine that I need not try and improve. You may be able to put XML to new usage, though. You may innovate on a higher level.

equals() needed in most beans, entity/domain objects

Q: Suppose you are writing your own class, and in other classes you plan to use List or Set. What method(s) do you need to write in What if you don’t write the method(s)?I know toString() is not something must have.

A: equals(). Object.equals() uses reference comparison. Without overriding equals(), if you call Collection.contains() or Collection.remove(), you can’t pass in an identical carbon copy. A caron copy won’t pass contains() or remove().

Now most “noun” objects need to be usable in a collection and need meaninful contain() or remove() operations.

Note, once you override equals(), you need to override hashCode(). A Set and a Map are even more dependent on equals().

JMS Q&A, again

J4: Looks like all my coding experience (++ Weblogic MQ, JbossMQ, ActiveMQ) doesn’t give me the nlg to appear experienced in front of the interviewer. Many answers are found in EJB book.

Q: major jms-specific objects involved for sending a msg to a Topic?
Hints: TopicConnectionFactory, TopicSession…

Q: there’s a simple but imp method for MDB and non-MDB alike?

Q: u know a jms program in a container need to query JNDI (for Session, Queue names ….) but how about a stand-alone java app?

Q: (vague question) how essential is onMessage()?
A: Not only MDB, but also needed by a stand-alone java app that subscribes to a jms queue/topic. P335 [[ ejb ]]
-> Q: what other methods in the stand-alone guy?
-> A: it need a way to bind to the queue/topic, often by JNDI

Q: which interface/abstract-class requires onMessage()?

A: topic conn factory <- jndi contains an entry for the factory
factory -> topic conn obj
topic conn -> session obj
topic <- jndi
session, topic -> topic publisher

A: needed too. see P334

A: onMessage()

A: MessageListener iface, which has only one method

Making sense of anonymity && longevity of pl/sql programs

The biggest confusion is nesting.

Longevity depends solely on the o u t e r m o s t layer:
* If outermost is anon, then your unit (even a function) is a throwaway.
* If outermost is in-DB ie an DB entity, then your unit (even if anon) is in-DB and permanent.

– In-DB => outermost is named, even though your unit could be a nested anon.
– named outermost =usually=> in-DB. Throwaway programs need no name.
– throwaway => outermost is anon
– anon outermost => throwaway

in a nested context, Anonymity is layer-specific:
– Your unit could be anon, but the outermost could be named. At the same time, A function may be nested inside your unit.
– Your unit could be a named procedure, but the outermost could be anon. Another anon may also be nested inside your unit.(

No need to combine this post with [[ anon ^ named ]] or [[ in-DB ^ in-anon ]], which offer useful insight. Combining these is time-consuming.