JSP
Make visible what, without you, might perhaps never have been seen.
- Robert Bresson
Make visible what, without you, might perhaps never have been seen.
- Robert Bresson
Make visible what, without you, might perhaps never have been seen.
- Robert Bresson
Uncontrolled vocabularies
"I try my best to make *all* my posts nice, even when I feel upset" -- Philippe Maquet
Make visible what, without you, might perhaps never have been seen.
- Robert Bresson
Uncontrolled vocabularies
"I try my best to make *all* my posts nice, even when I feel upset" -- Philippe Maquet
Uncontrolled vocabularies
"I try my best to make *all* my posts nice, even when I feel upset" -- Philippe Maquet
We do not want the duplicate code lying around in all of your sub components. So the common stuff that require to connect to the database/rendering the output/etc.. can be pushed up the chain to MikeBaseComponent.
If all you want is to use "querying the database" functionality, there is no need to extend, you can simple call this class’ methods.
Originally posted by Mapraputa Is:
Now to add another level of hierarchy as an abstract class means to change the direction to the opposite – from concrete to more abstract. This would serve to no other goal but to introduce confusion.
Does all this make sense?![]()
Make visible what, without you, might perhaps never have been seen.
- Robert Bresson
Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Originally posted by Michael Ernest:
Yusef really isn't defending the initial question of marking a concrete class abstract so that it can't be instantiated, a practice I still think has more potential for confusion than elegance.
Imagine the situation where you have useful non-abstract class A. Someone comes up with the clever idea that A can be enhanced with some new functionality. This new functionality can actually be implemented in 3 different ways. So they extend A with an abstract class B which provides the method signatures for the new functionality. Then they provide C, D, and E which implement the new functionality.Originally posted by Mapraputa Is:
I did some self-analysis to figure out why mixing abstract and concrete classes doesn’t feel right and here are the results…
Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Make visible what, without you, might perhaps never have been seen.
- Robert Bresson
Originally posted by Thomas Paul:
Imagine the situation where you have useful non-abstract class A. Someone comes up with the clever idea that A can be enhanced with some new functionality. This new functionality can actually be implemented in 3 different ways. So they extend A with an abstract class B which provides the method signatures for the new functionality. Then they provide C, D, and E which implement the new functionality.
Make visible what, without you, might perhaps never have been seen.
- Robert Bresson
Originally posted by Michael Ernest:
Why wouldn't you just create an interface with the new functionality? A default implementation class C, composed of class A and the implemented interface, would convey the same thing in a straightforward way.
D & E could then extend and override C behavior. If they're truly different implementations, capturing their commonalities in an interface rather than a parent class I think would make more sense.
Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Originally posted by Abu Yoosuf:
Mike,
Come on, lighten up! I was just kidding. Honestly, I am learning a lot from this site.
Make visible what, without you, might perhaps never have been seen.
- Robert Bresson
You may have just won ten million dollars! Or, maybe a tiny ad.
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|