Questions tagged «design»

在使用HATEOAS约束构建REST服务时，通过链接宣传存在的资源非常容易。您GET以我的网站的根目录为基础，然后我以列出所有第一层资源的根目录文档进行响应： { users: { href: "/users" } questions { href: "/questions" } } 了解如何读取这些href值的客户端可以对这些值执行GET请求，并发现应用程序中所有可用的当前资源。 这对于基本的查找方案非常有效，但不能指示资源是否可查询。例如，执行以下操作可能是合理的： GET /users?surname=Smith 是否有任何格式可以用足够的信息来表达此查询功能，以使客户端无需事先了解资源就可以形成连贯的查询？ 另外，有什么方法可以表示允许客户端POST对具有预期位置的给定位置执行操作。例如，可以期望客户执行以下操作来创建新的问题资源： POST /questions { title: "Are there strategies for discovering REST services using HATEOAS?", body: "When building a REST service with the HATEOAS constraint, it's very..." } 当使用HTML作为人类消费的格式时，我们可以通过使用表格和书面提示来表达很多这种形式，以使人们能够发现他们被允许对服务执行的操作。 是否有能够为客户提供类似功能的格式？

10 design  rest  hateoas 

我即将参加考试，并且正在查看过去的论文，以期获得一些期望的想法。我对以下内容有些困惑，如果有人可以给出示例答案，我将不胜感激。 在OCL中为以下每个操作（包括在java.util包的Stack类中）写入前置条件和后置条件： （1）布尔型empty（）-测试此堆栈是否为空 （2）E peek（）-在不从堆栈中移除的情况下，查看此堆栈顶部的对象 （3）E pop（）-删除此堆栈顶部的对象，并将该对象作为此操作的值返回 （4）E push（E item）-将一个项目推到此堆栈的顶部 这里E表示堆栈中元素的类型。 我的尝试如下： Boolean empty() pre: none post: self -> IsEmpty() = true //should this be result -> IsEmpty() = true because it returns a boolean value? E peek() pre: self -> NotEmpty() = true post: result = ??? // I …

10 design  languages  object  ocl 

我们的团队进行了以下讨论： 假设我们有以下两种方法： public Response Withdraw(int clubId, int terminalId,int cardId, string invoice, decimal amount); public Response Withdraw(Club club, Terminal terminal,Card card, string invoice, decimal amount); 通过有线方式发送的只是ID。 一方说第一种方法是正确的，因为我们只有终端和俱乐部的ID，并且应该清楚我们别无其他，这是我的方法。 另一边说第二种方法是正确的，因为它更灵活。 我们熟悉对象参数的想法，另一边也认为对象参数应该具有对象作为属性。 哪种方法正确？ 也许还有第三种更好的方法？

10 design  methods 

我正在寻找一个标签来描述使用基于人的计算方法或其他“伪造”算法手段的实践，以便快速推出产品或演示而无需花费时间来开发技术/可扩展/解析解决方案？例如：使用Amazon Turk来计算一家餐厅中空桌子的数量。 我也希望了解有关此主题的更多信息，但不确定要搜索什么。基于人的计算只是一种方法，我对伪实现的一般概念感兴趣。有什么想法，建议阅读？

10 design  programming-practices  concepts  pseudocode 

我目前正在两种可行的软件设计/解决方案之间进行选择。解决方案1易于实现，但会以专有格式锁定某些数据，以后将很难更改。解决方案2难以实现，但以后将更容易更改。 我应该选择YAGNI还是应该将退出成本纳入决策？还是换个角度问，退出成本是TCO的一部分吗？ 我正在考虑再回头问客户，他是否认为退出成本是相关的，但我想知道社区首先想到的是什么。 PS退出成本是否正确？

10 design  architecture  terminology  decisions 

