Questions tagged «design-patterns»

这些方面已经有了一个相当有用的问题（“ 非OOP设计模式？ ”），但是我对于刚开始使用动态和弱类型语言的人的过渡观点感到更加好奇。 那就是：假设我已经使用C ++，C＃或Java进行编程多年，并从GoF设计模式，Fowler 企业应用程序体系结构模式，SOLID原理等方面吸取了很多智慧。 m涉猎Ruby，Python，JavaScript等，并想知道我的知识如何应用。大概在很多情况下我都可以进行直接翻译，但是几乎可以肯定的是，这并不能充分利用我的新设置。仅仅靠鸭子打字就可以改变我很多基于界面的思想。 什么保持不变？有什么变化？是否有新手应该知道的诸如SOLID之类的指导原则或动态语言新手应该知道的规范模式（也许是全新的）？

11 design-patterns  object-oriented  dynamic-typing  solid  weak-typing 

我最近开始研究设计模式，除了一点点不同之外，我正在编写的一件事将完全适合于战略模式。 本质上，我的某些（但不是全部）算法需要一个或两个额外的参数传递给它们。 所以我要么需要 当我调用他们的calculate方法时，给他们传递一个额外的参数 要么 将它们存储为ConcreteAlgorithm类中的变量，并能够在调用算法之前对其进行更新。 有满足这种需求的设计模式吗？在坚持策略模式的同时如何实现？ 我考虑过将客户端对象传递给所有算法，并将变量存储在其中，然后仅在特定算法需要时才使用该对象。但是，我认为这既笨拙，又打败了战略模式的意义。 为了清楚起见，我正在用Java实现，因此没有太多的可选参数（可以很好地解决此问题）。

11 java  design-patterns  interfaces  strategy 

在构造函数上使用静态对象创建方法的利弊是什么？ class Foo { private Foo(object arg) { } public static Foo Create(object arg) { if (!ValidateParam(arg)) { return null; } return new Foo(arg); } } 我能想到的很少： 优点： 返回null而不是引发异常（将其命名为TryCreate）。这可以使客户端的代码更简洁明了。客户很少期望构造函数失败。 创建具有清晰语义的不同种类的对象，例如CreatFromName(String name)和CreateFromCsvLine(String csvLine) 必要时可以返回缓存的对象或派生的实现。 缺点： 较少发现，更难以浏览代码。 某些模式（例如序列化或反射）更加困难（例如Activator<Foo>.CreateInstance()）

11 design-patterns 

