Blogs:JaroslavTulach:Practical Design
From APIDesign
(→= Co-exist in Peace! Accept Alter Ego.) |
|||
Line 3: | Line 3: | ||
<startFeed /> | <startFeed /> | ||
- | ==== Co-exist in Peace! Accept Alter Ego. === | + | ==== Co-exist in Peace! Accept Alter Ego. ==== |
APIs age and from time to time they get into so bad state that they need an [[AlternativeBehaviour|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. | APIs age and from time to time they get into so bad state that they need an [[AlternativeBehaviour|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. |
Revision as of 16:56, 16 February 2009
Practical Design
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)