如果我的代码中有一个像这样的函数： class Employee{ public string calculateTax(string name, int salary) { switch (name) { case "Chris": doSomething($salary); case "David": doSomethingDifferent($salary); case "Scott": doOtherThing($salary); } } 通常，我会使用工厂类和策略模式将其重构为使用多态性： public string calculateTax(string name) { InameHandler nameHandler = NameHandlerFactory::getHandler(name); nameHandler->calculateTax($salary); } 现在，如果我正在使用TDD，那么calculateTax()在重构之前，我将对原始版本进行一些测试。 例如： calculateTax_givenChrisSalaryBelowThreshold_Expect111(){} calculateTax_givenChrisSalaryAboveThreshold_Expect111(){} calculateTax_givenDavidSalaryBelowThreshold_Expect222(){} calculateTax_givenDavidSalaryAboveThreshold_Expect222(){} calculateTax_givenScottSalaryBelowThreshold_Expect333(){} calculateTax_givenScottSalaryAboveThreshold_Expect333(){} 重构后，我将具有Factory类NameHandlerFactory和的至少3个实现InameHandler。 我应该如何重构我的测试？我应该claculateTax()从中删除单元测试，EmployeeTests并为的每个实现创建一个Test类InameHandler吗？ 我也应该测试工厂课程吗？

10 design  design-patterns  unit-testing  tdd  refactoring 

现在，我在编码中正在尝试DRY（不要重复自己）这个概念。我正在创建此函数，但我担心它变得太复杂了，但我尝试遵循DRY原理。 createTrajectoryFromPoint(A a,B b,C c,boolean doesSomething,boolean doesSomething2) 我说过的这个函数需要3个输入参数，然后在给定布尔组合doesSomething和的情况下，该函数会做一些稍有不同的事情doesSomething2。但是我遇到的问题是，随着每个新的布尔参数的添加，此函数的复杂性大大增加。 所以我的问题是，最好是让一堆不同的函数共享很多相同的逻辑（从而违反DRY原理），或者让一个函数在给定多个参数的情况下表现稍有不同，但使其复杂得多（但是保存DRY）？

10 java  design  dry 

大多数时候，当我编写一些代码来处理某个函数调用的响应时，我会得到以下代码结构： 示例：此功能将处理登录系统的身份验证 class Authentication{ function login(){ //This function is called from my Controller $result=$this->authenticate($username,$password); if($result=='wrong password'){ //increase the login trials counter //send mail to admin //store visitor ip }else if($result=='wrong username'){ //increase the login trials counter //do other stuff }else if($result=='login trials exceeded') //do some stuff }else if($result=='banned ip'){ //do …

10 design  php  design-patterns  object-oriented  clean-code 

问题 我正在一个Python项目中，该项目的主类有点“ God Object ”。有这么受诅咒的多属性和方法！ 我想重构班级。 至今… 第一步，我想做一些相对简单的事情。但是当我尝试最直接的方法时，它破坏了一些测试和现有示例。 基本上，该类具有大量的属性列表，但是我可以清楚地查看它们，并认为：“这5个属性是相关的……这8个属性也都是相关的……剩下的就是这些。” getattr 我基本上只是想将相关属性分组为类似dict的帮助器类。我有种__getattr__理想的工作选择。因此，我将属性移到了一个单独的类，并且确实可以__getattr__很好地发挥其魔力…… 一开始。 但是后来我尝试运行其中一个示例。示例子类尝试直接设置这些属性之一（在类级别）。但是由于该属性不再在父类中“物理定位”，所以我收到一个错误消息，指出该属性不存在。 @属性 然后，我阅读了有关@property装饰器的信息。但是后来我也读到，self.x = blah当x父类的属性是子类时，它会给想要做的子类带来问题。 期望的 self.whatever即使父类的whatever属性不在类（或实例）本身的“实体位置” ，也要让所有客户端代码继续使用。 将相关属性分组到类似dict的容器中。 减少主类中代码的极端噪音。 例如，我不只是想更改此内容： larry = 2 curly = 'abcd' moe = self.doh() 变成这个： larry = something_else('larry') curly = something_else('curly') moe = yet_another_thing.moe() …因为那仍然很吵。尽管这成功地将简单的属性赋予可以管理数据的属性，但是原始属性具有3个变量，而经过调整的版本仍具有3个变量。 但是，我可以这样： stooges = Stooges() 如果查找self.larry失败，将检查stooges并查看是否larry存在。（但是，如果子类尝试larry = 'blah'在类级别执行此操作，那么它也必须起作用。） …

10 design  python  refactoring 

鉴于对API /公共方法签名的更改应尽可能少，以防止破坏使用这些方法的客户端代码，我想知道Demeter法则是否不适用于这些方法。 一个简单的例子： class Account() { double balance; public void debit(Transaction t) { balance -= t.getAmount(); } } 请注意，借记方法传递的是交易对象，而不是仅仅两倍的金额（据我所知，``德米特尔法则''会说只传递所需的信息，在这种情况下，只是传递金额，而不是交易对象... ）。其背后的原因是因为将来该方法可能需要除数量之外的其他一些交易属性。据我了解，这将防止将来通过添加新参数来破坏方法签名。 那么，这是否使之成为明智的选择？还是我错过了什么？

10 design  api-design 

我“发现”了界面，并开始喜欢它们。接口的优点在于它是一个契约，任何需要履行该契约的对象都可以在需要该接口的任何地方使用。 接口的问题是它不能具有默认实现，这对于平凡的属性是一种痛苦，并且会破坏DRY。这也很好，因为它可以使实现与系统保持分离。一方面，继承会保持更紧密的耦合，并且有可能破坏封装。 案例1（与私有成员的继承，良好的封装，紧密耦合） class Employee { int money_earned; string name; public: void do_work(){money_earned++;}; string get_name(return name;); }; class Nurse : public Employee: { public: void do_work(/*do work. Oops, can't update money_earned. Unaware I have to call superclass' do_work()*/); }; void HireNurse(Nurse *n) { nurse->do_work(); ) 情况2（只是一个接口） class IEmployee { virtual …

10 c++  design  interfaces  class-design  inheritance 

我对如何从能够编写脚本（bash，awk）和编写简单的应用程序（c，php，python）到设计和开发更大，更复杂的软件缺乏具体的解释感到沮丧。似乎一方面有编程语言书籍，另一方面有专为程序员团队设计的软件工程/项目管理书籍。 我都读过很多。我已经阅读过XP / Agile经典著作，并对软件开发过程有不错的理论理解。我喜欢阅读别人的代码，可以很好地遵循它。但是，当我对一个项目有一个想法或想从“问题/需求在这里”到“解决方案在这里”时，我的脑子一片空白，我不知道从哪里开始。 我只是破解吗？对于没有团队合作或大型软件公司的个人开发人员，是否有任何结构化的工作流程？我真的不希望获得PMP或在软件公司工作。我只是在寻找有效，高效，实用的工作流程。

10 design  code-quality 

如果将新的配置选项添加到程序，则在将选项带到需要对其执行操作的位置时，它通常会产生大量涟漪效应。我知道有三种基本的处理方法： 将所有配置设置传递给程序中明确需要它们作为原语的部分。这是最明确的方式，也是最能使事物解耦的方式。缺点是这既冗长又脆弱。 将最常用的配置设置设为全局/静态。这是最简单的方法，但是会引入一定距离的操作，阻碍了可测试性，并假定该配置确实是全局的（您在任何给定时间只需要一个配置）。 创建一个包含整个程序或程序中每个主要问题的所有配置选项的配置类/结构，然后将其显式传递。它不如（1）明确，但比（2）更明确。如果只想更改一个函数调用的设置，则可以克隆config对象并更改该值。这在测试和实践中都是有用的。但是，您仍然可能最终将大量信息传递给它不需要的功能，并且更改config类/结构中的值仍会导致一定距离的操作。 您会考虑（3）模式还是反模式？如果是反模式，您该怎么办？

10 design  testing  configuration  object 

尽管我可以编写代码，但是我还没有从事大型项目的经验。到目前为止，我所做的是要么编写可以在几秒钟内完成编译的小程序（各种c / c ++练习，例如算法，编程原理，思想，范例，或者只是尝试api ...），要么在一些较小的项目上工作使用无需编译的脚本语言（Python，PHP，JS）制作。 问题是，当使用脚本语言进行编码时，每当我想尝试某些可行的方法时，我只要运行脚本，看看会发生什么。如果事情不起作用，我可以简单地更改代码，然后再次运行脚本来再次尝试，然后继续进行直到获得所需的结果。.我的意思是，您不必等待可以编译任何东西，因此，使用大型代码库，对其进行修改，对其进行添加或只是简单地使用它都是非常容易的-您可以立即看到所做的更改。 作为示例，我将使用Wordpress。尝试弄清楚如何为其创建插件非常容易。首先，您首先创建一个简单的“ Hello World”插件，然后为管理面板创建一个简单的界面以熟悉API，然后对其进行构建并使其变得更复杂，同时更改其外观。在每次较小的更改后尝试“如果它有用”和“它如何工作/感觉”之后，必须一遍又一遍地重新编译WP之类的东西的想法似乎效率低下，缓慢而错误。 现在，我该如何使用以编译语言编写的项目来做到这一点？我想为一些开源项目做出贡献，这个问题一直困扰着我。情况因项目而异，其中一些事先被明智考虑的项目将以某种方式“模块化”，而另一些只是一个大问题，需要一次又一次地重新编译。 我想了解更多有关如何正确完成的信息。有哪些通用实践，方法和项目设计（模式？）来应对？在程序员世界中如何称呼这种“模块化”？我应该在Google上寻求更多信息以了解更多信息吗？项目是否经常超出了最初的想法范围，这在一段时间后变得很麻烦？有什么方法可以避免长时间编译设计欠佳的项目？一种以某种方式模块化它们的方法（也许在开发时排除了程序的非重要部分（还有其他想法？））？ 谢谢。

10 design  productivity  build-system 

不久前，我们的任务是进入一个项目，并使用SQL Server作为后端，用新的Intranet ASP.NET解决方案替换客户的旧Mainframe系统。部分原因还在于业务的重新设计-本质上，随着我们更换系统，我们正在考虑如何更好地开展业务。 因此，第一个任务是进入并执行逻辑和物理数据模型。客户参与了这些讨论，并已完成签收。下一阶段是实际进行每个模块的设计和构建。好了，总而言之，编程已经完成，我们现在正在对该系统进行并行测试。到目前为止，对于大多数模块来说，一切都进行得很顺利-除了一个。 我们拥有一个系统-如果您仅让业务用户查看应用程序和报告，一切都会很好。它与新的集成工作流程一起使用，可以自动执行以前的手动流程，并且可以按规格执行。并行测试发现了与迁移的旧数据有关的一些问题。遗留系统的构建者很难理解新的架构和业务流程，因此，他们很难理解如何获取遗留数据并将其放入新的架构。因此，他们召集业务用户和利益相关者开会，并告诉他们新系统没有提供旧系统所做的数据（实际上确实如此），这确实使新系统看起来很糟。 至少可以这样说，这令人沮丧。新系统运行良好，可提供他们需要和想要的一切，如果不是由于IT员工无法用旧数据填写新表，则业务用户将对新特性感到满意。 我正在寻求有关如何处理此问题的建议。由于采取了一些政治措施，新的“架构师”对系统的工作原理一无所知，并且无法完全理解IT员工要求的变更的后果。IT员工希望对系统进行一些根本性的更改，这些根本上不必要的更改实际上是一个糟糕的设计-但他们是客户。 有什么想法吗？

10 design  customer-relations  acceptance-testing