首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

Unity应用架构设计(4)——设计可复用的SubView和SubViewModel(Part 2)

SubView行为多变性 在上篇文章中,我阐述了为什么要使用SubView,总结起来就3个字:『可复用』 。...那么问题来了,既然是可复用,那就意味着SubView可以在任何场景下使用,那怎样才能确保它做的是正确的行为呢? 举个栗子,还是 以如下图FaceBox为例,不同的场景下点击头像应该处理不同的事: ?...在战团中点击头像,则显示该成员的具体信息 在队伍里点击头像,则进入换人界面 在战斗时点击头像,则显示它配置的战术 你看,同样一个SubView,在不同的场景下它的行为往往是不一致的。...定制SubView的行为 你可能会以如下方式去定制SubView的行为: void OnClick(){ if(战团){ 显示该成员的具体信息 }else if(队伍){...一个Button也好,还是一个SubView也好,他们都是可复用的组件,不应该与具体的业务逻辑相结合。通过事件或者委托的形式,暴露给开发者来决定究竟要处理什么逻辑,这样才能和具体业务逻辑解耦。

66070

Unity应用架构设计(4)——设计可复用的SubView和SubViewModel(Part 1)

那么如何去设计SubView和SubViewModel,我总结出几条原则: 当一个功能被不同的场合频繁用到,建议将这个功能抽象成SubView(SubViewModel) SubView(SubViewModel...)应该保持高内聚,低耦合原则 SubViewModel不应该处理具体的业务逻辑,它很单纯,可通过委托Delegate的方式交由外部处理 构建SubView和SubViewModel 假设现在有如下一个需求...看到左上角的勋章吗,这个勋章会在不同的场景出现,我们优先把它考虑成一个SubView(BadgeView),也就是最外层的FaceBoxView里嵌套了一个BadgeView。...badgeView.BindingContext.Initialization(newValue); } 我们可以看到,组件化的实施从代码量上是变得复杂了,组件的颗粒度越细,那么嵌套的层次就越深,如果某个功能只出现一次,并且不会被复用,那么我不推荐将它变为一个SubView...uMVVM的理念是只需要一个View,View是唯一的入口,并且View可以是非常复杂,里面维护了所有的SubView,所以换UI也好,换功能也罢,只要关注于对应的View即可。

1.1K50
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    View编程指南(三)

    这里仅仅是少数: 布局和subview管理 view定义了与其父view相关的默认调整大小行为。 一个view可以管理subview列表。 view可以根据需要重写subview的大小和位置。...使用这些方法比删除subview并重新插入它们要快。 要从其superview移除subview,请调用subview的removeFromSuperview方法(而不是superview)。...当subview添加到其父项时,subview的当前frame矩形表示它在superview内的初始位置。frame位于其superview的可见边界之外的subview在默认情况下不会被剪切。...请记住,如果您从其supview中删除subview并打算重用它,则必须再次保留该subview。 removeFromSuperview方法在移除之前autorelease一个subview。...将subview添加到另一个View时,UIKit会通知superview和subview

    1.7K30
    领券