Inheritance and InetAddress

I'm painfully new to Java so I must be missing something obvious here. Hopefully someone can help me.
I don't like isReachable in InetAddress so I want to override it with my own isReachable method. The problem is I cannot figure out how to extend the InetAddress class.
Here is what I have for my new class class:
package MyProgram;
include java.net.InetAddress;
public class MyInetAddress extends InetAddress {
public boolean isReachable(int timeout) {
//code here
}The above will not compile. The compiler returns "class creation was unsuccessful for an unknown reason". A single red X appears next to the extends line above and says "InetAdress() is not public in java.net.InetAddress; cannot be accessed from outstide package".
I'm using Netbeans 5.0 and JDK 1.5.0_07 on Windows XP SP2.
So what am I doing wrong? Can I really not extend the InetAddress class?
Thanks.

"include" should be "import", and isReachable() has to return a boolean.
But the more substantial problem is a little more subtle. Every class has got
to have a constructor - even if it's only the default no argument constructor
that java supplies. This default constructor does nothing except call the
parent class's no argument constructor. This process is very important
because it ensures that constructors are called for all ancestor classes and
all the necessary initialisation is done.
Back to your problem. InetAddress does not have a no agument constructor
(not one that is visible, so you can call it). The only way round this is for you
to supply a different constructor for MyInetAddress and have it call a different
constructor of InetAddress. (java is happy so long as some constructor
is called and all the initialisation can take place.)
But as you no doubt realise: InetAddress has no visible constructors.
You are left with no valid way of making a subclass. Sorry.
You didn't really say why you wanted a subclass. If you don't like
isReachable(), you dont have to use it!
Another approach is to have MyInetAddress not subclass InetAddress, but
rather implement all the methods (it wants to) itself. This is not all that
hard, because it can have a InetAdress member variable to which it
delegates: when getAddress() is called on the new class it just returns
the result of calling getAddress() on the member variable.

Similar Messages

Difference between inheritance and abstract class

difference between inheritance and abstract class

See this thread:
http://forum.java.sun.com/thread.jspa?forumID=24&threadID=663657
And before Post New Topic, just search in this forums. All most will get answers.

Problem with inheritance and outputting values in toString.

Hey guys, i'm having a major problem with inheritances.
What i'm trying to do with my program is to create objects in my demo class. Values are passed to several other objects that each do their own calculations of grades and results and then outputs the result in my toString. I followed step by step the instructions in my book on how to setup the inheritance and such. I can only output everything that was created in my superclass, any other thing that was created in an object that belongs to a subclass does not display in the output at all.
Even if I change or create new instance variables, I can't figure out for the life of myself how to output the other values.
Because there's so much code to be splitting on the forums, I zipped my whole project in a RAR. I'll link it here
http://www.4shared.com/file/ZleBitzP/Assign7.html
The file to run the program is CourseGradesDemo class, everything else is either a subclass or superclass to some part of the program. After you run CourseGradesDemo, you will see the output, and understand what displays and what stays at 0.0 value. If anyone can help me out with this it would be greatly appreciated
Thanks in advance.

Basshunter36 wrote:
Hey guys, i'm having a major problem with inheritances.
What i'm trying to do with my program is to create objects in my demo class. Values are passed to several other objects that each do their own calculations of grades and results and then outputs the result in my toString. I followed step by step the instructions in my book on how to setup the inheritance and such. I can only output everything that was created in my superclass, any other thing that was created in an object that belongs to a subclass does not display in the output at all.
Even if I change or create new instance variables, I can't figure out for the life of myself how to output the other values.No idea what you're talking about. Provide an [url http://sscce.org]SSCCE.
Because there's so much code to be splitting on the forums, I zipped my whole project in a RAR. I'll link it here
http://www.4shared.com/file/ZleBitzP/Assign7.html
Not gonna happen. Provide an [url http://sscce.org]SSCCE. And don't say you can't. You definitely can. You may have to spend an hour building a new program from scratch and getting it to reproduce the problem, but if you can't or won't do that, you'll find few people here willing to bother with it.

When to use inheritance and When to use Composition

java support both inheratiance and composition .I also know "is a" and
"has a realitionship" but there is always a problem with me to understanding whethere i have to use extends or having a object of a class has a member of othere class.
and also "A pure OOP must support polimorphisim,inheretiance,encapluction,Abstraction and Composition" correct me if i am wrong
thank you and have a nice day.

Bruce Eckel, author of Thinking In Java, has this to say about composition vs. inheritance:
When deciding between inheritance and composition, ask if you need to upcast to the base type. If not, prefer composition (member objects) to inheritance. This can eliminate the perceived need for multiple base types. If you inherit, users will think they are supposed to upcast.
Choose composition first when creating new classes from existing classes. You should only used inheritance if it is required by your design. If you use inheritance where composition will work, your designs will become needlessly complicated.
Bill Venners: Composition versus Inheritance
Use inheritance (of implementation) only when the class satisfies the following criteria:
1) "Is a special kind of," not "is a role played by a";
2) Never needs to transmute to be an object in some other class;
3) Extends rather than overrides or nullifies superclass;
4) Does not subclass what is merely a utility class (useful functionality you'd like to reuse); and
5) Within PD: expresses special kinds of roles, transactions, or things.
-- from Java Design: Building Better Apps and Applets (2nd Edition), by Peter Coad and Mark Mayfield

