标签: god-object

我一直在阅读很多博客,主张胖模型和瘦控制器方法,尤其是.Rails阵营.因此,路由器基本上只是找出在什么控制器上调用什么方法,并且所有控制器方法都在调用模型上的相应方法然后调出视图.所以我在这里有两个我不明白的问题:

1. 控制器和路由器实际上没有做太多不同的任务,只是根据路线调用类似神的模型上的方法.
2. 模特做得太多了.发送电子邮件,创建关系,删除和修改其他模型,排队任务等.现在基本上你有类似神的对象,应该做任何与建模和处理数据有关或可能不关心的事情.

你在哪里划线？这不仅仅是落入神模式吗？

有谁知道重构上帝对象的最佳方法？

它并不像将它分成许多较小的类那样简单,因为有很高的方法耦合.如果我拿出一种方法,我通常会把所有其他方法拉出去.

在我一直在研究的一些MVC项目中,显而易见的是,有一些有问题的控制器已经有机地成长为上帝类 - 如果你愿意的话,每个人都在他们自己的领域.

这个问题可能更多的是"什么在哪里",但我认为这是一个关于SRP(单一责任原则),DRY(不要重复自己),保持简洁,"敏捷"的重要问题 - 而且我没有足够的经验(有这种模式和一般设计)对此有所了解.

在一个项目中,我们有一个NutritionController.随着时间的推移,它已经成长为包含这些动作(许多动作都有各自的GET,POST和DELETE方法):

Index (home controller)
ViewFoodItem
AddFoodItem
EditFoodItem
DeleteFoodItem
ViewNutritionSummary
SearchFoodItem
AddToFavorites
RemoveFromFavorites
ViewFavorites

Run Code Online (Sandbox Code Playgroud)

然后我们有一个ExerciseController,它将包含许多类似的操作,例如搜索和收藏夹操作.这些应该重构到他们自己的控制器中,以便它是这样的吗？

SearchController {
    SearchExercise
    SearchNutrition
    //... etc
}

FavoritesController {
    ViewNutritionFavorites
    AddToNutritionFavorites
    AddToExerciseFavorites
    EditNutritionFavorites
    EditExerciseFavorites
    //... etc
}

在我看来,如果你将它们分解为单独的控制器,你将在某种程度上增加一个令人难以置信的大依赖性来处理你需要的信息.或者你将拥有一个非常难以处理的完全通用的处理应用程序,因为你必须跳过这么多的箍来获得你想要的效果(在M,V或C级别).

我想错了吗？例如,我应该有一个通用的收藏夹对象,然后让控制器决定将它扔到哪个视图？

*很抱歉拼写出缩略语 - 我这样做是为了防止其他人遇到这个问题并且对这些东西是什么一无所知

编辑: 我执行的所有逻辑几乎都在服务层中处理.例如,控制器将'new'FoodItem发送给服务.如果它已经存在,或者它有错误,服务会将其冒泡回控制器.

阅读关于神对象的维基百科条目,它说当一个类知道太多或太多时,它就是一个神对象.

我看到了这背后的逻辑,但如果这是真的,那么你如何结合每一个不同的阶级呢？您是否总是使用主类来连接窗口管理,数据库连接等？

我在一个中等规模的团队工作,我经常遇到这些痛苦的大班文件.我的第一个倾向是用刀子去找他们,但这通常会让事情变得更糟,让我陷入一种糟糕的心态.

例如,假设您刚刚获得了Windows服务.现在这个服务中存在一个错误,你需要弄清楚服务的作用,然后你才有希望修复它.你打开服务,看到有人决定只使用一个文件.Start方法就在那里,Stop方法,Timers,所有处理和功能.我正在谈论成千上万行代码.一百行代码下的方法很少见.

现在假设你不能重写整个班级,而这些上帝课程只会不断出现,处理它们的最佳方法是什么？你从哪里开始的？你先尝试做什么？你是如何应对这种事情的,而不只是想要全力以赴.

如果你有一些策略只是为了控制你的脾气,这也是受欢迎的.

提示远远:

1. 建立测试覆盖率
2. 代码折叠
3. 重组现有方法
4. 记录发现的行为
5. 旨在逐步改进

编辑:

查尔斯康威推荐一个播客,结果非常有帮助.链接

Michael Feathers(播客中的人)开头的前提是,他们太害怕简单地将一个项目从源代码控制中取出来直接玩它然后扔掉它们.我可以说我对此感到内疚.

他基本上说要把你想要了解的项目拿到更多,然后开始将它拆开.发现它的依赖关系,然后打破它们.随处可见.

伟大提示 获取在其他地方使用的大类,并使其实现一个emtpy接口.然后使用类获取代码并让它实例化接口.这将为您提供代码中该大型类的所有依赖项的完整列表.

我刚开始使用AngularJS,所以我不是专家.

我有一个div代表我的html视图的正确区域.在那个div我有一个控制器,即

<div class="rightContainer" ng-controller="rightContainerCtrl">...</div>

在div中我有一个表,一个搜索区域等.该div中的每个区域都有自己的控制器,它看起来像这样:

<div class="rightContainer" ng-controller="rightContainerCtrl">
...
   <div class="search" ng-controller="searchCtrl">...</div>
...
   <div class="table" ng-controller="tableCtrl">...</div>

 </div>

例如,搜索区域有自己的控制器,它是rightContainerCtrl的子节点,因为它需要改变父节点中的某些内容(rightContainerCtrl),但是rightContainer div正在增长,现在它很大,并且包含几个嵌套控制器.

