Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
When using Management Beans in Java, its interface is exposed through MBean Interface. But if there are various parameters to be exposed through MBean. And with different version of the system, many new parameters might be added or subtracted from the MBean, then it becomes very tedious to manage such system.
Is there any design pattern that can be used to avoid such problems ?
If you want things to happen dynamically, you’ve got to have some logical rule to dynamically determine which fields \ methods of the managed class should be exposed and which should not.
Now, you might be able to implement a Dynamic MBean (see a great explanatory example here) and use reflection to gather up-to-date information of the managed class. The reflected class info should then be filtered against the previously mentioned rule (hoping all other programmers follow it! I wouldn’t count on it).
OK, so this isn’t a design pattern. I think the real recommended pattern is that the programmer that adds certain property should take the few moments reasoning whether it is worth exposing and whether it is safe to be exposed. And when removing a property, one should think whether it doesn’t break any exsiting client code out there.