design patterns

I am looking to do some changes to my existing component at work and am starting to see the advantages of using design patterns. The problem is I have some specific examples for which I am trying to use what I learned in design patterns and am having issues doing that. Here is what I am trying to do.

I have a existing component that monitors the performance of say n different software packages each catering to a specific type. i.e Existing component

• package A for type 1
• package B for type 2
• package C for type 3 and so on....

Each package does some performance monitorings and has its own data logs, records, etc.. Each package has only one type now.

In the future we may have a new feature coming up for

• including a analysis log. This will have the data log that is alrea开发者_开发知识库dy existing and add some other data on top of that.
• Supporting multiple types for a package. i.e package A for type1, type 2 (Bitype) package B for type 1,type 2, type 3 (tritype)

Looking at this, I was thinking adapter pattern could be of use here. I could use the existing component as the adaptee . Then do the new functionality in the adapter class. My target will be the final component with the 2 functionalities added.

Since, I am dealing with existing code here, I think I should add a adapter class to adapt the new features. But I am having second thoughts because, adapter is for making one interface usable with another interface. Here I have existing interface, but I do not have a target interface already present. I will have to create both the adapter and the target too. So am confused if this definition fits my requirement or not.

Could someone who has some experience with design patterns make your suggestions here? Thanks

The software is for sportsmen. The existing system tracks the training details of these sportsmen. It has details like training log, what brands they prefer and personal details etc. There is a separate package created for a type of sportsmen. sportsmen types are tennis player, golf player, swimmer etc.So a sportsmen can be in one type only , either tennis player or golf player and not both. In the future there will be a requirement to include more functionality

1. To include a performance log (i.e take the already existing logs and add performance log details on top of it).
2. There can be overlapping sportsmen interests i.e a single sportsmen can be participating in more than one sport. A single sportsmen could be participating in tennis, gold and swimming.

Hope it is clear now.

Unfortunately, you can't implement patterns that would be suggested here. You must be familiar at least with the most common ones and understand when to use each of them. It can be happened that you even create your own patterns for some particular cases.

Your description is not very clear for me, but I can suggest you to look into direction of Bridge pattern and try to make something like:

abstract class Sportsmen {
  ILogger logger;
  List<IPackage> packages;
  List<IInterest> interests;
}

interface IPackage {
  IList<ISomeType> SupportingTypes {get;set; }
}

I would recommend you a great free online book about patterns: http://gameprogrammingpatterns.com/

Good luck!

This looks like a good case for the Decorator pattern.

You can have an abstract data logger from which you would derive your initial package A, B, C etc. In addition, you'd create a 'decorator' which is an abstract class deriving from your base data logger, and also having a base data logger as its member.

You can build on top of the functionality provided by this member datalogger and expose it as the functionality of this decorator. (e.g. the LogData method of the AnalysisDecorator would log some analysis information in addition to the data that it logs) You can create one decorator for every functionality that you want to add.

Now if you want to add some additional functionality to package A, you can wrap it with the decorator of the desired functionality. This way you can have any combinations of added functionality to your base package.

Hope this helps!