Design issues - observer,factory, composition and more

So i need to design something like that :

I have a spreadsheet which can contain numerous sheets (maybe of different kinds).

each sheet has let's say 1A-9Z cells.

in each cell i can have one the above : String, Number, Formula - which means the cell gets an operation like +,-,/,* etc... and cells numbers, and in the cell i have the result of the operation.

I need to design the classes, so in the future i can add other type of cells (besides string/number/formula) and add also different kind of operation to the formula - all in an easy manner.

how would u design it ?

I though about something like this :

class SpreadSheet
{
  private:

  vector<Isheet> sheets;

  public:

  write(Isheet sheet,int CellNum,ICell value);
  GetValue(Isheet sheet,int CellNum,ICell value);
  AddSheet(ISheet sheet);

 };


  class Isheet
  {
    vector<ICell> cells; // can i do something like that ? cause ICell is a template      
  };

 template<class T>
 class ICell
 {

   Vector<Iobserver> observers;

   public:
    T GetValue() {return m_value;};
    SetValue(T val) {m_value=val;};
    AddObserver(Iobserver obs);
    NotifyAll();
    GetPos() {return m_pos;};


   private:
    T m_value;
    int m_pos;

   };


  class CInt : public ICell<int>
 {

 };

 class CString : public ICell<std:string>
 {

 };

 class CFormula : public ICell<int>, Iobserver
 {

 };


 class Iobserver
 {
    Update(int pos);
 };

anyway, i'm really not sure where should i create the cell Concrete classes (CInt,Cstring,CFormula), should i use some kind of factory ? where to put the factory ? inside ISheet ? and my main concern, where should i calculate the the right result for a CFormula cell ? i used the observer pattern to开发者_如何学编程 keep the formula cell updated in case of other cell's changes.

any advices would be great

---

As an engineer to whom 'design pattern' means very little, I recently had the pleasure of working on a project (ongoing) with some computer scientists. I have implemented all of the things they call 'observer patterns', 'factories', 'reactors', etc before, but to be honest I found it a thoroughly unhelpful way to think about design.

What you need is a solution to your problem. Think about: data flow, think about execution paths, think about what needs to cause what.

Don't try to shoe-horn your problem into a textbook solution, likelihood is, it won't fit very well, and you'll end up with far more levels of abstraction than are useful, and which make the code very difficult to understand when you return to it months later.

My two cents, hope this is helpful.