编程语言
首页 > 编程语言> > 如何在模块化应用程序中处理泛型类/接口?

如何在模块化应用程序中处理泛型类/接口?

作者:互联网

我是Java新手,我正在编写一个这样的模块化应用程序:

*************          *******         ***********
*           *          *     *         *   Data  *
* Front-end * -------- * API * ------- * Handler *
*           *          *     *         *         *
*************          *******         ***********

本质上,我希望能够使用N个类定义一个API,然后让“数据处理程序”模块处理将对象存储在某个地方(例如数据库),而不需要前端知道如何实施.

所以,假设我的API中定义了两个类:Contract和Company.
我希望前端能够做到这样的事情:

myContract = new Contract();
myCompany = new Company();
myContract.setCompany(myCompany);
myContract.save();
myCompany.save();

这样,将来我可以改变存储数据的方式(数据处理程序模块),而无需更改前端的任何代码.

为此,我在API模块中为Contract和Company编写了两个接口.
然后,在数据处理程序模块中,我写了实现两个接口的类:DbContract和DbCompany.

现在,我遇到了问题因为我已经在Contract接口中定义了getter / setter方法:

public interface Contract {
    public Company getCompany();
    public void setCompany(Company company);
}

并在DbContract中实现它们:

public class DbContract implements Contract {
    private DbCompany company;

    @Override
    public Company getCompany() {
        return this.company;
    }

    @Override
    public void setCompany(Company company) {
        this.company = company;
    }
}

但是,我在整个地方都遇到了班级类型不匹配的错误……
我完全忽视了这一点吗?我该怎么做呢?

在此先感谢您的帮助.

解决方法:

myContract = new Contract();

这不起作用,因为您无法创建接口的实例.

你似乎有正确的想法,但似乎也对“实施”一词存在误解.

如果前端需要创建这些接口的实例,则需要知道实现或提供自己的实现.另一方面,如果前端根本不了解实现,则应调用后端来创建新实例.

除此之外,制作合同和公司数据容器并移动用于保存到服务的实际逻辑可能是更好的设计,例如,你的代码看起来像这样:

class Contract { ... } //as before, but classes not interfaces
class Company { ... } //as before, but classes not interfaces

创建新合同:

Contract myContract = new Contract();
Company myCompany = new Company();
myContract.setCompany(myCompany);

contractService.save( myContract ); //assuming this would save the company as well

您可以查找服务或注入服务.对于后者,请看一下Spring依赖注入.

更新:

在您的评论中,您声明公司和合同将是JPA实体,如果我理解正确,您不希望前端有任何关于JPA正在使用的概念.

在这种情况下,您有两个选择:

>使对象成为普通POJO,并在后端为JPA映射添加XML.然后,您将从前端传递的每个实例视为分离的实体.
>如果要对映射使用注释,并且不希望前端知道您需要提供API使用的中间层(称为数据传输对象= DTO).然后,内部后端将在实体和DTO之间进行转换.

标签:java,modularity,decoupling
来源: https://codeday.me/bug/20190628/1317535.html