Better Faster Lighter Java [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Better Faster Lighter Java [Electronic resources] - نسخه متنی

Justin Gehtland; Bruce A. Tate

نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
افزودن یادداشت
افزودن یادداشت جدید









1.2 Options



There are many possible solutions

for
dealing with the bloat in Java. Head-on is but one possibility. It
takes courage and energy to take on the bloat, and you may not wish
to fight this battle. You''ve got alternatives, each
with a strong historical precedent:



Change nothing; hope that Java will change




This strategy means letting your productivity and code quality slide.
Initially, this is the option that most developers inevitably choose,
but they''re just delaying the inevitable. At some
point, things will get too hard, and current software development as
we know it will not be sustainable. It''s happened
before, and it''s happening now. The COBOL
development model is no longer sufficient, but that
doesn''t keep people from slogging ahead with it.
Here, I''m talking about the development model, not
the development language. Java development is just now surpassing
COBOL as the most-used language in the world, begging the question,
"Do you want to be the COBOL developer of the
21st century?"




Buy a highly integrated family of tools, frameworks, or applications,
and let a vendor shield you from the bloat.




In this approach, you try to use bloat to your best advantage. You
may put your trust in code generation tools or frameworks that rely
on code generation, like EJB, Struts, or Model Driven Architecture
(MDA). You''re betting that it can reduce your pain
to a tolerable threshold, and shield you from lower-level issues. The
idea has some promise, but it''s dangerous.
You''ve got to have an incredible amount of foresight
and luck to make this approach succeed. If you previously bet big on
CORBA or DCE, then you know exactly what I mean.



Quit Java for another object-oriented language.




Languages may have a long shelf-life, but they''re
still limited. For many, the decision to switch languages is too
emotional. For others, like author Stuart Halloway, the decision is
purely pragmatic. The long-time CTO of the respected training company
DevelopMentor and tireless promoter of their Java practice recently
decided to choose Objective C for an important project because Java
was not efficient enough for his needs. Alternatives are
out there. C# has some features that Java developers have
long craved, like delegation, and C#
hasn''t been around long enough to suffer the bloat
that Java has. Ruby is surprisingly simple and productive, and works
very well for GUI prototyping and development.




Quit object-oriented languages for another paradigm




Every 15 to 20 years, the current programming model runs out of gas.
The old paradigms simply cannot support the increasing sophistication
of developers. We''ve seen programming languages with
increasingly rich programming models: machine language, assembly
languages, high-level languages, structured programming languages,
object-oriented languages. In fact, today you''re
probably noticing increased activity around a new programming model
called aspect-oriented programming (see Chapter 11). Early adopters were using object
technology 15 years before it hit the mainstream. Unfortunately, new
programming paradigms traditionally have been very difficult to time.
Guess too early and you''ll get burned.



Spend time and effort becoming a master craftsman.




An inordinate amount of bloated code comes not from people who know
too much about writing software, but from people who know too little.
The temptation when faced with a problem that you
don''t fully understand is to put everything and the
kitchen sink into the solution, thus guarding against every unknown.
The problem is that you can''t guard against unknowns
very effectively; frankly, all the extra complexity is likely to
generate side effects that will kill the application. Thoroughly
understanding not just your problem domain but the craft of software
development as well leads to better, smaller, more focused designs
that are easier to implement and maintain.




Each of these techniques has a time and a place. Research teams and
academics need to explore new programming models, so they will
naturally be interested in other programming paradigms. Many serious,
complex problems require sophisticated enterprise software, and the
developers working on these problems will look to complex frameworks
that can hopefully shield them from the bloat. Small, isolated
development projects often have fewer integration requirements, so
they make effective use of other programming languages, or paradigms.
But for most day-to-day Java applications, the alternatives are too
risky. My choice is to actively fight the bloat.



/ 111