标签: software-design

我目前正在构建一个包含大量JavaScript的小型Web应用程序.当我对最初的想法进行原型设计时,我只是将一些函数拼凑在一起,以演示应用程序最终将如何在面向对象的本质中重新编写JavaScript.

现在我已进入实施阶段,我发现为面向对象而创建面向对象的JavaScript似乎有点过分 - 该项目未来可能不需要进行任何重大修改面向对象的设计.相反,我发现一套简洁,有凝聚力的功能运作良好.

因此,有了这样说并试图遵循KISS原则,当一组函数为问题提供合适的解决方案时,是否还有其他理由值得考虑将我的代码转换为面向对象的设计？

假设我正在实现我自己的Scrabble版本.我目前有一个Board包含很多的类Squares.甲Square反过来由的IBonus和Piece.奖金实施实际上是拼字游戏的常用奖励,但有可能我会尝试添加一些新的和扭曲的奖励以增加游戏的灵活性 - 这里的灵活性至关重要!

经过一段时间的思考,我得出的结论是,为了IBonus实现工作,他们需要知道整体Board及其当前位置(在Board,所以它知道它在哪里,它可以检查同样的部分广场作为奖金是).这让我感觉很糟糕,基本上它需要知道很多信息.

所以,我的天真实现是将Boardas参数传递给IBonus.calculate()方法IBonus.calculate(Board board, Point position),即.

此外,它似乎创建一个循环引用.还是我错了？

我并不特别喜欢这种方法,所以我正在寻找其他可能的方法.我知道我可以calculate接受一个接口而不是一个具体的类,即,calculate(IBoard board)但我的IMO并不比第一个案例更好.

我担心过于专注于我目前的实现,能够想到至少能够解决这个问题的完整不同的设计.也许我可以重新设计整个游戏并在其他地方获得奖金,这样会有助于计算吗？也许我太专注于他们了Board？我当然希望有其他方法解决这个问题!

谢谢

抛出软件永远不行吗？
Joel 总结说,公司永远不应该抛弃软件.

我试着成为一个优秀的小程序员并遵循这条规则.我已经进入了一个由一个人经营的五年历史的项目.它充满了反模式,通常设计不佳.大多数问题来自具有内联动态SQL的数据层.

• 专业人士:用户熟悉此应用程序的工作方式,并熟悉它的错误.建立了需求,但是存在一些潜在问题导致用户质疑应用程序的整体可靠性.
• Con:反模式,强耦合,内联SQL,不可能的数据层.

我可以重新收集需求并使用OO,设计模式和现代.NET技术构建这个应用程序.易于管理和可饮用.
在小型应用程序中,如果出现这些问题,我们应该遵循Joel的建议吗？

这个问题可能因为主观而被抛弃,但我发现这对我作为程序员的工作至关重要.

我想对以下问题提出一些建议:假设你想为VCL控件编写适配器.所有适配器应具有相同的基类,但在包装特殊控件方面有所不同(例如,从TEdit获取值与从TSpinEdit获取值不同).所以第一个想法就是创建一个类层次结构

TAdapter = class
end;

TEditAdapter = class (TAdapter)
end;

TSpinEditAdapter = class (TAdapter)
end;

现在我想引入一个字段来保存对vcl控件的引用.在我的特殊适配器中,我想 - 当然 - 使用具体的子类.但是Base类还应该包含一个引用(例如,如果我想使用适配器使控件可见).

可能性1(物业存取中的向下):

TAdapter = class
protected
  FCtrl : TControl;
end;

TEditAdapter = class (TAdapter)
  public
    property Control : TEdit read GetControl write Setcontrol;
end;
{...}
function TEditAdapter.GetControl : TEdit;
begin
  Result := FCtrl as TEdit;
end;

因此,如果我实现一个特定的方法,我使用属性Control,如果我在基类中执行某些操作,则使用protected字段.

可能性2(使用通用基类):

TAdapter = class
end;

