Develop Reference

Is it possible to assign an instance of a subclass to a variable of a superclass?

I am confused as to the definitions and the logistics behind the superclass and subclass.

In a word - yes. Since a subclass instance "isA" superclass, you can assign it to such a variable.
Consider the following example - a String is an Object, so this assignment would be legal:
Object obj = "abcd"; // this is a string literal

To quickly answer your question: yes, it is possible to assign a subclass almost anywhere the superclass goes.
The reasons for this involve inheritance and object oriented programming. Let me give you an example. Let's think about trains and railway cars that are part of the train.
The superclass is RailwayCar. Every RailwayCar has a weight.
public class RailwayCar {
private int weight;
public RailwayCar() {
}
public RailwayCar(int weight) {
setWeight(weight);
}
public int getWeight() {
return weight;
}
public void setWeight(int weight) {
this.weight = weight;
}
public void arriveAtStation(Station station) {}
public void leaveStation(Station station) {}
}
That is just a basic car. However, there are special cars.
// Engines have power in addition to weight
public class Engine extends RailwayCar {
private int power;
public Engine(int weight, int power) {
super(weight);
setPower(power);
}
public void setPower(int power) {
this.power = power;
}
public int getPower() {
return power;
}
}
There are other types of cars. For example, for example, there could be a PassengerCar where the weight might change at each station as passengers get on and off. There are specific types of cars for specific types of cargo. LogCar would contain long logs.
All of these subclasses of RailwayCar may override the station methods (arriveAtStation() and leaveStation()) to perform specific actions by overriding these methods.
All of these cars could be put into the same list or array. For example, RailwayCar[] cars, or List cars = new ArrayList<>();

Create instance in class or get object from outside, which on is true?

I studied about SOLID Principle and created a question for me about it.
you suppose that we need a Tea Object in Mug class, now is this better than create a instance from Tea in Mug class or pass from outside through Constructor or setter method.
which on is true?
example:
class Mug {
private Tea tea;
public Mug(){
this.tea = new Tea();
}
public boolean isFull(){
return this.tea.value != 10;
}
}
or
class Mug {
private Tea tea;
public Mug(Tea tea){
this.tea = tea;
}
// public void setTea(Tea tea){
// this.tea = tea;
// }
public boolean isFull(){
return this.team.value != 10;
}
}
use:
public class Test {
static void main(String[] args){
Mug mug = new Mug();
//or
Mug mug = new Mug(new Tea());
}
}
which one is better?
NOTE: Suppose that Mug support only Tea object in our program.

Both of your cases violate SOLID.
Your each concrete implementation (concrete class) should only be dependent upon Abstractions.
in your case Tea is not an abstraction. Mug has tight coupling with Tea. Below is a possible way to code it.
public interface ITea{
//tea related methods which you think should be exposed to outside world. Also all implementation of ITea must support these method (L in SOLID)
}
public class Tea implements ITea{
// Implement the contract methods from ITea
}
public class Mug {
private ITea tea;
// Have constructor or setter to inject concrete implementation. Setter will provide you capability to modify behavioral at run time.
}
EDIT:
1. If we are sure there is only one possible implementation Of tea. Then also interface is better as concrete implementations are hard to mock and hence makes unit testing is difficult.
Avoid using enums for setting type. Enums inject switch cases and in future if a case is added all such switch cases needs to be modified leading to violation of O in SOLID.
If a case is added you have to modify existing code and in case you forget to add a case somewhere it leads to unexpected errors. (It violates OCP. Instead of enums put logic in specific implementation, have common interface and specific implementation). Also if we implement the case specific logic in individual instances of enum then the enum file will become gigantic. Instead if we have specific logic in individual concrete classes implementing common interface makes the user code easy as it can be injected with concrete classes in a polymorphic way.
p.s. this answer is about following the principles and it's not always possible to do so. It's fine to violate the principle but we must know that we are violating it, and have a very good reason to do so.

