What principles do you generally follow when doing class design?
相关问题
- how to define constructor for Python's new Nam
- Keeping track of variable instances
- Object.create() bug?
- std::vector of objects / pointers / smart pointers
- Name for a method that has only side effects
相关文章
- 接口B继承接口A,但是又不添加新的方法。这样有什么意义吗?
- NameError: name 'self' is not defined, eve
- Implementation Strategies for Object Orientation
- Check if the Type of an Object is inherited from a
- When to use Interfaces in PHP
- Are default parameters bad practice in OOP?
- How to return new instance of subclass while initi
- In OOP, what is the best practice in regards to us
Principles Of Object Oriented Class Design (the "SOLID" principles)
Source: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
Don't forget the Law of Demeter.
Basically I get away with programming to interfaces. I try to encapsulate that which changes through cases to avoid code duplication and to isolate code into managable (for my brain) chunks. Later, if I need, I can then refactor the code quite easily.
Domain Driven Design is generally a good principle to follow.
A thing which I would like to add to all this is layering, Define layers in your application, the overall responsibility of a layer, they way two layers will interact. Only classes which have the same responsibility as that of the layer should be allowed in that layer. Doing this resolves a lot of chaos, ensures exceptions are handled appropriately, and it makes sure that new developers know where to place their code.
Another way to design is by designing your class to be configurable creating a mechanism where the configuration can be plugged in your class, rather than overriding methods in sub classes, identify what changes, see if that can be made configurable and ensures that this functionality is derived from configurations
The most fundamental design pattern should be KISS (keep it simple stupid) Which means that sometimes not using classes for some elements at all it the right solution.
That and CRC(Class, Responsibility, Collaborators) cards (write the card down in your header files, not on actual cards that way they because easy to understand documentation too)