标签: anti-patterns

我是唯一一个有时采取看似简单但错误的方式摆脱某些设计情况的人吗？我承认我已经分享了可疑的Singleton对象.除此之外,我已经知道要制造一两个上帝的对象以使事情看起来更容易.

即使你知道你不应该使用反模式吗？

在相当大的Ruby应用程序中,我们有一种情况,即给定的对象由几个东西识别:name和id,比如说.这些值类型中的每一个都有不同的用途,因此不完全等效(id和name在不同的地方持续存在).因此,我们将围绕应用程序传递各种值(ID,名称和对象).这种情况至少在某种程度上似乎是一个问题,因为我们已经被错误所困扰,这些错误涉及不清楚应该将哪种类型传递给给定的函数.我实际上回想起多年来在许多应用程序中看到类似的问题代码,尽管我再也没有给出具体的名称.

Ruby作为一种无类型语言,不像C++那样允许基于类型的经典多态函数.作为一种解决方案,一位同事经常采用这种代码:

  def initialize starting_value
    if starting_post.kindof? Foo
      @starting_id = get_id_from_foo starting_value
    elsif starting_post.kindof? Bar
      @starting_id = get_id_from_bar starting_value
    else
      raise "illegal type"
    end
  end

围绕我们的代码库(不仅仅是初始化器)的代码的增加导致我称之为"凌乱多态".它经常有效但有时会产生非常令人费解的情况.

我有三个问题.

• 作为反模式,这是否有正式的名称？"凌乱的界面？","凌乱的多态？" 或者是其他东西？
• 人们认为这有多糟糕？
• 有没有系统的方法来重构这个？我们在普通重构中遇到的挑战是我们创建的许多测试都使用这种松散类型,因此我们必须同时更改测试和实现,因此不会产生普通的基于测试的重构的支架效应.我认为实际上可以"加强"这种松散的多态性,并将代码抽象为函数而不是立即将其删除.但这是个好主意吗？

我常常发现自己构建了带字符串操作的选择器(split,search,replace,concat,+,join).

是好是坏？

我已经听过并阅读了许多关于设计模式,编码风格,编程技术等的材料......但很少阅读反模式材料.我认为阅读这些材料可以以"消极"的方式吸取教训,这对编程新手以避免常见错误具有重要意义.事实上,不仅是新手,还有一些经验丰富的程序员仍在编写可怕的代码.

所以,我想知道有关这个主题的任何材料,请在此留下您的建议,谢谢!

我已经构建了一个小的静态对象,用于将泛型类型保存到WP7上的独立存储.这适用于较旧的项目,但有些新项目使用DI来管理配置.我是DI的粉丝,因为这意味着我可以在一个地方更改配置并将其过滤到所有依赖项.

我的想法是创建一个名为Injection的命名空间,并将该对象包装在一个带有接口的实例中,以便我可以将其注入.它还使我能够为需要更具体实现的存储处理程序换出存储处理程序.

这是常见做法还是反模式？

作为一个注释,我想保持静态选项不是每个人都需要或可以使用DI.我只是尝试以最少的重复次数启用它们.

假设我有一个对象,Car,它有各种方法......不同？也许像Blob一样？(如反模式中的"blob")这些方法在不同的集合中运行,并且在功能上并不真正纵横交错.

Car
# methods related to suburban driving
  ->foo1
  ->foo2
# methods related city driving
  ->bar3
  ->bar4

现在让我们说我想添加"越野驾驶"作为我的汽车对象可以支持的案例之一.如果我向Car对象添加方法,是不是让它更像blob？

Car (augmented)
# methods related to suburban driving
  ->foo1
  ->foo2
# methods related city driving
  ->bar3
  ->bar4
# methods related off road driving
  ->blah5
  ->blah6

我是不是该:

答:汽车的子类.我可以制作一个OffRoadCar扩展Car对象.但是如果Car和OffRoadCar共享相同的数据/状态,并且只是方法不同呢？OffRoadCar只比汽车更具体"行动",但不再具体描述,也没有独特的领域.因此实例化OffRoadCar毫无意义.

OffRoadCar extends Car
# methods related off road driving
  ->blah5
  ->blah6

