从私有方法和公共方法调用成员/字段的最佳做法是什么？私有方法是应该总是调用私有字段还是应该调用公共成员？

private string _name;
public string Name
{ 
   get {return _name; }
   set { _name = value; }
}

public void DoSomething()
{
   _doSomething();
}


private void _doSomething()
{
   _name.ToLower();
}

不确定标题是否抓住了我在这里想说的内容.

在OO中进行设计时,我应该将对象分割成最具体的区域 - 所以如果我有一个工厂对象来处理创建对象,但后来我遇到了另一种创建对象的方法,即使它们可能是相同的对象是值得创建一个单独的fcatory或只是添加到exsiting.

我最大的担心是用大量的东西填补课程,或者拆分物品并将我的项目稀释成大量的课程.

有帮助吗？

编辑:

我想在我的旁注/子主题部分想要找出你应该在程序中使用的粒度级别.那种,你有多低？

我已经研究了几个试图遵循DDD原则的应用程序,我注意到我们最终遇到了服务层和感觉像代码味道的存储库之间存在重复的情况.

对于服务层中的大多数操作,它似乎是直接映射到CRUD操作,GetAll,GetById,创建,删除等.架构流程在这些行中:我有一个控制器调用服务层调用一个调用ORM的Repository,它与后端进行通信.

因此,例如GetAll将存在于SL和Repository中.现在,如果我们有一个变更/业务要求,GetAll应该忽略某些项目,我应该怎么做,我应该忽略存储库中的这些,还是应该进入服务层的业务逻辑？如果我们只是让服务层直接调用ORM,那么生活会不会更容易？

总结一下:我理解服务层可以抽象一些业务逻辑,但是在大多数情况下 - 它处理简单的CRUD操作,是不是更容易摆脱存储库？但是,如果SL 还包含一些具有复杂业务逻辑的方法,那么它们应该通过存储库吗？从良好的设计角度来看,我是否应该支持一致性并始终通过存储库或只是保持简单,只使用存储库,而不是简单的一对一映射到CRUD操作.

PS:我发现似乎有类似的问题,但没有找到任何令人满意的答案

我们有一个应用程序,它对服务器端代码进行了大量的jQuery JSON调用.因此,我们有大量的绑定代码来解析响应并将适当的值绑定到表单.这是一个两部分问题.

1. 处理大量具有不同数据的表单的建议方法是什么？现在正在尝试采用结构化方法为每个页面设置一个js"类",​​使用init,wireClickEvents等来尝试让所有内容都符合.

2. 是否有任何"最佳实践"创建重复的jQuery代码或任何类型的reccomended结构,而不仅仅是在js文件中抛出一堆函数？

在编写非DI系统时,一个困扰我的比喻是"一个人玩他/她的玩具".作为对象的人和人的玩具是对象创建,存储,初始化和操作的任何东西.玩具可以在达到特定状态时发送事件,但他们对使用它们的人一无所知; 它们只是带有控制开关的黑色小盒子,构成了它们的接口.该人可以从玩具中听取事件并通过操纵他们的界面进行响应.这个人可以用他/她的玩具做任何他/她想做的事情,但他/她可能不应该干涉他们的内脏,因为他们可能会破坏.

DI对我的比喻造成的破坏是它将玩具变成有意识的生物,知道它们的主人,使用它们的人.玩具可以操纵这个人,但是这个人对他们的工作方式一无所知,甚至不关心.这个人只拥有玩具,并期望玩具操纵他/她玩具自己满意.

WTF？听起来很糟糕!
什么是他们用来思考DI系统如何工作的良好心理隐喻？

今天我读了一本书,作者写道,在一个设计良好的类中,访问属性的唯一方法是通过其中一个类方法.这是一个被广泛接受的想法吗？为什么封装属性如此重要？不做的后果可能是什么？我之前在某处读过,这可以提高安全性或类似的东西.PHP或Java中的任何示例都非常有用.

我仍然有一个小问题,抓住纯OOD的概念.

假设我们有一类人类,我们生活在一个人类行走的世界里(大脑命令腿部),有时树木会消失(人类注意到这一点),有时候人类会随机相互撞击.

前两种情况真的很简单:

class Tree {
  private:
    void disappear()
    {
       // call onTreeDisappeared() for all human observers
    }
};

class Human {
  public:
    // The human notices that a tree disappeared
    void onTreeDisappeared();
  private:
    int x, y, z;
    // Human wants to walk forward
    void moveForward();
    // Hit another human, possibly causing him to fall down
    void hit(Human &target);
};

现在我遇到了一个非常糟糕的问题.当然,你可以这么说很好

anna.hit(bob);

直到这里我觉得它很好(如果有什么不好就请抱怨)并且读起来像散文(好的OOP代码应该).但是你如何将击球转移到OOP？如果安娜击中鲍勃并且鲍勃跌倒,那么跌倒既不是由安娜也不是鲍勃造成的.它是由命中,失去平衡和物理造成的.

我知道这种情况只有2个选项,但不知怎的,我觉得两个都很糟糕:

public: void fallDown()
{ z = 0; }

public: void hit(Human &target)
{
  bool targetFallsDown = …

我注意到,当我将方法定义为抽象时,子类的签名需要与它兼容.这让我有机会在子类的签名中使用类型检查.

如果我将父方法定义为具有默认实现的具体方法,那么我可以覆盖父方法而不遵守其接口.

在存在合适的默认实现的情况下,我倾向于使用第二种方法.但我是否让自己陷入困境？

对我来说,"抽象"的使用可能是如此限制似乎很奇怪,所以我想知道我是否遗漏了一些东西......

注意 - 我看到类似的问题已经被问到与其他语言相关,但不是PHP.

子集属性广泛用于UML规范图中.

• 子集属性的语义(含义)是什么？
• 如何使用UML子集属性？

一个现实世界的例子会很棒

编辑:

UML规范2.5(Beta)的以下屏幕截图

你能告诉我这个图中的子集是什么意思吗？

我们的商业模式需要识别不同类型的车辆.例如,摩托车,船,游艇,农场设备,雪地车,重型卡车,轻型卡车,乘用车和"其他".

我认为有两种方法可以处理它:创建一个带有几个子类的Vehicle类,比如船,卡车,汽车,并有一个枚举指示实际类型.这可以工作,允许您表示与公共子类共享一些共同特征的车辆.但是它允许你在类中使用不匹配的枚举.

我认为处理它的传统方法是为每种类型设置一个单独的子类,它可以是车辆的子类或车辆的子类.例如,重型和轻型卡车可能是卡车的子类; 船和游艇可能是船的子类; 雪地摩托车可能是车辆的子类.问题是,它并不能真正代表其他概念.

有没有人对这些场景有任何模式或最佳实践？

彼得

编辑: 目标的目的是传达有关车辆的信息,并能够以用户友好的方式显示该信息.例如,从数据库中提取数据并将其显示在要查看/编辑的屏幕上.

这导致了传统OO手段的另一个缺点,即偏离实际类型的类型指示器,因为它显示了需要执行某种实例的类型并将值转换为用户友好的类型.

(另外,澄清我说的是单个枚举,而不是每个子类的枚举.)