接口和抽象类，我晕，该如何应用，高手帮忙。

Question

现在有如下需求：
数据对象在进入数据库之前要进行一系列的业务逻辑验证，通过验证进入数据库，否则返回给请求。具体的业务逻辑验证多种多样，还会不断变化。
想用接口和抽象类来设计一个验证类，可不知如果下手。希望高手给个思路……
谢谢！！！

Answer 1

public interface Validate{
  public Boolean validateDataA(DataObject dataObject) throws Exception;
  public Boolean validateDataB(DataObject dataObject) throws Exception;
  public Boolean validateDataC(DataObject dataObject) throws Exception;
  ……
}
然后有个实现这个接口的类。
楼上是这意思么？

Answer 2

interface Validatable{
 public ValidateException validate();
}abstract SavableObject implement Validatable{
 public void save(){
  validate();
 }
}后面各个对象extends SavableObject，overide methods save dan validate

Answer 3

楼上，overide methods save dan validate 这是啥意思啊？

Answer 4

and,写错了一个字，就是重载这两个方法。

Answer 5

To :idilent(怎么理解怎么说)
你这样做的思想是什么？为什么这样做？能给详细说明一下么？

Answer 6

每个数据对象继承SavableObject呀，然后每个对象存入数据库的方法都重载save，然后在各个对象中自己验证自己的业务逻辑。这种设计方法好像那个interface有些多余。如果一定要用inferface的话，也可以这样，Saveable中有一个proteced的属性，就是interface了，然后把各个验证逻辑实现这个接口，这样一来，如果有saveable的对象共享一个逻辑的话就可以不必重写了。interface IValidator{
 public ValidateException validate();
}
calss ValidatorFactory{}
abstract SavableObject implement Validatable{
 protected Validator validator;
 public void save(){
  validatory = ValidatorFactory.getValidator(this.getClass());
  validatory.validate(this);
  //save object to database.
 }
}

Answer 7

http://blog.csdn.net/idilent/archive/2003/07/18/18768.aspx这是我很早以前写的使用oo解决关闭窗口的文章，和这个类似，不过是英文的。

Answer 8

To :idilent(怎么理解怎么说)
我的理解是这样的，感觉有点怪，哪有问题啊？请指教……
1、
public class UserInfo {
private String userName;
private String passWord;


public String getPassWord() {
return passWord;
}
public void setPassWord(String passWord) {
this.passWord = passWord;
}
public String getUserName() {
return userName;
}
public void setUserName(String userName) {
this.userName = userName;
}
}
2、
public interface Validate { public boolean validateObject(UserInfo userInfo) throws Exception;
}
3、
public abstract class AbstractValidate implements Validate{

protected Validate userValidate;

public abstract int insertObject(UserInfo userInfo)throws Exception;
public abstract int updateObject(UserInfo userInfo)throws Exception;

}
4、
public class UserValidateExt extends AbstractValidate{

public boolean validateObject(UserInfo userInfo) throws Exception{
boolean isValidate = false;
//业务逻辑验证
return isValidate;
}

public int insertObject(UserInfo userInfo) throws Exception{
int i = 0;
if(userValidate.validateObject(userInfo)){
//插入数据库
i=1;
}else{
i=0;
}
return i;
}

public int updateObject(UserInfo userInfo) throws Exception{
int i = 0;
if(userValidate.validateObject(userInfo)){
//更新数据库
i=1;
}else{
i=0;
}
return i;
}}

Answer 9

