Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #24662

Re: multiple inheritance in Java

Show all headers | View raw

Jim Janney wrote:
> In theory, if this is a simple aggregation of data, with no relationship
> between the various parts, then you might as well just make them public.
> If there is some meaning beyond simple aggregation, in particular if you
> can define one or more invariants for the class, then you need to
> encapsulate the fields so that the class can maintain those invariants.

Good points, and indirectly raises to mind that there are many factors that 
influence implementation choices like access level. Harping on "in theory", 
if the theoretical model is solely semantic then public variables are fine.

In practice, that is with a model that includes more analytical dimensions, 
you seal an attribute in a get/set for invariants, yes, but also strictly 
internal ones, and also for thread safety, initialization timing, exception 
handling, and such other matters not directly connected to the primary
semantic model.

Also in practice, as an idiomatic matter, there are engineering advantages 
to using the method approach to attribute implementation.

> On the other hand, and this is probably more important, the Java
> community sets great store on always doing things the usual way, and

Pish-posh. You imagine an overarching cultural inertia to a community 
well known for its fractious insistence on competing worldviews.

What I have observed is that people who speak up on such matters in the Java 
"community" tend to be of the "I'm from Missouri, you'll have to show me" 
variety.

Turns out the get/set as a routine idiom has all upside and virtually no 
downside, so as an engineer one tends to use it, just as in C# you use 
its attribute idioms routinely. But "routinely" doesn't mean "mindlessly" 
or "superstitiously" or "to meet the 'community's' approval".

> this has turned into a strength for the language: you can pull a
> third-party library library into a project and expect that it will work

That had better be a strength of every third-party library in every language 
for every platform, hm?

> with and follow the same conventions as the rest of the code.  There are

Code conventions and a library's utility are weakly correlated, I venture.

Internal consistency within the library, sure, but conformity to yours or 
another third party's conventions, even in Java, are not really guaranteed, 
certainly no more so than in other widely-used languages with good conventions.

> languages that encourage the programmer to express his or her
> individuality (Lisp comes to mind).  Java is not one of them.

Sorry, LISP doesn't have coding conventions?

And what does "express ... individuality" have to do with writing good code?

I mean, perhaps it does, I just don't see its help to code quality. In 
decades of working on other peoples' code, the most "individual" code has 
been the most bug-riddled and difficult to maintain. I really don't think 
there is any evidence of a cultural or political conspiracy toward good 
quality code, which by natural selection tends to the better written.

There certainly is a lot of room for style in Java coding, but if you follow 
good engineering practices rigidly there will tend to be commonalities with 
so-called "conventions". You're going to write complete, thorough, informative 
Javadoc comments as a matter of habit. You're going to use get/set methods.
You're going to use a lot of read-only, final, immutable types. You will tend 
to use generics. You're going to indent consistently, if not conventionally. 
You're going to use version control even for solo projects where you are 
producer, director, cinematographer, stars and extras. Every input will be 
checked for boundary conditions. You probably even will have written various 
sorts of useful tests. And this is true whether you're using Java or the useful 
idioms and practices of some other platform.

It happens because you want to write and use code that works, doesn't break, 
that you can fix, that you know what, when, where, how and why. 

One of the most successful IT businesspeople I ever knew charged a service 
contract subscription but only installed stuff that never broke. He was able 
to compete heavily on up-front costs because service was a profit center. Plus 
he used the service contract as an excuse to stay in close touch with all his
customers. Thus cost of sales was actually borne by the customer, and they 
loved it. I can't recall a single customer complaining to him because their 
stuff just kept on working without trouble.

-- 
Lew

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: multiple inheritance in Java Jim Janney <jjanney@shell.xmission.com> - 2013-07-05 10:04 -0600
  Re: multiple inheritance in Java Jim Janney <jjanney@shell.xmission.com> - 2013-07-05 11:17 -0600
    Re: multiple inheritance in Java Arne Vajhøj <arne@vajhoej.dk> - 2013-07-05 17:10 -0400
  Re: multiple inheritance in Java Lew <lewbloch@gmail.com> - 2013-07-05 12:26 -0700
    Re: multiple inheritance in Java Jim Janney <jjanney@shell.xmission.com> - 2013-07-05 16:22 -0600
    Re: multiple inheritance in Java Arne Vajhøj <arne@vajhoej.dk> - 2013-07-05 21:52 -0400
  Re: multiple inheritance in Java Arne Vajhøj <arne@vajhoej.dk> - 2013-07-05 17:09 -0400
    Re: multiple inheritance in Java Jim Janney <jjanney@shell.xmission.com> - 2013-07-05 16:29 -0600
      Re: multiple inheritance in Java Arne Vajhøj <arne@vajhoej.dk> - 2013-07-05 21:53 -0400
        Re: multiple inheritance in Java Jim Janney <jjanney@shell.xmission.com> - 2013-07-05 22:31 -0600
          Re: multiple inheritance in Java Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-18 22:48 -0300

csiph-web