First off, I need to override the method:
public boolean recordBid(int bidPrice, String sellerID)
so it manages the recording of a bid.
To begin with, if the bidPrice is greater than the buyNowprice then this bidPrice should reset to the buyNowPrice. After the bid price has been reset (if required) the method should invoke the superclass version of the recordBid() method, passing along the bid price and seller ID as parameters, and trap the result that it returns (ie. store it in a variable), so that it can be checked to determine if the bid price has been recorded successfully.
Im a little confused on how I need to trap the result and also not sure if Im doing it the right way here?.
My original recordBid() method:
public boolean recordBid(int bidPrice, String bidderID)
{
if (saleEnded == true)
{
return false;
}
else if (bidPrice <= this.highestBid)
{
return false;
}
else
{
this.highestBid = bidPrice;
this.bidderID = bidderID;
return true;
}
}
My subclass, where I need to overwrite recordBid()
public class BuyItNowSale extends ItemSale {
//instance variables
private double buyNowPrice;
private boolean acceptingNearestOffer;
public BuyItNowSale(String itemNumber, String itemDescription, String itemCondition,
String sellerID, boolean acceptingNearestOffer) {
super(itemNumber, itemDescription, itemCondition, sellerID);
this.acceptingNearestOffer = false;
//overidden recordBid() method
public boolean recordBid(int bidPrice, String bidderID) {
if(bidPrice > buyNowPrice) {
bidPrice = 0;
super.recordBid(bidPrice, sellerID);
}
}
With your requirement
if the bidPrice is greater than the buyNowprice then this bidPrice should reset to the buyNowPrice
Your method should be:
#Override
public boolean recordBid(int bidPrice, String bidderID) {
if(bidPrice > buyNowPrice) {
bidPrice = (int) buyNowPrice;
}
return super.recordBid(bidPrice, sellerID);
}
Hi guys,this is my first question on StackOverflow
I am kind of new to java and I need to solve this uml diagram .
I got a solution from one of my classmates but I don't think it's correct and I did it my way. My question is which one of the solutions is correct? I know that the type of relation is an association one . Not an inheritance
Her code
class Sensor {
protected int value;
protected String location;
public Sensor() { // default constructor
value = 0;
location = "North-West";
}
public Sensor(int value, String location) { // overridden constructor
this.value = value;
this.location = location;
}
protected int getValue() { // value getter
return value;
}
protected void setValue(int v) { // value setter
this.value = v;
}
protected void displaySenzorInfo() { // display information on the sensor
System.out.println("Temperature is " + value + ", located " + location + ".");
}
}
class Controller extends Sensor {
protected String name;
public Controller(String name) { // overridden constructor
this.name = name;
}
public Controller(String name, int value, String location) { // overridden
// instructor
this.name = name;
super.value = value;
super.location = location;
}
public Controller() { // default constructor, which creates a new Sensor()
//Sensor s = new Sensor();
}
protected void checkTemperature() { // checks temperature of sensor
System.out.println("Temperature of " + name + " is " + super.value + ", located at " + super.location + ".");
}
}
public class E3 {
public static void main(String[] args) {
Controller control = new Controller();
control.displaySenzorInfo();
Controller c = new Controller("Pizza", 30, "North");
c.checkTemperature();
}
}
My code
class Sensor{
int value;
String location;
Sensor(){
value=0;
location="Sibiu";
}
Sensor(int value,String location){
this.value=value;
this.location=location;
}
int getValue(){
return value;
}
void setValue(int v){
this.value=v;
}
void displaySenzorInfo(){
System.out.println("Temperature is " + value + ", located " + location + ".");
}
}
class Controller{
Sensor tempSensor;
String name;
Controller(){
name="Sibiu";
tempSensor=30;
}
Controller (String name,Sensor tempSensor){
this.name=name;
this.tempSensor=tempSensor;
}
void checkTemperature(Sensor tempSensor){
if (tempSensor>=30)
System.out.println("the temperature is too high!");
else
System.out.println("the temp is too low" );
}
}
public class E3{
public static void main(String []args){
Sensor s1=new Sensor();
Controller c1=new Controller();
c1.displaySenzorInfo();
Controller c2=new Controller(30,"Oliver");
}
}
Please guys. If you have some suggestions or if you see any problems in m program tell me. I know that I will have some errors because I didn't work at this exercise in any IDE because I am at work and I don't have any . Thank you!!!
your solution is the correct one. As you mentioned already, it is an association and not an inheritance. You can see how an inheritance looks like on wikipedia: https://en.wikipedia.org/wiki/Class_diagram
Though overall coding (MyCode) for relationship from the given diagram is OK, I have following observations. (Her code) - Inheritance is not correct. Unidirectional association is correct.
If this is diagram is only for exercise purpose its OK, otherwise it will violate data hiding and encourage client classes to violate encapsulation (Using somebody else's data directly)
tempSensor=30;is not correct for data type.
if (tempSensor>=30) is incorrect for data type and even if you correct, it violates encapsulation (works on somebody else's data) as an effect of first violation of making instance variables non-private. classes should work on their own data.
Even if for some reason we accept above violation, checkTemperature(Sensor tempSensor) makes use of fresh instance of Sensor (for every call), which is not the one obtained from association relationship. This method should not have parameter, it should work on this.tempSensor (with accepted data leakage). Ideally this is indication that data and its behavior are getting separated and design needs to be corrected.
In case the diagram can not be changed then just remove the parameter in checkTemperature() and take care of data types as shown above.
But I would suggest change at Design level as follows for better encapsulation.
public class SensorNew {
private static final double UPPER_THRESHOLD = 25;
private static final double LOWER_THRESHOLD = 20;
private String location;
private Controller controller;
public SensorNew(String location, Controller controller) {
this.location = location;
this.controller = controller;
}
public int getCurrentTemp() {
// obtain from sensor hardware
return 10; // Just example
}
private void makePeriodicCheck(){
double currentTemp = getCurrentTemp();
if (currentTemp > UPPER_THRESHOLD){
controller.coolDown();
} else if (currentTemp < LOWER_THRESHOLD){
controller.heatUp();
} else {
controller.stopIfRunning();
}
}
public void displaySenzorInfo() { // replace by toString()
System.out.println("Temperature is " + getCurrentTemp()
+ ", located " + location + ".");
}
}
public class ControllerNew {
private String name;
// Need to maintain the state of Controller
// either by variable or State design pattern (preferred)
public ControllerNew(String name, Sensor tempSensor) {
this.name = name;
}
public void coolDown() {
// action depending upon current state of controller
}
public void heatUp() {
// action depending upon current state of controller
}
public void stopIfRunning() {
// action depending upon current state of controller
}
}
The advantage is that we do not have to provide public getXX() setXX() methods to these classes. Hence it maintains encapsulation.
I work on my first Java project, which is a basic roleplaying game. Now I work on spells, and I need some OOD guidance.
I have Character, which is an abstract class. Character has some subclasses (like mage, fighter, rogue, cleric).
Mage and cleric(as for now, cleric doesn't have mana, but it might change) are both spell-casters.
I also have a Spell class, with some info (like spell name, mana cost etc). MageSpellsList and ClericSpellsList are another classes and both have lists of class Spell. and I also have Effects class(casting a spell should use it).
What would be a good object oriented design for dealing with spells (the solution shouldn't include Effects class, I can deal with that later) ?
Maybe using a "SpellCaster" interface with some methods like castSpell and showSpellbook, so Mage and Cleric will implement the interface? .
Maybe MageSpellsList and ClericSpellsList should be a subclass of Spell ? My goal is to use castSpell("spell name here") and let castSpell do the job, by using a good OOD, rather than writing a specific method for each spell (and without duplicate code between mage and Cleric)
Mage.java:
public class Mage extends Character {
private List<Spell> spellBook;
private int mana;
private int CurrentMana;
public Mage(String name) {
super(name);
setName(name);
setCharacterClass("Mage");
setLevel(1);
setHitDice(4);
setStrength(10);
setConstitution(10);
setDexterity(14);
setIntelligence(16);
setWisdom(14);
setCharisma(10);
setHp((int) (4 + getModifier(getConstitution())));
setCurrentHp(getHp());
setArmorClass(10 + getModifier(getDexterity()));
setBaseAttackBonus(0);
setMana(20 + 2 * getModifier(getIntelligence()));
setCurrentMana(getMana());
spellBook = new ArrayList<Spell>();
}
public int getMana() {
return mana;
}
public int getCurrentMana() {
return CurrentMana;
}
protected void setMana(int mna) {
mana = mna;
}
protected void setCurrentMana(int CurrMana) {
CurrentMana = CurrMana;
}
public void showSpellBook() {
for (Iterator<Spell> iter = spellBook.iterator(); iter.hasNext(); ) {
Spell spell = iter.next();
System.out.println("Spell name: " + spell.getSpellName());
System.out.println("Spell effect: " + spell.getEffect());
}
}
public void addToSpellBook(String spellName) {
Spell newSpell;
newSpell = MageSpellsList.getSpell(spellName);
spellBook.add(newSpell);
System.out.println(newSpell.getSpellName() + " has been added to the spellbook");
}
public void chooseSpells() {
System.out.println();
}
void castSpell(String spellName, Character hero, Character target) {
try {
Spell spell = MageSpellsList.getSpell(spellName);
System.out.println("You casted: " + spellName);
System.out.println("Spell effect: " + spell.getEffect());
} catch (Exception e) {
System.out.println("No such spell");
}
}
}
Spell.java:
public class Spell {
private String name;
private int spellLevel;
private String effect;
private int manaCost;
private int duration;
Spell(String name, int spellLevel, String effect, int manaCost, int duration) {
this.name = name;
this.spellLevel = spellLevel;
this.effect = effect;
this.manaCost = manaCost;
this.duration= duration;
}
String getSpellName() { return name; }
int getSpellLevel() { return spellLevel; }
String getEffect() { return effect; }
int getManaCost() {
return manaCost;
}
int getDuration() { return duration; }
}
MageSpellsList.java:
public class MageSpellsList {
static List<Spell> MageSpellsList = new ArrayList<Spell>();
static {
MageSpellsList.add(new Spell("Magic Missiles", 1, "damage", 2, 0));
MageSpellsList.add(new Spell("Magic Armor", 1, "changeStat", 2, 0));
MageSpellsList.add(new Spell("Scorching Ray ", 2, "damage", 4, 0));
MageSpellsList.add(new Spell("Fireball", 3, "damage", 5,0 ));
MageSpellsList.add(new Spell("Ice Storm", 4, "damage", 8, 0));
}
static void showSpellsOfLevel(int spellLevel) {
try {
for (Iterator<Spell> iter = MageSpellsList.iterator(); iter.hasNext(); ) {
Spell spell = iter.next();
if (spellLevel == spell.getSpellLevel()) {
System.out.println("Spell name: " + spell.getSpellName());
System.out.println("Spell effect: " + spell.getEffect());
}
}
} catch (Exception e){
System.out.println("Epells of level " + spellLevel + " haven't been found in spells-list");
}
}
static Spell getSpell(String spellName) {
try {
for (Iterator<Spell> iter = MageSpellsList.iterator(); iter.hasNext(); ) {
Spell spell = iter.next();
if (spellName.equals(spell.getSpellName())) {
return spell;
}
}
} catch (Exception e){
System.out.println(spellName + " haven't been found in spells-list");
return null;
}
return null;
}
}
Effects.java:
public class Effects {
public void damage(int dice, Character attacker, Character target){
int damage = DiceRoller.roll(dice);
System.out.println(attacker.getName() + " dealt " + damage + " damage to " + target.getName());
target.setCurrentHp(target.getCurrentHp() - damage);
}
public static void damage(int n, int dice, int bonus, Character target) {
int damage = DiceRoller.roll(n,dice,bonus);
System.out.println("You dealt" + damage + "damage to " + target.getName());
target.setCurrentHp(target.getCurrentHp() - damage);
}
public static void heal(int n, int dice, int bonus, Character target) {
int heal = DiceRoller.roll(n,dice,bonus);
if (heal + target.getCurrentHp() >= target.getHp()) {
target.setCurrentHp(target.getHp());
} else {
target.setCurrentHp(target.getCurrentHp() + heal);
}
System.out.println("You healed" + heal + " hit points!");
}
public static void changeStat(String stat, int mod, Character target){
System.out.println(stat + " + " + mod);
switch (stat) {
case "strength":
target.setStrength(target.getStrength() + mod);
break;
case "constitution":
target.setConstitution(target.getConstitution() + mod);
break;
case "dexterity":
target.setDexterity(target.getDexterity() + mod);
break;
case "intelligence":
target.setIntelligence(target.getIntelligence() + mod);
break;
case "wisdom":
target.setWisdom(target.getWisdom() + mod);
break;
case "charisma":
target.setCharisma(target.getCharisma() + mod);
break;
case "armorClass":
target.setArmorClass(target.getArmorClass() + mod);
break;
}
}
}
Preamble
I try to generalise the classes as much as possible, so I do not end up with lots of specific classes that just represent different data, instead of a different structure. Also, I try to separate data structures from game mechanics. In particular, I try to keep the combat mechanics all in one place, instead of splitting them across different classes, and I try not to hard-code any data. In this answer, we will cover the characters, their abilities/spells, the effects of the abilities, and the combat mechanics.
Characters
Consider, for instance, a PlayableCharacter, that represents your characters. This is a standard data class. It provides methods for increasing or decreasing health and mana, and a collection of available abilities.
class PlayableCharacter {
private final int maxHealth;
private int health;
private final int maxResource; // mana, energy and so on
private int resource;
private final Collection<Ability> abilities;
// getters and setters
}
Abilities
Abilities are equally data classes. They represent mana costs, triggered effects, and so on. I often represent this as a normal class, and then read the individual abilities from external data files. Here we can skip that and declare them with enumerations.
enum Ability {
FIREBALL("Fireball", 3, 5, new Effect[] {
new Effect(Mechanic.DAMAGE, 10, 0),
new Effect(Mechanic.BURN, 2, 3)
});
private final String name;
private final int level;
private final int cost;
private final List<Effect> effects;
}
Effects
Finally the effects tell what an ability does. How much damage, how long it lasts, how it affects a character. Again, this is all data, no game logic.
class Effect {
private final Mechanic effect;
private final int value;
private final int duration;
}
The mechanics are just an enumeration.
enum Mechanic {
DAMAGE, BURN;
}
Mechanics
Now it is time to make things work properly. This is the class that your game loop will be interacting with, and you must feed it the game state (which characters are battling, for instance).
class BattleEngine {
void useAbility(PlayableCharacter source, PlayableCharacter target, Ability ability) {
// ...
}
}
How you implement each mechanic is up to you. It can range from an infernal switch or if/else for each Mechanic, or you can move the code to the Mechanic enum, or to private nested classes and use an EnumMap to retrieve each handler.
Example Mechanic
interface MechanicHandler {
void apply(PlayableCharacter source, PlayableCharacter target, Effect effect);
}
class BattleEngine {
private final Map<Mechanic, MechanicHandler> mechanics;
void useAbility(PlayableCharacter source, PlayableCharacter target, Ability ability) {
source.decreaseResource(ability.getCost());
for (Effect effect: ability.getEffects()) {
MechanicHandler mh = mechanics.get(e.getMechanic());
mh.apply(source, target, effect);
}
}
private static final class DicePerLevel implements MechanicHandler {
#Override
public void apply(PlayableCharacter source, PlayableCharacter target, Effect effect) {
int levels = Math.min(effect.getValue(), source.getLevel());
int damage = 0;
for (int i = 0; i < levels; ++i) {
int roll; // roll a d6 die
damage += roll;
}
target.decreaseHealth(damage);
}
}
}
The SpellCaster spellbook should be a Map<String, Spell> so you can look it up by name when it is cast. The Spell class should define an abstract method for applying the effects to a Character. I don't see the point of a "SpellCaster" interface because the implementation of the castSpell() method is always the same (the behavior is delegated to the Spell itself).
Here is a sample scenario:
Mage fireMage = new Mage("Red Niminim");
fireMage.addSpell(new Fireball());
fireMage.addAttribute(Attribute.RESIST_FIRE);
fireMage.addAttribute(Attribute.WEAK_TO_COLD);
Mage iceMage = new Mage("Blue Niminim");
fireMage.addSpell(new Icestorm());
fireMage.addAttribute(Attribute.RESIST_COLD);
fireMage.addAttribute(Attribute.WEAK_TO_FIRE);
Cleric cleric = new Cleric("Friar Joe");
cleric.addSpell(new Heal());
// battle!
fireMage.castSpell("Fireball", cleric); // 15 damage
fireMage.castSpell("Fireball", iceMage); // 30 damage
fireMage.castSpell("Fireball", fireMage); // 0 damage
iceMage.castSpell("Icestorm", cleric); // 15 damage
iceMage.castSpell("Icestorm", fireMage); // 30 damage
iceMage.castSpell("Icestorm", iceMage); // 0 damage
cleric.castSpell("Heal", cleric); // 15 healed
Attribute.java
public enum Attribute {
RESIST_FIRE, WEAK_TO_FIRE, RESIST_COLD, WEAK_TO_COLD;
}
Spell.java
public abstract class Spell {
private String name;
private int manaCost;
public Spell(String name, int manaCost) {
this.name = name;
this.manaCost = manaCost;
}
public abstract void apply(Character character);
public String getName() {
return name;
}
public int getManaCost() {
return manaCost;
}
}
SpellCaster.java (snippet)
public void castSpell(String name, Character character) {
getSpellBook().get(name).apply(character);
}
public void addSpell(Spell spell) {
getSpellBook().put(spell.getName(), spell);
}
Fireball.java
public class Fireball extends Spell {
private static final String NAME = "Fireball";
private static final int MANA_COST = 8;
private static final int DAMAGE_AMOUNT = 15;
public Fireball() {
super(NAME, MANA_COST);
}
#Override
public void apply(Character character) {
int damage = DAMAGE_AMOUNT;
if (character.getAttributes().contains(Attribute.RESIST_FIRE)) {
damage = 0;
}
else if (character.getAttributes().contains(Attribute.WEAK_TO_FIRE)) {
damage = damage * 2;
}
character.setCurrentHp(character.getCurrentHp() - damage);
}
}
Icestorm.java
public class Icestorm extends Spell {
private static final String NAME = "Icestorm";
private static final int MANA_COST = 8;
private static final int DAMAGE_AMOUNT = 15;
public Icestorm() {
super(NAME, MANA_COST);
}
#Override
public void apply(Character character) {
int damage = DAMAGE_AMOUNT;
if (character.getAttributes().contains(Attribute.RESIST_COLD)) {
damage = 0;
}
else if (character.getAttributes().contains(Attribute.WEAK_TO_COLD)) {
damage = damage * 2;
}
character.setCurrentHp(character.getCurrentHp() - damage);
}
}
Heal.java
public class Heal extends Spell {
private static final String NAME = "Heal";
private static final int MANA_COST = 10;
private static final int HEAL_AMOUNT = 15;
public Heal() {
super(NAME, MANA_COST);
}
#Override
public void apply(Character character) {
character.setCurrentHp(character.getCurrentHp() + HEAL_AMOUNT);
}
}
Here is an example of how you can use enum instead of strings in your Effects class. I took the liberty of renaming your Character class to PlayerCharacter to avoid collision with java.lang.Character.
Effects.java:
public class Effects {
...
public static void changeStat(Stat status, int mod, PlayerCharacter target) {
System.out.println(status + " + " + mod);
status.effect(mod).accept(target);
}
}
A little bit cleaner, isn't it? How it works? The magic is all in the enum:
Stat.java:
import java.util.function.Consumer;
import java.util.function.IntUnaryOperator;
import java.util.function.ObjIntConsumer;
import java.util.function.ToIntFunction;
public enum Stat {
STRENGTH(PlayerCharacter::getStrength, PlayerCharacter::setStrength),
CONSTITUTION(PlayerCharacter::getConstitution, PlayerCharacter::setStrength),
DEXTERITY(PlayerCharacter::getDexterity, PlayerCharacter::setDexterity),
INTELLIGENCE(PlayerCharacter::getIntelligence, PlayerCharacter::setIntelligence),
WISDOM(PlayerCharacter::getWisdom, PlayerCharacter::setWisdom),
CHARISMA(PlayerCharacter::getCharisma, PlayerCharacter::setCharisma),
ARMORCLASS(PlayerCharacter::getArmorClass, PlayerCharacter::setArmorClass);
Stat(ToIntFunction<PlayerCharacter> findcurrentvalue, ObjIntConsumer<PlayerCharacter> setnewvalue) {
this.findcurrentvalue = findcurrentvalue;
this.setnewvalue = setnewvalue;
}
private ToIntFunction<PlayerCharacter> findcurrentvalue;
private ObjIntConsumer<PlayerCharacter> setnewvalue;
Consumer<PlayerCharacter> effect(int mod) {
return target -> {
setnewvalue.accept(target, findcurrentvalue.applyAsInt(target) + mod);
};
}
}
The two mysterious types ToIntFunction and ObjIntConsumer are functional interfaces:
ToIntFunction takes some kind of object as input (here: a PlayerCharacter) and returns an int.
ObjIntConsumer takes some kind of object (here: a PlayerCharacter) and an int as input, and returns nothing.
You could also create your own functional interface if you like, like so:
Effect.java:
#FunctionalInterface
public interface Effect<T extends PlayerCharacter> {
void affect(T t);
}
Stat.java:
...
Effect<PlayerCharacter> effect(IntUnaryOperator calculator) {
return target -> {
setnewvalue.accept(target, calculator.applyAsInt(findcurrentvalue.applyAsInt(target)));
};
}
...
Then you can do this in changeStat:
public class Effects {
...
public static void changeStat(Stat status, int mod, PlayerCharacter target) {
System.out.println(status + " + " + mod);
status.effect(x -> x + mod).affect(target);
}
}
This way you can decide in the Effects class what will happen. Well, I don't imagine the character stats to change much from spells, but a similar mechanic can be used for HP and such :)
The x -> x + mod bit could come from the spell itself too. It's a function that takes an int and returns an int, which is called an IntUnaryOperator in Java:
Effects.java:
...
public static void boost(int dice, PlayerCharacter target) {
int value = DiceRoller.roll(dice);
changeStat(Stat.STRENGTH, x -> x + value, target);
}
public static void changeStat(Stat status, IntUnaryOperator change, PlayerCharacter target) {
status.effect(change).affect(target);
}
...
Here the spell (boost in this case, which I just invented!) will increase the player's strength (the STRENGTH constant) by a dice roll. It accomplishes this by calling the changeStat with three parameters:
STRENGTH → tells the method what status to change.
A "formula" for changing the value (note that you don't actually need to know the value here, just the formula!).
The target to affect.
As you can see, there is no need here to know how to find the strength value, or how to set it to something else. That is all handled by the enum, so you can keep your spell code clean.
You could even inline the changeStat method directly in the spell method this way, since there isn't really any "real" code in it anymore – that logic is hidden in the enum.
Clean and neat :)
I think your idea of having a SpellCaster interface (which includes the castSpell()) is a good one. This defines the behavior or ability of the character.
I would include the list of available spells as an instance field in the Mage or Cleric classes. Come to think of it, maybe it would be a good idea to create an abstract class called SpellCaster which extends Character. The SpellCaster class can declare the list of spells and subclasses (Mage and Cleric) can add specific spells to it.
I'm going to discard the Effects class for now. Each spell can take care of its own behavior. So for example, when calling castSpell("spellName", hero, target) you can pass the required parameters to the spell object and it can take care of dealing the damage or changing stats.
In addition, there could be multiple Spell subclasses. For example, DamageSpell, Buff, Debuff. The superclass Spell has a method apply() and each subclass can implement it with it's own behavior. When calling castSpell() then you delegate the control to a specific subclass of a Spell which has encapsulated the behavior and knows exactly if it should deal damage or change stats. That's essentially the Strategy Pattern.
Why treat spells different than abilities? A fighter class might not have spells as magic spells, but it should be able to perform class specific moves like a whirlwind.
Class PlayableCharacter: abstract class, defines the abstract methods for handling resources(regen rate, max, effects on character), abilities, gear. And implements all the basics.
Class ManaCharacter: extends PlayableCharacter handles it resource as mana.
Class Mage extends ManaCharacter: Will just implement the methods to define what kind of gear it can use, the special abilities it can perform, etc.
I am a little bit confused about something and I would appreciated it if you all can bring some clarity to this. I have a class payment which has some methods and getter/setters.
Do I for example use the method ItemCost to return the valve of attribute itemCost or do I use a getter?
public class Payment {
private int itemCost, totalCost;
public int itemCost(int itemQuantity, int itemPrice){
itemCost = itemPrice * itemQuantity;
return itemCost;
}
public int totalCost(BigDecimal itemPrice){
totalCost = totalCost + itemCost;
return totalCost;
}
public int getBalance(int clickValue, int totalCost){
totalCost = totalCost - clickValue;
return totalCost;
}
public int getTotalcost(){
return this.totalCost;
}
public void setTotalcost(int totalCost){
this.totalCost = totalCost;
}
public int getItemcost(){
return this.itemCost;
}
public void setItemcost(int itemCost){
this.itemCost = itemCost;
}
}
ok so instead of instantiating:
int cost = payment.itemCost(quantity, itemPrice) in another class
DO: payment.itemCost(quantity, itemPrice)
payment.getItemcost
?
Edit 2: Would making all the methods return void and just use the getters be better coding?
public class Payment {
private int itemCost, totalCost;
public void calculateItemcost(int itemQuantity, int itemPrice){
itemCost = itemPrice * itemQuantity;
}
public void calculateTotalCost(BigDecimal itemPrice){
this.totalCost = totalCost + itemCost;
}
public void calculateBalance(int clickValue, int totalCost){
this.totalCost = totalCost - clickValue;
}
public int getTotalcost(){
return this.totalCost;
}
public void setTotalcost(int totalCost){
this.totalCost = totalCost;
}
public int getItemcost(){
return this.itemCost;
}
public void setItemcost(int itemCost){
this.itemCost = itemCost;
}
}
getter/setters are for the purpose of setting value to particular attribute in object and getting same from the object, this way you can define attributes as private and enforce encapsulation (One of the OO principles) .
When you are doing any calculations (or) business logic, its always better to use appropriate operation name instead get/set.
EDIT:
As neel commented, Its always suggested to leave POJO as simple beans instead of stuffing in business logic/calculations. You may have another class with business logic and use get/setter to get values from POJO while doing calculations.
At the moment you have 2 methods that can set itemCost.
public void setItemcost(int itemCost){
this.itemCost = itemCost;
}
public int itemCost(int itemQuantity, int itemPrice){
itemCost = itemPrice * itemQuantity;
return itemCost;
}
Ideally you would have one setting method but if you want the class to work like this I would suggest making both of these methods return void and use getItemCost to get the value.
Generally, it should be possible to understand what your method is supposed to do just from the name of your method.
So, you should use getters and setters only if you want to return or set the property of your class. That way your code looks more readable, and the name of the methods clearly states what it would do.
But, if your method is not returning the exact property, but a returning the result of some calculation, then you should name your method accordingly.
For E.g: - If your method returns the cost as a calculation on some property of your class, then name that method as calculateCost. It makes more sense.
PS: -
Remember, your code would me maintained for more number of time, than you took it to create. Code for others to understand, not for yourself to understand.