Is the visitor pattern useful in languages supporting class extensions?
Why bother implementing it, when you have open classes or can subclass.
If you want new functionality for a class you could just subclass it, so unless I'm missing something, is it still (very) useful in languages supporting class extensions?
Related
I am full-stack developer and currently study in software engineering in the university 2 course. Currently I am working on a Bookstore project using spring boot for back and React for frontend. So I need to implement 5 software design patterns in my project. However I don't now how to do such implementations and not yet experienced. So I need your help. How I can implement this?
First of all I am not here to demotivate you or anything else, what I will suggest you to start making a class diagram and from that class diagram you will notice somethings that will look weird to you, so the things that will look weird to you will be things that will required the implementation of the Design Patterns.
There are basically three types of Design Patterns Creational, Observer and Behavioral. So, as soon as you will create the Class Diagram, you will notice some base cases such as one class should use the single database object or same logic on a single time that is the place where you will be using the Singleton Design Pattern.
Let's say you have created a Class Diagram such that one parent class should not be able to create the objects of other class but the subclasses should do that kind of work, so this is the classic example of Factory Method design pattern and so and so on.
I wish you best of luck for your project as well.
Why is all the math not in one class in codenameone? This makes it so you need to go and check to see which Method is in which class. Not a big deal but does not seem to be logical. I am sure you have a great reason I just was interested to see what it is.
The Math class in CN1 follows the CLDC11 API, whose Math class doesn't include all of the methods of JavaSE. This made CN1 more easily portable to those devices. Adding these methods in a separate class was just easier to port.
Now that J2ME is in the past, I don't see any reason why we can't move the Math class inline with the JavaSE Math class. I have opened an RFE for this here
There is a naming convention to call the DependencyProperty xyzProperty for a property xyz.
Is this just convention or does WPF behave differently if that naming convention is violated?
If it's not just convention: Isn't C# used that way moving towards a scripting language like TCL where everything is a string?
Is this just convention or does WPF behave differently if that naming
convention is violated?
No, all code is compiled and Xaml parsed and linked so there is no difference in the resulting WPF. Feel free to name your properties in any way.
Coding conventions are simply to make all developers adhere to a system which may or may not lend itself to more maintainable code; hence its target audience is developers and not the end system.
If it's not just convention
I have been working professionally in WPF/Silverlight/WP Xaml since its inception and frankly have never come across that convention actually used.
Isn't C# used that way moving towards a scripting language like TCL where everything is a string?
No. C# is not moving that way because it was designed from the ground up to be procedural language and not a functional language. It may take in some things which give it a functional air, but it was designed as a procedural language and it cannot simply change its philosophy without abandoning a large chunk of its codebase to achieve that direction.
Apologies for the not entirely code related question.
I am in the process of building a WPF application with a View Model Locator pattern. In that I have interfaces to represent functionality not present in portable class libraries.
I then assign those properties concrete values in my application so that they are available for injection to my view models.
My question is, do we have a name for this pattern? It seems a standard enough way to do this but I am never sure what to call it and end up having to explain it every time.
A term Microsoft uses to describe the way one can inject in a PCL concrete implementations of code that cannot be written to directly target a PCL is platform abstraction.
There are several techniques to achieve this. Here are some useful links:
http://blogs.msdn.com/b/dsplaisted/archive/2012/08/27/how-to-make-portable-class-libraries-work-for-you.aspx
http://blog.stephencleary.com/2012/11/portable-class-library-enlightenment.html
http://log.paulbetts.org/the-bait-and-switch-pcl-trick/
I've been considering how you would write a business application in only F# with WPF. Here's my thinking of a general outline of how to go about it, but I'm looking for whether or not it will work:
Start with ADO.NET Entities to automatically generate a data access layer.
Since F# doesn't support partial classes, use F# Extension Methods to create a BLL that extends the entity objects with extra members (these will have to mutate the entities)
Instead of writing explicit ViewModels, write F# functions that build ViewModel objects on the fly using object expressions.
Write an F# function that uses Active Patterns and Decision Trees to build WPF Views on the fly, given ViewModel objects as input. It would also take care of setting up bindings between the View and ViewModel objects.
So, opening a form or page would involve executing a function to generate a ViewModel object instance, and then passing that to the function that builds a View from the ViewModel, and then setting that as the content of your Window. From that point on, it executes in a normal "mutable" MVVM way.
My knowledge of F# is still limited, so I may be going down the wrong rabbit hole here.
Question(s):
Will this work (in general), or not?
Is there a better way that you know of?
I don't know much about ADO.NET entities, or MVVM, or WPF, so I can't offer much critique of the technical ideas personally. It sounds like you have experience with all those technologies and know what's going on there. So my only commentary is that it sounds like there are too many new things to try all at once. To mitigate risks and increase the chance of success, I'd stage this across a few projects. E.g. maybe start with a traditional data layer using existing tools, and just try out your ideas for the F# View & ViewModel. And once you've worked out the kinks and gotten more comfortable with F#, then try tackling the data layer.
Do also be aware of
http://blogs.msdn.com/b/dsyme/archive/2010/07/29/some-f-project-templates-available-online.aspx
which include e.g. MVVM starter templates for F#, in case they provide any ideas/value (I am unclear how much your strategy departs from tradition to know if this will be helpful).
Here's another random link that may or may not be valuable:
F# and ADO.NET - idiomatic F#
This should work (tho I'm not sure about mutable entities, as I'm not an F# expert).
But my concern is the performance: F# uses a lot of recursion, especially in the case of decision trees, that will be a lot of work at runtime. I would consider pre-generating everything or a caching system. It's okay to generate at runtime using meta-programming, but why doing it every time when you can do it only once?