我们依赖于第三方服务，该服务公开了一个巨大的接口，我们只需要像3种方法。此外，界面经常更改... 我决定将接口包装在我们项目的一个类中，只公开我们需要的方法。 但是我不确定如何处理返回值...接口返回类型为的对象Storage。我们内部有一个类型StorageModel，它是a的内部表示形式Storage。 您将在映射器中返回什么：Storage或StorageModel？我们有一个DataService StorageService，它获得了注入的包装的依赖关系。 目前，我基本上是这样的： public class StorageService { private readonly IExternalStorageWrapper externalStorageWrapper; public StorageService(IExternalStorageWrapper externalStorageWrapper) { this.externalStorageWrapper = externalStorageWrapper; } public StorageModel GetStorage(int storageId) { return this.externalStorageWrapper.GetStorage(storageId).ConvertToStorageModel(); } } public class ExternalStorageWrapper : IExternalStorageWrapper { public Storage GetStorage(int storageId) { using(var ext = new ExternalStorage()) { return ext.GetStorage(storageId); …

11 c#  design-patterns  programming-practices  code-reviews  wrapper 

场景： 堆栈：Java，Spring，Hibernate。 型号：客户端-服务器应用程序。 模式：模型-视图-控制器（MVC）。 服务层类具有三种行为： 一些服务在方法内具有业务规则，并将持久性委托给应用程序。喜欢： EntityManager.save（entity）; 一些服务只是调用数据库函数（传递参数），例如： CallableStatement cls = con.prepareCall（“ {call databaseFunction（args）}”）; 某些服务同时具有两种行为的方法。 我的问题： 让应用程序服务直接调用数据库功能有什么问题吗？这不是不好的做法吗？适用于这样的项目的架构模型是什么？ 在同一服务中混合行为是否有问题？如交易和一致性？ 在维护的情况下，这种封装是否使开发人员不清楚他也应该更改数据库中的功能？如何避免这种情况？ 这种情况是否会在世界各地的其他应用程序中发生，或者仅仅是架构错误？

11 design-patterns  architecture  mvc  code-quality 

在网络上的许多文章中，术语“控制反转”和“依赖反转原则”似乎混为一谈并用作同义词（进一步的混乱由称为“ DI-Containers”和“ IoC-Containers”的工具所强加）。Wikipedia的一篇文章很好地解释了IoC与DI不同： 控制反转（IoC）描述了一种设计，其中计算机程序的自定义编写部分从通用的可重用库接收控制流 因此，DIP是关于让模块依赖于抽象而不是具体的实现。 而IoC则是将程序流的控制权交给一个单独的模块。您可以让此模块执行的操作之一是在运行时解析依赖关系。 这种差异看起来确实很公平，但是我从未见过有人提到过IoC原理的任何其他应用程序，除了依赖关系解析之外。Wikipedia的定义非常广泛，似乎您可以使用一个模块进行更多的工作，该模块可以根据其配置和一些内部逻辑调用自定义代码。 因此，这里有一些我还无法弄清楚的问题： IoC和DIP之间的实际关系是什么？IoC始终是实现DIP的手段吗？ 为什么将依赖关系解决工具称为DI容器和IoC容器？这意味着DI和IoC是同一件事。 注意：这个问题不是DI和IoC有什么区别的重复，因为后者询问的是依赖注入，而不是依赖反转。

11 design-patterns  inversion-of-control  dependency-inversion 

我有一个类：A这是一个综合了一些更小的类，的B，C和D。 B，C和D实现接口IB，IC和ID分别。 由于A支持的所有功能B，C并且D，A器具IB，IC并ID为好，但不幸的是这导致了大量的重路由在执行A 像这样： interface IB { int Foo {get;} } public class B : IB { public int Foo {get {return 5;}} } interface IC { void Bar(); } public class C : IC { public void Bar() { } } interface ID { string Bash{get; set;} } public …

11 c#  design-patterns  patterns-and-practices  composition 

在为中型MVC Web应用程序规划体系结构时，如何实现这些层尽可能地分离和易于测试？（基本上遵循最佳实践）假设我首先使用代码作为数据访问权限。 我为定义“业务逻辑”的定义以及与数据层交互的方式感到困惑。以车辆销售应用程序为例，业务逻辑是否是执行诸如计算给定车辆的税阶，比较每加仑英里数统计信息之类的任务的类？至于业务实体（例如汽车，货车，摩托车），我会将它们与DataContext班级一起放在数据层中。 还有什么会构成与业务相对的应用程序逻辑-我正在猜测会话/用户输入验证之类的东西？ 因此，例如，汽车管理员可能会返回一个操作/查看结果，其中列出了按类型和最佳mpg过滤的前十名汽车。假设我有一个ICarRepository“ carRepo”注入到我的控制器中（使用存储库模式/ DI），我从一个动作方法参数中过滤了我的汽车var cars = carRepo.getCarsByType("hatchback"); 因此，我已使用存储库将数据访问知识排除在控制器之外，现在使用域模型将业务逻辑排除在控制器之外-var result = new MpgCalculator（cars）; -假设我需要计算器类，因为它需要执行其他逻辑以计算最佳燃油效率，而不仅仅是从数据库中加载/过滤实体。因此，现在我有了一个供呈现的视图数据集，该数据集使用存储库从数据访问层检索，并且使用特定于域的对象来处理和执行与数据相关的业务相关任务。 我在这里犯错吗？我们仍然需要使用存储库模式吗？或者我可以只对接口进行编码以解耦ORM和进行测试吗？关于这个主题，因为我的具体数据访问类dbcontext在数据层中，所以接口定义是否应该进入域/业务层，这意味着如果数据访问技术发生了变化，我的其他层是否会受到影响？ 根据到目前为止的研究，我的结构如下所示： MVC Internet应用程序 ->标准Internet项目-这里的模型是ViewModels 域/业务层 ->特定于业务的类/模型，控制器可以使用这些类/模型来处理数据层中的域实体，然后再传递到相关视图 存储库抽象有必要吗？->我听到很多关于此的辩论，尤其是在使用ORM时 数据层 ->实体类（汽车，货车，摩托车），DbContext-具体数据访问技术层

11 design-patterns  mvc  asp.net-mvc  repository  n-tier 

人们简单地检查班级是否违反单一责任原则的实用技术是什么？ 我知道一个班级应该只有一个改变的理由，但是那句话在某种程度上缺乏真正实现这一改变的实用方法。 我发现的唯一方法是使用句子“……本身应该……”。其中第一个空格是类名称，第二个空格是方法（职责）名称。 但是，有时很难确定责任是否确实违反了SRP。 还有更多检查SRP的方法吗？ 注意： 问题不在于SRP意味着什么，而是关于检查和实施SRP的实用方法或一系列步骤。 更新 我添加了一个明显违反SRP的示例类。如果人们可以以此为例来说明他们如何遵循单一责任原则，那将是很好的。 这个例子是从这里开始的。

11 design  design-patterns  object-oriented  refactoring  single-responsibility 

首先，我知道这个问题与游戏开发主题相关，但是我决定在这里提出这个问题，因为它实际上归结为一个更一般的软件工程问题。 在过去的一个月中，我阅读了很多有关实体组件系统的信息，现在对这个概念相当满意。但是，似乎有一个方面似乎缺少明确的“定义”，并且不同的文章提出了根本不同的解决方案： 这是ECS是否应该破坏封装的问题。换句话说，其OOP风格的ECS（组件是具有状态和行为的对象，它们封装了特定于它们的数据）与纯ECS（组件是c样式的结构，仅具有公共数据，并且系统提供了功能）。 请注意，我正在开发框架/ API /引擎。因此，目标是无论使用它的人都可以轻松扩展它。这包括添加新类型的渲染或碰撞组件之类的东西。 OOP方法的问题 组件必须访问其他组件的数据。例如，渲染组件的draw方法必须访问变换组件的位置。这将在代码中创建依赖项。 组件可以是多态的，这进一步引入了一些复杂性。例如，可能有一个Sprite渲染组件，它会覆盖渲染组件的虚拟绘制方法。 纯方法的问题 由于必须在某个地方实现多态行为（例如，用于渲染），因此它只是外包给了系统。（例如，精灵渲染系统创建一个继承渲染节点的精灵渲染节点，并将其添加到渲染引擎中） 系统之间的通信可能很难避免。例如，碰撞系统可能需要根据任何具体的渲染组件计算出的边界框。这可以通过让他们通过数据进行通信来解决。但是，这会删除即时更新，因为渲染系统将更新边界框组件，然后碰撞系统将使用它。如果未定义调用系统更新功能的顺序，则可能导致问题。存在一个事件系统，该事件系统允许系统引发其他系统可以订阅其处理程序的事件。但是，这仅适用于告诉系统该怎么做，即无效函数。 还需要其他标志。以图块地图组件为例。它将具有大小，图块大小和索引列表字段。瓦片贴图系统将处理相应的顶点数组，并根据组件的数据分配纹理坐标。然而，每帧重新计算整个图块地图是昂贵的。因此，将需要一个列表来跟踪所有更改，然后在系统中对其进行更新。以OOP方式，这可以由图块地图组件封装。例如，SetTile（）方法将在调用顶点数组时对其进行更新。 尽管我看到了纯方法的美妙之处，但我真的不明白与传统OOP相比它将带来什么样的具体好处。组件之间的依赖性仍然存在，尽管被系统隐藏了。同样，我将需要更多的类来实现相同的目标。在我看来，这似乎是一种过度设计的解决方案，但这从来都不是一件好事。 此外，我对性能的关注并不那么深，所以面向数据设计和现金遗漏的整个想法对我来说并不重要。我只想要一个好的架构^^ 尽管如此，我阅读的大多数文章和讨论都建议使用第二种方法。为什么？ 动画 最后，我想问一个问题：如何在纯ECS中处理动画。目前，我已将动画定义为根据0到1之间的进度操纵实体的函子。动画组件具有一个动画列表，该列表包含一个动画列表。然后，在其更新功能中，它将当前激活的任何动画应用于实体。 注意： 我刚刚读了这篇文章实体组件系统体系结构对象是否按定义导向？可以比我更好地解释问题。尽管基本上是同一主题，但对于纯数据方法为何更好，仍然没有给出任何答案。

11 design-patterns  object-oriented  game-development  entity-component-system 

我目前是我当前项目的独立开发人员。我从另一个离开公司的开发商那里继承了这个项目。它是C＃中的模型视图控制器样式的Web应用程序。它使用实体框架进行对象关系映射。域模型中的类型有两组不同的类。一组用于与ORM进行交互，另一组用作MVC系统中的模型。例如，可能有两个类别，如下所示： public class Order{ int ID{get;set;} String Customer{get;set;} DateTime DeliveryDate{get;set;} String Description{get;set;} } 和 public class OrderModel{ String Customer{get;set;} DateTime DeliveryDate{get;set;} String Description{get;set;} public OrderModel( Order from){ this.Customer= from.Customer; // copy all the properties over individually } public Order ToOrder(){ Order result =new Order(); result.Customer = this.Customer; // copy all …

11 design-patterns  database  object-oriented-design 

我正在开发一个应用程序，该应用程序的模块按顺序执行以下财务操作： 当用户要求将一定金额转入她的银行帐户时： 检查现在是否可以进行任何交易？（交易只能在特定时间段内进行） 检查用户是否已要求提取最低金额 检查用户是否具有任何默认帐户 以上所有操作的结果均应记录。 如果满足以上所有条件，则执行交易。将来可能还会有其他检查。 哪种面向对象设计模式最适合上述情况？

11 design-patterns  object-oriented-design 

考虑一个负责解析任何给定类型文件的模块。我已经在这里进行了解释，我正在考虑使用策略模式来解决此问题。在继续此问题之前，请参阅链接的帖子。 考虑需要product.xml文件内容的类B。此类将需要实例化Parser接口的适当具体实现程序以解析XML文件。我可以将适当的具体实现者的实例委派给Factory，以使B类“拥有” Factory。但是，类B随后将“依赖”于工厂以实例化具体的实现者。这意味着将需要将类B中的构造函数或setter方法传递给Factory。 因此，需要解析文件的Factory和B类将紧密地结合在一起。我了解到目前为止，我所解释的内容可能完全错误。我想知道是否可以在要注入的依赖项是Factory的情况下使用依赖项注入，以及实现此目标的正确方法是什么，以便在单元测试中利用诸如模拟Factory的优势。

10 java  design-patterns  dependency-injection 

我正在阅读《程序员在工作》，Brendan Eich引用了Norvig在Harlequin时发表的一篇论文，“关于设计模式实际上只是编程语言中的缺陷”。 任何人都可以提供本文的链接吗？

10 design-patterns  articles 

我有以下代码： public void moveCameraTo(Location location){ moveCameraTo(location.getLatitude(), location.getLongitude()); } public void moveCameraTo(double latitude, double longitude){ LatLng latLng = new LatLng(latitude, longitude); moveCameraTo(latLng); } public void moveCameraTo(LatLng latLng){ GoogleMap googleMap = getGoogleMap(); cameraUpdate = CameraUpdateFactory.newLatLngZoom(latLng, INITIAL_MAP_ZOOM_LEVEL); googleMap.moveCamera(cameraUpdate); } 我认为通过这种方式，例如，我消除了了解LatLng另一门课中的内容的责任。 而且，您无需在调用函数之前准备数据。 你怎么看？ 这种方法有名称吗？真的是不好的做法吗？

10 design  design-patterns  clean-code  code-smell  bad-code