I would use the second one where possible, injecting a classes dependencies, take this example where the Tea constructor requires more information:
class Mug {
private Tea tea;
public Mug(int temperature) {
this.tea = new Tea(temperature);
}
public boolean isFull() {
return tea.value != 10;
}
}
See how ugly that is that Mug's constructor now needs information only used by Tea's constructor.
But as it stands I would say that neither of your examples violates any SOLID principle.
There is nothing that says you can't create a new object inside another and nothing that says you must create abstractions.
Here would be a real violation in this area:
class Mug { // VIOLATION
private Tea tea;
private Coffee coffee;
public Mug(boolean tea) {
if (tea) {
this.tea = new Tea();
} else {
this.coffee = new Coffee();
}
}
public boolean isFull() {
return tea.value != 10 || coffee.value != 10;
}
}
The class depends upon multiple similar classes. Compare to:
class Mug {
private Liquid liquid;
public Mug(Liquid liquid) {
this.liquid = liquid;
}
public boolean isFull() {
return liquid.getVolume() != 10;
}
}
interface Liquid {
int getVolume();
}
class Tea implements Liquid {
private int volume;
#Override
public int getVolume() {
return volume;
}
}
class Coffee implements Liquid {
private int volume;
#Override
public int getVolume() {
return volume;
}
}
But as you only have one thing that can go in a Mug there is no violation and no need for an abstraction. In general, never write any code that doesn't solve a problem.
And never create an abstraction with a name like ITea. In such a case either the concrete class name is not specific enough, or the abstraction name is not general enough.

What is the best way to share only the getter methods to client?

I am writing an API with a class like this:
public class NKMPMission {
private String name;
private int age;
public NKMPMission(String name, int age)
{
this.name = name;
this.age = age;
}
public String getName()
{
return name;
}
public int getAge()
{
return age;
}
}
My Questions:
How can I make sure the user of this NKMPMission class accesses only the getters?
How can I introduce setters for this function so that I as a developer can set, but the user cannot set?

The usual way to do this is to not expose the class at all, just expose interfaces to that class. One interface for the general public and one for developers.
You then need a factory to create them.
/**
* Expose this interface to the public.
*/
public interface INKMPMission {
public String getName();
public int getAge();
}
/**
* Only expose this interface to developers.
*/
interface IDeveloperNKMPMission {
public void setName(String name);
public void setAge(int age);
}
public static class NKMPMissionFactory {
/**
* Expose only the INKMPMission construction.
*/
public INKMPMission make(String name, int age) {
return new NKMPMission(name, age);
}
/**
* Protected version for developers.
*/
IDeveloperNKMPMission forDeveloper(INKMPMission it) {
return IDeveloperNKMPMission.class.cast(it);
}
/**
* Private so no-one outside the factory knows about the inner workings.
*/
private static class NKMPMission implements INKMPMission, IDeveloperNKMPMission {
private String name;
private int age;
private NKMPMission(String name, int age) {
this.name = name;
this.age = age;
}
#Override
public String getName() {
return name;
}
#Override
public int getAge() {
return age;
}
#Override
public void setName(String name) {
this.name = name;
}
#Override
public void setAge(int age) {
this.age = age;
}
}
}
For the truly paranoid you can even use a proxy. This will make it difficult (but not impossible) to use the setters through reflection.
/**
* Expose only the INKMPMission construction.
*/
public INKMPMission make(String name, int age) {
return new NKMPMissionProxy(new NKMPMission(name, age));
}
/**
* Protected version for developers.
*/
protected IDeveloperNKMPMission forDeveloper(INKMPMission it) {
if (it instanceof NKMPMissionProxy) {
it = ((NKMPMissionProxy) it).theMission;
}
return IDeveloperNKMPMission.class.cast(it);
}
/**
* A proxy for the truly paranoid - makes using reflection more difficult (but not impossible)
*/
private static class NKMPMissionProxy implements INKMPMission {
private final NKMPMission theMission;
private NKMPMissionProxy(NKMPMission theMission) {
this.theMission = theMission;
}
#Override
public String getName() {
return theMission.getName();
}
#Override
public int getAge() {
return theMission.getAge();
}
}

