Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
In C#, properties could be used to return or reset the value of private members of a class. But people can also define methods to fulfill these, so my questions are:
why bother to introduce properties, why don't just use methods?
private members are intended to be accessed by the class only. then why are properties defined to modify the private member?
Methods represent actions (think of them as verbs) and properties represent data (think of them as nouns). Properties should not perform computationally complex logic or produce side effects. Methods on the other hand should.
Why use Properties:
Properties are be used in data binding. For example, in ASP.Net MVC you use properties as part of Models.
Properties provide fine-grained access control. For example, you can have read-only properties, by just providing a getter.
It helps with debugging. For example, you can set a breakpoint on the property and the IDE will break when the value of the property is touched.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I am new to unity ( <200 hours) and I don't know what the proper practice is regarding when to create a new script vs. modify an old one.
For example:
My UI elements all share a script which has booleans for 'isSlider' and 'isButton', etc.
This toggle is used to activate or deactivate unique functions depending on the type of UI element while reusing some generic functions used across all of them.
Would it be better practice to create a new script for each UI element and just copy the generic code or is it okay to have toggleable functions to modify the functionality in the inspector.
Thanks for your help!
in OOP, you want to abstract functionality, rather than put it all under the same class
Look at the principle of single responsability: https://en.wikipedia.org/wiki/Single-responsibility_principle
it states that each class should be responsible for a single unit of functionality, therefore buttons and sliders should be different classes
if you have some generic it would make sense to share between all components, you can make your ui elements inherit of a parent class that handles that logic, for that, look at the concept of abstraction: https://www.guru99.com/java-data-abstraction.html
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
In our project we are using a CQS pattern. Because some of our queries call other webservices, which in our case can be slow, we want to cache those results. Now I've found several solutions how to do this:
Create an CachedQuery which inherits from a Query object.
Add a 'CacheResult' attribute to the queryhandler, have a decorator check for the presence of this attribute
Add a 'CacheResult' attribute to the query, have a decorator check for the presence of this attribute
Implement a 'ICacheableQuery' interface, have a decorator check for the implementation of this interface.
option 1 is discarded because of "composition over inheritance'
option 2 is not really flexible, e.g. it is not possible to not cache
But how to choose between 3 and 4? Adding an attribute is not inheritance (or is it?) so that is equal. Both are flexible enough, at least for now.
Do I miss some convincing argument? Or is it a matter of personal preference, if so what would you choose to do?
Adding an attribute is not inheritance (or is it?)
Whether you want your custom attribute to be inherited is up to you to implement. When you write code that checks the presence of an attribute, you can write it so that it checks the base classes/interfaces for the attribute as well.
As a commenter already noted, attributes allow you to add metadata that could be useful depending on what you're trying to implement.
Generally, I dislike having interfaces without methods just for the sake of differentiating types. But in the end...
Is it a matter of personal preference
Yes.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have tried many options for a long time and that is the last one that comes to my mind, so I will try to ask:
I am trying to develop an MVVM project in WPF and I have downloaded a ready-to-use WPF control (GMap.NET). However, this control is not prepared to use it in MVVM and I am a newbie in that, so I do not want to modify a source code on my own. The control requires to set many parameters (not accessible through XAML, so I cannot simply bind them), and call some functions on control object. So here goes my question:
How can I access a WPF control instance from any place from the code and manage it from there?
Particularly, I want to access a View element from ViewModel part and I know that it brakes the pattern, but I have no idea how to avoid it and I am running out of time.
Hard to say without knowing the concrete control. But in general, I see 2 options for make such a control MVVM conform:
Subclass the control and add dependency properties so it can be used in XAML
Create a "container control" that wraps the unMVVMable control and provides the required dependency properties.
However, if the API of the control is complex and has not only properties, but also some methods, it may be pragmatic do break MVVM here. MVVM is not the only way to separate GUI related logic from the view. You could abstract the used functions with an interface and use the interface within your view model for example.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 6 years ago.
Improve this question
In C#/.Net is there a way to reflect from an object, which is a member of a collection up to the collection itself so we can (a) iterate over the other members of the collection, and (b) assuming the collection is itself a member of a collection follow the tree back up to the root?
A typical example would be if there is a common attribute which can be set at multiple levels the collection tree and when an object is changed, find the nearest trunk entry.
The only way to do it is if the type you are working with explicitly has things in it to handle this, in winforms this is handled via the IComponent.Site property. Other libraries may use other standards.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
For example I have a method in the Booking class that updates a dataGridView control in the BookingForm.
Booking booking = new Booking();
booking.getBookings(dataGridViewBooking);
Similarly:
booking.getTables(comboBoxTables);
Is it bad practise to use controls as parameters? I have changed all the textBox parameters to strings and passed textBox.Text but how would something similar be done with other controls or are there any better ways to do this?
You can pass controls as parameters. They are normal objects that can be passed around.
It's questionable to pass UI objects to some kind of business logic, though. The business logic is not supposed to know anything about the UI.
Also, if you have the option of passing textBox.Text instead that simplifies the logic of that method. Probably, that method should not concern itself with extracting data from the UI. The SRP applies.
Usually you try to detangle the control from the data. i suggest you read up on BindingList . Create an intermediate record class that has all the fields you want to display, each field is one Property. Then create a. BindingList of that type and assign it to the DataSource of your grid.