Car car = new Car("car");

>Car car = new Car("car");

Other urls found in this thread:

github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
twitter.com/AnonBabble

>no you fucking can't instance new objects without pointers and wild shit. Why, because i said so and throw that shitty string out. ONLY CHARARRAYS WITH UNSIGNED OBJECTS ALLOWED IN MY VECTOR. Also, yes, even something as simple and integral as an array needs to be complicated to fucking obscurity.

You can overdue the whole simplicity shit a la python, but this shit is just dumb

void setDimensions(int x, int y) {
this.x = x;
this.y = y;
}

val Sedan = Car()

You're welcome.

Car car = new CarBuilder(BodyStyle.SEDAN).addEngine("V8").addDriveTrain().addWheels(4).setColor(Color.BLUE).build();

>returning this in the setter
step away from the keyboard

>You can't assign directly, you must assign a Vector2 containing x and y values

>mem8
No, thanks.

(car (car (car (car
...
)))))))))))))

lar lar in the car car

var logRunTime = new Stopwatch();


what is hard about this?maybe you should try using a real language instead of java.

Java will have var keyword in march 2018 sweetie :*

This hits too close to home, anyone who enjoys lisp is a dangerous human that cannot be trusted.

car := new(Car)

...
} Catch (\catchable $catch) {
throw new \Exception($catch->message());
}

I've unironically have done this before.

>Vector3 v = new Vector3();
>v.x = 3.0f;
>v.y = 4.5f;
>v.z = 7f;
>Camera.main.transform.rotation = Quaternion.Euler(v);

stupid gopher

wheres the problem my brainlet friend?
also that 3 lines in the middle are not needed ever heard of constructors?

somebody post the new new new one

Not him, and pardon my brainletness, but isn't that the point of the builder pattern?

>POINT OF THE BUILDER PATTERN O'RLY
Just because someone wanted to shill his book to you doesnt mean it's good

taking a stab at it...

New new = new New("new");

This wouldn't work though. new is a reserved word.

why would you name your car "car" instead of "chris d'elia"?

So, you have no idea what you're talking about, got it.

>CarFactoryFactory factoryFactory= new CarFactoryFactory(currAppContext);
>AbstractCarFactory factory = factoryFactory.getNewFactory("toyota");
>Car prius = factory.getNewCar("prius");

anyone willing to defend design patterns? If they were useful they'd be language features or smaller macro systems.

What, you think a Car can make itself? Look at that retard.

What, you think it matters WHICH factory your car was made from? Oh, La-dee-dah.

In uni i did a unit on java, the language is so bs. I dropped it and did python instead

they're useful up to a certain extent, but nowadays (especially) in java the rigid adherence to doing everything the "correct" way with design patterns left, right, centre and up the arse just makes it awful.
about 90% of enterprise software is design pattern bloat, and half of the accepted design patterns are antipatterns anyway

>not using every design pattern in every project
do you even corporate, bro?

github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition

>defend design patterns?
They produce a common language among common solutions between programs. They're great at well defined problems. They can also function as reference points in programs with ad hoc architecture.

That said, they often get misused or intentionally used as smokescreen because the programmer doesn't know how to solve a problem or is dealing with schizophrenic suits.

I rarely use design patterns except when they clearly fit a problem or produce a better result than an organic solution. Trying to get a pattern that is misused or misapplied out of a codebase is a pain in the ass, and dipwads getting their first taste spam them like confetti.

Better than Car car = new Car('what', 'the', 'fuck', 'is', 'this', 'argument', 'in', 'the', 'constructor', 'supposed', 'to', be');

All of my why

>They produce a common language among common solutions between programs.

if that was true they should be a language feature, or automatically generated, or a macro system; not a bunch of 'standardized boilerplate'

Builders are used primarily for one of two reasons:
-So that internal resources can be cached and re-used (a lot of this was unnecessary panic over all the minor memory overhead from using referenced objects rather than C-style POD structs, but there are still times you want to cache frequently-re-used resources especially for GUIs and other graphical systems)
-because the act of converting some raw material into an object is complex logic that does not belong in the object itself because it has nothing to do with what the object is and the object could presumably be created other ways. For example (probably a bad one, but) taking a file with an unknown format and converting it to some form of BitMap memory.

They aren't something you should see everywhere, but there are times when it's better to segregate the conversion process from the actual object as other things interact with it.

No sane person actually writes Lisp that way.

You don't even know it, why are you complaining?

>So that internal resources can be cached and re-used
then it should be a VM/language construct and stop wasting my time

>because the act of converting some raw material into an object is complex logic that does not belong in the object itself

again, this is a language/VM thing

I love when normies lose their shit when you shit on a patterns because HURR DURR THEY ASK ABOUT THEM IN INTERVIEWS.
Like, duh. Of course. But that doesn't mean they are pathetic attempts at emulating functional programming.

>then it should be a VM/language construct and stop wasting my time
You have absolutely no idea what you're talking about. Do you even know what caching means? How the hell does the language inherently know what should and shouldn't be cached?

>again, this is a language/VM thing
OK, so you are just retarded.

c := &Car{}

>How the hell does the language inherently know what should and shouldn't be cached?

LMAO OOP FAGS LITERALLY CAN'T IMAGINE A LANGUAGE THAT DOES THINGS FOR THEM

::holds up spork::

>auto myCar = new Car("Tesla", "Model X")

>How the hell does the language inherently know what should and shouldn't be cached?

user I heard a rumor that there exists languages CAPABLE OF MEMORY MANAGEMENT, I don't believes it

They are ironically the same fags that wank over GC.
OOP is a beautiful lie.

>How the hell does the language inherently know what should and shouldn't be cached?

Probably a compiler that tracks each object thats been called and finds out when its end point is.

Aka modern/sophisticated object manager.

Most design patterns are shit but how do you propose improving on Builder?

>2017
>using abstract classes

var car = "car";

:^)

