【问题标题】:Naming abstract classes and Interfaces in TypeScript [closed]在 TypeScript 中命名抽象类和接口 [关闭]
【发布时间】:2017-06-15 00:59:40
【问题描述】:

这个问题存在争议,没有一致性,所以我想澄清一下 typescript 的类、文件名、后缀和其他命名标准。 我想知道,您在 Typescript 项目中如何命名抽象类、接口和逻辑组织代码?

可能的解决方案:

对于接口:

  • 以“I”为前缀
  • 以“接口”为后缀
  • 根本没有添加任何东西

对于抽象类:

  • 以“抽象”为前缀
  • 类似“Base”的前缀
  • 一无所有

C# 示例

public class User : AbstractUser, IUser

Java 和 PHP 相同

public class User extends AbstractUser implements UserInterface

在打字稿中

export class User extends AbstractUser implements UserInterface

这是在基于 C#、Java 和现代 PHP7+ 等语言的框架中使用的常规方法


Microsoft 建议添加“Interface”作为后缀,这对我来说是正确的。 https://github.com/Microsoft/TypeScript-Handbook/blob/master/pages/Interfaces.md#class-types

另一个流行的风格指南建议不要为接口添加任何前缀的后缀,对我来说违反了规则、可读性和整体看起来是错误的。 https://basarat.gitbooks.io/typescript/content/docs/styleguide/styleguide.html#interface

export class User extends AbstractUser implements User

【问题讨论】:

    标签: javascript node.js oop typescript naming-conventions


    【解决方案1】:

    我们的节点应用程序对接口的要求很高 - 它们无处不在,我们进行类型检查和类型提示,因此有意义的名称对我们来说非常重要。

    import {MediaInterface} from 'app/models/mediaInterface';
    import {ServerInterface} from 'app/server/serverInterface';
    import {UserInterface} from 'app/models/userInterface';
    
    export class MediaStorage extends AbstractStorage implements StorageInterface {
    
      /**
       * current user
       * @private
       */
      private user: UserInterface;
    
      /**
       * @constructor
       * @param {ServerInterface} app
       */
      constructor(private app: ServerInterface) {
        // ...
      }
    
      /**
       * @param {UserInterface} user
       * @returns {Promise<any>}
       */
      public deleteUserMedia(user: UserInterface): Promise<any> {
        // ...
      }
    
      /**
       * @param {object} req request
       * @param {object} res response
       * @returns {Promise<MediaInterface>}
       */
      public create(req: any, res: any): Promise<MediaInterface> {
         // ...
      }
    
    }
    

    【讨论】:

      【解决方案2】:

      我认为这是一个品味问题。

      我会使用接口名称User 而不是IUserUserInterface 如果 用户对象可以用纯JSON 来描述,因此是一个没有类的纯数据对象行为。因为你可能永远不需要一个实现类,你总是可以使用对象字面量:

      interface User {
          name: string;
          email: string;
      }
      
      function createDummyUser(): User {
          return {
              name : "Alice",
              email: "a@wonder.land"
          }
      }
      

      我会使用对象抽象类的普通名称(如“Car”),并为非抽象类使用特定名称(如“Beetle”)。您可以通过保护构造函数来确保您的抽象实现不会被错误地使用:

      class Car {
          protected constructor() {
          }
      }
      
      const fail = new Car();  // error because c'tor is protected
      
      class Beetle extends Car {
             public constructor(){
                 super();
             }
      }
      
      let itBe = new Beetle();  // here we go!
      

      【讨论】:

        猜你喜欢
        • 2015-06-27
        • 1970-01-01
        • 2012-03-25
        • 2023-04-03
        • 1970-01-01
        • 2021-12-11
        • 2017-11-15
        • 2016-09-27
        • 2017-02-19
        相关资源
        最近更新 更多