Comments on: Keyed Access Pattern http://www.potentialgames.com/blog/2009/02/09/keyed-access-pattern/ Notes of a Potential Independent Game Developer Sat, 01 May 2010 13:27:33 -0400 http://wordpress.org/?v=2.9.2 hourly 1 By: neb http://www.potentialgames.com/blog/2009/02/09/keyed-access-pattern/comment-page-1/#comment-1398 neb Mon, 09 Feb 2009 15:45:49 +0000 http://www.potentialgames.com/blog/?p=338#comment-1398 All good points. I see modules as improving the Java application deployment process, but not providing any new language-level API improvements. Annotations are closer to the code, but also do not provide any compile-time API restrictions. The goal of this pattern is not <em>security</em>, but <em>integrity of design</em>. I agree that this is not a reasonable solution. The real solution is to either package all such classes together or separate them and live with public methods (or write blog articles discussing improvements to the platform). I feel that the spirit of Java has always been correctness over convenience, which then feeds back on itself as the correctness becomes ease of development. I'm a big believer in RTFM, but opening up a bunch of public methods can make a code base hard to use and maintain. Overall, I prefer to have a strictly defined API, but you're absolutely correct that it can get out of hand. Mainly, I think I just don't like convenience. All good points. I see modules as improving the Java application deployment process, but not providing any new language-level API improvements. Annotations are closer to the code, but also do not provide any compile-time API restrictions.

The goal of this pattern is not security, but integrity of design. I agree that this is not a reasonable solution. The real solution is to either package all such classes together or separate them and live with public methods (or write blog articles discussing improvements to the platform).

I feel that the spirit of Java has always been correctness over convenience, which then feeds back on itself as the correctness becomes ease of development. I’m a big believer in RTFM, but opening up a bunch of public methods can make a code base hard to use and maintain.

Overall, I prefer to have a strictly defined API, but you’re absolutely correct that it can get out of hand. Mainly, I think I just don’t like convenience.

]]> By: Todd http://www.potentialgames.com/blog/2009/02/09/keyed-access-pattern/comment-page-1/#comment-1397 Todd Mon, 09 Feb 2009 14:47:19 +0000 http://www.potentialgames.com/blog/?p=338#comment-1397 I believe "modules" are under discussion for the next version of Java. You might find a better solution using annotations, too. I would be interested in knowing why you feel this sort of control is necessary. Yes, it seems you have a solution to the problem here, but I would hardly call it a reasonable solution. Personally, I believe access restrictions are useful primarily to make it easier for another developer to know what is available in a class. What this proposes makes things pretty convoluted. And besides, we can take one of three philosophies about code protection: 1. We can assume that another developer is incompetent and will mess up the application. 2. We can assume that another developer is malicious. 3. We can assume the other developer is competent. Sure, there are certainly cases where 1 and 2 are legitimate problems, but I feel that maybe we shouldn't allow 1's and 2's to access our code at all. I just seems that being overly protective is, like nearly all security measures, simply punishing the honest people. In this case, yourself. I believe “modules” are under discussion for the next version of Java. You might find a better solution using annotations, too.

I would be interested in knowing why you feel this sort of control is necessary. Yes, it seems you have a solution to the problem here, but I would hardly call it a reasonable solution. Personally, I believe access restrictions are useful primarily to make it easier for another developer to know what is available in a class. What this proposes makes things pretty convoluted.

And besides, we can take one of three philosophies about code protection:

1. We can assume that another developer is incompetent and will mess up the application.

2. We can assume that another developer is malicious.

3. We can assume the other developer is competent.

Sure, there are certainly cases where 1 and 2 are legitimate problems, but I feel that maybe we shouldn’t allow 1’s and 2’s to access our code at all. I just seems that being overly protective is, like nearly all security measures, simply punishing the honest people. In this case, yourself.

]]>