Questions tagged «object-oriented»

在我正在查看的某些代码中，我看到的东西在道德上等同于以下内容： public class Foo { private Bar bar; public MethodA() { bar = new Bar(); bar.A(); bar = null; } public MethodB() { bar = new Bar(); bar.B(); bar = null; } } 从逻辑上讲，该字段bar是局部变量，因为其值永远不会在方法调用之间持久化。但是，由于许多方法都需要类型的对象，因此原始代码作者刚刚创建了一个type字段。FooBarBar 这显然是不好的，对吧？ 此反模式有名称吗？

68 object-oriented  terminology  anti-patterns 

向下转换意味着从基类（或接口）转换为子类或叶类。 如果您从转换System.Object为其他类型，则可能会导致沮丧。 向下转换不受欢迎，可能有代码味道：例如，面向对象的理论更喜欢定义和调用虚拟或抽象方法，而不是向下转换。 什么是向下转换的好用例（如果有）？也就是说，在什么情况下编写向下转换的代码是合适的？ 如果您的答案为“无”，那么为什么该语言支持向下转换？

67 c#  object-oriented 

下面的两个UpdateSubject方法有什么区别？我觉得如果只想对实体进行操作，使用静态方法会更好。在什么情况下应该使用非静态方法？ public class Subject { public int Id {get; set;} public string Name { get; set; } public static bool UpdateSubject(Subject subject) { //Do something and return result return true; } public bool UpdateSubject() { //Do something on 'this' and return result return true; } } 我知道，对于这个非常烦人的问题，我会从社区中得到很多帮助，但我无法阻止自己提出这个问题。 在处理继承时，这变得不切实际吗？ 更新： 它正在我们的工作场所中发生。我们正在与5位开发人员一起开发6个月的asp.net …

64 object-oriented  static-methods 

单一责任原则规定，一个班级只能做一件事情。有些情况很明确。但是，其他方法则很困难，因为在给定的抽象级别上查看时看起来像“一件事”，而在较低级别上查看时可能是多个事物。我还担心，如果在较低级别上遵循“单一责任原则”，则会导致过度分离，冗长的馄饨代码，而不是实际解决手头的问题，因为花更多的时间在所有内容上创建微型类并收集信息。 您将如何描述“一件事”的含义？有什么具体迹象表明一个班级确实比“一件事情”做得更多？

64 design  object-oriented 

今天我和某人吵架。 我正在解释使用富域模型相对于贫血域模型的好处。我用一个简单的类演示了我的观点： public class Employee { public Employee(string firstName, string lastName) { FirstName = firstName; LastName = lastname; } public string FirstName { get private set; } public string LastName { get; private set;} public int CountPaidDaysOffGranted { get; private set;} public void AddPaidDaysOffGranted(int numberOfdays) { // Do stuff } …

63 c#  object-oriented  single-responsibility 

我仍然是一名高中学生（正在读10年级），并且还没有在学校学习实际的计算机课程。到目前为止，我所做的一切都是通过书本。这些书教会了我诸如继承的概念，但是将程序分成多个类又有什么帮助呢？这些书从未告诉过我。 我问这个问题主要是因为最近有一个项目。这是一款街机视频游戏，就像有人所说的Flash游戏一样（尽管我不知道Flash游戏是什么）。事实是，这只是一堂课。仅使用一个类，它就可以很好地工作（但是偶尔会有一些滞后）。所以，我只是问如何将其拆分为多个类会有所帮助。 这个项目是用Java编写的，我是唯一从事该项目的人。

62 java  object-oriented  inheritance  class 

OOP背后的主要思想是统一单个实体（对象）中的数据和行为。在过程编程中，有数据和修改数据的单独算法。 在“模型-视图-控制器”模式中，数据和逻辑/算法分别放置在不同的实体中，分别是模型和控制器。在等效的OOP方法中，模型和控制器不应该放在同一逻辑实体中吗？

61 design  object-oriented  mvc 

我与一位同事就ORM及其优缺点进行了非常刺激和有趣的讨论。我认为，ORM仅在极少数情况下才有用。至少以我的经验。 但是我现在不想列出自己的论点。所以我问你，你对ORM有什么看法？优点和缺点是什么？

58 object-oriented  design-patterns  orm  anti-patterns 

问题摘要： 长话短说，我继承了代码库和不允许更换的开发团队，使用God Objects是一个大问题。展望未来，我想让我们重构事情，但是我从那些想与God Objects一起做所有事情的团队中得到了回击，“因为它更容易”，这意味着我将无法重构。我以多年的开发经验为后盾，我是受雇来了解这些事情的新老板，等等，第三方离岸公司的销售代表也是如此，现在这是在执行层和我的会议上现在是明天，我想投入大量技术弹药以倡导最佳实践，因为从长远来看，我认为这对于公司而言会便宜得多（而且我个人认为这是第三方所担心的）。 我的问题是从技术角度讲的，我知道它的长期稳定性，但是我在超短期和6个月期限方面遇到了麻烦，尽管我“知道”我无法通过引用和引用的资源来证明这一点。一个人（罗伯特·C·马丁，又名鲍勃叔叔），因为我被告知要从一个人那里获得数据，而只有一个人（罗伯特·C·马丁）的论点不够好。 题： 我可以直接引用一些本领域知名专家的资源（标题，出版年份，页码，报价），这些资源明确表示对“上帝”对象/类/系统的这种使用不好（或很好，因为我们正在寻找）技术上最有效的解决方案）？ 我已经做过的研究： 我在这里有很多书，并且已经搜索了它们的索引以查找单词“ god object”和“ god class”的使用。我发现奇怪的是它几乎从未使用过，例如我所拥有的GoF书的副本就从未使用过（至少根据我面前的索引），但是我在下面的两本书中找到了它，但是我想要更多我可以用。 我在Wikipedia页面上检查了“上帝对象”，并且该页面当前是一个存有很少参考链接的存根，因此尽管我个人同意它说，但在个人经历被认为无效的环境中，我没有太多用处。被引用的书也被认为太老了，无法被我在讨论这些技术要点的人们接受，因为他们提出的论据是：“曾经被认为是不好的，但没人能证明它，而现在的现代软件则说：”上帝“对象很好用”。我个人认为这句话是不正确的，但无论事实如何，我都想证明事实。 在罗伯特·C·马丁（Robert C Martin）的“ C＃中的敏捷原理，模式和实践”（ISBN：0-13-185725-8，精装本）的第266页中，它指出：“每个人都知道，神的阶级是个坏主意。我们不想将系统的所有智能集中到单个对象或单个功能中。OOD的目标之一是将行为划分和分布到许多类和许多功能中。” -然后继续说有时还是最好还是使用上帝课程（以引用微控制器为例）。 在罗伯特·C·马丁（Robert C Martin）的“清洁代码：敏捷软件技巧手册”第136页（仅此页面）中，谈到了“上帝的阶级”，并称其为违反“阶级应该很小”规则的主要例证。从第138页开始，他使用了“单一责任原则”。 我遇到的问题是，我所有的参考文献和引用都来自同一个人（Robert C. Martin），并且来自同一个人/来源。有人告诉我，因为他只是一个观点，所以我不使用“上帝类”的愿望是无效的，并且未被接受为软件行业的标准最佳实践。这是真的？从技术的角度来看，我是在努力遵循鲍勃叔叔的教导做错事情吗？ 上帝对象和面向对象的编程与设计： 我对这一点的思考越多，我就越会在学习OOP时学到更多，而且从来没有明确指出过。它对良好设计的暗含是我的想法（请随意纠正我，因为我想学习），问题是我“知道”这一点，但不是每个人都知道，因此在这种情况下，它不被视为有效的论证，因为当实际上大多数人在统计上都不了解它时，我实际上将其称为普遍真理，因为从统计学上讲大多数人都不是程序员。 结论： 我不知所措，想获得最好的附加结果来引用，因为他们提出了技术要求，并且我想知道真相并能够像真正的工程师/科学家一样被引用证明事实，即使由于我对使用神物的经验，我对神物有偏见。任何帮助或引用将不胜感激。

56 object-oriented  class  object  single-responsibility 

使用面向对象范例的最大希望可能是代码重用。有人对此表示怀疑。为什么没有实现？ OOP定义的代码重用是否会使项目更高效？ 或更易于管理？还是更容易维护？还是质量更高？ 也许大家都同意代码重用是一件好事，但是有几种方法可以实现这一目标。问题是关于OOP提供的代码重用方法。这是好事吗？是否有比面向对象，子分类，多态等更好的方法来实现代码重用？有什么方法更好？为什么呢 告诉我们您在OOP重用或其他范式重用方面的经验。

56 productivity  code-quality  object-oriented  code-reuse 

我正在完成我的硕士学位（计算机）并申请工作。我注意到许多公司专门要求了解面向对象。流行的访谈问题涉及继承，多态性，访问器等。 OO真的那么重要吗？我什至接受了C语言编程工作的面试，面试的一半是面向对象的。 在现实世界中，开发实际应用程序时，几乎总是使用面向对象吗？诸如多态性之类的关键功能是否大量使用？ 我认为我的问题来自我的弱点之一。尽管我了解OO，但是似乎无法将其大量集成到我的程序中。

55 object-oriented  inheritance  polymorphism 

C ++具有简单的多重继承，许多语言设计都将其视为危险。但是某些语言（例如Ruby和PHP）使用奇怪的语法来完成相同的操作，并将其称为mixin或traits。我多次听说，mixin /特性比普通的多重继承更难滥用。 是什么使它们危险性降低了？是否有不能用mixins / traits来实现，但是可以用C ++风格的多重继承来实现？他们有可能遇到钻石问题吗？ 似乎我们在使用多重继承，但只是借口说它们是混合/特性，因此我们可以使用它们。

54 object-oriented  inheritance  multiple-inheritance  mixins 

在我工作的地方，我看到很多班级都做了这样的事情： public class ClassThatCallsItsOwnGettersAndSetters { private String field; public String getField() { return field; } public void setField(String field) { this.field = field; } public void methodWithLogic() { setField("value"); //do stuff String localField = getField(); //do stuff with "localField" } } 如果我是从头开始写的，那我应该写成methodWithLogic()这样的： public class ClassThatUsesItsOwnFields { private String field; public …

53 java  object-oriented  programming-practices 

我已经看到，通常情况下，面向对象的编程都是基于对真实世界的建模，但是是吗？ 在我看来，业务层以外的任何事物都不是真的。我的GUI类/数据访问类在现实世界中没有任何模型。即使在我的业务层，我也有一些类，例如观察员，经理，工厂等，这些类并不是真实的对象。我尝试设计类以利用诸如封装之类的优势，但是现实世界是否被封装？ 虽然我创建的某些对象正在对真实世界的对象进行建模，但OOP之前的代码会不会做到这一点？我怀疑OO是第一个在其代码库中包含诸如Customer之类的概念的人的。但是OO确实是关于如何对事物建模的方法，而这种建模方法对我来说似乎并不受现实世界的启发。 那么：面向对象的编程真的可以为现实世界建模吗？

52 object-oriented 

IOC容器的目的是什么？合并的原因可以简化为以下内容： 当使用OOP / SOLID开发原则时，依赖注入会变得混乱。您可能具有顶层入口点，这些入口点管理着位于其自身下方的多个级别的依赖关系，并通过构造递归传递依赖关系，或者您在工厂/构建器模式和接口中有一些重复的代码，可以根据需要构建依赖关系。 没有OOP / SOLID方式可以执行此操作并拥有超级漂亮的代码。 如果上述陈述是正确的，那么IOC容器该如何做？据我所知，他们没有采用手动DI无法完成的未知技术，因此唯一的解释是IOC容器通过使用静态对象私有访问器来打破OOP / SOLID原则。 IOC容器是否在幕后打破了以下原则？这是真正的问题，因为我有很好的理解，但是感觉到其他人有更好的理解： 范围控制。范围是我对代码设计做出几乎所有决定的原因。块，本地，模块，静态/全局。范围应该非常明确，在块级别尽可能多，而在静态级别则尽可能少。您应该看到声明，实例化和生命周期的结尾。只要我明确指出，我相信该语言和GC可以管理范围。在我的研究中，我发现IOC容器将大多数或所有依赖项设置为静态，并通过幕后的一些AOP实现对其进行控制。所以没有什么是透明的。 封装。封装的目的是什么？我们为什么要保留私人会员呢？出于实际原因，因此我们的API的实现者无法通过更改状态（应由所有者类管理）来破坏实现。但是，出于安全原因，也不会发生注入超过我们的成员国并绕过验证和类控制的情况。因此，在编译之前以某种方式注入代码以允许外部访问私有成员的任何东西（模拟框架或IOC框架）都非常庞大。 单一责任原则。从表面上看，IOC容器似乎使事情更清洁。但是想象一下，如果没有帮助程序框架，您将如何完成相同的任务。您将传递带有十几个依赖项的构造函数。这并不意味着用IOC容器将其掩盖，这是一件好事！这是重构代码并遵循SRP的标志。 打开/关闭。就像SRP并非仅是类一样（我将SRP应用于单一职责范围，更不用说方法了）。打开/关闭不仅是不更改类代码的高级理论。这是一种了解程序配置并控制要更改和扩展的内容的实践。IOC容器可以部分地完全更改类的工作方式，因为： 一种。主要代码没有确定切换出依赖项，而是框架配置。 b。范围可以在不受调用成员控制的时间进行更改，而是由静态框架在外部确定。 因此，该类的配置不是真正封闭的，它会根据第三方工具的配置自行更改。 这是一个问题，是因为我不一定是所有IOC容器的大师。尽管IOC容器的想法不错，但它们似乎只是掩盖了糟糕的实现的外观。但是，为了完成外部Scope控制，私有成员访问和延迟加载，必须进行许多非平凡的可疑事情。AOP很棒，但是通过IOC容器完成AOP的方式也值得怀疑。 我可以相信C＃和.NET GC可以完成我期望的工作。但是我不能再信任第三方工具来改变我的已编译代码，以执行我无法手动执行的操作的变通办法。 EG：实体框架和其他ORM创建强类型对象并将其映射到数据库实体，并提供样板功能来执行CRUD。任何人都可以建立自己的ORM，并继续手动遵循OOP / SOLID原则。但是这些框架对我们有帮助，因此我们不必每次都重新发明轮子。看来，IOC容器可以帮助我们有目的地围绕OOP / SOLID原则开展工作并加以掩盖。

51 object-oriented  solid  inversion-of-control