Blogs:JaroslavTulach:Practical Design

From APIDesign

Revision as of 12:58, 21 November 2009 (edit) JaroslavTulach (Talk | contribs) ← Previous diff		Revision as of 08:59, 24 November 2009 (edit) (undo) JaroslavTulach (Talk | contribs) Next diff →
Line 2:		Line 2:
	<startFeed />		<startFeed />
		+
		+	==== Avoid [[Visitor]]s. Unless you really know them. ====
		+
		+	[[Visitor]] pattern is one of the well known [[OOP]] patterns. However using it in an [[API]] is dangerous. At least unless you have read [[chapter 18]] of [[TheAPIBook]] or studied my [[visitor|sample code]].
		+
		+	--[[User:JaroslavTulach|JaroslavTulach]] 08:59, 24 November 2009 (UTC)
	==== Podcast: [[AOP]] is not dead. If you know how to use it! ====		==== Podcast: [[AOP]] is not dead. If you know how to use it! ====

---

Revision as of 08:59, 24 November 2009

Contents 1 Practical Design 1.1 Avoid Visitors. Unless you really know them. 1.2 Podcast: AOP is not dead. If you know how to use it! 1.3 Screencast: Module System for Java 1.4 The End of MVC as We Know it 1.5 @Synchronized 1.6 XML, Schema, SAX. @Annotations! 1.7 Extend Inextensible! 1.8 Try to Steal my Object! 1.9 Plug into Your Compiler! Optimize Your Framework by Generating Compile Time Caches. 1.10 Victims of Conceptual Surface 1.11 Splitting applet and beans via CodeInjection 1.12 Help me modularize JDK 1.13 Everyone is equal. Except Power Users. 1.14 Double Injection. Loosely Coupled SpringFramework. 1.15 Clear Definition of Version 1.16 Lookup is Free! 1.17 D2D: Factory instances are more flexible than factory classes 1.18 Can there Be Implement Only Interface? 1.19 Application Context in Ruby 1.20 Get Rid of Multi-Meaning Classes 1.21 Eliminate Fuzzy Modifiers! 1.22 Time to Fix Java Access Modifiers! 1.23 Co-exist in Peace! Accept Alter Ego. 1.24 Beware Exposing Yourself to Public! 1.25 Try, catch, and don't give up! 1.26 Accept Unacceptable! 1.27 Singletonize your own Factories! 1.28 Wizard is the best API 1.29 Builder vs. Cumulative Factory 1.30 Cumulative Factory API Design Pattern 1.31 How Many People Have to Die leakages 1.32 Exceptions in API 1.33 Have You Ever Wondered? 1.34 Request/Response Pattern Revisited

Practical Design

Avoid Visitors. Unless you really know them.

Visitor pattern is one of the well known OOP patterns. However using it in an API is dangerous. At least unless you have read chapter 18 of TheAPIBook or studied my sample code.

--JaroslavTulach 08:59, 24 November 2009 (UTC)

Podcast: AOP is not dead. If you know how to use it!

Recently I saw the future of AOP. I thought one should say goodbye to AspectJ and its clones and get ready for ease of use that makes AOP wide spread! After few comments I know that it is enough to learn more advanced capabilities of AspectJ. But don't forget to do so, such flavor of AOP is much better than plain writing of aspects.

--JaroslavTulach 12:56, 21 November 2009 (UTC)

Screencast: Module System for Java

Module system is single, most important missing feature of Java. It is essential for the vitality of the Java system to define and agree on shared standard. On shared common ground. Recently me and Geertjan created a recording where we discuss why it is important to have it. We also demonstrate on the NetBeans and Mylyn synergy how such system would simplify our lives. If you have half an hour, listen to our screencast and join us with comments.

--JaroslavTulach 09:07, 27 October 2009 (UTC)

The End of MVC as We Know it

Geertjan literally forced me to record a screencast about DCI with him today. We did rehearsal over lunch and beer (quite lively and interactive). Then he drag me into the recording room and we did it (less interactive, but more serious and important).

Join us to learn why MVC days are over and you should switch to a new paradigm ready for the 21st century!

--JaroslavTulach 20:52, 22 September 2009 (UTC)

@Synchronized

Synchronization is getting more and more important in applications and libraries written these days. However synchronization is hard. The primitives available in Java (or other languages), are ... well, are primitive. Higher level abstractions are available, but still they don't guarantee completely deadlock prone system. This has all been discussed in Chapter 11, Runtime Aspects of APIs.

Java Monitors just aren't what they supposed to be (read why). Thus I am glad to see that the project Lombok's @Synchronized seems to successfully replace the synchronized keyword with annotation (vivat annotations!).

