New CarFactory(Car);

>new CarFactory(Car);

If you don't see a use for the factory pattern, you've never had to do software architecture.

The question is: how often can the factory pattern be replaced by a decent dependency injection library?

Factories are for cars m8, not programming.

System.Technology.Mechanical.Vehicles.Car car = new System.Technology.Mechanical.Vehicles.Car(1, 2, 3, 4)

>m-muh dependency injection
Look kids, it's another buzzword Sup Forums uses but don't understand the meaning of.

Something dynamic with a lot of variations that depend on parameters you pass to the factory. Anything else should be done with DI - much cleaner and more maintainable that way. So the answer to your question is basically always.

Is this from the C#ar library?

God damn I love Go. Look at the perfection below.

car := car.New(1, 2, 3, 4)

What's you problem?

It's not that complicated.

:=

The fuck is that? Looks like some Cthulhu shit right there.

pseudo-code for variable declaration. Go does not exist. Heil Rust!

You need to study some maths.

If you like that pattern, in C++ what about a static member function?

I show bitches my padded structs and get sluts wet instead. Maths if for pussies.

From the char to my doubles baby. All the way don.

the car on the left is a variable
the car on the right is a package

package car has a function New() that returns a car.Car

lolnogenerics

I understand.

class Car
{
Car(int a, int b, int c, int d)
{};

static Car* New(int a, int b, int c, int d);
};


Car* Car::New(int a, int b, int c, int d)
{
return new Car(a,b,c,d);
}


you don't need a car object to exist to call Car::New The only difference I can see is slight syntax, and who is responsible for deleting the car object.

>returning a pointer
disgusting

The only padded thing is in your pants

Car car = new Car("car");

c++ may be too big for you.

It's clearly too big for you, because you haven't heard of return value optimization.

How does dealing with a pointer in any way influenced by RVO? It is a number sitting in a register. No new object is going to be constructed on an =.

Returning a Car is more efficient and easier than heap-allocating a Car and returning a Car*.

val Car = Car()


Kotlin masterrace.

>no new keyword
I don't like it desu

var car:Car = new Car();

var car1;
car=CarFactory();

This isn't even remotely always true as you seem to think

t. never had a non-wageslave job

You cannot say that for all objects. For something small, sure.

>what is functional programming

if I take off that pointer, would you die?

>unironically using oop

Car car = Car.builder()
.withColor(Car.Color.WHITE)
.withMake(Car.Make.NISSAN)
.withParams({hasSpoiler: true})
.build();

The only case it wouldn't be cheaper is if the object is big (i.e. so big that a move operation is more expensive than a new and a delete operation) and the object is immediately being moved out of the caller's local variables.

This is why we have constructors instead of static functions, by the way. So we can construct in-place.

>needing new
Why?

@Inject
void drive(Car car) {
...
}

I like constructor calls to be distinguishable. Things which are different should look different.

the word Car is capitalized. only constructors should have the first letter capitalized.

Okay, that honestly triggered my memory. I haven't done software architecture for a long long time that I forgot what Factory was meant to do. Now I remembered it all thanks to you.

what is the ugliest declaration of variables

Object.create

Just bow down to the JavaScript hegemony!

builders =/= factories

because i wrote a builder? that's not really architecture imo, more like software design. architecture is at a higher level of abstraction.

I think we are saying the same thing. Where my c++ gets hazy is how you would implement some sort of smart pointer object like seems to want that does not involve calling a Clone() on the pointer with a lot of senseless copy constructors being called, etc. as you = your way around.

I have no idea how these new-age languages pass objects around the 'stack' (or whatever they have that passes for this).

let mut x : isize;

most languages heap-allocate everything and just leave the jit to figure out if they can be optimized into stack allocations with escape analysis

I can't explain it, but somehow I remembered something about Factory when I saw your post. Call me a crazy faggot but my brain works in weird ways.

Like I said, this is why we have constructors.
auto car = Car{1, 2, 3};
auto carptr = new Car{1, 2, 3};
No problem. Let the caller decide where allocation takes place.

Car *Car0x0001 ;
Car0x0001 = CarSummon(23,325,1743,21,0xA23534FF); /*see CarSummon() documentation for details*/

DIM A(100) AS INTEGER

>Using a product rather than coproduct to represent errors

Sometimes that can get tricky. I have been working with bison recently. With the parsers it generates for c++, you can't get your hands in the guts of allocation. You must pass objects around. Some of those objects make a whole lot of sense to just wrapper *'s.

I really don't think it is so bad (my solutions pass Valgrind). It is using the object structure/model that c++ intends, even if it is a little inefficient. Regardless I can't control when new happens - and iirc it is calling a constructor on a region of ram that did not even come from a new (maybe a union of all objects that could form a node? - not in front of it right now) - it is handling whatever parse stack it generates itself in crazy ways.

>analogies
Why can't they just use practical examples?

I don't understand these threads.

then go is the language for you!

Here's your (You)

did you meant:
using System.Technology.Vehicles;
var Car = new Car(1,2,3,4);

?

>this thread again
have a (you) and a sage

>le ebin programming meme
Disgusting

>tfw your programming language doesn't have explicit memory allocation

sad

Transport::Car* car = new Transport::Car("OOcar", Transport:: Colour::Blue, Transport::Pattern::GoFasterStripes);

type* var
stop

auto car = Car();

C++ convention
It's what Bjarne wants

bjarne's a faggot

New-Variable -Name MyVariable -Option AllScope -Visibility Public -Force

CarFactory.Create(VehicleType.Car, object[] { "Volkswagen", "Polo", 2017, VehicleColor.Blue });

>blue polo
the ugliest pattern and the car to match

>unironically using design patterns
Literally made for uncreative brainlets, normal people would spend 90% designing the right datastructures with pen and paper and spend only 10% of the time writing concise and simple code tailored for the job.
If you start writing code immediately and figuring out stuff on the go, you’re doing it wrong. And dont try to shoehorn ugly design patterns, that is just slavery invented by CEOs to keep the pajeets in check.

>If you start writing code immediately and figuring out stuff on the go, you’re doing it wrong.
TDD in a nutshell.

1) www.google.com
2)

The joke is that Design patterns and OOP are fucking garbage.

>If you start writing code immediately and figuring out stuff on the go, you’re doing it wrong

Hold on guys, let me get this piece of paper and write down what the program will look like, hold on.

Tf you doing

Modern C++ exists for a reason. Use smart pointers

Hell, I'll take a at this point, than this

>smart pointers

More like dumbass pointers.

OOP is trash. We already knew this faget.

>org.springframework.aop.framework.AbstractSingletonProxyFactoryBean
oop really is an abstract kind of hell

>car := car.New(1, 2, 3, 4)
>car := car

you are a moron

Using patterns at all is an anti pattern. It means the general design and your skill suck so hard you can't go without them. Basically an indication of single digit iq.

that's retarded

myCar = new CarFactory().begin().addWheels(4).paint(Color.Red).build(); //makes sense

>import car

>car = new Car()
>car:setMake(SUCKURA)
>car:setColor(WHITE)
Marginally less code, 100 times more clarity, spaghetti minimization by confining class-related shit to the class itself.

Why do you need the functions when you can just change the variables themselves?

>my encapsulation

Because these functions do more shit than just change a single variable. Trivial getters and setters are absolute cancer.