class-design

In java adjectives ending in -able are interfaces Serializable , Comparable etc... So why is Throwable a class? Wouldn't exception handling be easier if Throwable were an interface? (Edit: e.g. Exception classes don't need to extend Exception/RuntimeException.) Obviously, changing it now is out the question. But could it be made abstract? Wouldn't that avoid the bad practice of throw new Throwable() ; So why is Throwable a class? I can think of two reasons: Exceptions have state. In particular, message, cause, and stack trace. It is easier for the JVM to implement efficient catch blocks. Class

I'm trying to work out exactly how deep inheritance goes. For example if I start with class A Class B extends class A Class C extends class B Class D extends class C Class E extends class D Class F extends class E Class G extends class F most of the lower levels are abstract classes with methods filled with code and abstract methods. its a rather large and complex structure. (doing my head in) Will Class G still be able to access Class A methods and parameters, as well as still have access to the abstract methods from Class A ? I'm asking because I have been having trouble with eclipse not

I'm designing a namespace to hold a set of classes that will handle user related tasks for a several different applications. (Log-in, authenticate etc) The problem is the namespace will be called Fusion.User but then it requires a class in that namespace that makes sense to call User . Should you have a class with the same name as the namespace? Or am I taking the wrong approach here? Having class named in the same way as the name space (package) may lead to a thought that class is central to the package. But if I get it correctly User is just a data object in your case. As far as I see you

I have a set of data transfer objects (e.g. a lot of reqest, response message classes, like MainRequest, MainResponse, ShutDownRequest, ShutDownResponse) Where new classes keep coming as the project evolves . These classes must be (de)serialized from and to various XML formats with different public XSDs . New XML formats come as the project evolves too. My question here is how I would design my classes and interfaces around these two requirement , especially where I should put the actual (de)serilization logic. Should I write a static service that can take the various DTO instances an knows

This is in regards to the design principals behind the Startup class explained here: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/startup?view=aspnetcore-2.1 I understand that the class needs to include methods like ConfigureServices or Configure . Why CreateDefaultBuilder(args).UseStartup<Startup>() does not mandate any base class or interface for better readability? With this design approach, someone must read the documentation and know about the magic method names like ConfigureServices or Configure . If this is part of a new class design mindset, then where can I read more

I would like to confirm whether I am on the right track when identifying common UML class relationships. For example, is the relationship between: 1 a stackoverflow member and his/her stackoverflow user account categorized as a composition relationship or an aggregation relationship? At first I thought it was an association because this member "has a" account. However on second thought, I am thinking its composition because each "part" (user account) belongs to only one whole (user) at a time, meaning for as long as I am logged into stackoverflow, I have to use this one and only account until

I thought I'll post this to the community. I am using coredata, and have two entities. Both entities have a hierarchical relationship. I am noticing quite a lot of duplicated functionality now, and am wondering if I should re-structure to have a base Entity which is abstract (HierarchicalObject), and make my entities inherit from them. So the question is are there some limitations of this inheritance that I should take into account? Reading some of the posts out there, I see a few trade-offs, let me know if my assumptions are correct. (Good) clean up structure, keep the HierarchicalObject