0

私が現在取り組んでいる従来の Java コードベースは、悪名高いフレームワークを利用しています。すぐに使用できるドメイン クラスが適切にパッケージ化された jar で提供されます。ドメイン クラスは、getter と setter の袋にすぎません。

これは、手続き型コードを静的な Util クラスから適切な場所、つまりドメイン クラス自体に抽出することによって、豊富なドメイン モデルを作成することを妨げています。たとえば、次のメソッド内のロジックを考えてみましょう。

public static boolean areFriends(User user1, User user2) {
    for (User friend : user1.getFriends()) {
        if (friend.equals(user2)) {
            return true;
        }
    }
    return false;
}

isFriendOf(User another)これは、代わりにUserクラスのようにうまく表現できます。しかし、Userクラスはすべてロックされています。ところで、フレームワークはライフサイクル メソッドを使用してUserオブジェクトを渡します。

//Life-cycle method
public void execute(FrameworkBlob frameworFattyObject) {
    ...
    User user = frameworFattyObject.getUser();
    User loggedInUser = getLoggedInUserFromSomewhere();
    bool areFriends = BadUtilClass.areFriends(user, loggedInUser);
    ...  
}

テスト容易性を念頭に置いて、次のようなことを言う方法はありますか:

bool areFriends = user.isFriendOf(loggedInUser);
4

1 に答える 1

1

悪名高いフレームワークに慣れていません。最初にコメントしなければなりませんが、長すぎます。

Life-cycle メソッドに何かを注入することは可能ですか?

例えば：

public class AClassIDontKnow {

    private DomainModelMapper mapper;//inject this
    //Life-cycle method
    public void execute(FrameworkBlob frameworFattyObject) {
        ...
        UserDomainModel user = mapper.getUser(frameworFattyObject);
        UserDomainModel loggedInUser = getLoggedInUserFromSomewhere();
        bool areFriends = user.isFriendOf(loggedInUser);
        ...  
    }
}

public class DomainModelMapper {
    UserDomainModel getUser(FrameworkBlob frameworFattyObject) {
         User userAnemicModel = frameworFattyObject.getUser();
         //map the anemicModel to a rich domain model
         return ....;
    }
}

したがって、テスト戦略:
1) マッピングをテストするために DomainModelMapperUnitTest が配置されます。
2) UserDomainModelUnitTest は isFriend(user) をカバーします
。 3) 必要に応じて、AClassIDontKnowUnitTest で DomainModelMapper のモックを使用します。

于 2013-10-25T13:09:40.237 に答える