EXTREMEZONE FORUM
WWW.EXTREMEZONE.3XFORUM.RO - WWW.TORENTZ.3XFORUM.RO- WWW.PETARDEARTIFICII.CABANOVA.COM http://www.facebook.com/petardeartificiidevanzare
|
Lista Forumurilor Pe Tematici
|
EXTREMEZONE FORUM | Reguli | Inregistrare | Login
POZE EXTREMEZONE FORUM
Nu sunteti logat.
|
Nou pe simpatie:
Profil Roxxy22
 | Femeie
25 ani
Cluj
cauta Barbat
25 - 48 ani |
|
|
sanraj
INCEPATOR
Inregistrat: acum 16 ani
Postari: 45
|
|
Apress L. P. | ISBN 978-1-4302-0973-7 | Pages: 417 | English | PDF | Size: 3.6 MB | RAR-Commpressed : 2.0 MB | No Password
Prologue: Yet Another Design Book?
“There are more than enough design books in the programming world already,” you might think. In fact, there are so many that it makes sense to ask why I would write—and especially why you would read—yet another one. Particularly, there is the famous Design Patterns: Elements of Reusable Object-Oriented Software,1 about design patterns in object-oriented systems, written by the so-called “Gang of Four,” which is a must read for every developer making use of any object-oriented language. In addition, there are many specialized books describing design patterns, all of them useful when writing specific types of applications. Moreover, there is the unofficial Java programmer’s bible, Effective Java.2 In light of these facts, is there really a need for yet another design book? I believe the need exists. I’ve been designing NetBeans APIs—that is, application programming interfaces—since 1997. I’ve passed through almost all the possible stages a person designing a framework or a shared library can pass. In the early days, I slowly gained a feel for the Java language while trying to apply coding styles that I knew worked well in other languages. Later, I became fluent in Java. At that point, applying various known patterns to my code written in Java seemed so simple, although after a while I realized that things are not always as easy as they seem. I realized that traditional patterns are not appropriate for an object-oriented application framework such as NetBeans, and that you need a completely different set of skills. The oldest NetBeans APIs were designed in 1997. Some of them are still in use and working adequately even after ten years of service, although to be honest, these are not exactly the same APIs as they once were. Over the years, we needed to accommodate new requirements, extend library functionality, and fix beginners’ mistakes. Despite that, the API clients that compiled their code then are still able to execute their code, even with today’s latest versions of those libraries. This is possible because we always tried, as far as reasonably possible, to maintain backward compatibility. As a result, the programs written against our decade-old libraries are likely to work even in their current versions. This preservation of investment— that is, our decision to let our libraries evolve in a backward-compatible way—is something not seen in common design books, at least not in the ones I’ve read so far. It’s not that all Net- Beans APIs were evolved without problems, but I’ve come to believe that the NetBeans team has now mastered this skill to a high degree, and also that this skill is widely needed among other groups of programmers. That is why a large part of this book talks about retaining backward compatibility and about special API design patterns that produce code suitable for maintaining in a backward-compatible way. Prologue: Yet Another Design Book?
The other challenge we faced when working on the NetBeans project was scalability of teamwork. In those early days, back in 1997, I wrote the APIs on my own. The other NetBeans engineers “just” wrote the code; that is, they provided user interfaces and implementations for various parts of the NetBeans IDE, while continually making use of the APIs that I provided. Unsurprisingly, this created a bottleneck. I came to realize that the number of people working on various NetBeans IDE features had grown to a capacity where one “architect” was unable to handle the demand for APIs. Over time, change was urgently needed. We needed a majority of the NetBeans development team to be able to design their own APIs. At the same time, we also wanted to maintain a certain level of consistency between the APIs created by different people. This turned into the biggest problem, not because developers didn’t want to be consistent, but because I wasn’t able to explain to them what I meant by consistency. Maybe you know the
feeling of knowing how to do something, without knowing how to explain it coherently. That was my situation: I thought I knew how to design APIs, but it took many months before I managed to formulate the most important constraints that I wanted others to follow.
Download
Code:
http://www.uploading.com/files/PF14EDMN/Apress_Practical_API_Design_Confessions_...rar.html |
|
|
| pus acum 16 ani |
|
