is there a design pattern that isolate 'methods' from member?

basically, i want to have something like: class DataProcessor{ };

however, in the future, i will need to pass DataProcessor's instance to some other functions, because DataProcessor contains some crucial data.

what I got in mind is to separate the members from methods:

开发者_高级运维

class DataProcessorCore{};
class DataProcessor : public DataProcessorCore    {};

Is this a common way to do this job? or there is some patterns out there that I can fit my ideas into?

thanks a lot

---

I'm not sure this is a pattern, I would just use an interface.

class DataProcessorCore {
   public virtual void doProcessing() = 0;

   // Any other virtual methods, but no implementation
};

class DataProcessor : public DataProcessorCore {
   // implement the methods
};

Now anything that just needs the functionality of DataProcessor should take the interface class instead of the concrete class. If I understand you correctly, then this achieves separating the methods from the methods.

---

Maybe the Strategy Pattern is the one you are looking for. This would give you the oppurtunity to change the methods working on your data at runtime.

wiki: strategy pattern

---

At first I thought it's C# question and extension methods came into my mind, but when I spotted this is C++ I tryed to find analogy and, as I understand, the analogy is

Argument dependent name (Koenig) lookup

Reference:

Extension Methods - A Polished C++ Feature

---

First, I don't see why you want other function to see an object with data and no methods. What is the problem in passing the usual kind of object, which has both?

Second, what should that function see? An object with all-public member variables? Or just one with private member variables and fewer accessor/mutator methods than DataProcessorCore?

A relatively common idiom in C++ is to put as many methods as possible outside the object.

So your solution could be something like this:

class DataProcessor {
   // Fill in only the basics. Member variables and a small set of "core" functions to access/modify them.
};

void ComplexOperation(DataProcessor& proc) { ...}
float AnotherOperation(DataProcessor& proc, int i) { ...}

And then eliminate DataProcessorCore entirely. You don't need it, because you have the object containing the data (and, I'd assume, a small set of core functions), and all the more extensive functionality can be implemented as free functions instead of in a dereived class.

The standard library uses this technique extensively. Think of std::sort which is not a member of individual container classes, but a free function that can be called on a container.

---

An Interface that offers only getters()?

---

I'm not sure I understood exactly what you want, but maybe the Decorator pattern is one to have a look at.

The Decorator Pattern attaches additional functionality to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

Wiki : Decorator Pattern

---

As Holger Says the pattern that will fit is the Strategy, separating the logic of processing the data from the data-structure itself. More insight on what they try to do would be useful, patterns emerges, they are not applied.

---

I think we can achieve this by combining inheritence and abstraction patterns

interface Operations {
  public void printValue();
}

public class Data {

  private String value;

  protected void loadValues() {
   this.value = "somevalue";
  }

  protected String getValue() {
    return this.value;
  }
}

public class DataProvider extends Data implements Operations {
  public Operate() {
    super.load();
  }

  public void printValue() {
    System.out.println("Value is "+getValue());
  }
}

public class Consumer {
  public static void main() {
    Operations operate = (Operations) new DataProvider();
    operate.printValue();
  }
}