The following message was posted as part of the Dissertation House’s blog within the “Winter 2014 Challenge” thread.  It is repeated here so that those who read the general blog, will receive the message as well. At the time of the original post, there were 112 messages. Now, there are 134. Good job “DHers!”

The Winter 2014 Challenge thread is here: https://dissertationhouse.wordpress.com/blog-online-challenge/winter-2014/. Feel free to join. The thread will be active until the end of June 2014.

————————————————————————-

January 23, 2014

Buenos tardes a todos!!/Good afternoon to everyone!!

Estoy en Ecuador y estoy muy feliz porque hay 112 mesajes aqui!/I am in Ecuador and am very happy because there are 112 messages here!

Congratulations to all of you on your persistence! What does your persistence mean? If you blogged in during the snow storm, you have already proven that you have what it takes. You have drive and determination. That is a large part of the battle. The Dissertation House exists to assist you with navigating the process and adding “knowledge of the process” to your enthusiasm.

My message for you today is simple:

1) Don’t stop until you’re done!
Dr. Carter-Veale, Dr. Cortes, and some of you have seen people in the DH who felt frustrated, tired, and upset, BUT … they finished. They defended, handed in their dissertations, and walked across the stage with the big robe and the thick bars on their arms. That will be you … soon.

2) Pay close attention to the tips that you will receive in the DH.
These are tried and tested methods. With a pure heart, I ask you to “just do it.”

3) As much as possible, stay in close contact with your advisor.
Your advisor needs to know that you are working.You also want to be sure that you are on the right page and that the expectations are in sync.

4) Utilize the community that is being established in the DH. It helps!
Working on the dissertation does not have to be a lonely, isolated process. You are now surrounded by a community of scholars with like minds and goals. There’s energy there. Feed on it. Use it. Bask in it!

5) Embrace the process.
This is the hard one. The process is difficult, but there are parts of the process that are worth the frustration. The dissertation process teaches you how to deal with long-term projects, how to deal with contrasting personalities (e.g., your committee), how to deal with rejection, and how to handle your own emotions. This is a maturation process. You may not know all of the answers, but you learn how to investigate solutions, and you learn to think through options. You may not like all of the people with whom you’re working, but you learn how to negotiate for what you need, and you learn to appreciate the strengths that people bring to the table, regardless of whether or not you care for them personally. You can still learn from “Painful People.” You can still learn from people, even when they aren’t providing information or assistance in a way that is amiable or projecting a feeling of giving. Take what they provide and find its worth. Above all, learn to appreciate the process of becoming more adept in your field.

Overall, I’m sorry that I’m not there in person for this session, but feel free to make an appointment with me to talk when I return to UMBC in February. Good luck to all of you! Congratulations on your hard work and keep it up. Those letters … “P,” “h,” and “D,” are dangling, hanging around, waiting for you to finish so that they can accompany your name!

Best regards,
Renetta Tull

————————————————————————————–

The Dissertation House is a program of PROMISE: Maryland’s AGEP

Dr. Wendy Carter-Veale is the “Head Coach” for the Dissertation House.

"UMBC Suits You" is collecting new and gently used professional clothing as part of Career Week in April.  Students will have the opportunity to learn about dressing professionally and will then be able to select one free outfit to use in their job search. We are asking staff to donate new and gently used professional clothing at collection bins around campus from February 11th - March 11th.

Starting February 11th, Professional Clothing can be dropped off at the following on-campus locations:

• Career Services Center, Math/Psych 212: 8:30 a.m. – 5 p.m. (Mon-Fri)

• The Women’s Center, The Commons: 

9 a.m. – 7 p.m. (Mon-Thurs), 9 a.m. – 5 p.m. (Fri)

• Commons Info Desk: 7:30 a.m. – 12 a.m. (Mon-Thurs), 

7:30 a.m. – 1 a.m. (Fri), 8 a.m. – 1 a.m. (Sat), 10 a.m. – 11 p.m. (Sun)

• Residential Life Office, Erickson Hall: 8:30 – 4:30 p.m. (Mon-Fri)

CWIT Office (ITE452)  8:30 a.m. – 5 p.m. (Mon-Fri)

• RAC Front Desk: 7:30 a.m. – 9 p.m. (Mon-Fri), 12 p.m. – 6 p.m. (Sat-Sun)

