courtrigrad said:
Hello all
I need help with java. On Tuesday we will be having a test on superclasses and subclasses. There will be basic questions such as: Can a subclass inherit from a superclass's private instance variables?
That doesn't quite make sense. Are you sure the question wasn't can a subclass
access a superclasses private instance variables? The answer would be no.
However, I really need to work on the free response section my teacher will be giving. It is called a "design question." Can anyone give any advice as to what the best way is for studying for the free response? Has anyone ever heard of a "design question?" Also, what are the best Java books out on the market (heard Deitel and Deitel is pretty good)
Good design is in software engineering is pretty hard and really only comes with experience, but there are a few general principles that one should abide by when following an object oriented methodology. The first principle is that your classes should correspond as close as they can to real world objects, or understandable "virtual" objects. This is not always possible or useful, but it is a good principle to follow. In a similar vein, your objects should also be well named. For example if I am doing a racing simulation, I would probably have a class called "Vehicle" which corresponds to and models everything I want about the vehicles I am going to model. I would then have subclasses with particular types of vehicles to model.
Follow the 'is a" rule for inheritance. In other words if you can't say that a subclass "is a" type of the superclass, then don't inherit. An example would be that a "Truck" is a "Vehicle" in our racing simulation. On the other hand, I may not need several layers of subclasses if I cannot justify it. For instance, I could have something like Vehicle->Truck->Pickup->Ford 150, but is there really a need for the Truck and Pickup sublclasses? Do all trucks have enough in common that I can do something meantful at that level that will be used by all subclasses?
Follow the "has a" rule for containership. If class A has another class B as a instance variable. you should be able to say that the class A "has a" class B. For example, suppose I want to model the engine of the car. I would probalby have another class called "Engine" that would model the engine, and put it as an instance variable in my class "Vehicle", because all Vehicles have Engines.
Public instance variables should never be used. Use accessor functions instead. Many people think this is unwieldy but it is a good design principle.
Static class methods should rarely be used.
Functions should be simple and accomplish small, but meaningful tasks. For example, I might have some function called vehicle.start() which starts the car running. Yes, it might only be a few lines of code but it has accomplishes a definite, easily understandable goal. I would not want a funciton like vehicle.simulate() which does everything. That would probably go in some other class which manages the entire simulation. A good principle to follow is that you have any more than 10 if, else, for, or switch statements, you probably need to start a new function or come up with some different classes.
If you want to take a look at good design, Sun's Swing toolkit isn't bad. Its fairly complex but believe me its a lot simpler than a lot of GUI's out there.
I'm not sure about books, I actually never took a software engineering class in college, and know enough about languages that I can read the documentation and language specfication and figure out everything for myself. O'Reilly books tend to be well written. It seems like the shorter the book, the more useful it is. Avoid anything like Java in 21 days, Java for dummies, etc. Knuth's books would probably be a bit too advanced for you but you can check them out if you're up for a real challenge.
