ADT与类的设计

ADT与类的设计

 

个人对ADT的理解是，我们编程时可以从系统任意一个层面去思考，我们可以把精力集中在某一层面的逻辑而不需要过多的考虑底层（相对来说）的实现细节。例如做一个贪吃蛇，我们不需要去关注链表的插入和删除的操作（或者数组元素的操作），我们只需要关心吃食物，随即食物，增长蛇身的操作等。

ADT与类的设计。类的接口应该展现一直的抽象层次，如果一个类包含了多个ADT那么就应该考虑对这个类进行重新设计（如果已经开始实现功能就应该考虑开始重构它！），因为一个业务逻辑层的类是不该包含对数据库的操作的。接口展现一致的抽象，也是类设计的一个原则。

         提供成对的服务。例如开灯，关灯。打开菜单，关闭菜单。获得长度，设置长度等等。

         把不相关的信息转移到其他类中。一个类的职责要单一，不该做很多类的事情，只能做一类事情。一个类也不应该对另一个类过多的依赖（除非这个类完全是一个proxy），应避免把两个类混在一起使用。

         针对接口编程。 编程中更多的应该考虑当前类（或方法）应该做的事和不该做的事情，把自己该做的事情做完做好就ok，应该信任另一个类为你做的事情。任何时候，也不应该为了实现一个功能而实现它，每一个功能的实现，都是为了完成我们设计时，分配给这个类的任务，它有职责完成这些任务，并有义务给其他类提供一致的抽象。类之间也需要“团队合作”。另外，一个类不应过多的了解另一个类。比如调用一个方法，是不应该知道先调用A才能调用B的细节的，一切都应该封装起来，隔离变化，降低每个类（和方法）的复杂度。通常，当你发现自己需要查看类的内部实现来得知如何使用这个类的时候，你就不是在针对接口编程了。透过了接口编程的话，封装性就被破坏了，抽象能力也遭殃了。

         同时考虑抽象和内聚。高内聚的类通常具有很好的抽象，很好的抽象通常也会聚会很高的内聚性。如果发现内聚性不够，就应该问问自己，这个类是否做了不该做的事情，是否展示了一致的抽象。

         展现一致的接口也可以提高代码的可读性。

         不知如何使用一个类时，不是去查看它的内部实现，而是找到这个类的作者，告诉他你不知道如何使用这个类，他check out出来，修改这个类以及其接口，然后告诉你，“你现在知道如何使用它了。”