There's far more than that:
>Because not every language supports optional arguments, so if there's tons of possible arguments it gets messy fast
>Because it's fail-fast. Rather than expecting the user to do all the necessary setThis() and setThat() calls before actually using the object, you can have the build() method throw an exception.

Python-style optional arguments.

Vehicle mustang = new Vehicle(Vehicle.Type.Car, Vehicle.Make.Ford, Vehicle.Make.Ford.Models.Mustang);

Car car("car");
Only good option.

>car_t* car = car_new();

>OP op = new Fag("OP");

auto car = Car();

Fuck you for reminding me this jahvah bullshit

Car car = new Car();
car.setBodyStyle(BodyStyle.CONVERTIBLE);
car.setEngineLayout(EngineLayout.INLINE_4);
car.setColor(Color.RED);
car.build();


FTFY?

>Non-static method cannot be referenced from a static context

@SuppressWarnings("unchecked")

What would be better is not having a shitty language that doesn't allow default parameters for a function or named parameters like Python.

car(sedan).
color(sedan, white).
has(sedan, engine, 1).
has(sedan, wheels, 4).
running(C) :- car(C), carkey(K), has(C, K, 1), turned(K).

Memetastic.

he is using the cache key builder pattern to reimplement something as simple as string formatting.

>pointers
>wild shit
Don't pick either. Just get out.

car car?
no.
bad car car.
is tiem 4 man car

I prefer this.

Although when it gets fucking ridiculous I think dependency injection is needed.

depenency injection is a fucking enterprise pajeet meme pal
explain how it could help in any way here?

new Car(BmwContext)

/thread

Once again, Sup Forums doesn't disappoint in revealing that they're all mostly unemployed with zero work experience as a programmer.

Yeah, no shit design patterns seem pretty stupid when you're shoe horning them into your dumbass hello world tier program.

Not only that, but if your takeaway from the GoF design patterns is that you're forced into modelling your problems with their design patterns 100% then the subtlety and nuance of that text has gone so far over your head it's beyond a joke.

Design patterns are a good conversation starter to think about the problem you're trying to solve. It describes a common approach to solving common tasks. If you're brainlet ass can't understand why this sort of approach to software development isn't useful in large organizations you're unemployable and just stick to ricing out your latest meme distro of the month.

>implying anybody on Sup Forums has read design patterns
what do you take us for

>"If you're brainlet ass"
Pottery

>using DI in a situation where a factory + inheritance doesn't result in a bloated Car class

create a list/array of set functions and then evaluate.

Button button = (Button)findViewById(R.id.button)

Carl carl = new Carl("carl");

val car = Car(make = "Tesla", model = "Roadster")

Car *car = [[Car alloc] initwithBodyStyle:@"Sedan"
numberOfWheels:4
engineType:@"V8"
color:@"Blue"
transmissionType:@"Manual"
];

>t. neet larping as employed

You would think otherwise if you ever worked in some non-wagecuck-tier position in your life

...

...

(cdr (cdr (cdr
...
))))))))

class Car:
__DEFAULT_MAKE = "Mazda"
__DEFAULT_MODEL = "MX-5"

def __init__(self, make, model):
self.__make = make if make is not None else Car._Car__DEFAULT_MAKE
self.__model = model if model is not None else Car._Car__DEFAULT_MODEL

def __str__(self):
retstr = ""
retstr += "Make: %s\n" % (self.__make,)
retstr += "Model: %s" % (self.__model,)
return retstr

def main():
print Car("Honda", "Accord")
return

if __name__ == "__main__":
main()

Wait, defaults don't work in that version. Fixed:

class Car:
__DEFAULT_MAKE = "Mazda"
__DEFAULT_MODEL = "MX-5"

def __init__(self, make=None, model=None):
self.__make = make if make is not None else Car._Car__DEFAULT_MAKE
self.__model = model if model is not None else Car._Car__DEFAULT_MODEL

def __str__(self):
retstr = ""
retstr += "Make: %s\n" % (self.__make,)
retstr += "Model: %s" % (self.__model,)
return retstr

def main():
print Car()
print Car("Honda", "Accord")
return

if __name__ == "__main__":
main()

that Hamster makes me salivate

car :: Car
car = Car "car"

This shit is why i like kwargs in python

What is this supposed to show?

>setting dependencies from outside the class being built ever.

Reee

struct Car car;
init_car(&car, "car");

Camera.main.transform.rotation = Quaternion.Euler(new Vector3(3.0f, 4.5f, 7f));

#include
#include

typedef struct
{
char* str;
} Car;

Car* Car_init(char* s)
{
Car* c = malloc(sizeof(c));

c->str = s;

return c;
}

int main()
{
Car* car = Car_init("car");

puts(car->str);

free(car);

return 0;
}

val car = Car {
bodyStyle = SEDAN,
engine = "V8",
driveTrain = true,
wheels = 4,
color = BLUE
};

I thought the same then I saw an example of a constructor that took up 400+ lines.

Car car = cdr(_car)

my $car = Car.new;

>Car car = AbstractCarFactoryBeanSingletonDecorator();

so this is the power of OOP...

lua is beautiful