This talk goes through many of the Object-Oriented Programming principles and characteristics. Things that all developers should have in mind while writing code.
Class invariants are established during construction and constantly maintained between calls to public methods.
LSP&apos;s importance is noticed mainly when it is violated. Client code needs to do instanceof or type casting.
LSP&apos;s importance is noticed mainly when it is violated. Client code needs to do instanceof or type casting. violation of the Liskov Substitution Principle since the methods will weaken (violate) the postconditions for the Rectangle setters, which state that dimensions can be modified independently.
Client pays fee (obligation) and get a product back (benefit). Supplier gives product to client (obligation) and get money in exchange (benefit). Three questions we need to ask when defining a method: - What does it expect? - What does it guarantee? - What does it maintain?
Pre-condition checks using assertions are quite often associated with Design by Contract. Some languages like Eifel have native support. In Java, frameworks like JContract are meant to do check pre-condition, post-condition and invariants using annotations.
Side effect examples: a function might modify a global or static variable , modify one of its arguments, raise an exception, write data to a display or file, read data, or call other side-effecting functions. Bugs due to &amp;quot;action at a distance&amp;quot; may arise because a program component is doing something at the wrong time, or affecting something it should not. It is very difficult, however, to track down which component is responsible. Side effects from innocent actions can put the program in an unknown state, so local data is not necessarily local. The solution in this particular scenario is to define which components should be interacting with which others. A proper design that accurately defines the interface between parts of a program, and that avoids shared states, can largely eliminate problems caused by action at a distance.
Red box: TradeService.processTrade(tradeXml) or Order.placeOrder(shoppingBasket) - The closer the code is to the system&apos;s interface, the broader and more generic its responsibility will be. The further away the code is from the system&apos;s interface, the narrower and more specific its responsibility will be. - The closer the class is to the system&apos;s interface, the more delegation the class will do. The further way the class is from the system&apos;s interface, less delegation the class will do.
God object is an object that knows too much or does too much . The God object is an example of an anti-pattern .
- Low coupling often correlates with high cohesion, and vice versa. - Sign of good design and well maintainable code.
Content coupling (high) Content coupling is when one module modifies or relies on the internal workings of another module (e.g., accessing local data of another module). Therefore changing the way the second module produces data (location, type, timing) will lead to changing the dependent module. Common coupling Common coupling is when two modules share the same global data (e.g., a global variable). Changing the shared resource implies changing all the modules using it. External coupling External coupling occurs when two modules share an externally imposed data format, communication protocol, or device interface.This is basically related to the communication to external tools and devices. Control coupling Control coupling is one module controlling the flow of another, by passing it information on what to do (e.g., passing a what-to-do flag). Stamp coupling (Data-structured coupling) Stamp coupling is when modules share a composite data structure and use only a part of it, possibly a different part (e.g., passing a whole record to a function that only needs one field of it). This may lead to changing the way a module reads a record because a field that the module doesn&apos;t need has been modified. Data coupling Data coupling is when modules share data through, for example, parameters. Each datum is an elementary piece, and these are the only data shared (e.g., passing an integer to a function that computes a square root). Message coupling (low) This is the loosest type of coupling. It can be achieved by state decentralization (as in objects) and component communication is done via parameters or message passing (see Message passing ).
What about encapsulation? How can we write tests for this?
1. Software Craftsmanship by Sandro Mancuso Twitter: @sandromancuso http://www.londonswcraft.com How much do we know about OOP/OOD?
2. Inheritance >> Before we start What can we expect from this session?
16. Single Responsibility Principle - SRP <ul><li>How do we know a class or method has a single responsibility? </li></ul><ul><ul><ul><li>- Outside view </li></ul></ul></ul><ul><ul><ul><li>- Inside view </li></ul></ul></ul>SRP violations >> What about the “else” keyword? What does it imply when we use it?
22. Coupling Types >> Coupling or dependency is the degree to which each program module relies on each one of the other modules - Low coupling often correlates with high cohesion, and vice versa. - Sign of good design and well maintainable code.
29. Dependency Inversion Principle - DIP DIP >> <ul><ul><li>High-level modules should not depend on low-level modules. Both should depend on abstractions </li></ul></ul><ul><ul><li>Abstractions should not depend upon details. Details should depend upon abstractions </li></ul></ul>Violation What if we want to write it to disk? How can we reuse Copier?
34. Open Closed Principle (OCP) LoD >> Software entities (classes, modules, functions, etc) should be open for extension, but closed for modification <ul><li>Achieved via </li></ul><ul><ul><li>Inheritance and override (Bertand Meyer – 1988) </li></ul></ul><ul><ul><li>Use of abstract classes to define the interface and multiple concrete implementations </li></ul></ul><ul><ul><li>Achieved by template method, proxy, delegate, chain of responsibility, specification and other patterns. </li></ul></ul>Misconception : Closed to modification does not mean that we cannot change a class. It means that we should avoid modifications that affect clients. Is it still a good idea today?