小编tmh*_*tmh的帖子

抱歉标题,可能太通用了.

我已经阅读了Java 如何编写动作监听器教程,我已经阅读了这个问题,但我仍有一些疑问:当我必须多次执行相同的动作时,我想知道哪种解决方案是最好的.

我想重用相同的ActionListener,但我不确定如何以最好的方式实现这一点(在代码可读性,代码可持续性,性能和代码风格方面).

首先是"标准"代码(如果我不打算重用动作监听器,我将使用它):

btnMenu.addActionListener(
    new ActionListener() {
        public void actionPerformed(ActionEvent e) {
            Navigator.showMenu();
        }
    }
);

这样我就无法重用任何obv,因为它是一个匿名的内部类......

现在,我可以想到以下解决方案:

1. 在字段中存储匿名内部类的引用(很可能是static final);
2. 编写一个实现ActionListener接口的新类.

解决方案1的示例代码:

public static final MENU_ACTION_LISTENER = new ActionListener() {
    public void actionPerformed(ActionEvent e) {
        Navigator.showMenu();
    }
};

btnMenu.addActionListener(MENU_ACTION_LISTENER);

解决方案2的示例代码:

// package-private, only GUI-package classes should be able to use it.
// most likely I won't ever need to subclass it, so why not making it final?
final class …

我想知道DAO应该处理的业务逻辑数量.

好的,我们都知道DAO的目的是封装数据访问并隐藏有关它的所有信息以及实现.此外,DAO的目标还在于将业务逻辑与数据访问逻辑分开.

我认为DAO 必须有一些业务逻辑,例如,如果由于特定域的某些要求而无法删除或更新业务对象,该怎么办？我想没有人会为那个DAO实现删除/更新方法,而且 - 正如我所看到的 - 这意味着对业务逻辑的一些了解.

现在,你可以想象我的问题更具概念性而非实际性,因此使用ORM是没有用的建议,因为没有具体的使用场景.

问题是:鉴于对持久数据的操纵有任何限制,DAO应该处理多少业务逻辑？

示例:
BusinessObject1在其生命周期中只能更新一次.假设我们可以很容易地知道它是否已经更新,如果我们尝试BusinessObject1再次更新DAO会抛出异常吗？或者它应该检测不到任何东西,这应该在业务层管理？

我不确定如何管理GUI中的异常; 我的目标是让用户知道是否出现问题,显示可理解的消息.

我想做这样的事情:

// I'm inside an actionPerformed() method
try {
    // do whatever I have to do here
} catch (KnownBusinessException1 e) {
    // inform the user and do something;
    // most times simply inform the user that it wasn't possible to complete the
    // operation and remain in the same window instead of moving forward.
} catch (KnownBusinessException2 e) {
    // just as above
} catch (KnownDataAccessException1 e) {
    // just as above
} catch (KnownDataAccessException2 e) { …

我必须满足以下要求:

[...]如果登录的用户闲置超过30分钟,他必须退出.

其中,闲置的意思是"不按鼠标也不键盘".

现在,当我第一次阅读它时,我非常确定如何实现这一点:对我而言,它听起来像是与业务逻辑有关的要求,所以我应该在业务层实现它(具有3层架构) .
这里有一些代码:

// simplified and generalized version of my login method
public boolean login(String email, String password) {
    user = dao.read(email, password); //returns either null or the user
    boolean logged = user != null;
    if (logged) {
       // initialize Session somehow, let's say for example:
        Session.start();
    }
    return logged;
}

// simplified and generalized version of my logout method
public void logout() {
    operatore = null;
    // terminate Session somehow, let's say for example: …

我有这个验证密码的方法:

/**
 * Checks if the given password is valid.
 * 
 * @param password The password to validate.
 * @return {@code true} if the password is valid, {@code false} otherwise.
 */
public static boolean validatePassword(String password) {
    int len = password.length();
    if (len < 8 || len > 20)
        return false;
    boolean hasLetters = false;
    boolean hasDigits = false;
    for (int i=0; i<len; i++) {
        if (!Character.isLetterOrDigit(password.charAt(i)))
            return false;
        hasDigits = hasDigits || Character.isDigit(password.charAt(i));
        hasLetters = hasLetters || Character.isLetter(password.charAt(i));
    } …

我想知道我们可以在多大程度上进行无损数据压缩；我无法找到无损算法的在线模拟器来执行一些经验测试。我可以自己做一个，但不幸的是我这段时间没有足够的时间；我仍然对我的直觉很好奇，我将对此进行解释。

让我们仅采用两种更流行的算法：Huffman Coding和Run-lenght Enconding。

假设我们有一个数字A符号的字母表和来自该字母表的任意长的符号序列：例如：

Alphabet  = {A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, X, W, Y, Z}
Sequence1 =  SFBJNERUSNJGSDKKDEIJGNMSDJDDSUSJNF
Sequence2 =  MNMNMNREGUHSDFJUF
Sequence3 =  MMMMMNNNNNASDUERJGASIUJMMMNNNUNS

现在，如果我们只用一个固定长度的n比特字对每个符号进行编码，我们就会得到未压缩的序列，即长N比特。

如果我们使用 Huffman 编码一个序列，我们将使用H位而不是N位，从而节省(1-H/N)*100%位空间。

如果我们使用 RLE 编码相同的序列，我们将使用R位，节省(1-R/N)*100%.

我想知道，如果我们申请RLE + Huffman或者Huffman + RLE我们可以比仅使用其中之一节省更多空间会发生什么。

对我来说，这似乎是一个非常基本的想法，但是在谷歌上搜索我没有找到关于这个主题的任何有趣的东西。

编辑： …

我认为这是一个很常见的问题,但我仍然找不到满意的答案,所以我会问自己.

这是一段代码:

// this is insine OnClickView
TextView status = (TextView) findViewById(R.id.status);
status.setText("Trying to connect to the server...");
try {
    // this opens a socket and send a login request to the server.
    int result = CommunicationManager.login(String email, String password);
    switch (result) {
    case CommunicationManager.SUCCESS:
        // login ok, go on with next screen
        break;
    case CommunicationManager.WRONG_EMAIL:
        status.setTextColor(Color.RED);
        status.setText("Wrong Email!");
        break;
    case CommunicationManager.WRONG_PASSWORD:
        status.setTextColor(Color.RED);
        status.setText("Wrong Password!");
        break;
    }
} catch (CommunicationException e) {
    status.setTextColor(Color.RED);
    status.setText("Unable to estabilish a connection!");
} catch …