{"id":728,"date":"2021-03-23T08:49:11","date_gmt":"2021-03-23T12:49:11","guid":{"rendered":"https:\/\/www.alpharithms.com\/?p=728"},"modified":"2021-07-20T22:45:05","modified_gmt":"2021-07-21T02:45:05","slug":"liskov-substitution-principle-lsp-solid","status":"publish","type":"post","link":"https:\/\/www.alpharithms.com\/liskov-substitution-principle-lsp-solid-114908\/","title":{"rendered":"Liskov Substitution Principle (LSP): SOLID Design for Flexible Code"},"content":{"rendered":"

The Liskov Substitution Principle (LSP) is one of five SOLID object-oriented design principles. It states that a superclass object should be replaceable with a subclass object without breaking the functionality of the software. It is a type of behavioral subtyping defined by semantic, rather than syntactic, design consideration.<\/p>\n

The LSP is used to help limit code smell (a.k.a. design smell<\/a>) in object-oriented programming (OOP). It is a semantic<\/em> principle that describes ideal\u00a0behavioral<\/em> considerations for object-oriented feature designs. The LSP makes heavy use of inheritance<\/em> and polymorphism<\/em> and commonly leverages language features such as interfaces when multiple inheritances is not supported.<\/p>\n

Introduction<\/h2>\n

The Liskov Substitution Principle was first introduced by Barbar Liskov informally in a keynote address in 1987 (2) and formerly in her and Jeannette Wing’s 1994 paper A Behavioral Notion of Subtyping<\/em> (1). This paper describes the LSP as follows:<\/p>\n

The relationship [of how subtypes and sypertypes] should ensure that any property proved about supertype objects also holds for its subtype objects.<\/em><\/p>\n

The Liskov Substitution Principle is one of five core pillars of the SOLID principles of object-oriented design<\/a> outlined in Robert C. Martin’s 2003 book Agile Software Development, Principles, Patterns, and Practices <\/em>(3). These principles outline high-level strategies to develop more flexible, maintainable, and extensible software.<\/p>\n

Check Out<\/strong>: Complete List of Computer Science, Engineering, and Programming Books<\/a><\/p>\n

The Liskov Substitution Principle<\/strong> is supported by object-oriented design abstraction concepts of inheritance and polymorphism. These are often realized as the subclassing of superclass objects using abstract data types like interfaces that define common behavior.<\/p>\n

LSP Example Code<\/h2>\n

To exemplify the LSP let us consider a hypothetical Stock trading application. This application needs to facilitate Transactions like Buy and Sell. In addition, the application needs to support multiple transaction types for different security types such as bonds, stocks, and options. We can approach this with the Liskov Substitution Principle<\/strong> in mind by inheriting from a base Transaction class as such:<\/p>\n

\/**\r\n* The base Transaction class that defines a buy and sell feature.\r\n*\/\r\nclass Transaction{\r\n    \r\n    public void buy(String stock, int quantity, float price){\r\n        \/\/ implement buy logic here\r\n    };\r\n    public void sell(String stock, int quantity, float price){\r\n        \/\/ implement sell logic here\r\n    }; \r\n}\r\n\r\n\r\n\/**\r\n* A subclass implementation of the Transaction class that \r\n* defines Stock-specific buy and sell action logic.\r\n*\/\r\nclass StockTransaction extends Transaction{\r\n    \r\n    @Override\r\n    public void buy(String stock, int quantity, float price){\r\n        \/\/ implement Stock-specific buy logic here\r\n    }\r\n\r\n    @Override\r\n    public void sell(String stock, int quantity, float price){\r\n        \/\/ implement Stock-specific sell logic here\r\n    }\r\n}<\/pre>\n
In this example, the Transaction class is subclassed by StockTransaction<\/code> where the base buy()<\/code> and sell()<\/code> methods are overridden to provide the desired functionality. This approach, while basic and lackluster in many regards, conforms to the Liskov Substitution Principle by assuring that substituting a subclass instance of StockTransaction<\/code> for a superclass instance of Transaction<\/code> will not break core functionality. More concretely, the substituted subclass instance will still provide buy<\/code> and sell<\/code> functionality that could be called in the same manner.<\/p>\n
Final Thoughts<\/h2>\n
The Liskov Substitution Principle has been a core tenant of good software design for decades. Its inclusion by Martin in his 2003 Agile Software Development, Principles, Patterns, and Practices<\/em> solidified<\/span> it (pardon the pun) as a standard principle within the field of software design.<\/p>\n
As with other principles of SOLID design, the LSP can become an\u00a0antipattern<\/em>\u2014meaning sometimes the added complexity is not worth the tradeoff. Barring certain such cases, the LSP can help ensure a more flexible, maintainable, and extensible design. Learning the ways of the LSP will, at the very least, help one become a better software designer by understanding when not<\/em> to apply it!<\/p>\n
References<\/h2>\n
    \n
  1. Liskov, Barbara H., and Jeannette M. Wing. \u201cA Behavioral Notion of Subtyping.\u201d ACM Transactions on Programming Languages and Systems<\/i>, vol. 16, no. 6, 1994, pp. 1811\u201341. doi:10.1145\/197320.197383.<\/li>\n
  2. Liskov, B. \u201cData Abstraction and Hierarchy.\u201d (1987).<\/li>\n
  3. Martin, Robert C. Agile Software Development, Principles, Patterns, and Practices<\/i>. 1st ed., Pearson, 2002.<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
    The Liskov Substitution Principle (LSP) is one of five SOLID object-oriented design principles. It states that a superclass object should be replaceable with a subclass object without breaking the functionality of the software. It is a type of behavioral subtyping defined by semantic, rather than syntactic, design consideration. The LSP is used to help limit […]<\/p>\n","protected":false},"author":2,"featured_media":731,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[246],"tags":[300,305,304,306,299],"acf":[],"_links":{"self":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts\/728"}],"collection":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/comments?post=728"}],"version-history":[{"count":8,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts\/728\/revisions"}],"predecessor-version":[{"id":742,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts\/728\/revisions\/742"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/media\/731"}],"wp:attachment":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/media?parent=728"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/categories?post=728"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/tags?post=728"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}