Reputation: 830
Currently, I'm working on a C# "School System Project" that is customized to Kindergarten, Elementary and high schools. To this end, I've created three distinct projects that literally have similar classes with customized features.
The problem is that every time I've to modify a class (mainly due to bugs and new features), I'm required to update those similar classes on the three projects.
Now, I came to my senses and learnt that my design pattern should have been better than this. What's the industry standard for projects of my type where they share similar classes with customized features? Should I consider creating library classes that all can consume or there is a better option?
Upvotes: 0
Views: 218
Reputation: 2014
since you are saying certain classes are common between three project and you use them seperately in all those three projects. Now whenever you want to make changes to those common class, you need to make change in all those three projects.
Its surely calls for a design principle( OO principle) to follow.
"Encapsulate what varies"
extract all those common classes outside those three project, keep them in a single class or single project if it has more than one class, like a utility project. then share that utility project between all three projects.
now when ever any new features to be added or bug fix in the common class. its a one place change.
Upvotes: 0
Reputation: 48279
Two fundamental design patterns for dealing with slight changes of constant structure are
Template Method and Strategy
They differ only at technical level but share the common principle - sharing whatever is possible to share and differ only where differences occur.
Upvotes: 1
Reputation: 671
The bugs raises when you try modify your classes. So you have to implement SOLID Principles in your class design. Specially Single responsibility, Open/Closed, Interface Segregation and Dependency Inversion/IOC. You can read following article for learning about SOLID principle (if you don't have enough idea about solid) http://www.codeproject.com/Articles/93369/How-I-explained-OOD-to-my-wife
Then Introduce Repository and Unit of Work pattern for Data Access http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application
In business logic you will use patterns based on your logic like multiple same logic you can use factory method pattern, have to adapt more than one class you can use adapter class, for sending any notification you can use observer pattern etc.
Upvotes: 0
Reputation: 12626
Create a library, define a base class School with common properties and functions.
public abstract class School
{
public string Name { get; set; } // common property for each school
public int GetStudentCount() // common method for each school
{
}
}
Then define children classes for each of your school and specify their behaviour that other school don't have.
public class Elementary : School
{
public string SomethingSpecial { get; set; }
}
You can also use abstract and virtual methods and properties in order to define basic behaviour that should or can be overriden.
This way, you will have just one library defining domain objects (simply all entities you use, such as School, Student, Teacher, etc.) and ther behaviour. And whenever you will have to change something, you just operate on this single library.
You can also check some design patterns, like Visitor and Factory method, so your new architecture design is clear.
Upvotes: 1
Reputation: 4009
I would look into the Abstract Fatory Pattern.
You can see example of it here.
Upvotes: 0