When to use inheritance and when not to?

I've just been trying find out when to use inheritance and when not to use inheritance? I know that inheritance gives advantages such as code reuse and maintainability. But when are their times not to use inheritance that may effect the design of a project?
Also when should one consider aggregation over inheritance(is-a relationship)?
thanks,
plandis

Hi
Answering this question usually requires a few books, so, I'm sorry, it's not really as simple as choosing between using a screwdriver vs. a hammer.
But, very short, inheritance should ideally only be used when there exist a strict 'is-a' relationship. However, sometimes it may be clever to inherit when you have a 'is-almost-a' relationship... And sometimes this is a stupid move. This depends on the context/circumstances.
Aggregation is normally considered a 'has-a' relationship, thereby differing clearly from inheritance. The old 'car' model says "a car is-a vehicle and has-some (at least) wheels."
The wheels are aggregated to the car class, that itself is inherited from vehicle.
However, this is just a good rule-of-thumb and there may be circumstantial reasons for not following these guidelines.

Inheritance and access control - "private protected"

I'm reopening an old topic, seems to have been last discussed here 2-3 years ago.
It concerns the concept of restricting access to class members to itself, and its subclasses. This is what "protected" does in C++ and "private protected" did in early versions of the Java language. This feature was removed from Java with a motivation along the lines of not being "simple", and "linear" (in line with the other access modes, each being a true subset of the next). Unfortunately, the article which explained Sun's position on this keyword combination seems to have been removed from the site, so I haven't been able to read its original text.
But regardless of simplicity of implementation or explaining Java's access modifiers to newbies, I believe it is a fundamental part of OO programming for such an access mode to exist. The arguments for having the standard "private" mode in fact also apply for having a C++-style "protected" mode. (Arguing that classes within a package are related and it therefore doesn't hurt to also give them access to Java's "protected" members, is equally arguing that "private" is unneccessary, which noone of course believes.)
The whole concept of inheritance and polymorphism and encapsulation builds on the access modes private, protected, and public (in the C++ senses). In Java the "package" concept was added - a nice feature! But I see no justification for it to negate the proper encapsulation of a class and its specializations.

