Mermaid provides annotations as a means to differentiate abstract classes in UML class diagrams. This is not universally usable, for instance, if an abstract class implements interfaces.
Ideally, an abstract class would be rendered with its name in italics. I tried to do so with the following CSS file:
.abstract {
font-style: italic;
}
Which I applied to one of the examples:
class Animal:::abstract {
-int sizeInFeet
-canEat()
}
But as the style applies to the whole node, not only the class name is rendered in italics, properties and methods are so too:
Would there be another strategy to render an abstract class with its name in italics?
You can use a more specific CSS selector:
.abstract .classTitle {
font-style: italic;
}
Related
I started developing my own dependency injection package in dart just for fun. The problem I came across is that when a class is in it's own file and is not imported anywhere, dart's tree shaking will remove it and make it inaccessible. This makes it impossible for me to map implementation of some interface to the interface so I cannot ask context to give me implementation when I supply the interface. Here is what I mean:
import 'context/context.dart';
void main() {
Context context = Context();
Interface interface = context.getInstance<Interface>();
interface.works();
}
abstract class Interface {
void works();
}
And here is the implementation of the "Interface" abstract class:
#Singleton()
class Implementation implements Interface {
#override
void works() {
print('works');
}
}
If I import the file that contains the "Implementation" class, context is able to find it and map it but I want to avoid doing that. Is there any way to turn off the tree shaking or preserve the class without importing it ?
I have a composite condition like this:
static class OnJndiOrProperty extends AnyNestedCondition {
OnJndiOrProperty() {
super(ConfigurationPhase.PARSE_CONFIGURATION);
}
#ConditionalOnJndi()
static class OnJndi {}
#ConditionalOnProperty("something")
static class OnProperty {}
}
How do I, for example, reuse one of the nested conditions elsewhere? The following would not even compile:
#Conditional(OnJndiOrProperty.OnProperty.class)
because OnProperty is not a Condition, rather something that is interpreted as one thanks to the [package-private] OnPropertyCondition utility.
I could perhaps make it extend a custom Condition implementation and get rid of the #ConditionalOnProperty annotation, but that would effectively be the same as implementing the OnPropertyCondition, so it's just rewriting what's already supported.
I wan to implement IntelliSense support for custom language. Actually it is a customize version of C++. i.e the methods resides in separate files
So my main class is like followings and it has import file MyClassMethods which has all the methods.
public class MyClass {
#import MyClassMethods
// my code goes here
}
So my MyClassMethods fiel looks like following and it has two methods,
public void testMethod1() {
}
public void testMethod2() {
}
Then at the end I want to have IntelliSense features when I working on MyClass. Example when I put dot character on that class in a required place I want to have testMethod1() and testMethod2() in the IntelliSense menu.
Is this possible to achieve and if so how can I achieve this?
As Bloch states in Item 3 ("Enforce the singleton property with a private constructor or an enum type") of Effective Java 2nd Edition, a single-element enum type is the best way to implement a singleton. Unfortunately the old private constructor pattern is still very widespread and entrenched, to the point that many developers don't understand what I'm doing when I create enum singletons.
A simple // Enum Singleton comment above the class declaration helps, but it still leaves open the possibility that another programmer could come along later and add a second constant to the enum, breaking the singleton property. For all the problems that the private constructor approach has, in my opinion it is somewhat more self-documenting than an enum singleton.
I think what I need is an annotation which both states that the enum type is a singleton and ensures at compile-time that only one constant is ever added to the enum. Something like this:
#EnumSingleton // Annotation complains if > 1 enum element on EnumSingleton
public enum EnumSingleton {
INSTANCE;
}
Has anyone run across such an annotation for standard Java in public libraries anywhere? Or is what I'm asking for impossible under Java's current annotation system?
UPDATE
One workaround I'm using, at least until I decide to actually bother with rolling my own annotations, is to put #SuppressWarnings("UnusedDeclaration") directly in front of the INSTANCE field. It does a decent job of making the code look distinct from a straightforward enum type.
You can use something like this -
public class SingletonClass {
private SingletonClass() {
// block external instantiation
}
public static enum SingletonFactory {
INSTANCE {
public SingletonClass getInstance() {
return instance;
}
};
private static SingletonClass instance = new SingletonClass();
private SingletonFactory() {
}
public abstract SingletonClass getInstance();
}
}
And you can access in some other class as -
SingletonClass.SingletonFactory.INSTANCE.getInstance();
I'm not aware of such an annotation in public java libraries, but you can define yourself such a compile time annotation to be used for your projects. Of course, you need to write an annotation processor for it and invoke somehow APT (with ant or maven) to check your #EnumSingleton annoted enums at compile time for the intended structure.
Here is a resource on how to write and use compile time annotations.
I am developing windows phone 8 app. Is would like to have some user controls which they inherit from a specific user control. I define my parent user control like this:
public abstract class WidgetsUserControl : UserControl
{
}
and the child like:
public partial class childControl : WidgetsUserControl
{
}
but it get error in defining abstract which says : "Missing partial modifier on declaration of type 'project1.WidgetsUserControl'; another partial declaration of this type exists"
what am i doing wrong?
It's complaining that you don't have the "partial" keyword in your definition of the WidgetsUserControl class. You probably have a corresponding XAML file for WidgetsUserControl that is partially defining that class, so here, you need to specify that it is partially defined as well.
public abstract partial class WidgetsUserControl : UserControl
Please note that if you go in this direction, then you also need to make the childControl definitions consistent. That is, in the code you would have:
public partial class childControl : WidgetsUserControl
and in the XAML, you will also need to specify that the childControl is a WidgetsUserControl, not just a simple UserControl:
<project1:WidgetsUserControl>
</project1:WidgetsUserControl>
Although this will work, a problem you will run into with this is that the Visual Studio Designer will complain that it can't create an instance of WidgetsUserControl (because it is abstract). This makes visualizing and editing the childControl a bit difficult. To solve this, my suggestion would be to just do away with the "abstract" in the base WidgetsUserControl. If you really want the base class to be abstract, then see here for other suggestions:
Abstract class in designer
This works good:
Code behind for parent user control:
public abstract partial class WidgetsUserControl : UserControl {
...
}
xaml for parent class:
<UserControl
...
xmlns:we="clr-namespace:project1"
...>
</UserControl>
code behind for child user control:
public partial class childControl : WidgetsUserControl {
...
}
xaml for child user control:
<we:WidgetsUserControl x:Class="project1.childControl"
...
xmlns:we="clr-namespace:project1"
...>
<Grid x:Name="LayoutRoot" Background="{StaticResource PhoneChromeBrush}"></Grid>
</we:WidgetsUserControl>