Questions tagged «object-oriented»

一种使系统能够建模为一组对象的方法论,这些对象可以模块化方式进行控制和操作

3
是否有没有继承的OO语言?
在今天的代码审查中,我的一位同事说了一些有趣的事情: prototype仅在需要继承时才有用- 何时继承是个好主意? 我考虑了一下,然后意识到,我通常使用继承来解决最初设计不好的代码。现代的OO风格更喜欢使用组合而不是继承,但是我不知道有哪一种语言能够真正做到这一点并真正执行它。 是否有带有类,对象,方法,接口等的通用编程语言,这些语言不允许基于类的继承?(如果这样的想法没有意义,为什么不呢?)

7
传播模式改变了对象模型。
这是一个常见的情况,总是让我感到沮丧。 我有一个带有父对象的对象模型。父级包含一些子对象。这样的事情。 public class Zoo { public List<Animal> Animals { get; set; } public bool IsDirty { get; set; } } 每个子对象都有各种数据和方法 public class Animal { public string Name { get; set; } public int Age { get; set; } public void MakeMess() { ... } } 当子级更改时(在这种情况下,当调用MakeMess方法时),父级中的某些值需要更新。假设当Animal的某个阈值变得混乱时,则需要设置Zoo的IsDirty标志。 有几种处理这种情况的方法(我知道)。 1)每个动物都可以有一个父Zoo参考,以便交流更改。 …

9
OOP原则和方法名称
class Boxer: def punch(self, punching_bag, strength): punching_bag.punch(strength) class PunchingBag: def punch(self, strength): print "Punching bag punched with strength", strength boxer = Boxer() punching_bag = PunchingBag() boxer.punch(punching_bag, 2) 毫无疑问,punch对于拳击手来说,这是一个很好的方法名称。但是名字punch对出气筒的方法也好吗?在两种情况下,我的意思是打孔作为命令(即打孔)。

6
对象应该知道自己的ID吗?
obj.id似乎相当普遍,似乎也落入了对象可能了解的自身范围之内。我发现自己在问为什么我的对象应该知道自己的ID? 它似乎没有理由拥有它吗?存在它的主要原因之一是检索它,因此我的存储库需要知道它,然后将其用于数据库交互。 我还曾经遇到一个问题,我想将对象序列化为RESTful API的JSON,其中id似乎不适合有效负载,但是仅URI并将其包含在对象中使事情变得更加困难。 对象应该知道它自己的ID吗?为什么或者为什么不? 更新: 条款 id:对象的标识符属性。用数据库术语来说,代理键不是自然键。 对象:系统中的实体或其他可唯一标识的对象。


6
没有用例的松耦合是否是反模式?
对于某些开发人员而言,松散耦合是精心设计的软件的圣杯。当它使代码在可预见的将来可能发生的变化面前更加灵活,或者避免代码重复时,这无疑是一件好事。 另一方面,松散耦合组件的努力增加了程序中的间接访问量,从而增加了程序的复杂性,常常使程序难以理解,并常常使效率降低。 您是否认为在没有任何松散耦合用例的情况下专注于松散耦合(例如避免代码重复或计划在可预见的将来可能发生的更改)是一种反模式?松散的联轴器能否落入YAGNI的保护伞下?

3
如何处理C ++类构造函数中的失败案例?
我有一个CPP类,其构造函数执行一些操作。其中一些操作可能会失败。我知道构造函数不会返回任何东西。 我的问题是 除了初始化构造函数中的成员之外,是否可以执行其他操作? 是否可以告诉调用函数构造函数中的某些操作已失败? new ClassName()如果构造函数中发生某些错误,我可以使返回NULL吗?

4
“过于面向对象”
我具有强大的OO背景,并且我最近开始在一个组织中工作,尽管该代码是用Java编写的,但与过去相比,我对良好的OO设计的重视程度要低得多。有人告诉我,我引入了“太多的抽象”,而我应该以一直采用的方式编写代码,这是Java中的一种过程样式。 TDD在这里也不太常用,但是我想拥有可测试的代码。在大型“神类”(这似乎是该团队的常态)中以静态私有方法掩埋业务逻辑不是很可测试的。 我很难向同事清楚地传达自己的动力。有谁对我如何说服我的同事使用OO和TDD导致更容易维护的代码有任何建议? 这个问题有关技术债务是关系到我的问题。但是,我试图避免首先产生债务,而不是在另一个问题所涵盖的事实之后偿还债务。

5
如何避免巨型胶水方法?
在我目前的工作中,我曾几次被要求清理旧代码。通常,代码是迷宫式的,其背后的数据甚至更复杂。我发现自己将事情整理成漂亮,整洁的模块化方法。每种方法都做一件事并且做得很好。那时候事情开始往南走... 最终,我总是得到一个干净的API,并且没有真正的方法将它们捆绑在一起。解决方法是编写一个大的丑陋的“粘合”方法(通常充满条件语句),该方法最终调用我所有的“清洁”方法。 胶水方法通常最终是我试图清除的代码/数据缠结的简洁版本。它通常更具可读性,但仍然很烦人。 如何避免这种方法?这是数据纠结的征兆还是我做错事情的反映?

