I'm modeling a web application, which has some HTML pages, javascript files and 6 servlets.
Right now I have all the servlets in separate classes, but they all share the same methods (doPost, doGet, processRequest, with different implementations) and all of them have the <servlet> stereotype.
I was wondering if there is a way to represent all of them with one class. I'm going to do a text to describe the diagram, so maybe I can explain what that class represents.
As all the methods you cite (doPost, doGet, processRequest) seem to be inherited from Java's HttpServlet, you may as well represent all the implementations with their common parent class HttpServlet.
If the design goes ahead of implementation, I would suggest you create an interface with the common methods(doPost, doGet, processRequest); then different classes implement the same interface. You can optionally introduce an class with default implementation of the interface and let your classes generalize from this class.
If the implementation was already there, to be honest, it is not well designed. A refactor will be much better.
Related
I am building a relatively simple app and a little bit confused on a better practice of design.
I have a main class MClass. Classes Child1 and Chil2 both inherit from MClass. Now, there is another class AClass, which can inherit from either Child1 or Child2, but not both at the same time (which is only possible through, I believe, interface).
How do I go about having this optional inheritance from one or the other class?
There are also classes AChild1 and AChild2, which both inherit from AClass. The end result would be as follows:
MClass:Child1:AClass:AChild1
MClass:Child2:AClass:AChild2
These are the only two options possible. Is it better to simply combine AClass with its children having
MClass:Child1:AClass1
MClass:Child2:AClass2
I could do this but AClass1 and AClass2 would have a lot of redundant fields... Any reccomendations?
Thank you!
EDIT:
Here is a specific situation:
I have a piece of Equipment that can be either Type1 or Type2. Class Equipment has a bunch of properties. Type1 and Type2 have their own properties and they inherit from Equipment.
Both Type1 and Type2 have cables. There is a class Cable with specific properties. In addition, Type1 and Type2 have different types of cables, CableType1 CableType2, which have their own specific properties and inherit fields from either Type1 or Type2.
VB.NET does not allow multiple inheritance. Depending on your concrete use case, there are various things you can do:
Describe common functionality between the classes in interfaces. Of course you still need to implement the functionality in all classes separate and it does not help you with fields, but you can use a shared interface to access all classes that provide the functionality.
Put the functionality in the child classes like you suggested. This is possible but would mean some duplicate fields. In some cases this might be okay, in other cases not.
Put the functionality in the common base class MClass. Again this depends on the concrete scenario
Use composition over inheritance. The need for multiple inheritance often indicates a bad class design where the inheritance relationship ("is a") is misused and you really want to express a composition ("has a"). This would meaning putting the fields and/or methods in a separate class which is used by both childs. You should use the Single responsibility principle as a guidance, so that each of the classes has only one clearly defined responsibility.
Unfortunately you did not give us a concrete example, so it's difficult to say what would be best in your case. Quite possible a combination of these techniques will lead to best results.
As someone has already mentioned, .NET does not support multiple inheritance. That being said, a class can implement multiple interfaces, or an interface can inherit multiple interfaces, which in conjunction with extension methods provides a nice way to share implementation. This isn't as analogous to multiple inheritance as it is to a mixin, but the effect is largely the same.
If you rethink your model in terms of interfaces, you can do what you want in terms of multiple inheritance. The implementation classes would just be POCO's, and the implementation logic would be static methods in the form of extension methods.
For encapsulation, you can implement certain properties on the implementation class using explicit interface implementation, so that certain properties aren't visible when working with the class itself.
I've found that using this technique helps a lot with testability and prevents a lot of coupling.
I'm wondering about the performance differences between imports and inherits in a .net app.
I currently program by creating multiple classes that logically define my objects. e.g. a class for customers, users and product.
When i want to use these classes in a page i have to import them eg. "Imports Custmomers" and then later in my code i have to create a variable and datatype it before i can use the sub routines and functions from class.
I understand from a coding perspective this keeps it all neat and tidy.
So my question Would it be not better to combine all my classes into a base class, inherit that base class, rather than import it, when i want to use it and so cut down on the extra declarations and associated code that come from importing a class; and if i did this would it aid performance?
No, it will not improve performance to use a base class instead of separate classes, it will just make the application harder to maintain and extend. Prefer composition over inheritance.
If you're having performance problems with your application use a profiler and check where the hotspots are.
"Importing" a class is just a way to tell the compiler that you are too lazy to type the fully qualified names of the types all over your code and has no impact on the runtime performance.
Qt has a build-in supprt for creating objects with integrated reference counting via QSharedData and QSharedDataPointer. All works great, but for each such object I need to write a lot of code: QSharedData-based implementation class with constructor and copy constructor, object class itsef with accessor methods for each filed.
For a simple structures with 5-10 fields this requires really lot of near same code. Is it some ways to automate such classes generation? Maybe it's some generators exists that take a short description and automatically generates implementation class and object class with all accessors?
You usually don't have to implement copy ctor or operator= when using QSharedData/Pointer. The default impls copy/assign the QSharedData-derived member, which usually does the Right Thing (TM).
For the public class, you need to implement the ctor creating the private object, and if the private class is not declared in the header but in the implementation (which is better), a dtor (doing nothing, the only point is that is not inlined and defined in the .cpp, after the private declaration).
For the private class, no method/ctor/dtor implementations are necessary.
For simple value-based classes, writing setters is of course tedious, but the same is true if you use plain private member variables. The overhead in LOC doesn't grow with the number of members.
And no, there is no standard generator solution for that I know of, although writing a script or emacs macro etc. doing it is not that hard. Probably would make sense to add such things to a publicly available toolbox, or QtCreator...
I don't think generators would exist for these things, but I suggest two things:
(ab)use existing shared containers (QVector, QList...)
read the documentation (with examples) on QSharedData, QSharedDataPointer, and QExplicitelySharedDataPointer
The two subclasses have simple examples that show how to implement the shared-ness it seems. I can't help you further though, because I've never had the need to create my own.
On second thought, why not make all data fields public, and use the QSharedData derivative as a struct-like class with reference counting? Maybe not nice on encapsulation, but if you're careful, nothing wrong should happen.
I was toying with the idea of allowing module to with a class in a properties file ; something like
availableModules.properties
Contact=org.addressbook.ContactMain
Business=org.addressbook.BusinessMain
Notes=org.addressbook.Notes
...
My framework will use reflection to instantiate the relevant modules, and thereafter call methods on the relevant base classes, or pass the objects as parameters as required.
Is the above a good place to use reflection?
Are there any best practices on where to use reflection already posted on SO (I couldnt' locate one)? Could we start a list along those lines with any responses posted here?
EDIT
Here's another example of the kind of scenarios I have in mind.
Some core code needed to determine the point of call.
One application I saw achieved this by using reflection, another application used an exception. Would you deem the former to be a recommended scenario where reflection may be applied?
For a great framework supporting your idea have a look at the IOC container of the spring framework.
Is the above a good place to use
reflection?
I'd say no. If you want to do this kind of thing, you should probably be using one of the (many) existing mature frameworks that support Inversion of Control aka Dependency injection. Spring IOC is the most popular one, but there are many others. Google for "ioc framework java".
Underneath the hood, these frameworks most likely use reflection. But that doesn't mean you should reinvent the wheel.
I usually used reflection if I want to dynamically use a class which information (assembly name, class name, method name, method parameters, etc) are stored in a string (text files or database).
For example: a compatibility layer between scripting objects (like strings, arrays) or scripting engines( eval() ,readFile() etc.).
Without more context, I'd have to say interfaces as well. Consider that you can represent a function or delegate as an interface with a single method and that abstract classes are just interfaces with some methods potentially already implemented.
That said, it really depends on what you're trying to accomplish. Interfaces lend themselves to cases where you have lots of objects with a common interface but potentially varying implementations. If you are, for example, designing a very simple callback system for plugins (i.e.: let the plugin hook certain events in the host application) then delegates are probably simpler and sufficient for your needs.
Also keep in mind that if you do go with interfaces, you'll probably need some way for the host to instantiate instances. The easiest way to do this is by registering a delegate with the host under some unique name.
Abstract classes are only useful if you want to use interfaces and provide a default implementation of some things. A better solution in that case is to have an actual interface instead, and provide the default implementation as a mixin.
Interfaces have my vote. That way, as long as you define the interface any developer will be able to write something compatible fairly easily without you having to distribute too much code to them.