Interfaces & Abstract classesOne of the most important decisions a technical architect needs to make is whether to specify an interface or an abstract class in order to implement some desired polymorphic behavior in an object model.Both of these concepts support polymorphism by defining methods without bodies. Classes extending an abstract class or implementing an interface are required to implement the bodies of abstract methods (or all methods, in the case of interfaces). Any other class not familiar with the subclass can still utilize an object by calling the methods defined as abstract and getting results. This is where the similarities end, however. The differences between them intentionally make each valuable under different conditions.Interfaces:An interface is best used when a common inheritance tree is not possible among the objects sharing behavior.Have no method bodies or functionality whatsoever; all methods are implicitly abstract. 
Can be implemented on a class without affecting its ancestry. 
Can be used as a flag (as is the case with Cloneable and Serializable) to indicate that something is allowed to happen to a class. 
Cannot declare object attributes, but can implement static final attributes 
Can emulate attributes only by declaring getter and setter methods, which will require an implementing class to fill them with code. 
Abstract Classes:The most obvious situation where an abstract class is called for is when a significant amount of functionality needs to be shared across several classes that share some particular concept.Can have both implemented bodies with functionality and abstract methods. The implemented methods become shared code for the classes that extend the abstract class. 
Can have private methods and attributes, just like an ordinary class. 
Cannot be instantiated by definition; it must be subclassed in order to utilize its functionality. 
Both Interfaces and Abstract Classes:Require that a subclass or implementing class write method bodies for each of the methods in the interface or just the methods declared abstract in the abstract ancestor. 
Can be used to cast objects that implement or subclass from them for the purpose of polymorphism. 
Most texts describe interfaces as contracts. This is often the best way to think about an interface, because it’s a guarantee that a class will support some functionality without describing how it will be carried out. If you are a painter and business is good then you may have lots of contracts to paint houses, but the contracts will not be specific about how it will be performed. You might use a paintbrush or a spraygun or even subcontract it to someone else at a lower price, but the contract guarantees that the work will take place.An abstract class fits into the inheritance tree. By declaring a class abstract the developer is requiring that the functionality can only be instantiated as some object that subclasses it. This approach lends more towards inheritance (the sharing of functionality between classes) than polymorphism (the differentiation of classes by implementation) in the system’s object model.The decision that is made between designing an interface and coding an abstract class can have profound benefits or serious side effects on a system. In general, the abstract class has more functionality but the interface is more flexible. Specifically, by selecting an interface as the form of polymorphism, you lock your subclasses out of being able to share common code and attributes. By selecting an abstract class, you get the code but sacrifice the ability to subclass from anything else. While the choice is up to the architect, there are some clear cases where one is favorable over the other. The next two sections serve to demonstrate this with a pair of real-world cases that should only have been done one way or the other.

Answer 10

你这个设计肯定是有些问题，这样说你不要生气。呵呵。首先我们要知道接口是一个很抽象的东西，因此他要做的不仅仅是为了一个class提供接口，而是很多类都要用到这个。所以你的
public interface Validate {public boolean validateObject(UserInfo userInfo) throws Exception;
}
这样写就只能位UserInfo这一个class服务了。所以你要这样写得话就应该写成
public boolean validateObject(Object object) throws Exception;这样才能使这个接口可以验证任何一个要保存的对象。

Answer 11

TO:idilent(怎么理解怎么说)
我也觉得是，那样岂不是每个数据对象都要一个接口。
有几个问题：
具体的数据类如何转成object，该怎么设计？
validateObject方法的实现是应该写在AbstractValidate类的子类里，还是应该为接口单写实现接口的类？
面向对象的思想我一直不太理解，还请您多指教。谢谢！

Answer 12

你所有的class都是object的子类，所以没有必要装成，直接进去就可了。
validateObject方法的实现肯定要在子类里面，这个就是你的验证逻辑，不同的data object，验证逻辑肯定是不同的。建议你先了解一下面向对象的基础，了解一下为什么继承，有什么好处，为什么抽象，否则这样生搬硬套只会使code更乱。

Answer 13

最好的办法是看看书 然后再HEIP中去多次的运用不同的接口 慢慢就不用怕了
我也是这样过来的

Answer 14

To bgceft():
给推荐本面向对象基础的书吧，谢谢！

Answer 15

大学教程
有点基础就是去JAVA编程思想