research on class design

research on class design. if we have a legacy software, how to improve it? this article gives some thoughts, then follow these threads, we can move on broader view.

1. Discovering Hidden Design

Choosing Structure over Naming

There are many qualities that can make designs better. One that really helps names that have clear meaning in the domain. We can use those names to help us determine the relationship between different parts of our code. Beyond that, we can fall back on the classical ideas of coupling and cohesion — a design is good when it maximizes cohesion and minimizes coupling. Although the justification is rarely noted, it's likely that the concepts of coupling and cohesion are useful to us because they are cognitive aids for understanding unfamiliar things [1]. We can understand only so much at a time, so the pieces we attempt to understand should be small and their dependencies should be clear and few. We should be able to understand a chunk of code by itself. Good naming helps us by giving us a mental handle for the other chunks of code that a particular chunk depends upon. It helps us build up a web of understanding.

There are times, however, when our code has internal clustering in its graph and we can't conceive of good names for the clusters. If that is the case, is it acceptable to choose a poor name and move forward with class extraction? Aren't we making our code a little worse if we do that? Again, everyone has to make their own judgment on a situation-by-situation basis, but it's worth considering that naming is only one aspect of program understanding. Code, in general, becomes more understandable when we are looking at chunks that don't have many dependencies on externals. When we can look at a piece and feel that we can understand it locally, we are more likely to be able to change it correctly. The fact that we don't have a good name for it is regrettable, but there is always the chance that we might find a good name later, or that we might eventually merge the the extracted class back into its original class and find a better to way to refactor. In the meantime, we get the benefit of local understanding. If that understanding is constructive relative to the original state of the code, the refactoring might be worthwhile.

2. Coupling and Cohesion
3. Structured Design
4. Writing code for other people: cognitive psychology and the fundamentals of good software design principles
5. code of damned: good website
6. How to avoid temporal coupling in C#
7. Design for change: Coupling and cohesion in object oriented systems
8. All You Need to Know About UASP
9. Identifying Object-Oriented Classes
10. High Cohesion & Low Coupling using SOLID Principles -- Part 1
11. High Cohesion & Low Coupling Using SOLID Principles -- Part 2
12. Adaptive Code via C#: