Modify Standard Abstract Classes.

I would like to know what is the approach to extend a
Standard Delivered Abstract Class.
I tried the following approach, but it doesnt seem to work.
I want to add some methods to the standard Abstract Class
CL_CRM_AUI_ENTITY. So i created a copy(not inheritance )
-> ZCL_CRM_AUI_ENTITY and added a new abstract method to this class.
The Class CL_CRM_AUI_ONEORDER implements the methods of the abstract class. I implemented the new method here.
Now in my Application :
The following code works - Reference to the standard delivered abstract class cl_crm_aui_entity.
data : lv_bol_entity type ref to cl_crm_bol_entity lv_aui_entity type ref to cl_crm_aui_entity.
IF lv_bol_entity is bound.
lv_aui_entity ?= lv_bol_entity.
ENDIF.
The following code does not work and gives me a CX_SY_MOVE_CAST_ERROR.
data : lv_bol_entity type ref to cl_crm_bol_entity,
lv_aui_entity type ref to zcl_crm_aui_entity.
IF lv_bol_entity is bound.
lv_aui_entity ?= lv_bol_entity.
CATCH...
ENDCATCH.
ENDIF.
Is the solution then to modify the standard delivered abstract class or can we work around this?
Thanks.

Decorators work well if a Class define an interface. Using decorators gives the power to add multiple features which can freely combined without creating all combinations of classes.
If e.g. you want to enable tracing of each method you implement a trace decorator and put in the original implementation. Another decorator may due additonal security checks. If you now want to combine both you just can put the original instance in the first decorator and then in the second. With single inheritance you may need much more classes.
But similar to inheritance, the instances of the base class wont be able to call instances of the encapsulation. The decorator can replace or enrich the base class only.
I wonder why you want to make the original class to use your changes. Is it not sufficient that all programs using your enriched instances work with your additions.
Kind Regards
Klaus

Similar Messages

Is it Advicable to modify standard message class?

Hi Experts,
I need a small confirmation.Is modifying standard message class is having any restrictions?
Currently in SE91 message class number 002 i need to modify text .Is it ok to directly do and transport or need to take any extra precautions?
Regards
sas

Hi Thomas,
Thanks for the suggestion.
Actually message class name: HRTIMOOREC.
In that one message always shows what ever leave action is it shows as 'Number of days leave 5. Apply sick leave for HR'.
Requirement is just to remove 'Apply Sick Leave for HR'.
so that it wont confuse the clients who are applying for some other leaves..so request is to just modify
that number 001.
So in general need to modify SAP programs we required Access keys here its not required i guess...
Now Thomas is there any things need to taken care or general Message class how we do the same and Transfer? Thanks
Regards
sas

What are abstract classes/methods and what are they for?

Hi,
I've just heard about abstract classes and methods and I'm just wondering what exactly they're used for, and why are they there for the Graphics class for example?
Cheers.

raggy wrote:
bastones_ wrote:
Hi,
I've just heard about abstract classes and methods and I'm just wondering what exactly they're used for, and why are they there for the Graphics class for example?
Cheers.Hey bro, I'll try to solve your problemYou have to know two important concepts for this part. 1 is Abstract classes and the other is Interface classes. Depends on the nature of the project, you need to set certain level of standards and rules that the other developers must follow. This is where Abstract classes and Interface classes come into picture.
Abstract classes are usually used on small time projects, where it can have code implementation like general classes and also declare Abstract methods (empty methods that require implementation from the sub-classes).Wrong, they are used equally among big and small projects alike.
Here are the rules of an Abstract class and method:
1. Abstract classes cannot be instantiatedRight.
2. Abstract class can extend an abstract class and implement several interface classesRight, but the same is true for non-abstract classes, so nothing special here.
3. Abstract class cannot extend a general class or an interfaceWrong. Abstract classes can extend non-abstract ones. Best example: Object is non-abstract. How would you write an abstract class that doesn't extend Object (directly or indirectly)?
4. If a class contains Abstract method, the class has to be declared Abstract classRight.
5. An Abstract class may or may not contain an Abstract methodRight, and an important point to realize. A class need not have abstract methods to be an abstract class, although usually it will.
6. Abstract method should not have any code implementations, the sub-classes must override it (sub-class must give the code implementations). An abstract method must not have any implementation code code. It's more than a suggestion.
7. If a sub-class of an Abstract class does not override the Abstract methods of its super-class, than the sub-class should be declared Abstract also.This follows from point 4.
9. Abstract classes can only be declared with public and default access modifiers.That's the same for abstract and non-abstract classes.

Abstract class initialisation

