I am wondering if it have a sense to reuse the same ObservableTransformer instance in different compose() operation, kept as a singleton somewhere as example. I don't see any pitfall in the documentation and code (because it simply called the apply method under the hood for new compose use) but every example i find create a create a new one. So maybe I miss something.
Thx for your answer,
Related
We can expose an object of a class by two methods like:
ClassName obj=Classname(); or obj=Provider.of<ClassName>(context);
is there any difference between them , or is there anyone of them better method.
ClassName obj = Classname();
This is creating a new instance of Classname. In Dart, you can omit the new keyword (since v2.0), older versions and most other languages actually force you to spell it out:
ClassName obj = new Classname();
It will call the constructor of the class and create a new instance. Alternatives would be named constructors that could look like this:
ClassName obj = Classname.fromInt(42);
That said, what exactly is this and what is the difference:
obj = Provider.of(context);
A provider is a form of state management. State management is a complex way of saying "where do I actually call my constructors so that the instances are known to the program at the place and time I need them? Sometimes I want a new instance, sometimes I want the instance I used before."
A provider may create a new instance for you. It may also decide it already has the instance you are looking for. You decide that by configuring it.
The only way to create a new instance of a class is through one of it's constructors. Very likely (but configurable), a provider is using a class constructor to create the instance of a class that it is then providing to multiple layers of your program so you don't have to keep track of that variable yourself.
Keeping track of all your variables and their lifetimes by yourself gets complicated really fast the bigger your program gets.
My personal recommendation to everyone learning programming is: try it the way you already know (in this case: constructors). Then you will experience for yourself what the problem is and you will know why packages like provider or bloc were created. This is a much better learning experience than just believing a random person on the internet (me or someone else) who says they know it's "better". Because then you will understand the problem instead of being railroaded into some cargo cult of "use this, it's good for you".
welcome to the StackOverflow.
You can do both of them, but if you are using the Provider package, you have some benefits:
It is much easier to transfer state to another level (or even really far level) inside your app's tree.
It is really suitable for a large scale app to manage their state (but it's also suitable for the small app).
If you are passing a state or an object directly, you'll be completely in a mess when your app complexity grows (based on my experience).
I hope it will be helpful.
listening is not possible with normal object creation where as with provider it is possible.
obj=Provider.of(context, listen:true);
So - I am really really digging coffeescript. But, I am curious how the possibility of repetition of code is dealth with across a large repository of code.
For instance.
Lets say I create a simple class.
class Cart
constructor: (#session, #group) ->
class Shoes extends Cart
compiler will create __extends and __hasProp methods.
Mind you, this is just one example -- pretty much this happens with loops etc... So, granted each bit of code is usually in its walled garden.. BUT, there could be many many of the same methods thru-out a code base.... because of the compiler just creating generic helper methods that are all the same.
Anyone else have to contend with this or deal with that possible bloat?
That is probably a lot more specific to what build tool you are using to manage a large codebase. grunt-contrib-coffee for example provides the ability to concatenate before compilation which means something like the __extends method should only get declared once. Likewise, I believe, asset pipeline in rails makes similar optimizations through the require statements.
If I have a function (say messUp that does not need to access any private variables of a class (say room), should I write the function inside the class like room.messUp() or outside of it like messUp(room)? It seems the second version reads better to me.
There's a tradeoff involved here. Using a member function lets you:
Override the implementation in derived classes, so that messing up a kitchen could involve trashing the cupboards even if no cupboards are available in a generic room.
Decide that you need to access private variables later on, without having to refactor all the code that uses the function.
Make the function part of an interface, so that a piece of code may require that its argument be mess-up-able.
Using an external function lets you:
Make that function generic, so that you may apply it to rooms, warehouses and oil rigs equally (if they provide the member functions required for messing up).
Keep the class signature small, so that creating mock versions for unit testing (or different implementations) becomes easier.
Change the class implementation without having to examine the code for that function.
There's no real way to have your cake and eat it too, so you have to make choices. A common OO decision is to make everything a method (unless clearly idiotic) and sacrifice the three latter points, but that doesn't mean you should do it in all situations.
Any behaviour of a class of objects should be written as an instance method.
So room.messUp() is the OO way to do this.
Whether messUp has to access any private members of the class or not, is irrelevant, the fact that it's a behaviour of the room, suggests that it's an instance method, as would be cleanUp or paint, etc...
Ignoring which language, I think my first question is if messUp is related to any other functions. If you have a group of related functions, I would tend to stick them in a class.
If they don't access any class variables then you can make them static. This way, they can be called without needing to create an instance of the class.
Beyond that, I would look to the language. In some languages, every function must be a method of some class.
In the end, I don't think it makes a big difference. OOP is simply a way to help organize your application's data and logic. If you embrace it, then you would choose room.messUp() over messUp(room).
i base myself on "C++ Coding Standards: 101 Rules, Guidelines, And Best Practices" by Sutter and Alexandrescu, and also Bob Martin's SOLID. I agree with them on this point of course ;-).
If the message/function doesnt interract so much with your class, you should make it a standard ordinary function taking your class object as argument.
You should not polute your class with behaviours that are not intimately related to it.
This is to repect the Single Responsibility Principle: Your class should remain simple, aiming at the most precise goal.
However, if you think your message/function is intimately related to your object guts, then you should include it as a member function of your class.
I'm writing some documentation and I just can't find the right word. Let say my class is called Writer and some people will be using it. How should I name objects that use the class (or instances of) I'm documenting?
Users of Writer class? - Program is not "a user".
Consumers of Writer class? - Sounds like somebody will eat it.
Callers or Writer class? - Sounds good for methods only.
There must be a correct word for this and I should feel stupid for asking but please, help.
Edit: just to clarify, I'm thinking about the code (not programmer) that is calling and using the class or instance of it (well, maybe I'm thing in code to much...)
I will prefer user anyway, even it is not a end-user. When you write documentation for your code the target audience is a programmer that will use your code. That programmer and their programs are users of your code.
How about "Client"?
First of all, know that there are no stupid questions, just stupid answers.
An End-User (the developer in this case) would be the user of the class.
Consuming is a verb related to aquiring resources.
Indeed calling is for functions.
Well, in the classic book Thinking in Java 2nd edition, there are two ways of using a class: by composition or by inheritance.(yes, this bit is also important)
I don't remember the exact words, but the summary would be sort of like this:
composition - you create a new object from which the target class instance would be referred.
inheritance - you create a new class that inherits (extends) the target class, provided that class is able to be inherited from.
For the exact terminology, I would say it really doesn't matter that much.
But if you want just describe the case where a new instance of such a class is created, you could say some actor (user) instantiates a new object of this class.
Hope this helps.
Edited : the terminology really depends if you think it is the user or the user's code that makes use of the target class.
I have an extremely hard time figurering out how classes needs to communicate with eachother. In a current project I am doing, many classes have become so deeprooted that I have begun to make Singletons and static fields to get around(from what I get this is a bad idea).
Its hard to express my problem and its like other programmers dont have this problem.
Here is a image of a part of the program:
Class diagram
ex1. When I create a Destination object it needs information from Infopanel. How to do that without making a static getter in InfoPanel?
ex2. DestinationRouting is used in everybranch. Do I really have to make it in starter and then pass it down in all the branches?
Not sure if this makes sense to anybody :)
Its a problem that is reacurring in every project.
After looking at your class diagram, I think you are applying a procedural mind set to an OO problem. Your singletons appear to contain all of the behavior which operate on the records in your domain model and the records have very little behavior.
In order to get a better understanding of your object model, I'd try and categorize the relationships (lines) in your class diagram as one of "is-a", "has-a", etc. so that you can better see what you have.
Destination needs some information from InfoPanel, but not likely all information. Is it possible to pass only the needed information to Destination instead of InfoPanel?
What state is being captured in the DestinationRouting class that forces it to be a singleton? Does that information belong elsewhere?
There's just too little information here. For example, I am not even sure if MapPanel and InfoPanel should be the way they are. I'd be tempted to give the decorator pattern a try for what it's worth. I don't know why a Listener is a child of a Panel either. We need to know what these objects are and what system this is.