5
使用静态类作为名称空间
此问题是从Stack Overflow 迁移而来的,因为可以在Software Engineering Stack Exchange上回答。 迁移 8年前。 我看到其他开发人员使用静态类作为名称空间 public static class CategoryA { public class Item1 { public void DoSomething() { } } public class Item2 { public void DoSomething() { } } } public static class CategoryB { public class Item3 { public void DoSomething() { } } …

12
开发游戏是学习编程的最佳方式吗?[关闭]
关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗? 更新问题,使它成为软件工程堆栈交换的主题。 4年前关闭。 我最近听到一位指导老师的话,开发游戏是学习编程的最佳方法。除了必须使用代码创建所有内容外,他还说,您确实可以充分体验并将OOP实施到您的程序中。换句话说,您在游戏中所做的一切从技术上和概念上都是文字对象。进行此假设是否安全?还是在学习编程时总会有例外? 请注意,它是针对.net / xna / c#开发的。

4
如何大幅提高代码覆盖率?
我的任务是让遗留应用程序处于单元测试之下。首先介绍一下应用程序的背景知识:这是一个600k LOC Java RCP代码库,存在以下主要问题 大量代码重复 没有封装,大多数私有数据都可以从外部访问,一些业务数据也成为单例,因此不仅可以从外部更改,而且可以从任何地方更改。 没有抽象(例如,没有业务模型,业务数据存储在Object []和double [] []中),因此没有OO。 有一个很好的回归测试套件,一个高效的质量检查团队正在测试和发现错误。我知道如何从经典书籍(例如Michael Feathers)中对其进行测试的技术,但这太慢了。由于存在工作正常的回归测试系统,因此我不怕积极地重构系统以允许编写单元测试。 我应该如何着手解决问题以快速获得覆盖范围,以便能够向管理人员展示进度(实际上是从JUnit测试的安全网中开始赚钱)?我不想使用工具来生成回归测试套件,例如AgitarOne,因为这些测试不会测试是否正确。

5
具有后备情况的特殊情况是否违反《里斯科夫替代原则》?
假设我有一个FooInterface具有以下签名的接口: interface FooInterface { public function doSomething(SomethingInterface something); } 还有一个ConcreteFoo实现该接口的具体类: class ConcreteFoo implements FooInterface { public function doSomething(SomethingInterface something) { } } ConcreteFoo::doSomething()如果它传递了一种特殊类型的SomethingInterface对象(例如称为SpecialSomething),我想做一些独特的事情。 如果我加强方法的先决条件或引发新的异常,则绝对是LSP违规,但是如果我SpecialSomething在为通用SomethingInterface对象提供后备时又对特殊情况的对象进行了处理,这是否仍会违反LSP ?就像是: class ConcreteFoo implements FooInterface { public function doSomething(SomethingInterface something) { if (something instanceof SpecialSomething) { // Do SpecialSomething magic } else { // Do generic …

3
泛型与通用接口?
我不记得上次写泛型类的时间。每次经过思考后我都认为不需要时,我认为不需要它。 这个问题的第二个答案让我要求澄清(因为我还不能发表评论,所以我提出了一个新问题)。 因此,让我们以给定的代码为例,说明需要泛型的情况: public class Repository<T> where T : class, IBusinessOBject { T Get(int id) void Save(T obj); void Delete(T obj); } 它具有类型约束: IBusinessObject 我通常的想法是:该类只能使用IBusinessObject,使用该类的也是如此Repository。存储库存储这些对象IBusinessObject,最有可能的客户端Repository将希望通过IBusinessObject接口获取和使用对象。那为什么不只是为了 public class Repository { IBusinessOBject Get(int id) void Save(IBusinessOBject obj); void Delete(IBusinessOBject obj); } 那个例子不好,因为它只是另一种类型的集合,而通用集合是经典的。在这种情况下,类型约束看起来也很奇怪。 实际上,该示例class Repository<T> where T : class, IBusinessbBject与class BusinessObjectRepository我非常相似。泛型是要修复的东西。 重点是:泛型除了集合之外,是否对其他任何东西都有用,并且类型约束不会使泛型成为专用对象,就像使用类约束而不是在类内部使用泛型类型参数一样?

5
在几乎每个人都需要访问公共数据结构的情况下,依赖项注入有什么好处?
在OOP中,为什么全局变量是邪恶的有很多原因。 如果需要共享的对象的数量或大小太大而无法在函数参数中有效传递,通常每个人都建议使用依赖注入而不是全局对象。 但是,在几乎每个人都需要了解某种数据结构的情况下,为什么依赖注入比全局对象更好? 示例(一个简化的示例,以大体上说明这一点,而无需在特定应用程序中深入研究) 许多虚拟车辆具有大量的属性和状态,包括类型,名称,颜色,速度,位置等。许多用户可以对其进行远程控制,并且发生大量事件(用户都可以已启动和自动)可以更改其许多状态或属性。 天真的解决方案是仅将它们制成一个全局容器,例如 vector<Vehicle> vehicles; 可以从任何地方访问。 更加面向OOP的解决方案是让容器成为处理主事件循环的类的成员,并在其构造函数中实例化。每个需要它并且是主线程成员的类都将通过其构造函数中的指针被授予对容器的访问权限。例如,如果外部消息是通过网络连接传入的,则负责解析的类(每个连接一个)将接管,解析器将可以通过指针或引用访问容器。现在,如果解析后的消息导致容器元素发生更改,或者需要容器中的某些数据来执行操作,则无需通过信号和插槽来扔掉成千上万个变量(或更糟的是,将它们存储在解析器中,稍后由调用解析器的人检索)。当然,所有通过依赖注入接收对容器的访问的类都是同一线程的一部分。不同的线程不会直接访问它,但是会执行其工作,然后将信号发送到主线程,并且主线程中的插槽将更新容器。 但是,如果大多数类都可以访问该容器,那么到底它与全局容器有什么不同呢?如果这么多的类需要容器中的数据,那么“依赖注入方式”是否只是伪装的全局变量? 一个答案将是线程安全性:即使我注意不要滥用全局容器,也许将来另一个开发人员在紧迫的最后期限的压力下,仍会在另一个线程中使用全局容器,而不会照顾所有人碰撞情况。但是,即使在依赖注入的情况下,也可能会向在另一个线程中运行的某个人提供指针,从而导致相同的问题。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.