Win a copy of Head First Android this week in the Android forum!

Brian Schaefer

+ Follow
since Feb 20, 2001
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Brian Schaefer

Let's see, this is a guess. You have a class file from some one else, called Other.class You could decompile it( just load it into and IDE), and see what package it in in. Then put it in that package stucture, and use an import statement in your own code. Then use reflection on it.
As far as being able to do that dynamically, ( such as a user selecting a .class file from a gui) you could run exec commands that did all of the above. Quite a chore. There must be a better way.
20 years ago
Yup, that last answer by Max is the correct one. If you can mess with the object that the caller has a reference to, that is "pass by reference." Just because someone writes an article titled "Everything is pass by value." doesn't make it so. In fact, one of the articles referred to above has a terrible example using strings --- it makes a difference because strings are immutable.
20 years ago
Here are 2 more considerations:
1/ Although initial development may be easier in some languages than others, MOST software cost (80% they say) is in the maintenance. (from the developers point of view, most of the aggravation in the maintenance too) So a language that is easy to maintain is a major consideration.
2/ Java is faster than C in many situations. Try measuring the performance of a method using HotSpot. It never seems to cease getting faster as you run it longer. The day will come when dynamic byte code interpreters can more pervasively beat native compilers. In the meantime, thank our lucky stars for a language that makes OOP facile and enjoyable, and is plenty fast enough. ( even if you don't use some common sense and recycle or create less garbage)
20 years ago
Just to add to the record, I won a book a few weeks ago, and got the book promptly. Good book too: Enterprise Java with UML. I got the impression from the award that the winners are drawn at random from the participants in a forum ... not on the quality of the message.
This topic has been great. I think we have 3 good ways so far of partially implementing an interface:
1/ Divide and Conquer
2/ Throw a NoSuchMethod
3/ Override an Adapter (although the adapter methods would
vary depending on the purpose:
empty, implement, or throw.)
Here's a fourth ( weak) one that I can think of quickly:
4/ Use the Adapter class in composition instead of extending
it . Then delegate the calls to it. Not only can you
choose which calls to delegate, but you can ask "who
called?" and then implement dynamically.
20 years ago
It is true that UML is important because it provides a common language. However, one of the "over rated" aspects of it is how complete a language it is. It is analogous to icons compared to English: Like a Hand on the crosswalk light instead of WALK, or a circle with a line through it superimposed on a drawing of a bicycle. It suffers from the lack of richness that a language possesses. The common language for coders is code. When we think, we talk to ourselves in code. Personally, when I find myself designing, I think in terms of what the methods are doing, and what state they are operating on. A UML diagram does not contain that information. The names and signatures of methods only, and association lines all over the place, don't seem to help me very much. Class diagrams are certainly helpful to visualize a complex hierarchy, but that is simply a diagram that we would sketch anyway, like a directory key. The multiplicity notation may be helpful to some people, however I find it confusing until I know how it's implemented in the code through collections and sets. Tools for using UML, like TogetherJ, where the code and UML are visible and automatically kept in sync do hold more promise of helping coders think and communicate. However, the diagram will always be redundant to the code. I'm reminded of the saying, "A picture is worth a thousand words," and the observation that you need words to say that. Also needed is a person who thinks in that language. A picture may be worth thousands of words because of the details, but a set of icons is worth an exact small number of words.
One diagram that is useful to me is the old flow chart, activity diagrams. However even flow charts, as I've learned to code simpler, smaller methods and objects, are losing their usefulness. The goal is simple, self documenting code, that can be read by anyone... pleasurably, like poetry.