• The Shriver Center, Public Policy Building: 8:30 a.m. – 5 p.m. (Mon-Fri)

• Alumni House: 8:30 a.m. – 5 p.m. (Mon-Fri)

UMBC Alumni and Community Members are encourage to drop off donations at some of our neighborhood locations:

• Alumni House: 8:30 a.m. – 5 p.m. (Mon-Fri)

• UMBC Training Centers: 8:00 a.m. – 5 p.m. (Mon-Fri)

• bwtech (Cyber Incubator): 9 a.m. – 6 p.m. (Mon-Fri)

• Catonsville Chamber of Commerce 10:00 a.m. – 3 p.m. (Mon-Fri)

• Baltimore County Public Library- Arbutus 9:00 a.m. – 5 p.m. 

 • Items that will be accepted: dresses, shell tops, button-up shirts and blouses, skirts, blazers, dress pants, belts, ties, skirt suits and suits. 

• Items that will NOT be accepted: jewelry, handbags, shoes, and general accessories.

For more information on accepted information check out the link here.

Clothing donations will be used to benefit UMBC students and will not be considered as gift-in-kind or donation to UMBC. Clothing donations are not tax deductible. Any leftover clothing will be donated to local non-profits, Suited to Succeed and the Franciscan Center’s Attire 4 Hire program.

Special thanks to ZIPS dry-cleaning and T. Rowe Price for partnering with us once again on this endeavor.

Any questions or concerns about this project can be addressed to Kate Phelps, Career Services Center, kphelps@umbc.edu, 410-455-2216.

***Students be on the look out for more information about UMBC Suits You occurring on April 5 & 7 when you will be able to pick up a professional outfit.***

UMBC Career Week will occur April 7- April 10. Detailed information will be available soon. 

Entomologists believe bed bugs have started making a comeback in places like Philadelphia in recent years. A report that aired on WHYY in Philadelphia January 17 examines the city’s battle with bedbugs and how it has evolved.

Dawn Biehler, assistant professor of geography and environmental systems, was interviewed for the story and commented on the history of bedbugs in the United States and how they appeared consistently up until the 40s and 50s.

“It was almost kind of an accepted condition of urban life that every once in a while, you were going to get bedbugs,” Biehler said. “Some people had bedbugs pretty much constantly.”

Bedbugs have made a comeback in places like Philadelphia as they’ve developed resistance to chemicals aimed at pest control, and Biehler commented how bedbugs can cause many problems such as “degradation of mental health” by creating problems such as loss of sleep and family divisions.

You can listen to the full story on WHYY and read the accompanying article here. Biehler also analyzed the history and transformation of the phrase “sleep tight, don’t let the bedbugs bite,” and that can be heard here.

Dawn Biehler is author of Pests in the City: Flies, Bedbugs, Cockroaches, and Rats published in 2013.

The Single Responsibility (SRP), Open/Closed (OCP), Liskov Substitution, Interface Segregation, and Dependency Inversion. Five agile principles that should guide you every time you write code.

Because both the Liskov Substitution Principle (LSP) and the Interface Segregation Principle (ISP) are quite easy to define and exemplify, in this lesson we will talk about both of them.

Liskov Substitution Principle (LSP)

Child classes should never break the parent class' type definitions.

The concept of this principle was introduced by Barbara Liskov in a 1987 conference keynote and later published in a paper together with Jannette Wing in 1994. Their original definition is as follows:

Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

Later on, with the publication of the SOLID principles by Robert C. Martin in his book Agile Software Development, Principles, Patterns, and Practices and then republished in the C# version of the book Agile Principles, Patterns, and Practices in C#, the definition became known as the Liskov Substitution Principle.

This leads us to the definition given by Robert C. Martin:

Subtypes must be substitutable for their base types.

As simple as that, a subclass should override the parent class' methods in a way that does not break functionality from a client's point of view. Here is a simple example to demonstrate the concept.

class Vehicle {
    
    	function startEngine() {
    		// Default engine start functionality
    	}
    
    	function accelerate() {
    		// Default acceleration functionality
    	}
    }

Given a class Vehicle - it may be abstract - and two implementations:

class Car extends Vehicle {
    
    	function startEngine() {
    		$this->engageIgnition();
    		parent::startEngine();
    	}
    