In the name of cluelessness of your Java API users, don't forget to prefer private locks to synchronized methods. Or switch to the beautiful @Synchronized annotation.

--JaroslavTulach 08:51, 7 September 2009 (UTC)

XML, Schema, SAX. @Annotations!

Some say that code completion with annotations is not big improvement. XML can have code completion too if we give XML Schema with it. I disagree! Anyone to comment on that?

--JaroslavTulach 10:35, 31 August 2009 (UTC)

Extend Inextensible!

Interfaces are not extensible. Learn how to extend them!

--JaroslavTulach 11:31, 19 August 2009 (UTC)

Try to Steal my Object!

Recently my cousin was teasing my mind with a question whether there is a way to make anything private in Javascript. I may be wrong, but I think there is: Is there anyone who can steal and modify my internal impl object?

--JaroslavTulach 04:35, 5 August 2009 (UTC)

Plug into Your Compiler! Optimize Your Framework by Generating Compile Time Caches.

Learn how to generate CompileTimeCaches with a little help of source-only annotations and their AnnotationProcessors.

--JaroslavTulach 14:08, 25 July 2009 (UTC)

Victims of Conceptual Surface

Do you know how to eliminate classes with too many dependencies like java.beans.Beans? You need to Sneak in Simplicity!

--JaroslavTulach 16:32, 22 June 2009 (UTC)

Splitting applet and beans via CodeInjection

I have a basic infrastructure to split the JDK which could be useful in your project as well. Also I managed to successfully split java.beans and java.applet packages.

--JaroslavTulach 12:39, 17 June 2009 (UTC)

Help me modularize JDK

Creating modular JDK while keeping compatibility with the existing monolithic one may be tricky. Will you help me find right way to do it?

--JaroslavTulach 20:14, 14 June 2009 (UTC)

Everyone is equal. Except Power Users.

Learn to design Privileged API suitable for power users of your library. Don't forget to listen to podcast #3.

--JaroslavTulach 17:01, 25 May 2009 (UTC)

Double Injection. Loosely Coupled SpringFramework.

I have just finished the bridge between Spring and Lookup (originally written by AndreiBadea) and prepared a demo application to demonstrate what it can be useful for.

--JaroslavTulach 04:43, 28 April 2009 (UTC)

Clear Definition of Version

Interfaces are absolutely perfect tool to achieve ClearDefinitionOfVersion. A curious reader question made me write the ClearDefinitionOfVersion page - many thanks for your talkback.

--JaroslavTulach 19:55, 24 April 2009 (UTC)

Lookup is Free!

Time to pickup cherries! Nobody can know what happens to NetBeans after the Sun/Oracle acquisition. Better to be ready for everything and save the NetBeans API pieces that make sense outside of the project boundaries. One of them is Lookup. I am proud to announce that Lookup has new home now: lookup.apidesign.org. Welcome the refugee and let me know if there is a way I could improve the library.

--JaroslavTulach 05:54, 21 April 2009 (UTC)

D2D: Factory instances are more flexible than factory classes

As part of Designers To Designers section on this website I seem to have a unique chance to introduce Factory instances are more flexible than factory classes article by (yet) unknown designer. Enjoy, talk back.

--JaroslavTulach 08:40, 18 April 2009 (UTC)

Can there Be Implement Only Interface?

Here is my answer to question that I got by parren.

--JaroslavTulach 18:20, 12 April 2009 (UTC)

Application Context in Ruby

Recently I've noticed a lot of activity in the apidesign.org wiki. Perfect. Inspite it is more posts than I can handle.

However I am thankful for all your comments and I hope this wiki can become a place for exchange of ideas between people interested in API design. For example, Steve Shapero added a note about his will to seek for Application Context implementation in Ruby. I personally cannot be really useful, as my knowledge of the Ruby language is quite basic, but maybe some of you will join Steve's effort.

PS: Let us know how it went. You know, I feel that Ruby's duck-typing and API contracts may not be mutually strengthening...

--JaroslavTulach 19:30, 11 April 2009 (UTC)

Get Rid of Multi-Meaning Classes

In the latest example related to modifiers, I'll explain how to achieve even more clarity than advocated by EliminateFuzzyModifiers essay. Today we are going to eliminate multi-meaning classes!

--JaroslavTulach 16:42, 1 April 2009 (UTC)

Eliminate Fuzzy Modifiers!

Time for new post about modifiers. My recent take on access modifiers generated quite a bit of interest. I've received a bunch of comments and I am thankful for all of them! I've learned about approaches taken by different languages, I've started to think about my future, but more importantly Arno Nyhm asked me to:

please show not only a bad example for the Factorial

but also a good solution for this implementation.

At your wish Arno! Enjoy (almost) real world example how to EliminateFuzzyModifiers! And let me know what you think.

--JaroslavTulach 20:50, 27 March 2009 (UTC)

Time to Fix Java Access Modifiers!

I have an open letter to designers of Java language for JDK7: Can you please make Java modifiers API-friendly?

--JaroslavTulach 22:14, 25 March 2009 (UTC)

Co-exist in Peace! Accept Alter Ego.

APIs age and from time to time they get into so bad state that they need an alternative reimplementation. At that time one has to face a dilemma: Keep BackwardCompatibility or break it and improve the API? As AlternativeBehaviour page explains there is no contradiction between these two. One can deliver improvements while retaining BackwardCompatibility. All that is needed to teach the API to accept its Alter Ego.

--JaroslavTulach 16:56, 16 February 2009 (UTC)

Beware Exposing Yourself to Public!

Erwin Vervaet asked me to provide an explanatory example:

I have a question regarding chapter 11, section "Pitfalls of Java Monitors".

Could you please provide an example illustrating the problem, where

subclasses interfere with the parent class's monitors?

It took me a while to expose that example, but here finally is my newest page talking about Pitfalls of Java Monitors.

--JaroslavTulach 10:15, 12 February 2009 (UTC)

Try, catch, and don't give up!

When your call to a method generates an exception, what can you do? Print warning and give up? Yes, often. Unless the TryCatchRedo pattern is in use!

--JaroslavTulach 15:29, 2 February 2009 (UTC)

Accept Unacceptable!

When you maintain some code and you get a patch that you do not like, what can you do? Is the only option to refuse the change, or is there a better way? Of course, as this was just a rhetorical question, there is better solution: Just create a code slot!

--JaroslavTulach 21:31, 10 January 2009 (UTC)

Singletonize your own Factories!

I am reading my own book and I've just got to page that talks about a pattern called among the NetBeans team Singletonizer. TheAPIBook describes it with a small note, but as I think it is very useful, I've just created a dedicated page describing it in more detail, giving it more, well deserved, publicity.

--JaroslavTulach 16:29, 25 December 2008 (UTC)

Wizard is the best API

There is a nice discussion provoked by description of my manifest advantures. It reminds me once again how important tools are. As I wrote somewhere in TheAPIBook, I guess it is in Chapter 9, one of the best APIs is wizard. Good wizard can turn any API, regardless how bad, into perfectly shining, beautiful star. Good tools make everything easier.

--JaroslavTulach 13:49, 19 December 2008 (UTC)

Builder vs. Cumulative Factory

Is Builder better pattern than CumulativeFactory? As Radim and Paulo pointed out, it might be. However from my point of view, it is an extension to the previous one! Read more and help us decide...

--JaroslavTulach 13:02, 15 November 2008 (UTC)

Cumulative Factory API Design Pattern

Dear API writers, let me introduce you to cumulative factory API Design Pattern. Read more...

--JaroslavTulach 15:38, 9 November 2008 (UTC)

How Many People Have to Die leakages

Recently I've been warned that my sidebar in Chapter 4, Ever Changing Targets talks about events that are completely ununderstandable for international readers. That made me write a short essay about leakages of cultural contexts and the similarities with the API Design.

--JaroslavTulach 05:01, 21 October 2008 (UTC)

Exceptions in API

Casper Bang asked following question about exceptions in API after reading the TheAPIBook:

I was curious as to know how come, in a book strictly about API design in Java, you do not mention exceptions (particular checked exceptions) and the role they play in documenting assertions vs. hampering versionability. Did you simply think this to be too controversial an issue I wonder?

Good question! Inspiring. Here are my current answers: exceptions in API.

--JaroslavTulach 21:37, 14 September 2008 (UTC)

Have You Ever Wondered?

Many people want to know, before they start to read a book, whether it can help them solve some problems they have faced. That is very likely reason why many books start with have you ever wondered sections. The Practical API Design book does not contain such section itself, however that in no way means that there it is not helping to solve problems! You can bet that there is a lot of useful advices! The book is a lab journal describing adventures of NetBeans project and as such, it is almost completely stuffed with problem solutions. Here is short online version of Have You Ever Wondered to demonstrate that. Visit the page and check yourself what problems can TheAPIBook solve for you!

--JaroslavTulach 20:42, 17 August 2008 (UTC)

Request/Response Pattern Revisited

Here is few additional thoughts about Request/Response which did not make it into TheAPIBook's explanation of Request/Response pattern.

--JaroslavTulach 21:02, 25 June 2008 (UTC)