不同类型的客户 [英] differnt types of customer

问题描述

我是一名业余程序员。我在各种论坛上在线销售，并编写自己的软件来帮助进行销售处理。所以说我有一个SQL数据库，其中有一个名为SQL.Customer的客户表。如果我在线销售，我可以下载一个feeBay.Customer对象，其中包含与SQL.Customer几乎相同的信息。如果客户支付费用，我可以下载一个feePay.Customer对象，再次使用几乎相同的信息。



我的问题是我需要传递客户信息。例如，我下载了一个feeBay客户，检查数据库以查看客户是否是新的，检查feePal以查看地址是否匹配等等。但是因为它们都是不同类型，从一个转换到另一个（并且返回）是一种痛苦。



我认为这是一种常见的问题。似乎每次遇到这样的事情我都会以不同的方式处理它。是否有标准的设计模式/过程/体系结构来处理包含大部分相同信息的不同无关对象？

I''m an amateur programmer. I sell online in various forums and write my own software to help with sales processing. So say I have a SQL database that has a customer table in it called SQL.Customer. If I make a sale online I can download a feeBay.Customer object with pretty much the same info as SQL.Customer. If the customer pays with feePal I can download a feePay.Customer object, again with pretty much the same info.

My problem is that I need to pass customer info around. For example, I download a feeBay customer, check the database to see if the customer is new, check feePal to see if the addresses match, etc. But since they are all different types converting from one to another (and back) is a pain.

I would think this is a common type of problem. It seems that every time I run into something like this I handle it a different way. Is there a standard design pattern/procedure/architecture to handle different unrelated objects which contain mostly the same information?

推荐答案

我想说SA的方法是正确的一般。但是，如果您无法更改有问题的对象类型，因为这些定义属于某人或某事，那么您的问题就会略有不同。

在这种情况下，我会使用一种形式的中介对象假装''是你想要的类型，但实际上是你自己的对象，可以存储两种类型的所有数据集。换句话说，使用一种具有两个接口的类型，一个接口匹配您需要管理的每种类型，但是以自己的方式在内部存储数据。如果它们之间存在重叠或不一致，您需要额外的BehaveAs（）函数来告诉它伪装哪种类型。

这适用于具有纯函数接口的类型，即没有公共数据成员。如果涉及的类型具有公共数据成员，那么它就不那么容易了，第一步是完全转到智能指针，这样你总是只能通过另一个对象访问这些公共数据成员。然后可以使用一个特殊的智能指针，它实际上可以指向2个东西并且有一个BehaveAs（）函数来告诉它使用哪一个。

将所有这些放入代码中需要整篇文章和一个很多时候所以我希望压缩的英语解释很有用。

I would say SA''s approach is correct in general. However if you cannot change the object types in question because the definitions belong to someone or something else then you have a slightly different problem.
In this case I would use a form of mediator object which ''pretends'' to be the type you want but is actually your own object which can store the set of all data from both types. In other words use one type that has two interfaces, one interface matching each of the types you need to manage but stores the data internally in its own way. You''ll need an extra BehaveAs() function to tell it which type to ''pretend'' to be if there are overlaps or inconsistencies between them.
This is fine for types with pure function interfaces, i.e. no public data members. If the types involved have public data members then it''s not so easy, the first step is to go over fully to smart pointers so you always only access such public data members through another object. Then a special smart pointer can be used which can actually point to 2 things and has a BehaveAs() function to tell it which one to use.
Putting all this into code would require a whole article and a lot of time so I hope the compressed English explanation is useful.

你说的是反OOP思维的一个很好的例子。你不需要从一种类型转换为另一种类型。



首先，尽管不同客户有不同的属性，但它们有很多共同之处，例如地址，名称，某种独特的ID等。这应该放在一些抽象的基本类型中，并且无论客户类型如何都使用。



其他东西应该表示为虚函数。你知道这件事，是OOP的核心吗？你明白晚期绑定吗？如果没有，很难在一个简短的回答中完整地解释，但是想法是基类中的某些方法可以调用一些抽象方法，尽管它没有被实现。在从基类型继承的运行时类型中，调用将替换为最接近运行时类型的重写方法的调用。当然，在现实生活中，没有任何东西被替代，因为这样的调用是通过虚拟方法表完成的。通过这种方式，可以在抽象基类型中调用签名但在实现中不同的一些方法，但在运行时调用后期绑定方法。换句话说，你不知道在通话时究竟会调用什么实现;当使用具体的运行时类型时会发现它。



这个机制应该给你一个强大的抽象武器。



我想提前警告你：如果你问如何学习OOP甚至OOD，我的答案将是：从头学习基础知识;这不是教他们的地方。但是让我告诉你：如果你没有很好地学习OOP基础知识，你就无法在你描述的领域做任何事情。



不幸的是，它可能不是就如此容易。您的夜晚需要两个（或更多）不相关的层次结构：例如，一个处理付款，另一个处理您销售的产品的选项。尽管避免这种情况是最好的，但在现实生活中可能需要它。这个问题有不同的方法：多继承，聚合，接口（更准确地说，是多个基接口的实现，有时称为多重继承的弱形式）。



如果你受过足够的OOP教育（我质疑，但实际上我不确定，可能是你），请阅读我关于这个主题的文章，我提出了自己的并行层次结构方法，其中包括：动态方法调度程序 [ ^ ]。

-SA

What you say is a bright example of anti-OOP thinking. You don''t need to convert from one type to another.

First of all, despite of having some different properties of different customers, they have a lot in common, such as address, name, some kind of unique ID, etc. This should be put in some abstract base type and used regardless of the customer type.

Other things should be expressed as virtual functions. Do you know this thing, a heart of OOP? Do you understand late binding? If not, it''s hard to explain in full in a short answer, but the idea is that some method in a base class can call some abstract method, despite the apparent fact that it is not implemented. In a run-time type inherited from your base type, the call will be substituted with the call to the overridden method, closest to the run-time type. In real life, of course, nothing is "substituted", as such calls are done via a "virtual method table". In this way, some method general in signature but different in implementations, can be called in abstract base type, but the late bound method is called during run time. In other words, you don''t know what exactly implementation will be called at the point of the call; it will be found when a concrete run-time types is used.

This mechanism should give you a powerful abstraction weapon.

I want to warn you in advance: if you ask how to learn OOP and even OOD, my answer will be: learn the fundamentals from scratch; this is not a place to teach them. But let me tell you: if you don''t learn OOP fundamentals very well, you can do nothing in the field you describe.

Unfortunately, it might not be as simple as that. You night need two (or more) unrelated hierarchies: for example, one deal with payments, another with options of the products you sell. While it would be the best to avoid such situation, it may be needed in real life. There are different approach to this problem: multiple inheritance, aggregation, interfaces (more exactly, implementation of multiple base interfaces, which is sometimes called weak form of multiple inheritance).

If you are educated enough in OOP (I questioned that, but in fact I an not sure about it, may be you are), read my article on the topic, where I put forward my own approach to parallel hierarchies, among other things: Dynamic Method Dispatcher[^].

—SA

这篇关于不同类型的客户的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！