A super class
Transaction has two subclasses
Transaction is composed of multiple events that occur in time for a specific key (a file, a person, etc.). Depending on events, some transactions have to be discarded.
A concrete example with a file "key" would look like:
TransactionArepresents a set of file events whereas the file is being read, let's call it
TransactionBis a set of file events for the file being written, calling it
A same file can be read or write at any given time.
An event list would look like this (very simplified):
- Open FileA
- Open FileB
- Create FileB
- Read FileA
- Write FileB
- EOF FileA
- Read FileB
- EOF FileB
At step 1 and 2, the transaction is yet to be known, we have needed information (a timestamp, a file name, a username, etc.) but we don't know yet if it's a
My rational would be to create a class
Transaction that holds enough services to analyze events and a method
who_i_am that returns
WRITE if the pattern fits (Ex.: Open -> Read -> EOF for a read transaction),
None if no pattern found.
At some point the transaction type will be known and I think it would be a good approach to morph
Transaction into a
TransactionRead. I'm coding in Python atm, but I've never heard of a concept like this. Is it bad, why? Do languages provide tools for late inheritance?