Could someone please look the design?

[wangdong]

I am creating a system to allow a user to add a system file into the database and enable the user to convert this document into different format.

I create three classes,

FileObjectControll(interface)
FileSystemObj(Abstract)
File

because the program is database intensive. So I am always confused whether the add(), delete() function should be in the File class, or within a databasehandler class. Please someone have a look on the design, any comment will be great helpful.

public interface FileObjectController {
	public void convert();
	public void secur();
}

public abstract class FileSystemObj {
	public int objID;
	public String objName;
	public String objCreatTime;
	public Collection objCollection;
	
	// Add a file into the table	
	public void add() {
	}

	public void delete() {
	}

	// Get a file from the table
	public FileSystemObj get(int objID) {
		return null;
	}

	// Get a file collection from the table  
	public Collection get(String sql) {
		return objCollection;
	}
}

public class File extends FileSystemObj implements FileObjectController{
	
	
	public File(int _id, String _name){
		super.objID = _id;
		super.objName = _name;
	}
	public void convert() {
		// TODO Auto-generated method stub
	}

	public void secur() {
		// TODO Auto-generated method stub
		
	}
	
}

 

[BobRodes]

There's no real hard answer to this here. You'll find arguments for both sides. I tend to lean towards putting in a database handler class, although in some cases that would be overengineering.

Here's a thread for you: thread678-1121478

Also, take a look at grooke's posts.

Also, learn cohesion and coupling and work for a balance.

HTH

Bob

 

[wangdong]

Second question, is it the right way using abstract class and interface. Since I have learnt java, I am always confusing with interface class. As the listed example, what I don't understand is why not put a secur method into the file class.

 

[BobRodes]

Technically, an interface is an abstract class. The difference is that abstract classes may have some methods implemented, whereas an interface has no implementation at all. Therefore, in practice (as well as in java syntax), an abstract class is a class with some methods implemented and some not, and an interface is a class that relies on a subclass to do all of its implementation.

An interface, then, defines the way in which functionality will be exposed, but not the functionality itself. An abstract class defines how functionality will be exposed but also defines some of the functionality. Now, you can create an abstract (java) class with no concrete methods, but general practice is that abstract classes have some abstract methods and some concrete ones.

As for your code: I would say that you have followed these rules in the definition of your base classes. The interface is in fact an interface, and the abstract class has some methods implemented and some not. However, in your subclass, you haven't provided an implementation for add and delete from your abstract class. If my memory of java serves me correctly (my java knowledge is perhaps well described as "working"), this will work in your example because you haven't specifically defined add and delete as abstract in the base class. However, whether this is so or not, it is clearly your intent that they should be abstract, and your extending class should provide implementations of these two methods to be well-formed.

Furthermore, you should provide implementations of the interface. That's why the "//TODO" notation is there. Sometimes interfaces are implemented with some empty definitions if you don't need all of the methods you're implementing but want to provide clients with polymorphic capability. But it doesn't make sense to implement an interface if you don't actually do so.

HTH

Bob

 

[wangdong]

Thanks Bob. That's very helpful.

 

[BobRodes]

You're most welcome, and good luck.

Bob