Well, static is not evil but how people use it sometimes is. My friend Susan has taught Java for years and will forever be remembered for the mantra that "static is evil." In an object-oriented boot camp Susan taught there was one group who named themselves "Static is Awesome" just to make her say it! Spreading the message is a good thing. Not because static is evil, but because when static is misused it leads to brittle programs.
The word static means "fixed in position," it cannot be moved. In a computer language we have long applied the keyword static to "fix" the location of something. The how and why of fixing that location has changed over the years. Regardless of the particulars, something that is fixed is contrary to the principles in object-oriented programming where dynamic and abstract structures create robust and adaptable programs! Let's take a look at why that happens...
Wednesday, June 25, 2014
Monday, June 2, 2014
The LSP in Dynamic Languages
A question was raised with me about the effect of dynamic languages on the Liskov Substitution Principle. If you are a little vague on the LSP it goes beyond the basic idea of substitution to include behavior. I have another article that explains why the LSP cannot allow a square to be a rectangle because of the expected behavior.
Java and C# are examples of strongly-typed languages that support both early and late binding. They will check at compile time to make sure that a class has the correct interface to support an operation (method overloading), and at run time a decision is made as to which method will actually be used based on the object type (method overriding). This is a class diagram that shows an AccountCollection can contain a group of Account objects and does not concern itself with the actual subclass that each object is:
Java and C# are examples of strongly-typed languages that support both early and late binding. They will check at compile time to make sure that a class has the correct interface to support an operation (method overloading), and at run time a decision is made as to which method will actually be used based on the object type (method overriding). This is a class diagram that shows an AccountCollection can contain a group of Account objects and does not concern itself with the actual subclass that each object is:
Subscribe to:
Posts (Atom)