B:使用静态方法消耗汽车.喜欢OffRoadAdventure-> Embark(Car).所以OffRoadAdventure类接受一个Car对象并使用它.

在C#中,这将被称为扩展方法.

我想换另一种方式是什么是Blob反模式的解决方案？是子类吗？是扩展方法吗？

另外,我想要解决这些方法的另一个原因是,如果它们的实现会产生一些成本,比如包含其他类/包？我不希望核心类的用户经常为他们永远不会使用的东西买单.我认为让少数人明白成本对大多数人来说是值得的.它使依赖图更精确(而不是像blob一样).

PS - 实现语言是Perl.

如果我查询一个对象说一个动物,并且返回的对象不是null但是包含空变量是错误的吗？比如我可以打电话animal.getDeathDate(); 因为它还没死,但它返回null.因为Turtle getFlightSpeed()会返回null,因为它在添加了Turtle火箭包之前无法飞行.等等

我认为这是一种糟糕的做事方式,因为在调用对象的方法以验证它们包含非空值时,通常会导致需要大量的空检查.是否有任何关于此信息的链接可以进一步告知我和我的同事？

我知道该参数根据/ res/xml中的规范updatePeriodMillis确定应用程序widget更新的频率widgetproviderinfo.xml

<?xml version="1.0" encoding="utf-8"?>
<appwidget-provider xmlns:android="http://schemas.android.com/apk/res/android"
    android:configure="com.example.appwidget.ConfigurationActivity"
    android:initialLayout="@layout/layout_appwidget_large"
    android:minHeight="115dp"
    android:minWidth="250dp"
    android:updatePeriodMillis="1800000" ><!-- 30mins -->
</appwidget-provider>

这种方法的缺点在于,widget如果电话正在睡眠,则通过以指定的间隔唤醒电话来更新电话.所以问题是关于电池消耗,如果间隔非常小,这是一个主要问题.

但是,如果您需要更频繁地更新和/或在设备处于睡眠状态时不需要更新,则可以根据不会唤醒设备的警报执行更新.为此Intent,请AppWidgetProvider使用以下命令设置您收到的警报AlarmManager.将警报类型设置为ELAPSED_REALTIME或RTC,它仅在设备唤醒时发出警报.然后设置updatePeriodMillis为零("0").代码看起来像这样:

final Intent intent = new Intent(context, UpdateService.class);
final PendingIntent pending = PendingIntent.getService(context, 0, intent, 0);
final AlarmManager alarm = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
alarm.cancel(pending);
long interval = 1000*60;
alarm.setRepeating(AlarmManager.ELAPSED_REALTIME, SystemClock.elapsedRealtime(),interval, pending);

所以我的问题如下:假设AlarmManager用于执行更新.此外,如果在widgetproviderinfo.xml,updatePeriodMillis是不是设置为0时,将价值将采取优先？作为Alarm或updatePeriodMillis的一部分指定的值？

在学习Scala时，我学到的第一件事就是每个函数都返回一些东西。没有像Java中那样的“无效”函数/方法。因此，许多Scala函数在数学上都是真正的函数，并且对象在很大程度上可以保持无状态。

现在，我了解到actor模型是Scala等功能语言中非常流行的模型。但是，参与者促进了编程的“一劳永逸”风格，并且呼叫者通常不希望被呼叫者直接回复消息（使用“询问” /“？”方法时除外）。因此，参与者需要记住某种状态。

我是否假设角色模型更像是可伸缩性和可维护性之间的权衡（由于其状态），有时甚至可以认为是反模式？

我正在研究一个Angular 6应用程序,我被告知以下是一个反模式:

await someFunction().then(result => {
    console.log(result);
});

我意识到等待承诺链是毫无意义的.如果someFunction()返回一个promise,那么如果你正在等待它,则不需要一个promise链.你可以这样做:

const result = await someFunction();
console.log(result);

但我被告知等待一个承诺链可能会导致错误,或者它会破坏我的代码中的东西.如果上面的第一个代码片段与第二个代码段完全相同,那么使用哪个代码片段至关重要.第一个片段引入了哪个危险,第二个片段没有？