Java and OOP Principles

[JC724]

So what is pass by value and what is pass by reference in Java? By that I know you have to pass primitives by value and objects by reference correct? What else is forced to be passed by value and reference?


The super class calls the constructor but I don’t understand the point of that since all sub-classes have access to the parent class methods anyway?


Jave has an object type can somebody explain to me how that works?


For abstract classes can you have all abstract methods or NO abstract methods?

 

[modi123]

First part - this helps.
https://www.journaldev.com/3884/java-is-pass-by-value-and-not-pass-by-reference
https://www.javaworld.com/article/2...-java-pass-by-reference-or-pass-by-value.html

The super class calls the constructor but I don’t understand the point of that since all sub-classes have access to the parent class methods anyway?

I am not following the question. ARe you asking why a super constructor is called ?

Object type -> Java has a pretty defined class hierarchy and everything starts from the 'object' class. Per usual inheritance it contains basic information for all derived classes.
https://docs.oracle.com/javase/7/docs/api/java/lang/Object.html
https://www.geeksforgeeks.org/object-class-in-java/

Abstract classes -> You can investigate by creating a quick class and trying both ways.
https://docs.oracle.com/javase/tutorial/java/IandI/abstract.html

 

[Absalom]

So what is pass by value and what is pass by reference in Java?

Probably the most overloaded and confusing terms ever to come from Java folks. The terms are so misused and contradictory, that when someone even mentions them, I have to ask for context just to be sure we're even talking about the same semantics. And that's the point, it's a issue of semantics. I loathe the term 'pass-by' in a Java context. It's much easier to borrow the terms Value Types and Reference Types from .NET. They still apply even in a Java context.

By that I know you have to pass primitives by value and objects by reference correct?

You are on the right path, sort-of. Be careful with the word 'object'. In most cases, those two map really well to Value Type and Reference Type nomenclature respectively. But, what will really make your head explode is when you later run into the terms 'boxing' and 'everything in Java is an object'. So then you start asking yourself 'Wait, if everything in Java is an object then how can everything be pass-by-value?"

What else is forced to be passed by value and reference?

It's all about context. If by 'force', you mean 'boxing', then sure, a value type, event a primitive one like an int, would be passed by reference (unless, by passing-by-reference, you really mean passing-by-value, thereby extension of passing-a-reference-by-value. See my point?). Passing Integer instead of int would be an example of 'forcing'. But that's a very specific case that is rarely used.

Explanation: This is why Java has two types for holding an integer type: int, a Value Type and Integer, a Reference Type. Integer is simply an int primitive 'boxed' inside a Reference Type called Integer. If you were to pass an int argument into a method that attempts to modify it, it would be modifying a copy. In the case of an Integer argument, the method would 'unbox' the value, modify it by assigning a new value, then 'box' it back up for the caller.

Pass-by-value and pass-by-reference are C++ terms that don't really translate well over to modern OO languages such as Java and C#. My advice is don't use those terms outside of C++.

The super class calls the constructor but I don’t understand the point of that since all sub-classes have access to the parent class methods anyway?

I think you meant 'the super keyword calls the base class's constructor within the derived's constructor.' Inheritance only works one-way. And to answer your question, the reason why the super keyword is there has to do with overloading and member hiding.

Use of super in a constructor is a specific case, but the gist is, calling a base class's constructor explicitly is sometimes necessary when ambiguity arises. If the base class has no constructor overload, then super is implicitly called within all derived constructors and you don't need to provide it. However, providing it demonstrates that you really meant your derived class's constructor to call the default base class constructor. In most cases, yes, you can omit super from a constructor. When you start dealing with constructor overloads, you'll find more use in super.

That said, super is also useful outside of constructors when you must refer to a base class's member explicitly. Say I have a base class with a non-abstract member called DoSomething(). I may decide in my derived class to override it with my own DoSomething(). But say I want this behavior, but still need to retain the functionality of DoSomething() from the base class. In the real world, you may not have access to the base class source code or may have no idea how to reverse-engineer what it does. But you still want to extend DoSomething() functionality without breaking the original interface (i.e. forcing your clients to update their calls to DoSomething() to your new one DoSomething2). So what you typically do is override DoSomething() in your derived class, and within its implementation, make a call to base.DoSomething() which will directly call DoSomething() in the base class. You may decide to do this right away or later. In any event, you've not broken the original API and still maintained the overridden functionality while providing whatever extension your derived class hopes to achieve. And the best part is, your clients are none-the-wiser since you've not broken the original interface contract.

Basically, super is a way for you to access base class members that may be otherwise hidden. They may even be protected members that a public API wouldn't even expose in the first place. It's more freedom to re-use existing things without having to create a clusterf*ck of member name variations. It would get annoying to see a 5th generation derived class with a DoSomething5(). At that point, your clients are like 'wtf, why so many versions?'

Jave has an object type can somebody explain to me how that works?

You'll always get quoted the infamous 'Everything in Java is an object' or 'Everything in Java is derived from Object'. Yet another overloaded term.

Much like C#, Java has a super class that all classes (not primitives!) derive from. That class is called Object. This is done for API reasons. It's basically so the Java API doesn't need an overload for every built-in type. However, do not confuse this concept with 'everything being an object instance.' Primitive types, such as int, are not Object instances. Confused, yet? That's where boxing comes in. But since Integer derives from Object, it allows methods that accept Object parameters to not balk at int types (this is also called Auto-boxing when done implicitly).

For abstract classes can you have all abstract methods or NO abstract methods?

It's been a while, and my Java is a little rusty here, so I may be slightly off in my response (Java experts correct me if I'm wrong here). My answer here is basically drawn straight from C#, which is very similar.

A class marked abstract, just simply means it must be derived before you can instance it. An abstract class can have many abstract members, or none at all. Regardless, it must be derived to be of any use.

That said, any abstract members must also be implemented in the derived class. If there are no abstract members marked in an abstract class, then it begs the question why would one want such a thing? Well, maybe you want to provide some default functionality that can optionally be overridden, but must be, at minimum, provided because of the abstract class contract. If you don't want to provide any default implementation, then just marking a member as abstract will suffice. That forces the most derived class to, at minimum, provide an implementation for it.

In fact, an abstract class with nothing but public abstract members is nothing more than an interface in disguise. Either are attempts at establishing a contract (i.e. you agree that you will provide this implementation).