Slashdot Mirror
Sun's Joshua Bloch On OOP/OOD In Java
f00zbll writes: "A good article about development and OOP/OOD. The lessons apply to most OO languages and OOD. Interview with Joshua Bloch over at Javaworld. Ignore the fact that Java is owned by Sun and use the tips to help your work/project/development."
This is one of the most common fights between us (developers) and management. Often managers are only interested on the fastest route, without considering the maintenance costs down the road.
I'll be emaling my manager a link to this story (anonimously, of course. I want to keep my job ;-)
John
The drops of water don't know themselves to be a river; and yet the river flows.
I'd like to hear someone write about how to make the trade-offs architects really face:
These topics would be of greater value to the development community than articles which presume hypothetical arrangements.
This guy just gave me the encouragement I needed.
/standalone/ programmer/designer/analyst, I
As a
developed this API design philosphy on my own.
Actually, I have evolved to it.
If you are in a one-mans shop, or do alot of coding
for a specific domain, try to roll out your own
layer of helper APIs on top of the system provided ones.
I work on win32 and ODBC: I have my own class
hierchies of *standard* dialogs for DB applications.
Ex: the ActiveX components for DB Appz (advanced
list views, financial stats, bar charts and graphs, etc.)
are really resource greedy (the updating required
for a dynaset database connection, with millions
of records being fetched per minute is very
expensive.)
So I wrote some ready to run classes, that take
care of the interface (with all the company logos
and standard look-and-feel stuff.)
then wrote some other classes to wrap around the
"CResultView" classes, and finally,
wrote some classes that *know* about our strange
servers, and are optimized for them (including
a connection "language" I derived, which is nothing
more than a hand optimization of the subset of
SQL accepted by oracle.)
So, if the shop is good to you, be good to them
and put your talent to work.
The API method works, and I am a living witness for it.
tell that to Netscape.
Topics include how much subclasses should be "trusted", immutables, reasons for disallowing inheritance, copy v. cloning, factory methods versus constructors, and more.
Great theory. Unfortunately, you forgot that the company who does the quick but not reuseable work gets to market first. If they get there "first enough", the competition are already toast. All the reusability in the world doesn't mean jack if your company has already lost 95% market share to a rival who released 6 months earlier.
I am a great believer in the fact that "quality is free" -- doing a proper job of things like initial design and documentation more than pays for itself in the long run. However, it's important to do all things in moderation. Remember the old rule that it's only reuseable if it's useable in the first place. There is no point overengineering an initial solution for reuse if you're not going to meet your first set of requirements, which normally includes getting to market within a competitive timeframe. If an initial design isn't up to that, is it really a good design at all?
Well, that and a few years' headstart, anyway. :-)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I am a bit confused by this article.
"It is imperative that this method's client not modify the object after it is called, blah, blah, blah. Yes, you can successfully write code that way. Anyone who has programmed in C or C++ has done so"
C++ has the const keyword for parameters that are not to be mofidied, as well as const for methods that do not modify, such that they can be called as const objects for this very situition. Or does he mean something totally different?
Also, he says that you "must trust clients to obey the contract" later in the article, isn't making a defensive copy just breaking the trust?
OK, what can you really say about these issues?
So you do the best with what you can, and it either works or it doesn't, and you make money or you don't, or you stay in business or go out of business.
If you want to talk about business reality, that's business reality. The dot com boom and the dot com bust are business reality. Incredible hype about Enron followed by its bankruptcy are business reality. The recession is business reality, and so is prosperity. And sometimes business reality is producing crap software that is full of holes.
You have your compromise already. You work like hell and design well and find out that for all that people in business talk about profit for the company, it all turns out to be the color of their parachute. Then you figure this out and either cheat like all the rest or else you get into a position where you are allowed to write good software, which is almost never software that is sold, unless it's a game or industrial control software. What other kind of compromise were you expecting?
You can do things properly, or you can do them improperly. When you do them improperly they fail more often. You can pile up good, solid business reasons why you have to do things improperly, and I don't care what color your power tie or how earnest and "forward-looking" you are, or how many inspirational posters you have, doing things improperly leads to failure.
Any veteran of business software development would know these things and, if honest, would have to write about them. Then people wouldn't like it, and they'd mod it down or not buy the book or tell the author he's an asshole because they want to hear that there's a magic incantation that turns mediocrity into gold. They want to hear about Extreme Programming or The Latest New Buzzword that Embraces Change! The newer the better. Old ideas are annoying, because you've already had time to find out that they don't magically work, while there's always the chance that the latest and greatest will make everything OK and nobody will have to get nailed to a tree.