What effect upon inheritance other than hiding members
from subclasses is there?
None. And I cant think of another declaration that prevents members from being inherited but private.
Of course the onus comes on the programmer with Java's
definition of "protected" - but
1) there is rarely a single programmer working within
a package
The point was the package is a unit which does not hide from itself. Just like all methods within a class can see each other, all classes within a package can, and all packages within a program can.
2) it muddies the encapsulation in the design - when
you see a "protected" method someone else, or yourself
some time ago - wrote, how do you know if the design
intention is to have it accessed solely by the class
and its subclasses, or if it is indeed intended to be
shared with the whole package? The only way to do
this today is to always explicitly specify this in the
comments, which may be lacking, inconsistent, and
abused (since it isn't enforced).Encapsulation would be implementation hiding. Not method hiding. The only thing you should probably allow out of your package is an interface and a factory anyway.
I understand where you are coming from, but I really have not had occasion to take issue with it. I can't think of a real codeing situation where this is required. OTOH, I can't think of a coding situation where I need to access a protected method from another class either.

A question about inheritance and overwriting

Hello,
My question is a bit complicated, so let's first explain the situation with a little pseudo code:
class A {...}
class B extends A{...}
class C extends B {...}
class D extends C {...}
class E extends B {...}
class F {
ArrayList objects; // contains only objects of classes A to E
void updateObjects() {
    for(int i = 0; i < objects.size(); i++)
      A object = (A) objects.get(i); // A as superclass
     update(A);
void update(A object) { ... }
void update(B object) { ... }
void update(D object) { ... }
}My question now:
For all objects in the objects list the update(? object) method is called. Is it now called with parameter class A each time because the object was casted to A before, or is Java looking for the best fitting routine depending on the objects real class?
Regards,
Kai

Why extends is evil
Improve your code by replacing concrete base classes with interfaces
Summary
Most good designers avoid implementation inheritance (the extends relationship) like the plague. As much as 80 percent of your code should be written entirely in terms of interfaces, not concrete base classes. The Gang of Four Design Patterns book, in fact, is largely about how to replace implementation inheritance with interface inheritance. This article describes why designers have such odd beliefs. (2,300 words; August 1, 2003)
By Allen Holub
http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html
Reveal the magic behind subtype polymorphism
Behold polymorphism from a type-oriented point of view
http://www.javaworld.com/javaworld/jw-04-2001/jw-0413-polymorph_p.html
Summary
Java developers all too often associate the term polymorphism with an object's ability to magically execute correct method behavior at appropriate points in a program. That behavior is usually associated with overriding inherited class method implementations. However, a careful examination of polymorphism demystifies the magic and reveals that polymorphic behavior is best understood in terms of type, rather than as dependent on overriding implementation inheritance. That understanding allows developers to fully take advantage of polymorphism. (3,600 words) By Wm. Paul Rogers
multiple inheritance and interfaces
http://www.javaworld.com/javaqa/2002-07/02-qa-0719-multinheritance.html
http://java.sun.com/docs/books/tutorial/java/interpack/interfaceDef.html
http://www.artima.com/intv/abcs.html
http://www.artima.com/designtechniques/interfaces.html
http://www.javaworld.com/javaqa/2001-03/02-qa-0323-diamond_p.html
http://csis.pace.edu/~bergin/patterns/multipleinheritance.html
http://www.cs.rice.edu/~cork/teachjava/2002/notes/current/node48.html
http://www.cyberdyne-object-sys.com/oofaq2/DynInh.htm
http://www.gotw.ca/gotw/037.htm
http://www.javajunkies.org/index.pl?lastnode_id=2826&node_id=2842
http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=1&t=001588
http://pbl.cc.gatech.edu/cs170/75
Downcasting and run-time
http://www.codeguru.com/java/tij/tij0083.shtml
type identification
Since you lose the specific type information via an upcast (moving up the inheritance hierarchy), it makes sense that to retrieve the type information ? that is, to move back down the inheritance hierarchy ? you use a downcast. However, you know an upcast is always safe; the base class cannot have a bigger interface than the derived class, therefore every message you send through the base class interface is guaranteed to be accepted. But with a downcast, you don?t really know that a shape (for example) is actually a circle. It could instead be a triangle or square or some other type.
To solve this problem there must be some way to guarantee that a downcast is correct, so you won?t accidentally cast to the wrong type and then send a message that the object can?t accept. This would be quite unsafe.
In some languages (like C++) you must perform a special operation in order to get a type-safe downcast, but in Java every cast is checked! So even though it looks like you?re just performing an ordinary parenthesized cast, at run time this cast is checked to ensure that it is in fact the type you think it is. If it isn?t, you get a ClassCastException. This act of checking types at run time is called run-time type identification (RTTI). The following example demonstrates the behavior of RTTI:
//: RTTI.java
// Downcasting & Run-Time Type
// Identification (RTTI)
import java.util.*;
class Useful {
public void f() {}
public void g() {}
class MoreUseful extends Useful {
public void f() {}
public void g() {}
public void u() {}
public void v() {}
public void w() {}
public class RTTI {
public static void main(String[] args) {
Useful[] x = {
new Useful(),
new MoreUseful()
x[0].f();
x[1].g();
// Compile-time: method not found in Useful:
//! x[1].u();
((MoreUseful)x[1]).u(); // Downcast/RTTI
((MoreUseful)x[0]).u(); // Exception thrown
} ///:~
As in the diagram, MoreUseful extends the interface of Useful. But since it?s inherited, it can also be upcast to a Useful. You can see this happening in the initialization of the array x in main( ). Since both objects in the array are of class Useful, you can send the f( ) and g( ) methods to both, and if you try to call u( ) (which exists only in MoreUseful) you?ll get a compile-time error message.
If you want to access the extended interface of a MoreUseful object, you can try to downcast. If it?s the correct type, it will be successful. Otherwise, you?ll get a ClassCastException. You don?t need to write any special code for this exception, since it indicates a programmer error that could happen anywhere in a program.
There?s more to RTTI than a simple cast. For example, there?s a way to see what type you?re dealing with before you try to downcast it. All of Chapter 11 is devoted to the study of different aspects of Java run-time type identification.
One common principle used to determine when inheritence is being applied correctly is the Liskov Substitution Principle (LSP). This states that an instance of a subclass should be substitutible for an instance of the base class in all circumstances. If not, then it is generally inappropriate to use inheritence - or at least not without properly re-distributing responsibilities across your classes.
Another common mistake with inheritence are definitions like Employee and Customer as subclasses of People (or whatever). In these cases, it is generally better to employ the Party-Roll pattern where a Person and an Organization or types of Party and a party can be associated with other entities via separate Role classes of which Employee and Customer are two examples.

Private inheritance and dynamic cast issue

Hello. I am hitting a problem combining private inheritance and dynamic casting, using Sun Studio 12 (Sun C++ 5.9 SunOS_sparc Patch 124863-01 2007/07/25):
I have three related classes. Let's call them:
Handle: The basic Handle class.
DspHandle. Handle implementation, able to add itself to a Receiver.
IODriver. Implemented in terms of DspHandle, It is the actually instantiated object.
Consider the following code. Sorry, but I've tried my best trying to minimize it:
#include <iostream>
using namespace std;
class Handle {
public:
virtual ~Handle() {};
class Receiver {
public:
void add(Handle &a);
class DspHandle : public Handle {
public:
virtual ~DspHandle() {};
void run(Receiver &recv);
class IODriver : private DspHandle {
public:
void start(Receiver &recv) {
DspHandle::run(recv);
void DspHandle::run(Receiver &recv) {
cout << "Calling Receiver::add(" << typeid(this).name() << ")" << endl;
recv.add(*this);
void Receiver::add(Handle &a) {
cout << "Called Receiver::add(" << typeid(&a).name() << ")" << endl;
DspHandle d = dynamic_cast<DspHandle>(&a);
cout << "a= " << &a << ", d=" << d << endl;
int main(int argc, char *argv[]) {
Receiver recv;
IODriver c;
c.start(recv);
Compiling and running this code with Sun Studio 12:
CC -o test test.cc
./test
Calling Receiver::add(DspHandle*)
Called Receiver::add(Handle*)
a= ffbffd54, d=0
The dynamic cast in Receiver::add, trying to downcast Handle to DspHandle, fails.
This same code works, for example with GNU g++ 4.1.3:
Calling Receiver::add(P9DspHandle)
Called Receiver::add(P6Handle)
a= 0xbfe9c898, d=0xbfe9c898
What is the reason of the dynamic_cast being rejected. Since the pointer is actually a DspHandle* , even when it is part of a private class, shouldn't it be downcastable to DspHandle? I think that perhaps the pointer should be rejected by Receiver::add(Handle &a) as it could be seen as a IODriver, that can't be converted to its private base. But since it's accepted, shouldn't the dynamic_cast work?
Changing the inheritance of IODriver to public instead of private avoids the error, but it's not an option in my design.
So, questions: Why is it failing? Any workarround?
Best wishes.
Manuel.

Thanks for your fast answer.
But could you please provide a deeper answer? I would like to know where do you think the problem is. Shouldn't the reference be accepted by Receiver:add, since it can only be seen as a Handle using its private base, or should the dynamic_cast work?
Aren't we actually trying to cast to a private base? However, casting to private bases directly uses to be rejected in compile time. Should the *this pointer passed from the DspHandle class to Receiver be considered a pure DspHandle or a IODriver?
Thanks a lot.

Inheriting and the "super" keyword

I found a case where "super" is not working as I understand it should...
Can someone explain me the underlying theory that makes JAVA behave this way??
public class Base {
     public void method1() {
          System.out.println("method1 from \"Base\" class. About to call method2.");
          method2();
     public void method2() {
          System.out.println("method2 from \"Base\" class. About to call method3.");
          method3();
     public void method3() {
          System.out.println("method3 from \"Base\" class.");
public class Extension extends Base {
     @Override
     public void method1(){
          System.out.println("method1 from \"Extension\" class. About to call super.method2.");
          super.method2();
     @Override
     public void method2(){
          System.out.println("method2 from \"Extension\" class. About to call method3.");
          method3();
     @Override
     public void method3(){
          System.out.println("method3 from \"Extension\" class.");
public class Main {
     public static void main(String args[]) {
          System.out.println("In \"The Java Programming Language,\n" +
                    "Fourth Edition By Ken Arnold, James Gosling, David Holmes\"\n"+
                    "chapter: 3.3: \"Inheriting and Redefining Members\""+
                    " says:");
          System.out.println("Using super is the only case in which the type of\n" +
                    "the reference governs selection of the method implementation\n" +
                    "to be used. An invocation of super.method always uses the\n" +
                    "implementation of method the superclass defines (or\n" +
                    "inherits). It does not use any overriding implementation of\n" +
                    "that method further down the class hierarchy.\n");
          System.out.println("But by running this code, i get:");
          System.out.println("------------------------------------------");
          Extension ext = new Extension();
          ext.method1();
          System.out.println("------------------------------------------");
          System.out.println("\nWHY??? I was expecting:\n"+
                    "method1 from \"Extension\" class. About to call super.method2.\n" +
                    "method2 from \"Base\" class. About to call method3.\n" +
                    "method3 from \"Base\" class.");
THANKS!!

IgnacioKriche wrote:
But I used "super", so this means to use the methods of the super class and I understand that a method called within another, is part of this last one. this is:
if inside method 'x', method 'y' is called, then 'y' is part of 'x' . Agree? And therefore since I am using super I'm saying use 'x' method from super class since 'y' is part of 'x' then super applies for 'y' as well so what is method from the extended class doing here? It's like we have a mix between the 'x' from super and 'y' from the extended. Something like super only applies for the first level not at a deeper level (a method called from another)No. Just because the base class method2() invokes method3() does NOT mean it will always invoke base's version of method3. If it did that, then polymorphism would definitely be broken.
You explicitly invoked super.method2(), so that told the compiler to explicitly use the base class version of that method. But then method2 in the base class invokes method3(). That ends up invoking the overridden version in the subclass, by design, because afterall the actual object whose methods are being executed is a subclass instance. If it didn't do that, then polymorphism would be broken for everyone else.
If you think you need the behavior you are looking for, you are just designing it wrong in the first place.

Parameterized inheritance and implementation

I'm learning generics, and I'm having a problem getting the following to work
I have a base class with some data/behavior
public abstract Base<E> {
//...Then there is a concrete class that extends Base and implements Map
public Concrete<E extends Object & Map<K,V>> extends Base<E extends Object & Map<K,V>> implements Map<K, V>{
//...I cannot seem to specify that the type for Base must be a Map<K, V>.
I've thought about containing and delegating, but really Concrete IS-A Base and Concrete IS-A Map.
Am I missing something about inheritance and generics?
Any suggestions?

James,
Based on your previous posts I think you understand generics as well as I do, and in some aspects, probably better.
I was trying to capture my thought processes (and that is quite hard since mostly this happens sub-consciously - its quite hard to drag it up into consciousness then document it, but the effort was worthwhile for me and hopefully for others as well).
In this particular case, E is Map<K,V>, but there could be all sorts of relationships between the type variables, the idea is to identify these and back substitute them, slowly getting rid of type variables until you can't get rid of any more. The ones you are left with are the ones that need to be type parameters.
take the other post from yesterday
http://forum.java.sun.com/thread.jsp?thread=554360&forum=316&message=2719355
as another worked example...
from
"And I'm trying to create a special generic container (List) which would only take elements that
implement the Keyable interface above. For example:
public class ListOfKeyables <E extends Keyable> extends AbstractList<E>{..."
and
"Now, besides standard List methods that use type varable 'E' in their definitions, I would also
like to have a special method like this:
   public E getByKey(Object key)   {   ... "
I would start with (ignoring their "E extends Keyable" suggestion, its too premature for that).
public class ListOfKeyables < ???? > extends AbstractList<E> {
    public E getByKey(Object key) { ... }
} but "only take elements that
implement the Keyable interface" suggests replacing E with Keyable<K> thus
public class ListOfKeyables < ???? > extends AbstractList<Keyable<K>> {
    public Keyable<K> getByKey(Object key) { ... }
Note In this case the substitution getting rid of E introduced another type variable (K), thats OK, its still a step toward a solution.
Then the original poster said "But I would like to constrain the 'key' argument in this method to be of type that is specified as a type parameter to the Keyable interface"
So after implementing this requirement we have
public class ListOfKeyables < ???? > extends AbstractList<Keyable<K>> {
    public Keyable<K> getByKey(K key) { ... }
}At this point there is no more substitutions or requirements to fulfill.
So we look through and see what type variables are still unresolved. These (in this case there is only one K), are then the type parameters of the class, and thus we have what I suggested in that post
public class ListOfKeyables <K> extends AbstractList<Keyable<K>> {
    public Keyable<K> getByKey(K key) { ... }
}As a final step, we need to look at the type parameters and decide if they need any constraints (K extends something), These might come from some use of the type parameter ( such as if Keyable constrained its K parameter, we would need to do the same), or from the application requirements. But in this case, there are not any.
At a certain level of abstraction, this process is not a whole lot different to the process you use when working out what parameters a method or constructor needs (and that process also tends to happen below the consciusness threshold).
In really simplistic terms, the answer to both "what parameters do I need" questions is "all the ones you can't get from somewhere else or derive from the ones you already have".
Bruce

Permissons inheritance and SP Groups

Sorry in advance for the basic question but today I had a long conversation with a vendor that made me doubt what I know
Say you have a site collection, it has 5 subsites and all inherit from the parent.
They have the default permisson groups
Site1 Owners
Site1 Members
Approvers
Site1 Visitors
At some point you get asked to break inheritance and give all sites unique permissons.
From now on all the subsites no longer inherit from Site1, so if I add a user or change anything on that site it wont push down to Subsite1
Now here the part where the confusion came in, if the Appovers group or any exisitng group that is on Subsite1 gets modified will the sites below it see a difference in the Aprrovers group, mythoughts are they will because the group is already there and
breaking inheritance doesnt make the assigned groups unique, they are still the same SP group.
thanks
themush

So one thing to keep in mind is that all SPGroups and Users are stored at the RootWeb level. Subwebs may or may not use those groups or contain those users.
That said, in your scenario, the subweb(s) would still be leveraging the RootWeb's groups (Site1 Owners, Site1 Members, Approvers...) until you manually removed them. If you created an alternate Approvers group and assigned it to the subweb, then yes you
would have to manage both Approvers groups by hand.
So yes, you're absolutely correct -- it is the same Approvers group when you break subweb inheritance.
Trevor Seward
Follow or contact me at...
&nbsp&nbsp
This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

Inheritance and typecasting?

Hi,
Can anybody please give me an example of Inheritance and how type casting works with this?
I am really confused regd this.

Can anybody please give me an example of Inheritance
and how type casting works with this?Have you given up on your other typecasting thread? Asking a vague question like this one probably isn't going to help you - why not get the problem solved that you've been having so far - then if you're still having trouble with casting, tell us what about casting it is you're still having trouble with.

What is single inheritance, multiple inheritance, and describe Java's notio

What is single inheritance, multiple inheritance, and describe Java's notion of an interface?
Can you give me example or reference link? thx

Single inheritance is getting features like data and methods (functions) from a so called parent class. multiple inheritance is the same but you derive features from multiple parent classes (not supported by java). Interfaces are a way around this because you can inherit multiple interfaces. Inheriting from interfaces is like a promise to implement certain methods that these interfaces define but doesn't implement themselves.
check around java.sun.com in the tutorials section, you can probably find a text that describes object oriented program and how it is implemented in java.

Having a problem with inheritance and a constructor

i have two classes, i'm just going to give the constructors anyway. I'm having trouble getting the CDImage constructor to inherit something from songs, I believe the instructions are missing something or the cs lab guy misinterpreted them.
package songs;
import java.text.*;
public class Song implements Comparable {
    private int songLength;
    private String artistName;
    private String songName;
    public Song(int songLength, String artistNames, String songName) {
        this.songLength = songLength;
        this.artistName = artistNames;
        this.songName = songName;
    }These are the instructions that i beleive may be incorrect:
Design a CDImage class to represent a music CD. The constructor takes three parameters: the title of the CD, the recording label, and the number of tracks on the CD. (Each track contains one song.) The CDImage class uses the Song class developed above and should contain methods to accomplish the following:package songs;
import java.text.*;
public class CDImage extends Song {
    private String title;
    private String label;
    private int numberTracks;
    private Song[] songs;
    public CDImage(String title, String label, int tracks){
    this.title = title;// this is the album name
    this.label = label;
    numberTracks = tracks;
    songs = new Song [numberTracks];
    }i know i need to use the super modifier under the constructor but how? because nothing in the constructor of the CDImage class refers directly to the constructor in the Song class
thanks in advance.
Message was edited by:
kevin123

you know whats funny, this project has to do with arrays of objects and not inheritance. We learned inheritance last week but the lab we are doing which is this, is for arrays of objects. sorry for the confusion lol. so you can completely ignore this, it actually has it in big bold letters at the top of the web page for the lab.

Java inheritance and interface code help required

please help me I need your 30 mins only,,, working on assignment and I am trying to understand interface and inheritance might not need even 30 mins, please add me on skype *[deleted by moderator]*
Or add me on
yahoo msgr *[deleted by moderator]*
waiting for your help.
I have no single person friend or I can ask help from who knows java or programming. pretty much want to learn need a friend who can guide me in java.
unfortunately have to submit assignment tomorrow.
Thank you in advance for your time and consideration.
Akee
*Edited by moderator: EJP on 10/11/2012 10:38: removed your private contact details. This is a public forum, not a personal help desk. Ask your questions here or not at all.*

Hi,
there are lot of thread alredy posted please serach
check following link
http://help.sap.com/saphelp_nw04/helpdata/en/ce/1d753cab14a909e10000000a11405a/frameset.htm
XSLT Mapping:
http://help.sap.com/saphelp_nw04/helpdata/en/73/f61eea1741453eb8f794e150067930/content.htm
Java Mapping:
http://help.sap.com/saphelp_nw04/helpdata/en/e2/e13fcd80fe47768df001a558ed10b6/content.htm
Links of blogs on java mapping...
/people/prasad.ulagappan2/blog/2005/06/29/java-mapping-part-i
/people/prasad.ulagappan2/blog/2005/06/29/java-mapping-part-ii
/people/prasad.ulagappan2/blog/2005/06/29/java-mapping-part-iii
blog
/people/sap.user72/blog/2005/03/15/using-xslt-mapping-in-a-ccbpm-scenario
/people/anish.abraham2/blog/2005/12/22/file-to-multiple-idocs-xslt-mapping(file to xslt mapping)
/people/pooja.pandey/blog/2005/06/27/xslt-mapping-with-java-enhancement-for-beginners(xslt with java enhancement function)
Regards,
Amit

Inheritance and InetAddress

Similar Messages

Maybe you are looking for