I would recommend doing a spike for this refactoring before trying to provide a class diagram -- I would personally learn a lot that would have a major effect on the resulting class design that I can only guess about up front.
Another major challenge is in trying to keep the resulting .gfs file unchanged while straightening up the class design. The effort may be worthwhile, but I don't think the spike will be quick or trivial. The main reason to have any 1-to-many relationships in this class design (ex: CacheStats to RegionStats) is to build in aggregation, such as number of puts per Region and number of puts across every Region in the Cache. We also need PartitionedRegion aggregates such as number of puts across every BucketRegion for a specific PartitionedRegion -- which is also a 1-to-many of PartitionedRegionStats to (Bucket)RegionStats relationship (and of course a Cache can have many PartitionedRegions). I would prefer to come up with some sort of reusable statistic aggregation design as part of the spike. On Wed, Jul 10, 2019 at 4:49 PM Mark Hanson <mhan...@pivotal.io> wrote: > Hi All, > > As many of you may know our structure for our perf stats is not great. I > would like to propose we refactor the code to have the following > inheritance model, which Kirk and I came up with. > > It is my belief that fixing this will allow future features to be > implemented in a much less painful way. > > Thoughts? > > Thanks, > Mark >
