is it true "new operator considered harmful"? [on hold]

is it true "new operator considered harmful" ? I read this here

I read this Question but it's limited to Javascript , looking ans for java or other OOP language like PHP , python

Handle network requests/responses in a UI independent manner (and cancellable)

I have an app that is composed of 2 list fragments and 1 simple fragment with a layout view.
First list fragment shows a list of ~20 items.
Each item when clicked results in a network call that brings from a server ~70 items (max) that are displayed in another list in the second list fragment.
Once the user clicks in the list item data specific to that item are fetched from network and displayed in the last fragment.
So basically the first list is "broken" down to data. But the items in the second list are not more than ~70.

Design:
I have used volley queue for the network calls and functionality-wise it works fine and I display the data I need fine.
I have added a listener to the volley request and from my listener I update my adapter(s)

Problem:
Due to the fact that on click of the first fragment as I move to the second I start these backend calls and as I go to the third these calls are queued (I can see it in the logs), if I go to the third fragment the calls for the rest of the items are kept on firing and same if I go back to first.
Due to the fact that I get the responses for these requests from the Volley within the adapters and the actual fragment might not be "relevant" anymore, how can I design this better?

Android design pattern to manage UI elements

The answer to this question would be a design-pattern, to be used in development of Android applications, that simplifies the way user interface elements are managed such that many such elements can be managed centrally even though acted upon from various places in the application.

Given a small application without too many states, managing UI elements in the activity life cycle methods is fine. If the application grows and can change states based on processes outside the main thread, the number of places where changes are being made increases. This makes the application less maintainable (having state changing code in many places). I seek a design pattern that makes it more clear what happens to the UI in the various states.

I realize that persistence tools such as SQLiteDatabase andSharedPreferences are available, which might be part of the design pattern, but central control, where the state of the app can be maintained, along with control over what the user sees and what the user is able to do is the goal.

ValueObject pattern in django models

Currently I want to use the Value Object Pattern in my django project. I have a class Price like this:

class Price(object):
    def __init__(self, value, currency):
       self.value = value
       self.currency = currency

And now I want to use this class in a normal model. The question is simple, how should I use it in the model? What type of field?

My most important requirement is, that I can access the price directly on an instance of the model. So that I could write something like this:

item.price.in(Currency.EURO)

So I don't need to call some methods to invoke for example deserialization, if I store the price as JSON in the database.

Thanks for your help!

Design pattern for doing a sequence of operations on an I/O based object

I find myself frequently writing code that follows the following sequence:

1. Attempt to open an I/O based resource (i.e. from a database and/or file). This could potentially fail.
2. If successful, perform a series of operations via the object.
   • These operations change based on user input. For example: filter data, do calculation A, do calculation B, write the results somewhere.
   • Each of these operations could potentially fail and return with an error message. If a failure occurs at any time, the sequence should abort.
   • Some operations must be done before others: writing results cannot occur before calculations, for example.
3. Close the resource.

Is there a design pattern that would work well for a flow like this? When I try to wrap the above sequence into a class, the immediate problems I always run into are:

• How do deal with opening the resource. Ideally I would like to open it during class construction, but that gets messy if there is an error. Otherwise, I have to pass in a reference to the resource in the constructor, followed by an Open() method.
• How to make the flow of operations flexible to a user of the object, but not burdening them with the need remember to call a bunch of intermediate methods and/or a lot of error checking.

Design Patterns for PowerShell Cmdlets (in C#)

Working on a PowerShell Module in C# and something occurred to that seems logical but I can't find any other info to confirm or correct my assumptions.

Say I have one Cmdlet looks something like this

[Cmdlet(VerbsCommon.Get, CmdletHelpers.Noun, SupportsShouldProcess = true)]
[CmdletBinding]
public class GetSomething : PSCmdlet
{
    protected override void ProcessRecord() 
    { 
        var SomeCustomObject = new SomeCustomClass()
        WriteObject(SomeCustomObject); 
    }
}

Then say I have another Cmdlet which accepts a SomeCustomObject as a Parameter.

[Cmdlet(VerbsData.Import, CmdletHelpers.Noun)]
[CmdletBinding]
public class ImportSomething : PSCmdlet
{

    [Parameter(Mandatory = true, ValueFromPipeline = true)]
    public SomeCustomClass SomeCustomObject { get; set; }

    protected override void ProcessRecord()
    {
        // Do Something with SomeCustomObject
        // Return modified SomeCustomObject
        WriteObject(SomeCustomObject);
    }
}

So I would assume that a PowerShell Cmdlet that takes in a particular parameter should usually not modify the parameter and instead create a copy if changes need to be made to that parameter. However I can't find any definitive opinions on this.

In other words if I change my ProcessRecord above to

protected override void ProcessRecord()
{
    SomeCustomObject.ChangeSomething();
    WriteObject(SomeCustomObject);
}

If I have some PowerShell calls:

$SCO = Get-Something
$NewSCO = $SCO | Import-Something

$NewSCO AND $SCO BOTH would have been modified to the same state which seems bad, i.e. we'd always want the items upstream in the pipeline to retain their state so to speak so if later on we want to go back it always retains its original values when it was previously down stream of the Cmdlet that created it.

So instead (Assuming SomeCustomClass has a Copy Constructor) this should be the better design pattern.

protected override void ProcessRecord()
{
    var NewSomeCustomObject = new SomeCustomClass(SomeCustomObject);
    NewSomeCustomObject.ChangeSomething();
    WriteObject(NewSomeCustomObject);
} 

Am I completely off here?

Would there ever be a GOOD reason ESPECIALLY in the pipeline to modify a parameter object upstream of the current Cmdlet?

Native MongoDB Driver Node.js - should we store collections?

I haven't been able to find any documents outlining if it's a bad / good idea to keep a reference to a collection so that it can be re-used after the db connection has been established.

for instance, in our database.ts which is called during our server start-up. It will grab the collections and store it for use in the module which can then be references throughout the project.

example of storing the collection

/*database.ts*/
//module to keep 1 connection alive and allow us to have 1 instance of our collections.
import {MongoClient, Db, Collection } from 'mongodb';

let uri: string = 'connection_string';

export let db: Db;

export let usrCollection: Collection;

export let bookCollection: Collection;

export function initDb(cb: any) {
  MongoClient.connect(uri, function(err, database) {
    //handle err        

    db = database;
    cb(); //returns now since db is assigned.
  });
}

export function initCollections() {
  usrCollection = db.collection('users'); //non-async
  bookCollection = db.collection('book'); //non-async
}

  
/*app.ts*/
  
//in our express app when it start up
import {db, initCollections, initDb} from './database';

initDb(function() {
  //this will hold up our server from starting BUT 
  //there is no reason to make it async.
  initCollections();
});

what are some of the short coming of this pattern/build? what can I improve and what should I avoid for performance hits specificially with managing the collections.would this pattern keep my source code bug free or easy to find the bugs and extensible for the future? or is there even a better pattern - please no ext library aside from the native mongodb driver for node.js solutions, such as mongoose.