Hi,
I have the following problem. What do you suggest?
I have an interface A, abstract class B, B's subclasses C and D, and mainClass
interface A
abstract class B implements A {
    B b;
    public B(String desc)
     if (desc.equals("C")) b=new C();
     else if (desc.equals("D")) b=new D();
class C extends {
public C() {}
class D extends {
public D() {}
class mainClass{
B b=new B("C"); // but B can not be initiated
}B is an abstract class and can not be initiated, I can not define B as normal class, because in B, I define some abstract methods
and want all its subclasses to define them.
What do you suggest me for enhancement?

Hi duffymo,
Your answer quite intersting, can you provide some concrete example!
Do you mean like this:
interface A
class B implements A{
B b;
public B(String desc) {
b=Class.newInstance(desc);
class C extends B
class main {
B=new B(desc);
It seems quite okey, but the problem is that I want subclasses (C and D) to impelement some certain methods. Thus I though B as abstract class
It's called a Factory class or virtual constructor -
that's how you create different runtime types. It's a
GOF Pattern - read about it.
I wouldn't build all that stuff into the abstract B
constructor. That'll force you to modify the B class
every time you add a new subtype - that's not a good
idea. Move that code out into a separate class named
AFactory and give it a static method that does that
creation stuff for you. I know - "That just moves the
changes out of B and into the AFactory" - yes, but I
think that's where they belong.
The java.lang.Class class has a factory method built
into it already - newInstance(). You can use that to
instantiate different subclasses:
A newInstance = Class.newInstance("C");
A anotherInstance = Class.newInstance("D");That's the way I'd do it. - MOD

Extend abstract class & implement interface, different return type methods

abstract class X
public abstract String method();
interface Y
public void method();
class Z extends X implements Y
// Compiler error, If I don't implement both methods
// If I implement only one method, compiler error is thrown for not
// implementing another method
// If I implement both the methods,duplicate method error is thrown by
//compiler
The same problem can occur if both methods throw different checked exceptions,or if access modifiers are different..etc
I'm preparing for SCJP, So just had this weired thought. Please let me know
if there is a way to solve this.

Nothing you can do about it except for changing the design.
Kaj

Abstract classes and methods with dollar.decimal not displaying correctly

Hi, I'm working on a homework assignment and need a little help. I have two classes, 1 abstract class, 1 extends class and 1 program file. When I run the program file, it executes properly, but the stored values are not displaying correctly. I'm trying to get them to display in the dollar format, but it's leaving off the last 0. Can someone please offer some assistance. Here's what I did.
File 1
public abstract class Customer//Using the abstract class for the customer info
private String name;//customer name
private String acctNo;//customer account number
private int branchNumber;//The bank branch number
//The constructor accepts as arguments the name, acctNo, and branchNumber
public Customer(String n, String acct, int b)
 name = n;
 acctNo = acct;
 branchNumber = b;
//toString method
public String toString()
String str;
 str = "Name: " + name + "\nAccount Number: " + acctNo + "\nBranch Number: " + branchNumber;
 return str;
//Using the abstract method for the getCurrentBalance class
public abstract double getCurrentBalance();
}file 2
public class AccountTrans extends Customer //
 private final double
 MONTHLY_DEPOSITS = 100,
 COMPANY_MATCH = 10,
 MONTHLY_INTEREST = 1;
 private double monthlyDeposit,
 coMatch,
 monthlyInt;
 //The constructor accepts as arguments the name, acctNo, and branchNumber
 public AccountTrans(String n, String acct, int b)
 super(n, acct, b);
 //The setMonthlyDeposit accepts the value for the monthly deposit amount
 public void setMonthlyDeposit(double deposit)
 monthlyDeposit = deposit;
 //The setCompanyMatch accepts the value for the monthly company match amount
 public void setCompanyMatch(double match)
 coMatch = match;
 //The setMonthlyInterest accepts the value for the monthly interest amount
 public void setMonthlyInterest(double interest)
 monthlyInt = interest;
 //toString method
 public String toString()
 String str;
 str = super.toString() +
 "\nAccount Type: Hybrid Retirement" +
 "\nDeposits: $" + monthlyDeposit +
 "\nCompany Match: $" + coMatch +
 "\nInterest: $" + monthlyInt;
 return str;
 //Using the getter method for the customer.java fields
 public double getCurrentBalance()
 double currentBalance;
 currentBalance = (monthlyDeposit + coMatch + monthlyInt) * (2);
 return currentBalance;
}File 3
 public static void main(String[] args)
//Creates the AccountTrans object
 AccountTrans acctTrans = new AccountTrans("Jane Smith", "A123ZW", 435);
 //Created to store the values for the MonthlyDeposit,
 //CompanyMatch, MonthlyInterest
 acctTrans.setMonthlyDeposit(100);
 acctTrans.setCompanyMatch(10);
 acctTrans.setMonthlyInterest(5);
 DecimalFormat dollar = new DecimalFormat("#,##0.00");
 //This will display the customer's data
 System.out.println(acctTrans);
 //This will display the current balance times 2 since the current
 //month is February.
 System.out.println("Your current balance is $"
 + dollar.format(acctTrans.getCurrentBalance()));
 }

Get a hair cut!
h1. The Ubiquitous Newbie Tips
* DON'T SHOUT!!!
* Homework dumps will be flamed mercilessly. [Feelin' lucky, punk? Well, do ya'?|http://www.youtube.com/watch?v=1-0BVT4cqGY]
* Have a quick scan through the [Forum FAQ's|http://wikis.sun.com/display/SunForums/Forums.sun.com+FAQ].
h5. Ask a good question
* Don't forget to actually ask a question. No, The subject line doesn't count.
* Don't even talk to me until you've:
 (a) [googled it|http://www.google.com.au/] and
 (b) had a squizzy at the [Java Cheat Sheet|http://mindprod.com/jgloss/jcheat.html] and
 (c) looked it up in [Sun's Java Tutorials|http://java.sun.com/docs/books/tutorial/] and
 (d) read the relevant section of the [API Docs|http://java.sun.com/javase/6/docs/api/index-files/index-1.html] and maybe even
 (e) referred to the JLS for "advanced" questions.
* [Good questions|http://www.catb.org/~esr/faqs/smart-questions.html#intro] get better Answers. It's a fact. Trust me on this one.
 - Lots of regulars on these forums simply don't read badly written questions. It's just too frustrating.
 - FFS spare us the SMS and L33t speak! Pull your pants up, and get a hair cut!
 - Often you discover your own mistake whilst forming a "Good question".
 - Often you discover that you where trying to answer "[the wrong question|http://blog.aisleten.com/2008/11/20/youre-asking-the-wrong-question/]".
 - Many of the regulars on these forums will bend over backwards to help with a "Good question",
 especially to a nuggetty problem, because they're interested in the answer.
* Improve your chances of getting laid tonight by writing an SSCCE
 - For you normal people, That's a: Short Self-Contained Compilable (Correct) Example.
 - Short is sweet: No-one wants to wade through 5000 lines to find your syntax errors!
 - Often you discover your own mistake whilst writing an SSCCE.
 - Often you solve your own problem whilst preparing the SSCCE.
 - Solving your own problem yields a sense of accomplishment, which makes you smarter ;-)
h5. Formatting Matters
* Post your code between a pair of {code} tags
 - That is: {code} ... your code goes here ... {code}
 - This makes your code easier to read by preserving whitespace and highlighting java syntax.
 - Copy&paste your source code directly from your editor. The forum editor basically sucks.
 - The forums tabwidth is 8, as per [the java coding conventions|http://java.sun.com/docs/codeconv/].
 - Indents will go jagged if your tabwidth!=8 and you've mixed tabs and spaces.
 - Indentation is essential to following program code.
 - Long lines (say > 132 chars) should be wrapped.
* Post your error messages between a pair of {code} tags:
 - That is: {code} ... errors here ... {code}
 - OR: [pre]{noformat} ... errors here ... {noformat}[/pre]
 - To make it easier for us to find, Mark the erroneous line(s) in your source-code. For example:
 System.out.println("Your momma!); // <<<< ERROR 1
 - Note that error messages are rendered basically useless if the code has been
 modified AT ALL since the error message was produced.
 - Here's [How to read a stacktrace|http://www.0xcafefeed.com/2004/06/of-thread-dumps-and-stack-traces/].
* The forum editor has a "Preview" pane. Use it.
 - If you're new around here you'll probably find the "Rich Text" view is easier to use.
 - WARNING: Swapping from "Plain Text" view to "Rich Text" scrambles the markup!
 - To see how a posted "special effect" is done, click reply then click the quote button.
If you (the newbie) have covered these bases *you deserve, and can therefore expect, GOOD answers!*
h1. The pledge!
We the New To Java regulars do hereby pledge to refrain from flaming anybody, no matter how gumbyish the question, if the OP has demonstrably tried to cover these bases. The rest are fair game.

Final field in abstract class

Hi ... consider the code:abstract class It {
     protected final boolean
          USE;
public class Test extends It {
     public Test(){
          USE = true;
} upon compiling there is an error (infact, two errors).
final may not be assigned, can't assign to final.
of course, if "It" was not abstract, the first error might be true ... but it is abstract, so
shouldn't this checking of assignment to final be delayed until the class is inheritied
as concrete ? it would seem to make sense ... i can't see a reason for this not being
the case.
if it was the case, we could delay assignment until our constructor of "Test" where it
would assign to the final variable of "It".
it shouldn't be an error, should it ?
java version:java version "1.4.2_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)
Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)

is it because references to the final fields are resolved at compile-time ?
such that the compiler must know the value of USE in:if(USE){
// a
// b at compile time so it can remove either "b" or "a". I think so. hmm.

Abstract class, a question

i have an abstract class called shape with default constructor (double y1, double y2);
with an abstract method area.
now i have a circle class which extends it, but i want its constructor to have ONE radius (as its pi radius*radius)
at the moment this is how my circle looks like, and as you can see that there is really no need for second radius how can i modify circle class without modifying shape class?
class circle extends Shape{
circle(double radius, double radius1) {
super(radius, radius);
double area() {
return (3.14*x1*x1);
}

the answer from the test class in above case will be
0!Yes, because 3.14 * 0 * 0 is 0.
but if i change the x3 above to x1, it would work, You honestly don't see why? It's staring you right in the face. What does area() use? How does that field get set?
the
reason i decided to use x3 is so that ppl dont get
confuse! Here's what's confusing:
* field names x1, x2, x3. What do those mean? They sound like 3 x coordinates.
* two fields that are used by certain subclasses, but not others, and a third field that's used only by the subclasses that don't use the first two.
* that third field meaning "the single value that applies to what both of the other two fields mean" instead of just setting both fields to the same value.
* having any of those fields in there at all in the first place when they're not used by the abstract class and not used consistently by subclasses.
but shouldnt it work because i have done the
same thing i did to x1 and x2??

Abstract Class & Interface

Hi ,
I have a fundamental doubt regarding Abstract Class & Interface!!!
What is their real benefit...whether we implement an interface or extend an Abstract class we have to write the code for the abstract method in the concrete class.Then where the benefit remained....
And it is said that Abstract class provide default behaviour...what is the actual meaning of that?
Thanks & Regards
Santosh

In this section we will redesign our OneRowNim game to fit within a hierarchy of classes of two-player games. There are many games that characteristically involve two players: checkers, chess, tic-tac-toe, guessing games, and so forth. However, there are also many games that involve just one player: blackjack, solitaire, and others. There are also games that involve two or more players, such as many card games. Thus, our redesign of OneRowNim as part of a two-player game hierarchy will not be our last effort to design a hierarchy of game-playing classes. We will certainly redesign things as we learn new Java language constructs and as we try to extend our game library to other kinds of games.
This case study will illustrate how we can apply inheritance and polymorphism, as well as other object-oriented design principles. The justification for revising OneRowNim at this point is to make it easier to design and develop other two-player games. As we have seen, one characteristic of class hierarchies is that more general attributes and methods are defined in top-level classes. As one proceeds down the hierarchy, the methods and attributes become more specialized. Creating a subclass is a matter of specializing a given class.
8.6.1. Design Goals
One of our design goals is to revise the OneRowNim game so that it fits into a hierarchy of two-player games. One way to do this is to generalize the OneRowNim game by creating a superclass that contains those attributes and methods that are common to all two-player games. The superclass will define the most general and generic elements of two-player games. All two-player games, including OneRowNim, will be defined as subclasses of this top-level superclass and will inherit and possibly override its public and protected variables and methods. Also, our top-level class will contain certain abstract methods, whose implementations will be given in OneRowNim and other subclasses.
Generic superclass
A second goal is to design a class hierarchy that makes it possible for computers to play the game, as well as human users. Thus, for a given two-player game, it should be possible for two humans to play each other, or for two computers to play each other, or for a human to play against a computer. This design goal will require that our design exhibit a certain amount of flexibility. As we shall see, this is a situation in which Java interfaces will come in handy.
[Page 376]
Another important goal is to design a two-player game hierarchy that can easily be used with a variety of different user interfaces, including command-line interfaces and GUIs. To handle this feature, we will develop Java interfaces to serve as interfaces between our two-player games and various user interfaces.
8.6.2. Designing the TwoPlayerGame Class
To begin revising the design of the OneRowNim game, we first need to design a top-level class, which we will call the TwoPlayerGame class. What variables and methods belong in this class? One way to answer this question is to generalize our current version of OneRowNim by moving any variables and methods that apply to all two-player games up to the TwoPlayerGame class. All subclasses of TwoPlayerGamewhich includes the OneRowNim classwould inherit these elements. Figure 8.18 shows the current design of OneRowNim.
Figure 8.18. The current OneRowNim class.
What variables and methods should we move up to the TwoPlayerGame class? Clearly, the class constants, PLAYER_ONE and PLAYER_TWO, apply to all two-player games. These should be moved up. On the other hand, the MAX_PICKUP and MAX_STICKS constants apply just to the OneRowNim game. They should remain in the OneRowNim class.
The nSticks instance variable is a variable that only applies to the OneRowNim game but not to other two-player games. It should stay in the OneRowNim class. On the other hand, the onePlaysNext variable applies to all two-player games, so we will move it up to the TwoPlayerGame class.
Because constructors are not inherited, all of the constructor methods will remain in the OneRowNim class. The instance methods, takeSticks() and getSticks(), are specific to OneRowNim, so they should remain there. However, the other methods, getPlayer(), gameOver(), getWinner(), and reportGameState(), are methods that would be useful to all two-player games. Therefore these methods should be moved up to the superclass. Of course, while these methods can be defined in the superclass, some of them can only be implemented in subclasses. For example, the reportGameState() method reports the current state of the game, so it has to be implemented in OneRowNim. Similarly, the getWinner() method defines how the winner of the game is determined, a definition that can only occur in the subclass. Every two-player game needs methods such as these. Therefore, we will define these methods as abstract methods in the superclass. The intention is that TwoPlayerGame subclasses will provide game-specific implementations for these methods.
[Page 377]
Constructors are not inherited
Given these considerations, we come up with the design shown in Figure 8.19. The design shown in this figure is much more complex than the designs used in earlier chapters. However, the complexity comes from combining ideas already discussed in previous sections of this chapter, so don't be put off by it.
Figure 8.19. TwoPlayerGame is the superclass for OneRowNim and other two-player games.
To begin with, note that we have introduced two Java interfaces into our design in addition to the TwoPlayerGame superclass. As we will show, these interfaces lead to a more flexible design and one that can easily be extended to incorporate new two-player games. Let's take each element of this design separately.
[Page 378]
8.6.3. The TwoPlayerGame Superclass
As we have stated, the purpose of the TwoPlayerGame class is to serve as the superclass for all two-player games. Therefore, it should define the variables and methods shared by two-player games.
The PLAYER_ONE, PLAYER_TWO, and onePlaysNext variables and the getPlayer(), setPlayer(), and changePlayer() methods have been moved up from the OneRowNim class. Clearly, these variables and methods apply to all two-player games. Note that we have also added three new variables, nComputers, computer1, computer2, and their corresponding methods, getNComputers() and addComputerPlayer(). We will use these elements to give our games the capability to be played by computer programs. Because we want all of our two-player games to have this capability, we define these variables and methods in the superclass rather than in OneRowNim and subclasses of TwoPlayerGame.
Note that the computer1 and computer2 variables are declared to be of type IPlayer. IPlayer is an interface containing a single method declaration, the makeAMove() method:
public interface IPlayer {
public String makeAMove(String prompt);
Why do we use an interface here rather than some type of game-playing object? This is a good design question. Using an interface here makes our design more flexible and extensible because it frees us from having to know the names of the classes that implement the makeAMove() method. The variables computer1 and computer2 will be assigned objects that implement IPlayer via the addComputerPlayer() method.
Game-dependent algorithms
The algorithms used in the various implementations of makeAMove() are game-dependentthey depend on the particular game being played. It would be impossible to define a game playing object that would suffice for all two-player games. Instead, if we want an object that plays OneRowNim, we would define a OneRowNimPlayer and have it implement the IPlayer interface. Similarly, if we want an object that plays checkers, we would define a CheckersPlayer and have it implement the IPlayer interface. By using an interface here, our TwoPlayerGame hierarchy can deal with a wide range of differently named objects that play games, as long as they implement the IPlayer interface. Using the IPlayer interface adds flexibility to our game hierarchy and makes it easier to extend it to new, yet undefined, classes. We will discuss the details of how to design a game player in Section 8.6.7.
The IPlayer interface
Turning now to the methods defined in TwoPlayerGame, we have already seen implementations of getPlayer(), setPlayer(), and changePlayer() in the OneRowNim class. We will just move those implementations up to the superclass. The getNComputers() method is the assessor method for the nComputers variable, and its implementation is routine. The addComputerPlayer() method adds a computer player to the game. Its implementation is as follows:
[Page 379]
public void addComputerPlayer(IPlayer player) {
if (nComputers == 0)
computer2 = player;
else if (nComputers == 1)
computer1 = player;
else
return; // No more than 2 players
++nComputers;
As we noted earlier, the classes that play the various TwoPlayerGames must implement the IPlayer interface. The parameter for this method is of type IPlayer. The algorithm we use checks the current value of nComputers. If it is 0, which means that this is the first IPlayer added to the game, the player is assigned to computer2. This allows the human user to be associated with PLAYERONE if this is a game between a computer and a human user.
If nComputers equals 1, which means that we are adding a second IPlayer to the game, we assign that player to computer1. In either of these cases, we increment nComputers. Note what happens if nComputers is neither 1 nor 2. In that case, we simply return without adding the IPlayer to the game and without incrementing nComputers. This, in effect, limits the number of IPlayers to two. (A more sophisticated design would throw an exception to report an error. but we will leave that for a subsequent chapter.)
The addComputerPlayer() method is used to initialize a game after it is first created. If this method is not called, the default assumption is that nComputers equals zero and that computer1 and computer2 are both null. Here's an example of how it could be used:
OneRowNim nim = new OneRowNim(11); // 11 sticks
nim.add(new NimPlayer(nim)); // 2 computer players
nim.add(new NimPlayerBad(nim));
Note that the NimPlayer() constructor takes a reference to the game as its argument. Clearly, our design should not assume that the names of the IPlayer objects would be known to the TwoPlayerGame superclass. This method allows the objects to be passed in at runtime. We will discuss the details of NimPlayerBad in Section 8.6.7.
The getrules() method is a new method whose purpose is to return a string that describes the rules of the particular game. This method is implemented in the TwoPlayerGame class with the intention that it will be overridden in the various subclasses. For example, its implementation in TwoPlayerGame is:
public String getRules() {
return "The rules of this game are: ";
Overriding a method
[Page 380]
and its redefinition in OneRowNim is:
public String getRules() {
return "\n*** The Rules of One Row Nim ***\n" +
"(1) A number of sticks between 7 and " + MAX_STICKS +
" is chosen.\n" +
"(2) Two players alternate making moves.\n" +
"(3) A move consists of subtracting between 1 and\n\t" +
MAX_PICKUP +
" sticks from the current number of sticks.\n" +
"(4) A player who cannot leave a positive\n\t" +
" number of sticks for the other player loses.\n";
The idea is that each TwoPlayerGame subclass will take responsibility for specifying its own set of rules in a form that can be displayed to the user.
You might recognize that defining geTRules() in the superclass and allowing it to be overridden in the subclasses is a form of polymorphism. It follows the design of the toString() method, which we discussed earlier. This design will allow us to use code that takes the following form:
TwoPlayerGame game = new OneRowNim();
System.out.println(game.getRules());
Polymorphism
In this example the call to getrules() is polymorphic. The dynamic-binding mechanism is used to invoke the getrules() method defined in the OneRowNim class.
The remaining methods in TwoPlayerGame are defined abstractly. The gameOver() and getWinner() methods are both game-dependent methods. That is, the details of their implementations depend on the particular TwoPlayerGame subclass in which they are implemented.
This is good example of how abstract methods should be used in designing a class hierarchy. We give abstract definitions in the superclass and leave the detailed implementations up to the individual subclasses. This allows the different subclasses to tailor the implementations to their particular needs, while allowing all subclasses to share a common signature for these tasks. This enables us to use polymorphism to create flexible, extensible class hierarchies.
Figure 8.20 shows the complete implementation of the abstract TwoPlayerGame class. We have already discussed the most important details of its implementation.
Figure 8.20. The TwoPlayerGame class
(This item is displayed on page 381 in the print version)
public abstract class TwoPlayerGame {
public static final int PLAYER_ONE = 1;
public static final int PLAYER_TWO = 2;
protected boolean onePlaysNext = true;
protected int nComputers = 0; // How many computers
// Computers are IPlayers
protected IPlayer computer1, computer2;
public void setPlayer(int starter) {
if (starter == PLAYER_TWO)
onePlaysNext = false;
else onePlaysNext = true;
} // setPlayer()
public int getPlayer() {
if (onePlaysNext)
return PLAYER_ONE;
else return PLAYER_TWO;
} // getPlayer()
public void changePlayer() {
onePlaysNext = !onePlaysNext;
} // changePlayer()
public int getNComputers() {
return nComputers;
} // getNComputers()
public String getRules() {
return "The rules of this game are: ";
} // getRules()
public void addComputerPlayer(IPlayer player) {
if (nComputers == 0)
computer2 = player;
else if (nComputers == 1)
computer1 = player;
else
return; // No more than 2 players
++nComputers;
} // addComputerPlayer()
public abstract boolean gameOver(); // Abstract Methods
public abstract String getWinner();
} // TwoPlayerGame class
Effective Design: Abstract Methods
Abstract methods allow you to give general definitions in the superclass and leave the implementation details to the different subclasses.
[Page 381]
8.6.4. The CLUIPlayableGame Interface
We turn now to the two interfaces shown in Figure 8.19. Taken together, the purpose of these interfaces is to create a connection between any two-player game and a command-line user interface (CLUI). The interfaces provide method signatures for the methods that will implement the details of the interaction between a TwoPlayerGame and a UserInterface. Because the details of this interaction vary from game to game, it is best to leave the implementation of these methods to the games themselves.
Note that CLUIPlayableGame extends the IGame interface. The IGame interface contains two methods that are used to define a standard form of communication between the CLUI and the game. The getGamePrompt() method defines the prompt used to signal the user for a move of some kindfor example, "How many sticks do you take (1, 2, or 3)?" And the reportGameState() method defines how the game will report its current statefor example, "There are 11 sticks remaining." CLUIPlayableGame adds the play() method to these two methods. As we will see shortly, the play() method contains the code that will control the playing of the game.
[Page 382]
Extending an interface
The source code for these interfaces is very simple:
public interface CLUIPlayableGame extends IGame {
public abstract void play(UserInterface ui);
public interface IGame {
public String getGamePrompt();
public String reportGameState();
} // IGame
Note that the CLUIPlayableGame interface extends the IGame interface. A CLUIPlayableGame is a game that can be played through a CLUI. The purpose of its play() method is to contain the game-dependent control loop that determines how the game is played via a user interface (UI). In pseudocode, a typical control loop for a game would look something like the following:
Initialize the game.
While the game is not over
Report the current state of the game via the UI.
Prompt the user (or the computer) to make a move via the UI.
Get the user's move via the UI.
Make the move.
Change to the other player.
The play loop sets up an interaction between the game and the UI. The UserInterface parameter allows the game to connect directly to a particular UI. To allow us to play our games through a variety of UIs, we define UserInterface as the following Java interface:
public interface UserInterface {
public String getUserInput();
public void report(String s);
public void prompt(String s);
Any object that implements these three methods can serve as a UI for one of our TwoPlayerGames. This is another example of the flexibility of using interfaces in object-oriented design.
To illustrate how we use UserInterface, let's attach it to our KeyboardReader class, thereby letting a KeyboardReader serve as a CLUI for TwoPlayerGames. We do this simply by implementing this interface in the KeyboardReader class, as follows:
public class KeyboardReader implements UserInterface
[Page 383]
As it turns out, the three methods listed in UserInterface match three of the methods in the current version of KeyboardReader. This is no accident. The design of UserInterface was arrived at by identifying the minimal number of methods in KeyboardReader that were needed to interact with a TwoPlayerGame.
Effective Design: Flexibility of Java Interfaces
A Java interface provides a means of associating useful methods with a variety of different types of objects, leading to a more flexible object-oriented design.
The benefit of defining the parameter more generally as a UserInterface instead of as a KeyboardReader is that we will eventually want to allow our games to be played via other kinds of command-line interfaces. For example, we might later define an Internet-based CLUI that could be used to play OneRowNim among users on the Internet. This kind of extensibilitythe ability to create new kinds of UIs and use them with TwoPlayerGamesis another important design feature of Java interfaces.
Generality principle
Effective Design: Extensibility and Java Interfaces
Using interfaces to define useful method signatures increases the extensibility of a class hierarchy.
As Figure 8.19 shows, OneRowNim implements the CLUIPlayableGame interface, which means it must supply implementations of all three abstract methods: play(), getGamePrompt(), and reportGameState().
8.6.5. Object-Oriented Design: Interfaces or Abstract Classes?
Why are these methods defined in interfaces? Couldn't we just as easily define them in the TwoPlayerGame class and use inheritance to extend them to the various game subclasses? After all, isn't the net result the same, namely, that OneRowNim must implement all three methods.
These are very good design questions, exactly the kinds of questions one should ask when designing a class hierarchy of any sort. As we pointed out in the Animal example earlier in the chapter, you can get the same functionality from an abstract interface and an abstract superclass method. When should we put the abstract method in the superclass, and when does it belong in an interface? A very good discussion of these and related object-oriented design issues is available in Java Design, 2nd Edition, by Peter Coad and Mark Mayfield (Yourdan Press, 1999). Our discussion of these issues follows many of the guidelines suggested by Coad and Mayfield.
Interfaces vs. abstract methods
We have already seen that using Java interfaces increases the flexibility and extensibility of a design. Methods defined in an interface exist independently of a particular class hierarchy. By their very nature, interfaces can be attached to any class, and this makes them very flexible to use.
Flexibility of interfaces
Another useful guideline for answering this question is that the superclass should contain the basic common attributes and methods that define a certain type of object. It should not necessarily contain methods that define certain roles that the object plays. For example, the gameOver() and getWinner() methods are fundamental parts of the definition of a TwoPlayerGame. One cannot define a game without defining these methods. By contrast, methods such as play(), getGamePrompt(), and reportGameState() are important for playing the game but they do not contribute in the same way to the game's definition. Thus these methods are best put into an interface. Therefore, one important design guideline is:
[Page 384]
Effective Design: Abstract Methods
Methods defined abstractly in a superclass should contribute in a fundamental way to the basic definition of that type of object, not merely to one of its roles or its functionality.
8.6.6. The Revised OneRowNim Class
Figure 8.21 provides a listing of the revised OneRowNim class, one that fits into the TwoPlayerGame class hierarchy. Our discussion in this section will focus on the features of the game that are new or revised.
Figure 8.21. The revised OneRowNim class, Part I.
(This item is displayed on page 385 in the print version)
public class OneRowNim extends TwoPlayerGame implements CLUIPlayableGame {
public static final int MAX_PICKUP = 3;
public static final int MAX_STICKS = 11;
private int nSticks = MAX_STICKS;
public OneRowNim() { } // Constructors
public OneRowNim(int sticks) {
nSticks = sticks;
} // OneRowNim()
public OneRowNim(int sticks, int starter) {
nSticks = sticks;
setPlayer(starter);
} // OneRowNim()
public boolean takeSticks(int num) {
if (num < 1 || num > MAX_PICKUP || num > nSticks)
return false; // Error
else // Valid move
{ nSticks = nSticks - num;
return true;
} // else
} // takeSticks()
public int getSticks() {
return nSticks;
} // getSticks()
public String getRules() {
return "\n*** The Rules of One Row Nim ***\n" +
"(1) A number of sticks between 7 and " + MAX_STICKS +
" is chosen.\n" +
"(2) Two players alternate making moves.\n" +
"(3) A move consists of subtracting between 1 and\n\t" +
MAX_PICKUP + " sticks from the current number of sticks.\n" +
"(4) A player who cannot leave a positive\n\t" +
" number of sticks for the other player loses.\n";
} // getRules()
public boolean gameOver() { /*** From TwoPlayerGame */
return (nSticks <= 0);
} // gameOver()
public String getWinner() { /*** From TwoPlayerGame */
if (gameOver()) //{
return "" + getPlayer() + " Nice game.";
return "The game is not over yet."; // Game is not over
} // getWinner()
The gameOver() and getWinner() methods, which are nowinherited from the TwoPlayerGame superclass, are virtually the same as in the previous version. One small change is that getWinner() now returns a String instead of an int. This makes the method more generally useful as a way of identifying the winner for all TwoPlayerGames.
Similarly, the getGamePrompt() and reportGameState() methods merely encapsulate functionality that was present in the earlier version of the game. In our earlier version the prompts to the user were generated directly by the main program. By encapsulating this information in an inherited method, we make it more generally useful to all TwoPlayerGames.
Inheritance and generality
The major change to OneRowNim comes in the play() method, which controls the playing of OneRowNim (Fig. 8.22). Because this version of the game incorporates computer players, the play loop is a bit more complex than in earlier versions of the game. The basic idea is still the same: The method loops until the game is over. On each iteration of the loop, one or the other of the two players, PLAYER_ONE or PLAYER_TWO, takes a turn making a movethat is, deciding how many sticks to pick up. If the move is a legal move, then it becomes the other player's turn.
Figure 8.22. The revised OneRowNim class, Part II.
(This item is displayed on page 386 in the print version)
/** From CLUIPlayableGame */
public String getGamePrompt() {
return "\nYou can pick up between 1 and " +
Math.min(MAX_PICKUP,nSticks) + " : ";
} // getGamePrompt()
public String reportGameState() {
if (!gameOver())
return ("\nSticks left: " + getSticks() +
" Who's turn: Player " + getPlayer());
else
return ("\nSticks left: " + getSticks() +
" Game over! Winner is Player " + getWinner() +"\n");
} // reportGameState()
public void play(UserInterface ui) { // From CLUIPlayableGame interface
int sticks = 0;
ui.report(getRules());
if (computer1 != null)
ui.report("\nPlayer 1 is a " + computer1.toString());
if (computer2 != null)
ui.report("\nPlayer 2 is a " + computer2.toString());
while(!gameOver()) {
IPlayer computer = null; // Assume no computers
ui.report(reportGameState());
switch(getPlayer()) {
case PLAYER_ONE: // Player 1's turn
computer = computer1;
break;
case PLAYER_TWO: // Player 2's turn
computer = computer2;
break;
} // cases
if (computer != null) { // If computer's turn
sticks = Integer.parseInt(computer.makeAMove(""));
ui.report(computer.toString() + " takes " + sticks + " sticks.\n");
} else { // otherwise, user's turn
ui.prompt(getGamePrompt());
sticks =
Integer.parseInt(ui.getUserInput()); // Get user's move
if (takeSticks(sticks)) // If a legal move
changePlayer();
} // while
ui.report(reportGameState()); // The game is now over
} // play()
} // OneRowNim class
Let's look now at how the code decides whether it is a computer's turn to move or a human player's turn. Note that at the beginning of the while loop, it sets the computer variable to null. It then assigns computer a value of either computer1 or computer2, depending on whose turn it is. But recall that one or both of these variables may be null, depending on how many computers are playing the game. If there are no computers playing the game, then both variables will be null. If only one computer is playing, then computer1 will be null. This is determined during initialization of the game, when the addComputerPlayer() is called. (See above.)
In the code following the switch statement, if computer is not null, then we call computer.makeAMove(). As we know, the makeAMove() method is part of the IPlayer interface. The makeAMove() method takes a String parameter that is meant to serve as a prompt, and returns a String that is meant to represent the IPlayer's move:
public interface IPlayer {
public String makeAMove(String prompt);
[Page 385]
In OneRowNim the "move" is an integer, representing the number of sticks the player picks. Therefore, in play() OneRowNim has to convert the String into an int, which represents the number of sticks the IPlayer picks up.
On the other hand, if computer is null, this means that it is a human user's turn to play. In this case, play() calls ui.getUserInput(), employing the user interface to input a value from the keyboard. The user's input must also be converted from String to int. Once the value of sticks is set, either from the user or from the IPlayer, the play() method calls takeSticks(). If the move is legal, then it changes whose turn it is, and the loop repeats.
[Page 386]
There are a couple of important points about the design of the play() method. First, the play() method has to know what to do with the input it receives from the user or the IPlayer. This is game-dependent knowledge. The user is inputting the number of sticks to take in OneRowNim. For a tic-tac-toe game, the "move" might represent a square on the tic-tac-toe board. This suggests that play() is a method that should be implemented in OneRowNim, as it is here, because OneRowNim encapsulates the knowledge of how to play the One-Row Nim game.
Encapsulation of game-dependent knowledge
[Page

Abstract class & final class

Which is more correct... Or which is the more preferred way.
abstract class A
final method1(){}
final method2(){}
final method30(){}
}or
final class A
private A(){}
method1(){}
method2(){}
method3(){}
}My understanding is that both classes cannot be instantiated. The first one requires writing 'final' for EACH method. The second one involves writing a private constructor.

It depends on what you are trying to do. If you are trying to make a class that can be sub-classed but has some methods that cannot be overriden, then "abstract class A" with final methods is the way to go. If you want a class that cannot be sub-classed or instantiated then "final class A" with private constructor is the way to go.
classes cannot be instantiatedOnly true for "final class A" because you made the only constructor private. Not true for the abstract one.// you forgot return values for the methods
abstract class A
final static /*void*/ method1(){} // package private
final static /*void*/ method2(){} // package private
final static /*void*/ method30(){} // package private
// this would work
A a = new A(){};
// if I am in the same package as A, then this would work
a.method1();
// or this
public class B extends A
public B(String whatever)
    // Although, I cannot override the super methods
    // becuase they are all declared as final
    // I can only invoke them if I am in the same package. You
    // declared them as package private instead of class "private"
}Using final as a class modifier disables the ability to sub-class it but does not disable the ability to create an object of that class. You must make a private constructer. If the only constructor is "private" then you can't subclass or instantiate, so making the class final is uneeded.

SAP Standard Scripts ( how to Modify Standard Scripts)

hi every one , This is Abdul Rahman , i want to know how i should modify Standard SAP Scripts like RVORDER01 or MEDRUCK SCRIPTS ,i want to know whole process . and how to Run the Script . plz any kindly send some good DOC or web pages which i can acess
thankyou
Abdul Rahman

Hi,
Modifying SAP Forms
If you want to modify SAP forms, set up your development environment as follows:
Make sure that no SAP-standard forms are stored as client-specific copies in your development client.
Such forms should be held only in client 000, the SAP development and installation client. If you access an SAP-standard form from another client, then the central copy in client 000 is used.
If you need to remove SAP-standard objects from your development client, see Notes 10388 and 3355 in the SAP Online Service System (OSS). These notes explain the procedure for saving modified forms and then deleting all forms.
To modify SAP standard forms,
Copy the forms you need from client 000 to your development client.
Rename the forms using a name from the customer name reserve (names starting with Y or Z).
Copy the forms to one of your own Y or Z development classes.
Renaming the SAP standard object makes it possible to manage and transport your changes with the SAP workbench organizer. The organizer is not activated for SAP-standard objects that are modified in clients other than 000.
To put your modifications into effect, you must also modify the ABAP print program used to print documents that use this form. You should rename such print programs and store them in your own Y or Z development classes.
You can use the SAP Customizing System to replace the SAP print program with your modified print program in the affected applications.
Forms: Concepts
Forms are used to control the page layout and also the text formatting in your documents. Before formatting a document for output to the screen or to a printer, you must assign a form to it. If you do not specify a form for a document, then the SYSTEM form is assigned to the document by default.
Application-specific forms are used in SAP applications to specify the page layout for such special documents as invoice or checks. These forms specify the structure of the information on the page(s) of such a document. They define, for example, the address header, item lines, the footer, and so on.
There are two ways to format texts with forms:
In the standard SAPscript text processing (Tools ® Word processing ® Standard text), you can select a form for a document. You can then type text into the main window of the form and output the document in the format defined in the form.
For example, you can select a form for a letter. You can then type the body text of the letter in the main window. When you print the letter, the default text elements in the other windows of the form (heading, footer, and so on) are printed with the body text.
A document can be generated by a print program in one of the SAP applications. The print program uses a form to generate the document. Most correspondence and document generation in the SAP System are handled by way of print programs.
A print program selects the text elements that are to be printed in the windows of a form. It may also collect information from the user or ask the user to input text directly, as in some correspondence functions. The print program may also provide data for variables defined in the form.
Finally, the print program uses the form to format the document for display or printing.
Check this link...
http://help.sap.com/saphelp_erp2005/helpdata/en/d1/802d7d454211d189710000e8322d00/frameset.htm
Thanks and Regards,
Bharat Kumar Reddy.V

Abstract classes and inheritance

I'm trying to do some simple inheritance but I'm a little stuck. Without giving too much away here's what I have (or am trying to have). I have an abstract "Test" class and a number of concrete classes that extend that abstract class. In my main method I have an array of Test objects. Each object in the array is a certain kind of "Test" and each one has its own way of doing most things but it doesn't make sense to have just a plain Test object because it is an abstraction. In my code I go through the array and execute a method, runTest(), for each Test in the array. However, my abstract Test class doesn't have a runTest() method b/c it will never get used and java complains. At runtime shouldn't java figure out, OK this is TestA, so go to TestA's runTest method (polymorphism?). What should I put in my runTest method in the abstract class? I know I can put anything there but what is standard?

JFactor2004 wrote:
... Each object in the array is a certain kind of "Test" and each one has its own way of doing most things but it doesn't make sense to have just a plain Test object because it is an abstraction. In my code I go through the array and execute a method, runTest(), for each Test in the array. However, my abstract Test class doesn't have a runTest() method b/c it will never get used and java complains. If you want to instantiate the Test class
you need to provide an implementation for the runTest() method,
something like/*type*/ runTest() { throw new UnsupportedOperationException(); }

Abstract classes and OO theory...

I have an OO theory question related to abstract classes and their member variables. I realize opinions will vary from person to person but I'll ask anyway...
If I'm creating an abstract class, should member variables that will be used by subclasses be private or protected? Why? Either way, they will have accessor methods for classes that instantiate them (where appropriate) but I'm debating whether or not to give subclasses direct access to these variables or not.
To me, it seems odd to make variables in the abstract class private but I'm curious what your opinions are.
Thanks...

I knew you'd say that. I'd like to play along with a for-instance, if you will allow ... here's an example parent class:
public abstract class ProvideMenu   extends JFrame {
protected              JMenuBar       jmbar;
protected              JMenu          jmfile,
                                        jmedit,
                                        jmhelp;
protected              JMenuItem      jmfnew,
                                        jmfopen,
                                        jmfsave,
                                        jmfsaveas,
                                        jmfprint,
                                        jmfexit,
                                        jmecopy,
                                        jmepaste,
                                        jmhabout,
                                        jmhcontents;
public ProvideMenu() {
    jmbar       = new JMenuBar();
    jmfile      = new JMenu( FILE_MENU );
    jmedit      = new JMenu( EDIT_MENU );
public abstract void aMeth();
}Now the subclass does not need to provide setProvideMenuFont( new Font( ... ) ) and Font getProvideMenuFont() methods, setProvideMenuEnabled(), etc. but can use the standard methods setFont, getFont setBackground(), setEnabled, etc, etc.
Mind you I'm not advocating this ... what I am doing is trying to open the discussion up a bit - I hope no one minds ... what better design - just a for-instance - would you advocate?
~Bill

Private, protected Access Modifiers with a class

Why cant we use private and protected access modifiers with a class?
Thanks.

Matiz wrote:
>
Public access allows you to extend a parent class in some other package. If you only want users to extend your class rather than instantiate it directly, make the class abstract and design for extension.Agreed. However, would the same argument be not true for the default access at the class level? No. Default access would only allow you to extend a parent class in the same package (as opposed to some other package).
Now my confusion is why is a class allowed default access at the top level and not protected?Because protected for a top-level class makes no sense. The protected keyword provides member access to any other class in the same package and extending classes outside the package. A top-level class isn't a member of a class, by definition, so there's nothing that protected would do provide differently than public.
So, the two access modifiers for a top-level class are public and default. Public allows access to the class outside the package, whereas default restricts access to the class within the package.
~

How to read data from abstract class

Hi,
I have an abstract class which has a try block in the run method which looks like this:
public void run()
throws exception
try
ArrayList xCoord = new ArrayList();
Double xValue = null;
for (j=0; j<10; j++)
xValue = new Double (table.getX(j).toDouble());
xCoord.add(xValue); // to populate arraylist
i also have the required catch statements, i have not written them here to keep in concise.
My question is: How do I read the values stored in the xCoord arraylist from another 'concrete' class derived from the above abstract class.
I know that for this, I first have to be able to execute the above "run" method, because that is how the arraylist will get populated with values. But how do I do this from the concrete class?
Then, once the arraylist is formed, how do I read the values from the concrete class, without copying all the code?
Any guidance will be really helpful. Thanks -- Vinay.

Add a public or protected accessor (getter) method to retrieve the value calculated in run(). Modify run() to store the results in an instance variable in the abstract class.
- Saish

Modify Standard Abstract Classes.

Similar Messages

Maybe you are looking for