    	private function engageIgnition() {
    		// Ignition procedure
    	}
    
    }
    
    class ElectricBus extends Vehicle {
    
    	function accelerate() {
    		$this->increaseVoltage();
    		$this->connectIndividualEngines();
    	}
    
    	private function increaseVoltage() {
    		// Electric logic
    	}
    
    	private function connectIndividualEngines() {
    		// Connection logic
    	}
    
    }

A client class should be able to use either of them, if it can use Vehicle.

class Driver {
    	function go(Vehicle $v) {
    		$v->startEngine();
    		$v->accelerate();
    	}
    }

Which leads us to a simple implementation of the Template Method Design Pattern as we used it in the OCP tutorial.

Based on our previous experience with the Open/Closed Principle, we can conclude that Liskov's Substitution Principle is in strong relation with OCP. In fact, "a violation of LSP is a latent violation of OCP" (Robert C. Martin), and the Template Method Design Pattern is a classic example of respecting and implementing LSP, which in turn is one of the solutions to respect OCP also.

The Classic Example of LSP Violation

To illustrate this completely, we will go with a classic example because it is highly significant and easily understandable.

class Rectangle {
    
    	private $topLeft;
    	private $width;
    	private $height;
    
    	public function setHeight($height) {
    		$this->height = $height;
    	}
    
    	public function getHeight() {
    		return $this->height;
    	}
    
    	public function setWidth($width) {
    		$this->width = $width;
    	}
    
    	public function getWidth() {
    		return $this->width;
    	}
    
    }

We start with a basic geometrical shape, a Rectangle. It is just a simple data object with setters and getters for width and height. Imagine that our application is working and it is already deployed to several clients. Now they need a new feature. They need to be able to manipulate squares.

In real life, in geometry, a square is a particular form of rectangle. So we could try to implement a Square class that extends a Rectangle class. It is frequently said that a child class is a parent class, and this expression also conforms to LSP, at least at first sight.

But is a Square really a Rectangle in programming?

class Square extends Rectangle {
    
    	public function setHeight($value) {
    		$this->width = $value;
    		$this->height = $value;
    	}
    
    	public function setWidth($value) {
    		$this->width = $value;
    		$this->height = $value;
    	}
    }

A square is a rectangle with equal width and height, and we could do a strange implementation like in the above example. We could overwrite both setters to set the height as well as the width. But how would that affect client code?

class Client {
    
    	function areaVerifier(Rectangle $r) {
    		$r->setWidth(5);
    		$r->setHeight(4);
    
    		if($r->area() != 20) {
    			throw new Exception('Bad area!');
    		}
    
    		return true;
    	}
    
    }

It is conceivable to have a client class that verifies the rectangle's area and throws an exception if it is wrong.

function area() {
    	return $this->width * $this->height;
    }

Of course we added the above method to our Rectangle class to provide the area.

class LspTest extends PHPUnit_Framework_TestCase {
    
    	function testRectangleArea() {
    		$r = new Rectangle();
    		$c = new Client();
    		$this->assertTrue($c->areaVerifier($r));
    	}
    
    }

And we created a simple test by sending an empty rectangle object to area verifier and the test passes. If our Square class is correctly defined, sending it to the Client's areaVerifier() should not break its functionality. After all, a Square is a Rectangle in all mathematical sense. But is our class?

function testSquareArea() {
    	$r = new Square();
    	$c = new Client();
    	$this->assertTrue($c->areaVerifier($r));
    }

Testing it is very easy and it breaks big time. An exception is thrown to us when we run the test above.

PHPUnit 3.7.28 by Sebastian Bergmann.
    
    Exception : Bad area!
    #0 /paht/: /.../.../LspTest.php(18): Client->areaVerifier(Object(Square))
    #1 [internal function]: LspTest->testSquareArea()

So, our Square class is not a Rectangle after all. It breaks the laws of geometry. It fails and it violates the Liskov Substitution Principle.

I especially love this example because it not only violates LSP, it also demonstrates that object oriented programming is not about mapping real life to objects. Each object in our program must be an abstraction over a concept. If we try to map one-to-one real objects to programmed objects, we will almost always fail.

The Interface Segregation Principle

The Single Responsibility Principle is about actors and high level architecture. The Open/Closed Principle is about class design and feature extensions. The Liskov Substitution Principle is about subtyping and inheritance. The Interface Segregation Principle (ISP) is about business logic to clients communication.