我认为使用这个嵌套控制器在这个上下文中是不好的,因为所有嵌套控制器共享父作用域,并不是所有控制器都需要访问所有父作用域变量,所有控制器都是rightContainerCtrl的"囚犯",所以它们是与其父控制器高度耦合.

它看起来像一个上帝对象反模式(在这种情况下是上帝控制器),所以我认为不是使用嵌套控制器我可以重构我的代码以消除rightContainerCtrl控制器并改为使用服务(如在外观设计模式中),然后,控制器将使用该服务,而不是共享范围变量.

但由于我不是AngularJs的专家,我不确定我是对的还是离开这个父控制器更好,也许我错过了什么,所以我的问题是

何时更好地使用嵌套控制器(嵌套范围)以及何时更好地在angularjs中使用服务？

我有一个名为Parameters的对象,它跨越包边界从方法到方法向下和向上抛出调用树.它有大约五十个状态变量.每种方法可能使用一个或两个变量来控制其输出.

我认为这是一个坏主意,因为我不能轻易看到方法需要运行什么,甚至如果模块Y的某些参数组合与我当前的模块完全无关,可能会发生什么.

有什么好的技术可以减少与这个神对象的耦合,或者理想地消除它？

        public void ExporterExcelParFonds(ParametresExecution parametres)
    {
        ApplicationExcel appExcel = null;
        LogTool.Instance.ExceptionSoulevee = false;


        bool inclureReferences = parametres.inclureReferences;
        bool inclureBornes = parametres.inclureBornes;
        DateTime dateDebut = parametres.date;
        DateTime dateFin = parametres.dateFin;

        try
        {
            LogTool.Instance.AfficherMessage(Variables.msg_GenerationRapportPortefeuilleReference);

            bool fichiersPreparesAvecSucces = PreparerFichiers(parametres, Sections.exportExcelParFonds);
            if (!fichiersPreparesAvecSucces)
            {
                parametres.afficherRapportApresGeneration = false;
                LogTool.Instance.ExceptionSoulevee = true;
            }
            else
            {

来电者会:

                PortefeuillesReference pr = new PortefeuillesReference();
            pr.ExporterExcelParFonds(parametres);

我正处于一个大项目的完成阶段,该项目有几个大的组件:图像采集,图像处理,数据存储,工厂I/O(自动化项目)和其他几个.

这些组件中的每一个都是相当独立的,但是要使项目作为一个整体运行,我需要每个组件至少一个实例.每个组件还具有ViewModel和View(WPF),用于监视状态和更改内容.

我的问题是实例化所有这些对象的最安全,最有效和最易维护的方法,将一个类订阅到另一个类中的Event,并为所有这些提供一个共同的ViewModel和View.

如果我有一个名为God的类具有所有这些对象的私有实例,那会不会最好？我过去做过这件事而后悔了.

或者如果上帝依靠这些物体的Singleton实例来让球滚动,那会更好吗？

或者,如果Program.cs(或Main(...)所在的位置)实例化所有这些组件,并将它们作为参数传递给God,然后让他(窃笑)和他的ViewModel处理运行这个项目的细节.

我希望听到的任何其他建议.

谢谢!

在我的应用程序中,我有一个Controller由main方法启动的.控制器初始化钩子,数据库连接,UI,另一个连接和其他东西.它占据了程序的大部分状态(不,它不是Singleton).在另一个例子中,有一个用于机器人的控制器,用于处理解释和发出命令.两者都是相当大的文件.

我已经阅读了上帝的对象,但我真的不知道如何将它分开.如果我将机器人中的解释器和调度员分开,它将会形成一个可怕的调用链(类似于getBot().getParser().getOutput().sendMessage(recipient, message)).类似地,在第一个控制器中,如果我分开,你将只有包含字段的数据对象和一些别名实用程序方法.将它们拆分会让事情变得更糟.在你认为它不可维护之前,实际上并非如此.我甚至没有写Bot控制器,但我仍然知道发生了什么.

但问题是Bot类是2000行(如果我拿出Javadoc注释可能会更短)并且Bot大约是1000行.很多行=上帝的对象.但是对于项目的一个或两个核心类是否可以？

我在一个相当大的产品上工作.它一直处于开发阶段,因为.Net 1.0仍然是一个正在进行中的工作,所以它有很多质量不好的代码,并没有考虑单元测试.现在我们正在尝试提高质量并实现每个功能和错误修复的测试.我们现在遇到的最大问题之一是依赖地狱和上帝的对象.特别是有一个上帝对象是坏的:Session.基本上,与该程序的当前会话相关的任何内容都在此对象中.还有一些其他神物.

无论如何,我们通过使用Resharper从它们中提取界面,使这个神对象"可模仿".但是,这仍然使测试变得困难,因为大多数时候你必须查看你编写的代码,以找出真正需要在100种不同方法和特性中嘲笑的内容.

仅仅拆分这个类是不可能的,因为这个类有数百甚至数千个引用.

因为我有一个接口(几乎所有的代码都经过重构才能使用接口),但我有一个有趣的想法.如果我使ISession接口继承自其他接口,该怎么办？

例如,如果我们有这样的事情:

interface IBar
{
  string Baz{get;set;}
}

interface IFoo
{
  string Biz{get;set;}
}

interface ISession: IFoo, IBar
{
}

这样,不必更新使用ISession的现有代码,也不必更新实际实现.但是,在我们编写和重构的新代码中,我们可以使用更细粒度的IFoo或IBar接口,但是传入一个ISession.

最终,我认为这可能更容易最终分解实际的ISession和Session上帝接口/对象

现在给你.这是对这些上帝物体进行测试并最终将其分解的好方法吗？这是一种记录在案的方法和/或设计模式吗？你做过这样的事吗？