TAdapter <T : TControl> = class (TAdapter)
protected
  FCtrl : T;
end;

TEditAdapter = class (TAdapter <TEdit>)
end;

您更喜欢哪种解决方案？还是有第三种解决方案,哪种更好？ …

在软件设计中,这种类型的交互是仅用接口来描述的吗？如果是的话,我应该总是使用这种方法吗？

我必须设计应该具有高可测试性的类库(我使用C#).

该库有一个外观和一些在后台具有不同交互的类.

在优化这个库以获得良好可测试性的情况下,我用接口替换了我的大部分类.

当我这样做时,我在连接图(Visual Studio类图)中看到了只有接口.

这是我的问题的正常决定吗？还是应该有另一种方法？

P/S:也许它在软件设计中是众所周知的方式,但我在书中找不到一些确认.

前几天我与一位同事讨论了MVC的最佳实践,他问我如何最好地分开观点.他正在维护一个MVC解决方案,它有一个共同的输入形式,一个控制器有两个动作,一个get动作和一个post动作.两个动作都返回相同的视图,其中充满了内联逻辑,以及条件检查它是一个帖子还是一个get.

这种情况的最佳解决方案是什么？视图应该分成两个单独的视图吗？我想这取决于那里有多少逻辑,但是什么时候太多了？有没有办法量化什么时候你可以激励重构为两个视图？

根据UML上下文 关系图不存在上下文关系图.
所以我的问题是哪一个UML图表能够很好地展示这样的东西以及如何绘制它？

如果我有一个旨在用于视图目的的Viewmodel -

向viewmodel添加一堆静态方法是一个好习惯 - 通过使用db中的数据获取项目列表(viewmodel对象)？ - 使用viewmodel中的属性更新数据库？

我正在使用.NET MVC,感觉我的viewmodels混乱了大量的静态函数和更新方法.

为视图创建viewmodel背后的主要原因是因为视图开始包含许多功能,因此必须从所有地方获取信息.因此,我决定创建一个viewmodel,通过一次调用从一个地方获取信息.

我在这里遵循一个好的编码模式吗？还是我在黑暗中拍摄？

有这个代码库,我们使用automapper并有2层,Domain和Service.每个都有它的数据表示对象,DomainItem和ServiceItem.服务从域获取数据,使用构造函数注入的automapper实例进行映射

class Service 
{
  public ServiceItem Get(int id)
  {
    var domainItem = this.domain.Get(id);
    return this.mapper.Map<DomainItem, ServiceItem>(domainItem);
  }
}

假设最佳实践,因此mapper没有副作用,也没有外部依赖.您将编写一个静态函数,在几秒钟内将一个对象转换为另一个对象,只是映射字段.

考虑到这一点,在这样的单元测试中模拟映射器是一个好习惯吗？

[TestClass]
class UnitTests
{
  [TestMethod]
  public void Test()
  {
    var expected = new ServiceItem();

    var mockDomain = new Mock<IDomain>();
    // ... setup
    var mockMapper = new Mock<IMapper>();
    mockMapper.Setup(x => x.Map<DomainItem, ServiceItem>(It.IsAny<DomainItem>()))
      .Returns(expected);


    var service = new Service(mockDomain.Object, mockMapper.Object);
    var result = service.Get(0);

    Assert.AreEqual(expected, result);
  }
}

对我来说,似乎这样的单元测试并没有真正带来任何价值,因为它只是有效地测试了模拟,所以我要么根本不要写它或者我要使用实际的映射器,而不是模拟的映射器.我是对的还是我忽略了什么？

srand()/rand()第三方库中有大量使用预定义种子的呼叫.在同一过程中组合不同的库时会出现问题.有时很难确保正确的呼叫顺序,混合srand()和rand()呼叫是可能的.另一个问题是无法在应用程序级别选择播种值.作为一般规则,我们是否应该避免srand()在库中使用(包括开源),将播种任务留给应用程序？