1) How can i make sure user of this NKMPMIssion class access only getters.
You can't.
2) How can i introduce setters for this function so that as a developer i should be able to set, but the user should not be able to set.
It sounds like you're writing an API. If you return a NKMPMIssion instance from a public method of that API, the setters can be called. Even if you mark them private or protected, they can still be called via reflection. That said, usually making them non-public is sufficient. It does, at the very least, say "If you call these, you're in unsupported territory."
If you want to make it harder, you can return an instance that wraps a facade around the NKMPMIssion instance. But that just makes it harder, not impossible, since the facade instance has to have a reference to the NKMPMIssion instance, which (even if it's private) can be accessed via reflection.

The easiest thing is to make the API use the interface only and make the class an implementation detail.
public interface INKMPMission {
String getName();
int getAge();
}
public class SomeService{
private class MyNKMPMission implements INKMPMission {
//put getters and setters here
}
public List<INKMPMission> getMissions(){
//put some MyNKMPMissions in a list
}
}
Since MyNKMPMission is private the consumers will never be able do downcast and access the setters.

You can (in some kinda way), but you should not do it that way:
In each setter construct a new Exception
Inspect the generated Stacktrace
If the caller class is not within your package (or hardcode some direct classnames / methodnames) throw an IllegalAccessError
This way is neither pretty, nor fast as you have to check every single access to a setter.
Another way would be using the #CallerSensitive Annotation, though it's propritary API and is therefore not available on all plattforms / jre implementations: https://stackoverflow.com/a/22627383/1164913
The clean, and in most cases sufficent way would be using an Interface which only provides getters to the client, and returning that to the client.

It seems you trying to write an API. Assuming user means, developers who use your API.
In such cases, make the setter as protected and build some meaningful package structure, such that only child's and package members can see that.
If you want to protect that even from child's, there is no way other than making it private.

Answering the questions:
Q1. You can't as T.J. Crowder has said in his answer.
Q2. I would recommend you to try the following things in the following order from easiest to hardest, and take the option you consider the most suitable in terms of effort-return:
Have a look to: Java access modifiers.
Create an interface and expose that interface with the public methods to the "final" users of the "NKMPMission" class, as mentioned in Esben Skov Pedersen answer
Finally you can do the proxy approach mentioned in OldCurmudgeon answer
What I would do:
If your set of classes is going to be used internally then I would take option 1 combined with a good javadoc and project standards, it should be enough.
In case you are creating a public API I would take the option 2.
IMHO the option 3 adds too innecessary complexity in this case, and very few benefit, since every class method or attribute can be accessed anyway throw reflection (as many people has mentioned). I think everybody is aware about the fact that access throw reflection to API's hidden methods is hacky, dangerous and not convenient for the manteinance of the projects, due to API providers are in their right to change hidden methods implementations without further notification to the final users.

Setter methods, multiple with no parameters or single with value?

I'm working on a java based game with a friend and I've noticed he's taking an approach that concerns me, in terms of maintainability.
For a class representing a playable Character, instead of just creating 1 method which sets an object's property, he's creating separate methods which set the property to a specific value.
Which of these 2 options would be the best to follow going forward?
Option 1
public void runFast() {
this.character.speed = 5.0f
}
public void walk() {
this.character.speed = 2.0f
}
public void stop() {
this.character.speed = 0.0f;
}
Option 2
public void setSpeed(float speedTemp) {
this.character.speed = speedTemp;
}

Why not use an enum to set the speed - then you can still have
void setSpeed(Speed speed) {
this.character.speed = speed.getAmount();
}
with:
enum Speed {
FAST(5.0f), WALK(2.0f), STOP(0.0f);
private final float amount;
private Speed(flaot a) { this.amount = a; }
public float getAmount() {
return amount;
}
}
That way, you can quickly update the values, but still have a predefined amount. Its flexible and easy to maintain. You might want to save the enum instead of the float.

My Solution would be to use Enums instead,
it is cleaner and has more context and easily extensible if you have more to do with your speed maxHeartRate in the future.
public class Character {
private Speed speed;
public Speed getSpeed() {
return speed;
}
public void setSpeed(Speed speed) {
this.speed = speed;
}
};
public enum Speed {
STOP(0),
RUN(5.5),
WALK(2.5);
double value;
Speed(double value) {
this.value = value;
}
public double getValue() {
return value;
}
};

IMHO the best option would be to declare constants/enums, and use the option 2.
Example (constants) :
public static final float STOP = 0.0f;
public static final float WALK = 2.0f;
public static final float FAST = 5.0f;
setSpeed(STOP|WALK|FAST);
Example (enums) :
public enum Speed
{
FAST(5.5f),
STOP(0),
WALK(2.5f);
float value;
Speed(float pValue)
{
this.value = pValue;
}
public float getValue()
{
return this.value;
}
}
setSpeed(Speed.FAST);

It depends. For example
Are speeds limited to a few predefined values? In that case using an enum would be a good solution.
Is walking / running / stopping going have side effects other than just setting the speed? As a contrived example, starting to run might cause the character to drop an item it's holding, or stopping might cause the character to skid a little. In this case having separate methods might make sense.
Or maybe there are only a few predefined states, but depending on the environment running speed might be different.
What it comes down to is: Which way of conceptually modeling the properties of your character works best for your game logic / physics? Work this out and then base the interface of your classes on that. Don't get too hung up on the exact API early on, this sort of stuff is pretty easy to refactor.

getter and setters are useful when you want that your code is readble and for avoiding that public class fields can be used in the wrong way from another classes.
This example show how is important.
CLASS A:
public class ClassA{
// in the body class
private String fieldClass1;
//classic setter
public void setfieldClass1(String f1)
{
fieldClass1 = f1;
}
}
CLASS B:
public class ClassB{
// in the bodyclass
public String fieldClass2;
//classic setter
public void setfieldClass2(String f2)
{
setfieldClass2 = f2;
}
CLASS C:
public class ClassC{
//in the body of the class this method use class a and class b
public void calc()
{
ClassA aObject = new ClassA();
ClassB bObject = new ClassB();
ClassA.fieldClass1 = 5 + 5; // illegal expression for the compiler and costrain the developer to use setters
ClassB.fieldClass2 = 8 + 8; // legal expression
}
}
This mean that you must define a "modifiers logic" (protected, private, public) before make setters and getters. Define before the modifiers and after define the setters and getters.

Java Public Var question [duplicate]

This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Property and Encapsulation
NEWB Alert!!
I am starting with Android and Java and I am starting to understand it but I am wondering why I should use getters and setters and not just public variables?
I see many people make a private variable and create a get and set method.
What is the idea here?

Its called encapsulation and the concept is central to object oriented programming. The idea is that you hide the implementation of your class and expose only the contract i.e. hide the how and only expose the what. You hide the variables by making them private and provide public setters-getters and other public methods which the clients invoke to communicate with your class. They are not tied to the actual implementation of the methods or how you store your variables.
For example, suppose you had this class where you stored a phone number as a Long object:
public class ContactInfo {
private Long phoneNo;
public Long getPhoneNo() {
return phoneNo;
}
public void setPhoneNo(Long phoneNo) {
this.phoneNo = phoneNo;
}
}
Since the clients of the class only see the getter/setter, you can easily change the implementation of the class/methods by switching the phone number representation to a PhoneNumber object. Clients of ContactInfo wouldn't get affected at all:
public class ContactInfo {
private PhoneNumber phoneNo;
public Long getPhoneNo() {
return phoneNo.getNumber();
}
public void setPhoneNo(Long phoneNo) {
this.phoneNo = new PhoneNumber(phoneNo);
}
}
public class PhoneNumber {
private Long number;
public PhoneNumber(Long number) {
this.number = number;
}
public Long getNumber() {
return number;
}
}

The OOP concept involved is encapsulation (google it).
Some of the advantages are: you can specify different access level for setters (mutators) and getters (accessors), for example public getter and private setter. Another advantage is that you can add another code other than changing or retrieving the value. For example, you may want to check the validity of the set value, or you want to throw exceptions or raise some events in response to changing the variable to certain value. If you implement these inside an accessor or mutators, you can also change their implementations without changing any code outside of the class.

I believe the idea is "information hiding" http://en.wikipedia.org/wiki/Information_hiding
It also serves to control the access to variables (provides an interface). For example, you can provide a getter but not a setter, so that they may be read but not written. Whereas if everything was public any thing could read and write to the variables.
Also important is any checking/validation need to set a variable. For example you have a String name that is not allowed to be empty but if it is public it could easily be forgotten and set as name = "". If you have a setter such as public boolean setName(String newName) you can check newNames length and return true or false if it passes and is set or not

The concept is called encapsulation.
What it attempts to do is to separate the inner structure of a class from its behaviour.
For example, suppose a class like this
public class Point{
private float x;
private float y;
public float getX(){
return x;
}
public float getY(){
return y;
}
public float distanceToZero2(){
return x*x + y*y
}
public float getAngle(){
//havent considered the x = 0 case.
return atan(y/x);
}
public boolean isInFirstQuad(){
return x>0 && y>0;
}
}
In this case, encapsulation hides the inner structure of the class, and exposes only the operations available to a Point. If you dont like it, you can change its inner structure and mantain its behaviour (for example, changing carthesian coordinates to polar coordinates).
Anyoune who uses this class wont care about it, he /she will be happy that they have a Point class with this functionality.

Asides the encapsulation, you can also control the value get or set to your variable in some cases. For example, you want to validate the value of an age variable which should be >=1
class Person {
private int age = Integer.MIN_VALUE;
public void setAge(int age){
if(age>=1)
this.age = age;
}
public int getAge(){
return age;
}
}