tag:blogger.com,1999:blog-8678405.post7320793016864814396..comments2023-09-02T15:54:52.482+01:00Comments on Ricky's technical blog: Taking private out of code without losing encapsulationRicky Clarksonhttp://www.blogger.com/profile/13845104548520132930noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-8678405.post-13421066462567915852008-08-26T04:32:00.000+01:002008-08-26T04:32:00.000+01:00Fun exercise, perhaps, but what's the point?The ce...Fun exercise, perhaps, but what's the point?<BR/><BR/>The central theme in the points below is: Why pollute the namespace for other programmers? Here 'other programmers' includes yourself, when you are working on a different logical unit. - So no 'this isn't externally facing code' excuses, please.<BR/><BR/>* I have a constructor with way too many parameters / I like my generics inference when I construct objects / it just feels more natural to go with a static method that calls the constructor / These thingies are meant to be returned by other classes in this package only, so why make the constructor public? Now what? - You can't hide constructors in inner classes.<BR/><BR/>* I have a state-change function which also needs to do some validity checking. If not valid, throw an exception. The design model of 'I'll let a PropertyChangeListener throw the exception' is just insanely bad design. I'll leave it as an exercise to the reader why that is. An alternative PropertyChangeListener explicitly designed to do validation, that'd be allright with me.<BR/><BR/><BR/>Finally, on the notion of returning less specific types in order to hide public methods, which is really what's happening with your cableForID trick: Cute. Much more verbose than just tossing a 'private' in there, though.<BR/><BR/><BR/>You've convinced me that you can probably design a language with encapsulation that doesn't have access modifiers, but I'm not at all convinced such a language would be an improvement over something simple, such as 'private', 'friends', and 'external', which are roughly analogous to java's 'private', 'module public', and 'public', assuming the module stuff goes through voor java7 and works the way I think it will.<BR/><BR/>Incidentally, do you do much java programming in your daily routine these days? Just interested.Reinier Zwitserloothttps://www.blogger.com/profile/02743449554705742364noreply@blogger.comtag:blogger.com,1999:blog-8678405.post-35463301058299006952008-08-25T15:47:00.000+01:002008-08-25T15:47:00.000+01:00Interesting thought experiment, for sure. If this ...Interesting thought experiment, for sure. If this were a practical development style in the long haul, then I'd want built-in language features such as properties and closures, since they would reduce the window dressing associated with the code.<BR/><BR/>re: IDEA, I don't have IDEA, I do have Eclipse. Why? Because the price is right. Still I agree with this sentiment - if you were going to release such code in the wild, you would be imposing your development style on them. Some of it is obvious, but some of it is hidden. As a thought experiment, this is fine, in reality, you would need more common agreement.<BR/><BR/>More often than not, the cost of clone() outweighs its benefits, so few people use it. Similarly, the benefits of private outweigh its costs, and so everyone uses it.<BR/><BR/>One last thought: how would the lack of privacy impact VM optimizations?konberghttps://www.blogger.com/profile/04616226121996611123noreply@blogger.comtag:blogger.com,1999:blog-8678405.post-23262068602785765412007-06-22T04:40:00.000+01:002007-06-22T04:40:00.000+01:00Ah, I see, thanks. BTW, javascript has a syntax fo...Ah, I see, thanks. BTW, javascript has a syntax for a lambda calling itself -- arguments.callee is available in a function body. Oh, and if you're living in a functional language, there's always the Y-combinator. *ducks*Anonymoushttps://www.blogger.com/profile/17283718706293247157noreply@blogger.comtag:blogger.com,1999:blog-8678405.post-42264530457165659392007-06-21T10:06:00.000+01:002007-06-21T10:06:00.000+01:00cableIdFor is a Function, and Function only has in...cableIdFor is a Function, and Function only has invoke. I expect there's a reflective way to get at the field, but I'm not interested in preventing reflection.<BR/><BR/>Try this out:<BR/><BR/>Object o=new Object()<BR/>{<BR/>. . public void x(){}<BR/>}<BR/><BR/>o.x(); //won't compile<BR/><BR/>..whereas:<BR/><BR/>new Object()<BR/>{<BR/>. . public void x(){}<BR/>}.x(); //will compile.<BR/><BR/>One more reason to use private is when you have a recursive block of code - at first glance it seems hard to put one of those inside an existing method. You can, though:<BR/><BR/>new Object()<BR/>{<BR/>. . public int fac(int x)<BR/>. . {<BR/>. . . . return x<=1 ? x : x*fac(x);<BR/>. . }<BR/>}.fac(10);<BR/><BR/>I think this is one case that won't benefit from closures, because thus far, there seems to be no syntax for a closure invoking itself.Ricky Clarksonhttps://www.blogger.com/profile/13845104548520132930noreply@blogger.comtag:blogger.com,1999:blog-8678405.post-89433310380721993892007-06-21T03:11:00.000+01:002007-06-21T03:11:00.000+01:00I'm confused... what prevents someone from breakin...I'm confused... what prevents someone from breaking encapsulation by accessing cableIDFor.cableIDs?Anonymoushttps://www.blogger.com/profile/17283718706293247157noreply@blogger.comtag:blogger.com,1999:blog-8678405.post-53370264870350306852007-06-20T19:43:00.000+01:002007-06-20T19:43:00.000+01:00What you've done with the cableID map reminds me a...What you've done with the cableID map reminds me a lot of javascript programmers emulating private members. That is, returning a closure that captures non-global context.<BR/><BR/>Good provocative post.b0b0b0bhttps://www.blogger.com/profile/09035894926385999507noreply@blogger.comtag:blogger.com,1999:blog-8678405.post-37643525778727546532007-06-20T02:56:00.000+01:002007-06-20T02:56:00.000+01:00I'm not saying that checking isn't necessary. Wha...I'm not saying that checking isn't necessary. What bugs do private constructors prevent that an IDE inspection checking against instantiating a utility class would not?Ricky Clarksonhttps://www.blogger.com/profile/13845104548520132930noreply@blogger.comtag:blogger.com,1999:blog-8678405.post-68987811253252220852007-06-20T02:37:00.000+01:002007-06-20T02:37:00.000+01:00"I'm a smart enough developer that I don't need a ..."I'm a smart enough developer that I don't need a private constructor to tell me that"<BR/><BR/>That's great. So you and only you are the only one that uses your code base? Why do you need to have runtime checking? Make everything Object. You are a smart enough developer to use the correct type of object at the right time.<BR/><BR/>Most of us write code that is used by many developers so making the code prevent honest mistakes is a good thing, so stuff like a private constructor isn't unused code. It is code to prevent someone from introducing bugs when working at 1am. Other programmers, not us, we are too smart to make mistakes like this. :)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8678405.post-65594188595144927752007-06-19T14:51:00.000+01:002007-06-19T14:51:00.000+01:00Ghar ... sorry. I just spotted my mistake. :)Ghar ... sorry. I just spotted my mistake. :)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8678405.post-54587896644794894102007-06-19T14:48:00.000+01:002007-06-19T14:48:00.000+01:00"What about the property stuff do you not understa..."What about the property stuff do you not understand?"<BR/>I am just missing them in the example you gave. :)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8678405.post-86679891766621066932007-06-19T14:21:00.000+01:002007-06-19T14:21:00.000+01:00Stefan, I agree about the private constructor, and...Stefan, I agree about the private constructor, and about interesting getters. My Property interface would cater for those with no problem.<BR/><BR/>What about the property stuff do you not understand?<BR/><BR/>hashMap() is somewhat misleading, here's the implementation:<BR/><BR/>public static <K,V> Map<K,V> hashMap()<BR/>{<BR/>. . return new LinkedHashMap<K,V>();<BR/>}Ricky Clarksonhttps://www.blogger.com/profile/13845104548520132930noreply@blogger.comtag:blogger.com,1999:blog-8678405.post-40267340375639504302007-06-19T13:51:00.000+01:002007-06-19T13:51:00.000+01:00Removing a private constructor is no gain no loss,...Removing a private constructor is no gain no loss, except for it not being visible. Calling the constructor of a utility class also is no harm, you just end with an instance of no use only having static methods/fields. So, I see no problem here except for the missing documentation part of a private constructor.<BR/>To give you an idea of interesting getters: lazy instantiation/loading.<BR/>Btw. I missed the property stuff in your example. What's hashmap() doing?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8678405.post-30490437838113086412007-06-19T04:00:00.000+01:002007-06-19T04:00:00.000+01:00If I couldn't rely on IDEA then I'd do it in some ...If I couldn't rely on IDEA then I'd do it in some other way - <A HREF="http://rickyclarkson.blogspot.com/2007/05/using-just-jdk-and-55-lines-i-can-find.html" REL="nofollow">see this blog post</A>. Why wouldn't you have IDEA anyway?<BR/><BR/>Error checking isn't unused code. You will invoke error checking code as part of normal operation. I would not normally invoke that constructor in normal operation. It is unused code, gaining me only the idea that instantiating that class is pointless.<BR/><BR/>I'm a smart enough developer that I don't need a private constructor to tell me that - if there are no non-static members then I don't need an instance.Ricky Clarksonhttps://www.blogger.com/profile/13845104548520132930noreply@blogger.comtag:blogger.com,1999:blog-8678405.post-35001455185634074632007-06-19T03:26:00.000+01:002007-06-19T03:26:00.000+01:00"Low-hanging fruit first: Private constructors. So..."Low-hanging fruit first: Private constructors. Sometimes these are used to prevent instantiation of a utility class. IDEA actually warns me if I instantiate a utility class, so I don't need the constructor. It's a no-brainer to delete unused code."<BR/><BR/>You are assuming everyone using your code uses IDEA and has it setup to warn about this. If that is a good assumption, then this is good. If you are writing open source code, this isn't a good assumption so it would be bad to delete that constructor. IMHO.<BR/><BR/>It's not a no-brainer to delete unused code. If you do this, you'd delete error checking because if things go well, it is not used, right? Deleting this constructor assumes programmers will do the right thing so it is like error checking code.Anonymousnoreply@blogger.com