In all modular applications there must be some kind of interface that the client can rely on. These may be actual Interface typed entities or other classic objects implementing design patterns like Facades. It doesn't matter which solution is used. It always has the same scope: to communicate to the client code on how to use the module. These interfaces can reside between different modules in the same application or project, or between one project as a third party library serving another project. Again, it doesn't matter. Communication is communication and clients are clients, regardless of the actual individuals writing the code.

So, how should we define these interfaces? We could think about our module and expose all the functionalities we want it to offer.

This looks like a good start, a great way to define what we want to implement in our module. Or is it? A start like this will lead to one of two possible implementations:

• A huge Car or Bus class implementing all the methods on the Vehicle interface. Only the sheer dimensions of such classes should tell us to avoid them at all costs.
• Or, many small classes like LightsControl, SpeedControl, or RadioCD which are all implementing the whole interface but actually providing something useful only for the parts they implement.

It is obvious that neither solution is acceptable to implement our business logic.

We could take another approach. Break the interface into pieces, specialized to each implementation. This would help to use small classes that care about their own interface. The objects implementing the interfaces will be used by the different type of vehicles, like car in the image above. The car will use the implementations but will depend on the interfaces. So a schema like the one below may be even more expressive.

But this fundamentally changes our perception of the architecture. The Car becomes the client instead of the implementation. We still want to provide to our clients ways to use our whole module, that being a type of vehicle.

Assume we solved the implementation problem and we have a stable business logic. The easiest thing to do is to provide a single interface with all the implementations and let the clients, in our case BusStation, HighWay, Driver and so on, to use whatever thew want from the interface's implementation. Basically, this shifts the behavior selection responsibility to the clients. You can find this kind of solution in many older applications.

The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use.

However, this solution has its problems. Now all the clients depend on all the methods. Why should a BusStation depend on the state of lights of the bus, or on the radio channels selected by the driver? It should not. But what if it does? Does it matter? Well, if we think about the Single Responsibility Principle, it is a sister concept to this one. If BusStation depends on many individual implementations, not even used by it, it may require changes if any of the individual small implementations change. This is especially true for compiled languages, but we can still see the effect of the LightControl change impacting BusStation. These things should never happen.

Interfaces belong to their clients and not to the implementations. Thus, we should always design them in a way to best suite our clients. Some times we can, some times we can not exactly know our clients. But when we can, we should break our interfaces in many smaller ones, so they better satisfy the exact needs of our clients.

Of course, this will lead to some degree of duplication. But remember! Interfaces are just plain function name definitions. There is no implementation of any kind of logic in them. So the duplications is small and manageable.

Then, we have the great advantage of clients depending only and only on what they actually need and use. In some cases, clients may use and need several interfaces, that is OK, as long as they use all the methods from all the interfaces they depend on.

Another nice trick is that in our business logic, a single class can implement several interfaces if needed. So we can provide a single implementation for all the common methods between the interfaces. The segregated interfaces will also force us to think of our code more from the client's point of view, which will in turn lead to loose coupling and easy testing. So, not only have we made our code better to our clients, we also made it easier for ourselves to understand, test and implement.

Final Thoughts

LSP taught us why reality can not be represented as a one-to-one relation with programmed objects and how subtypes should respect their parents. We also put it in light of the other principles that we already knew.

ISP teaches us to respect our clients more than we thought necessary. Respecting their needs will make our code better and our lives as programmers easier.

Thank you for your time.

The Single Responsibility (SRP), Open/Closed (OCP), Liskov Substitution, Interface Segregation, and Dependency Inversion. Five agile principles that should guide you every time you write code.

Because both the Liskov Substitution Principle (LSP) and the Interface Segregation Principle (ISP) are quite easy to define and exemplify, in this lesson we will talk about both of them.

Liskov Substitution Principle (LSP)

Child classes should never break the parent class’ type definitions.

The concept of this principle was introduced by Barbara Liskov in a 1987 conference keynote and later published in a paper together with Jannette Wing in 1994. Their original definition is as follows:

Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

Later on, with the publication of the SOLID principles by Robert C. Martin in his book Agile Software Development, Principles, Patterns, and Practices and then republished in the C# version of the book Agile Principles, Patterns, and Practices in C#, the definition became known as the Liskov Substitution Principle.

