Java project wide defines

You can use Java's access control keywords to (public, package-private, etc.) to limit visibility. And, of course, try not to have too many globals in general.

Well, that's a quite standard implementation. You can plonk constants in any class- in a way it's nice because you can organize things in namespaces. You can also use static imports if you don't like seeing Class.CONSTANT and you'd prefer to see only the constant name.

Hiding the constructor is the most correct way if you want to completely avoid someone creating instances of a constant class, but you might really not need it, if it rubs you the wrong way. Also, the constants can live in classes that have other code- if that is right in your code.

There's also Java enums for some things- they are very nice enums!

(In general, you don't have to force yourself to do "OO". You can have as many static methods as you want, which are functions. It is nice to associate methods with structs, and it might be needed to interact with some APIs, but the "Java forces you to do OO" is IMHO somewhat overblown.)

koala said:

(In general, you don't have to force yourself to do "OO". You can have as many static methods as you want, which are functions. It is nice to associate methods with structs, and it might be needed to interact with some APIs, but the "Java forces you to do OO" is IMHO somewhat overblown.)

Click to expand...

All the toy projects I've written in Java (and some that might have even made it to prod) show that I was first taught a procedural language (either BASIC or Fortran, take your pick). All the resulting projects have worked as well as I expected. None of them were ever "real" OO projects. And that's fine, as none of them were designed to be enterprise programs that would need maintenance after the Unix Epoch rolls over. And even if they did need maintenance that far into the future, they'd just join the legions of C and COBOL (and even FORTRAN) programs that will still need maintenance then, too.

I don't remember the other reasons that OO was trumpeted as important, but it's the one that's always struck me as the easiest to disprove argue against.

There's plenty of literature that discusses this. OO APIs had their heyday with some GUI frameworks. Inheritance is also popular in other frameworks.

In Java there are two ways to implement threading, IIRC- one is to extend the Thread class, the other is to implement the Runnable interface. So even in Java you normally have an alternative to use inheritance.

Inheritance has some places where it can be a good solution, but it's rarely the best option.

Remember OO <> Class Inheritance (or indeed Inheritance at all)

OO is at it's core "messages being passed between objects which can have data and code associated with them"
Alan Kay gets to decide that because he invented it and the term

If you have types with OO programming then really the LSP is the bit that really starts to matter. Which is basically, what objects can I put into these holes (variables) correctly - where the type should mean that this is correct if the programmer did the right thing (and should have done so unless they are a numpty).

You can have purely interface based "Inheritance" in OO languages at which point the terminology of inherit doesn't actually make sense - there's nothing inherited unless you can have an interface extend another one. You are just committing your type T to implement the contract implied by interface I, no data or executable code is transferred from I to T.
VB6 is an example of this.

Many languages that are OO centric have class based Inheritance, but big ones like JavaScript did not (having prototype based forms instead) so classes themselves are in no way foundational to OOP (though some people incorrectly assert they are).

One aspect of java worth knowing is, an often derisory phrase (that is also not strictly true¹).

"In Java everything is a class"

However it does have quite a kernel of truth to it because, in java (and many other languages) all code and data needs to be associated with a class (and if not static and instance of that class).
This is just how the sepcification of those languages compiled forms work. So you'll end up needing to define a class to hold a bunch of constants, and that's fine.
C# had the same thing and the pattern was sufficiently well defined that syntax and compiler support were added to let you define "static" classes which would refuse under any circumstances to be extended or be instantiated - even by reflection. But it's basically the same technique, you define a private constructor and mark the class abstract.

Some things in java do not require explicit classes, but will be compiled into them anyway (with special names which the user cannot collide with as the names are reserved for the compiler use only). Lambda closures (where previously you needed anonymous inner classes) are one of the earliest examples of this, though they compile to pretty much the same thing under the hood in most cases. Thus "classes" can be a reification of the need to hold compile time determined pieces of state associated with code that uses them where the values and numbers of them are known only at runtime.

1. For a counter example an int is not a class, but an Integer is (and they are not the same thing, though sometimes the compiler will try to pretend they are for you to varying degrees)

Is there any term in computing that maintains its original meaning?

If you want a clearer rendition of what I'm trying to say: you can write mostly anything in Java using only static methods, classes as structs, without using "extends" at all... Certainly a lot of people would say that is not OO.

And if you work in that way, really a non-static method is pretty close to a function whose first argument is passed in funny. In a way, I kinda like how Python uses "self"; it makes that quite explicit (even if that makes "super" in Python a bit confusing, IMHO).

Java of course has a ton of classes behind the scenes, you really cannot avoid them altogether at a low level- but I would say that at a high level, you could program in Java as if it were just procedural-imperative like C.

(And maybe, if you are starting out, you should. For beginners, I think a lot of Java is confusing and unnecessary. It's certainly useful once you get to some degree of knowledge, but I think it just makes things more complex at the beginning.)