This leads us to the definition given by Robert C. Martin:

Subtypes must be substitutable for their base types.

As simple as that, a subclass should override the parent class’ methods in a way that does not break functionality from a client’s point of view. Here is a simple example to demonstrate the concept.

class Vehicle {
    
    	function startEngine() {
    		// Default engine start functionality
    	}
    
    	function accelerate() {
    		// Default acceleration functionality
    	}
    }

Given a class Vehicle – it may be abstract – and two implementations:

class Car extends Vehicle {
    
    	function startEngine() {
    		$this->engageIgnition();
    		parent::startEngine();
    	}
    
    	private function engageIgnition() {
    		// Ignition procedure
    	}
    
    }
    
    class ElectricBus extends Vehicle {
    
    	function accelerate() {
    		$this->increaseVoltage();
    		$this->connectIndividualEngines();
    	}
    
    	private function increaseVoltage() {
    		// Electric logic
    	}
    
    	private function connectIndividualEngines() {
    		// Connection logic
    	}
    
    } 

A client class should be able to use either of them, if it can use Vehicle.

class Driver {
    	function go(Vehicle $v) {
    		$v->startEngine();
    		$v->accelerate();
    	}
    } 

Which leads us to a simple implementation of the Template Method Design Pattern as we used it in the OCP tutorial.

Based on our previous experience with the Open/Closed Principle, we can conclude that Liskov’s Substitution Principle is in strong relation with OCP. In fact, “a violation of LSP is a latent violation of OCP” (Robert C. Martin), and the Template Method Design Pattern is a classic example of respecting and implementing LSP, which in turn is one of the solutions to respect OCP also.

The Classic Example of LSP Violation

To illustrate this completely, we will go with a classic example because it is highly significant and easily understandable.

class Rectangle {
    
    	private $topLeft;
    	private $width;
    	private $height;
    
    	public function setHeight($height) {
    		$this->height = $height;
    	}
    
    	public function getHeight() {
    		return $this->height;
    	}
    
    	public function setWidth($width) {
    		$this->width = $width;
    	}
    
    	public function getWidth() {
    		return $this->width;
    	}
    
    }

We start with a basic geometrical shape, a Rectangle. It is just a simple data object with setters and getters for width and height. Imagine that our application is working and it is already deployed to several clients. Now they need a new feature. They need to be able to manipulate squares.

In real life, in geometry, a square is a particular form of rectangle. So we could try to implement a Square class that extends a Rectangle class. It is frequently said that a child class is a parent class, and this expression also conforms to LSP, at least at first sight.

But is a Square really a Rectangle in programming?

class Square extends Rectangle {
    
    	public function setHeight($value) {
    		$this->width = $value;
    		$this->height = $value;
    	}
    
    	public function setWidth($value) {
    		$this->width = $value;
    		$this->height = $value;
    	}
    } 

A square is a rectangle with equal width and height, and we could do a strange implementation like in the above example. We could overwrite both setters to set the height as well as the width. But how would that affect client code?

class Client {
    
    	function areaVerifier(Rectangle $r) {
    		$r->setWidth(5);
    		$r->setHeight(4);
    
    		if($r->area() != 20) {
    			throw new Exception('Bad area!');
    		}
    
    		return true;
    	}
    
    } 

It is conceivable to have a client class that verifies the rectangle’s area and throws an exception if it is wrong.

function area() {
    	return $this->width * $this->height;
    }

Of course we added the above method to our Rectangle class to provide the area.

class LspTest extends PHPUnit_Framework_TestCase {
    
    	function testRectangleArea() {
    		$r = new Rectangle();
    		$c = new Client();
    		$this->assertTrue($c->areaVerifier($r));
    	}
    
    }

And we created a simple test by sending an empty rectangle object to area verifier and the test passes. If our Square class is correctly defined, sending it to the Client’s areaVerifier() should not break its functionality. After all, a Square is a Rectangle in all mathematical sense. But is our class?

function testSquareArea() {
    	$r = new Square();
    	$c = new Client();
    	$this->assertTrue($c->areaVerifier($r));
    }

Testing it is very easy and it breaks big time. An exception is thrown to us when we run the test above.

PHPUnit 3.7.28 by Sebastian Bergmann.
    
    Exception : Bad area!
    #0 /paht/: /.../.../LspTest.php(18): Client->areaVerifier(Object(Square))
    #1 [internal function]: LspTest->testSquareArea()

So, our Square class is not a Rectangle after all. It breaks the laws of geometry. It fails and it violates the Liskov Substitution Principle.

I especially love this example because it not only violates LSP, it also demonstrates that object oriented programming is not about mapping real life to objects. Each object in our program must be an abstraction over a concept. If we try to map one-to-one real objects to programmed objects, we will almost always fail.

The Interface Segregation Principle

The Single Responsibility Principle is about actors and high level architecture. The Open/Closed Principle is about class design and feature extensions. The Liskov Substitution Principle is about subtyping and inheritance. The Interface Segregation Principle (ISP) is about business logic to clients communication.

In all modular applications there must be some kind of interface that the client can rely on. These may be actual Interface typed entities or other classic objects implementing design patterns like Facades. It doesn’t matter which solution is used. It always has the same scope: to communicate to the client code on how to use the module. These interfaces can reside between different modules in the same application or project, or between one project as a third party library serving another project. Again, it doesn’t matter. Communication is communication and clients are clients, regardless of the actual individuals writing the code.

So, how should we define these interfaces? We could think about our module and expose all the functionalities we want it to offer.

This looks like a good start, a great way to define what we want to implement in our module. Or is it? A start like this will lead to one of two possible implementations:

• A huge Car or Bus class implementing all the methods on the Vehicle interface. Only the sheer dimensions of such classes should tell us to avoid them at all costs.
• Or, many small classes like LightsControl, SpeedControl, or RadioCD which are all implementing the whole interface but actually providing something useful only for the parts they implement.

It is obvious that neither solution is acceptable to implement our business logic.

We could take another approach. Break the interface into pieces, specialized to each implementation. This would help to use small classes that care about their own interface. The objects implementing the interfaces will be used by the different type of vehicles, like car in the image above. The car will use the implementations but will depend on the interfaces. So a schema like the one below may be even more expressive.

But this fundamentally changes our perception of the architecture. The Car becomes the client instead of the implementation. We still want to provide to our clients ways to use our whole module, that being a type of vehicle.

Assume we solved the implementation problem and we have a stable business logic. The easiest thing to do is to provide a single interface with all the implementations and let the clients, in our case BusStation, HighWay, Driver and so on, to use whatever thew want from the interface’s implementation. Basically, this shifts the behavior selection responsibility to the clients. You can find this kind of solution in many older applications.

The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use.

However, this solution has its problems. Now all the clients depend on all the methods. Why should a BusStation depend on the state of lights of the bus, or on the radio channels selected by the driver? It should not. But what if it does? Does it matter? Well, if we think about the Single Responsibility Principle, it is a sister concept to this one. If BusStation depends on many individual implementations, not even used by it, it may require changes if any of the individual small implementations change. This is especially true for compiled languages, but we can still see the effect of the LightControl change impacting BusStation. These things should never happen.

Interfaces belong to their clients and not to the implementations. Thus, we should always design them in a way to best suite our clients. Some times we can, some times we can not exactly know our clients. But when we can, we should break our interfaces in many smaller ones, so they better satisfy the exact needs of our clients.

Of course, this will lead to some degree of duplication. But remember! Interfaces are just plain function name definitions. There is no implementation of any kind of logic in them. So the duplications is small and manageable.

Then, we have the great advantage of clients depending only and only on what they actually need and use. In some cases, clients may use and need several interfaces, that is OK, as long as they use all the methods from all the interfaces they depend on.

Another nice trick is that in our business logic, a single class can implement several interfaces if needed. So we can provide a single implementation for all the common methods between the interfaces. The segregated interfaces will also force us to think of our code more from the client’s point of view, which will in turn lead to loose coupling and easy testing. So, not only have we made our code better to our clients, we also made it easier for ourselves to understand, test and implement.

Final Thoughts

LSP taught us why reality can not be represented as a one-to-one relation with programmed objects and how subtypes should respect their parents. We also put it in light of the other principles that we already knew.

ISP teaches us to respect our clients more than we thought necessary. Respecting their needs will make our code better and our lives as programmers easier.

Thank you for your time.

Another chance to catch the most interesting, and important, articles from the previous week on MIT Technology Review.