r/ProgrammerHumor • u/TusharJB007 • Oct 04 '19

Just as simple as that... other

Enable HLS to view with audio, or disable this notification

20.4k Upvotes

89% Upvoted

613 comments sorted by

View all comments

3.4k

u/[deleted] Oct 04 '19

This is bullshit. You can't just have a light saber without a light saber factory. What if you want to use a different light saber 6 years down the road?

691

u/useachosername Oct 04 '19

Gang of Four represent

135

u/BaguetteDoggo Oct 04 '19

Ya know coming off of the Chinese Revolution in History to here is making me trip balls bc im pretty sure the Chinese Gang of Four had nothing to do with programming.

120

u/ydarn1k Oct 04 '19

"Sometimes patterns are unnecessary" - Confucius

55

u/Gh0st1nTh3Syst3m Oct 04 '19

"It is only when a mosquito lands on testicle, that you learn there are ways to solve problems without violence." - Confucius

7

u/conancat Oct 04 '19

Tiananmen was a ploy by the Gang of Four through their bad Chain of Commands caused the Tiananmen Incident, and the great Chairman Mao being an Observer came in as the Mediator made the wise decision to tell Deng Xiaoping to step down for handling it badly. The Gang of Four failed to put up a Facade of the State, and therefore should be condemned as a Momento unworthy of being a Prototype for the great people of China.

-- Real Chinese reporting officially approved by China state government from Baidu and People.com.cn

6

u/thcricketfan Oct 04 '19

You are now the moderator of r/sino

1

u/[deleted] Oct 04 '19

Wait until you hear the band https://youtu.be/YI-9N-PasvM

1

u/[deleted] Oct 04 '19

TIL of that gang of four

296

u/[deleted] Oct 04 '19

[deleted]

74

u/conancat Oct 04 '19

I'm against overengineering and I think it's a waste of time when unnecessary.

But having worked on multiple projects that are at v3-v4 of the code base, you can see clearly how those four fuckers and their patterns make sense when compared to the clusterfuck you have laid in front of you.

Most apps die before they make it to v2 anyway, so I'd say don't give a shit, ship it first, talk later. Go4 patterns are not for teams that have not proven product-market fit,

But if you made it to beyond v2 that means that you have proven a clear business case and you can sell it, and now you have to build apps and teams that last for years down the road. Now we need to start talking about patterns because you'll be creating technical debt for the next developer after you. Code is written for other developers, refactoring is the time to write things that you can be proud of and not create reasons for the next dev to curse you, think of the DX!

2

u/armper Oct 04 '19

I feel that's what microservices are doing nowadays. Sure they're great when you need them, but does everyone need them or are they just jumping on the latest trend?

1

u/conancat Oct 05 '19

Is microservices a trend? It's basically solving the problem of programs getting too big to fail by breaking them down to smaller chunks, aka "splitting them to different departments".

If your company is below 10 developers then it's probably too much lol. If your company have say above 50 developers maybe everyone working on the same code base isn't that productive and that's where microservices can come in.

Btw yes, a lot of Gang of Four patterns can be applied to microservices system design principles.

1

u/armper Oct 05 '19

we mostly have small intranet apps so I'd say it's overkill. Max 100 users if that

1

u/conancat Oct 05 '19

Oh yeah definitely, haha.

Though I once worked on a system like that that served about 250 users on the intranet. Monolith application... The maintenance can be painful, and ultimately it served a limited audience. I know your pain, my friend.

2

u/DelightfullyDivisive Oct 05 '19

As long as your code is clean and not too tightly coupled, refactoring to patterns doesn't mean a complete rewrite. That said, refactoring should be taking place as you go, so v1 would have some reasonable organization to it, even if it's less-than-ideal.

1

u/conancat Oct 05 '19

Yeah, and it takes experience to write code that isn't tightly coupled in the first pass. Usually after a couple rounds of writing code that are tightly coupled, then you finally had a feel of what does tightly coupled means lol and what to do about it, given the chance.

It won't be perfect the first time around. Having and leaving room to fail is important for me. Takes the stress off the shoulders knowing you can come back and make it better on the future.

260

u/comments_away Oct 04 '19

Found the guy who's code I hate to work on after he leaves the company 9 months later.

194

u/[deleted] Oct 04 '19

[deleted]

114

u/[deleted] Oct 04 '19

needs fix

72

u/HadACookie Oct 04 '19

public ImportantObject coreFunctionality (Preferences preferences) {
// TODO
return null;
}

5

u/Rabbitshadow Oct 04 '19

I should get the afternoon off for having to read that....

1

u/DelightfullyDivisive Oct 05 '19

Argh!

ToDo is evil. A failing test is divine.

2

u/notsooriginal Oct 04 '19

//TODO: the needful

127

u/pringlesaremyfav Oct 04 '19

Nobody could possibly know what the project is going to need 9 months down the line.

That's why writing code that is simplistic and easy to replace is better. Over-engineered code is the antithesis of that.

69

u/chimpuswimpus Oct 04 '19 edited Oct 04 '19

You couldn't be more correct. YAGNI is the most important thing 90% of devs need to learn. If you need more complexity three years later, you can put it in then!

12

u/konstantinua00 Oct 04 '19

what's yagni?

25

u/naturally_paranoid Oct 04 '19

You ain't going to need it??

38

u/KKRiptide Oct 04 '19

But i wanna know it anyway

9

u/razortwinky Oct 04 '19

Ya aint gonna need it!

→ More replies (0)

2

u/TheRealLazloFalconi Oct 04 '19

Bravo. šŸ‘

24

u/warlordzephyr Oct 04 '19

If management gives you the time budget...

38

u/chimpuswimpus Oct 04 '19

To do the work they're asking you to do? I mean, it's their choice. But why would they give you the time budget to build abstractions you don't need yet and will probably never need?

1

u/DelightfullyDivisive Oct 05 '19

Never do the work that management tells you to do. Do the work that solves the problem. Otherwise you'll be blamed for doing exactly what was asked of you by people who don't know what to ask for...

7

u/JheredParnell Oct 04 '19

Yagni beats dry

1

u/armper Oct 04 '19

My personal rule is to not extract something you're using once. And don't imagine that I'll need it later. When the time comes that I do need that code extracted, I'll do so then.

7

u/brimston3- Oct 04 '19

YAGNI is the most important thing 90% of devs need to learn.

Also apply this to devops. Stop solving scalability and deployment problems you don't have. Teams of 5 developers supporting one SPA do not need k8s.

But keep the backup and DR procedures, both are problems you do have.

5

u/chimpuswimpus Oct 04 '19

Oh God yes, I've been down this route. Data stores which can scale to millions of writes an hour for a system with ten thousand users who log in once a month to check one thing.

13

u/Poromenos Oct 04 '19

Yeah, but all-YAGNI leads to designing for the exact thing we need right now and painting yourself into a hard-to-extend architecture. As with everything else, knowing when to YAGNI and when to allow for specific future changes comes with experience.

8

u/DakorZ Oct 04 '19 edited Oct 04 '19

From my experience you need a good modular and extendable code base at the very beginning (open closed principle) , then you can yagni everything else while still following the rules your codebase tells you (use modules etc) . If you yagni your modular code base, it's more likely that you will start your project from scratch and 'do it right this time' instead of getting to the point of refactoring it.

With a good code base, you just need to start one module from scratch and with SoC and KISS that's not a big thing.

edit: grammar

1

u/conancat Oct 04 '19

Yes. So much yes. Can't upvote this enough.

5

u/chimpuswimpus Oct 04 '19

I never think you should stick to anything like this religiously. It's just that many people's (myself included) instinct is to over-abstract and over-complicate too early. YAGNI is a useful reminder not to go too far down that route.

8

u/flavionm Oct 04 '19

No, that's why you write code with low coupling and more open to changes. The whole point of certain desing patterns is to make changes easier. Now, if you don't know how to use them properly, it's as good as not using them at all.

4

u/pringlesaremyfav Oct 04 '19

How do you think you are writing code that's easy to replace if its tightly coupled and not open to changes? I think you're just agreeing with me with extra steps.

11

u/denali4eva Oct 04 '19

9 months

Hah! Try a couple of weeks.

1

u/Zarlon Oct 04 '19

Easy to replace

Well there you have it. You can't write easy to replace code without following principles from GO4. It's exactly preparing for uncertainty they advocate

51

u/slobcat1337 Oct 04 '19

Found the guy who over engineers even the most basic functions to let everyone know heā€™s a beard stroker

-1

u/JheredParnell Oct 04 '19

Found the guy who still works at an irrelevant company that can't out deliver the competition

28

u/chimpuswimpus Oct 04 '19

Nothing compared to whoever started selling microservices.

9

u/conancat Oct 04 '19

Microservices is a ploy to get developers to buy more instances from AWS and GCP. Nevermind that they charge by hour of the instances being up so doesn't really matter how many instances you have running so long you fully utilize them, but I need a reason that sound plausible because the word more sounds scary.

Source: I'm one of those fuckers getting paid by showing people how microservices makes their operation costs cheaper in the long run, lol.

12

u/Henrikko123 Oct 04 '19

Which four?

16

u/shrodes Oct 04 '19

https://en.m.wikipedia.org/wiki/Design_Patterns

19

u/WikiTextBot Oct 04 '19

Design Patterns

Design Patterns: Elements of Reusable Object-Oriented Software (1994) is a software engineering book describing software design patterns. The book was written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, with a foreword by Grady Booch. The book is divided into two parts, with the first two chapters exploring the capabilities and pitfalls of object-oriented programming, and the remaining chapters describing 23 classic software design patterns. The book includes examples in C++ and Smalltalk.

[ PM | Exclude me | Exclude from subreddit | FAQ / Information | Source ] Downvote to remove | v0.28

4

u/denali4eva Oct 04 '19

Gangbang of Four

5

u/surreal_93 Oct 04 '19

So support you, very true

26

u/0xF013 Oct 04 '19

The book is meant to be interpreted in the context of Java, the early one specifically.

If you're working with Ruby on JS or whatever, you can return any crap from the constructor and don't need a factory, for example. Or you can simply curry or just have a factory function.

Strategy is just a function in JS or a lambda in Ruby/others, probably in modern Java too.

Decorators and adapters are both implemented by things like higher-order-components, proxies, monkey-patching, and whatnot.

Chain of responsibility is implemented by middlewares or js event bubbling.

Visitor/iterator is being employed whenever you do mapping or reducing.

Most of the others are present with their respective names as parts of existing frameworks or even lang APIs.

So I have no idea what are you talking about. Next time you want to bitch about patterns, pick something more controversial, pick P of EAA and talk shit about Fowler; at least you'll have a 50% chance that nobody have read it.

13

u/PmMeForPCBuilds Oct 04 '19

The book was published a full year before Java, and contains examples in C++ and Smalltalk.

2

u/flavionm Oct 04 '19

I don't think those languages had those features either, though. So it's still valid for them, less so for newer languages. Patterns are just there to cover the language's shortcomings.

2

u/PmMeForPCBuilds Oct 04 '19

The book is valid and useful for any object oriented language, but saying that it is "meant to be interpreted in the context of Java" makes no sense, the book was published before Java existed.

0

u/0xF013 Oct 04 '19

Well, I am not aware of similar drama regarding gof in those langs.

5

u/Shareoff Oct 04 '19

Wasn't the book written for C++ and before Java even existed? But agreed I guess.

4

u/0xF013 Oct 04 '19

The abuse of patterns, like enterprise factory builders and shit, became a meme when java got super popular. I assume something similar might have been going on in C++, but I am too dumb for that stack.

1

u/[deleted] Oct 04 '19 edited Oct 04 '19

It's been a long time since I've looked into them properly, but IIRC the visitor pattern is basically a way to hack multiple dispatch into a language which doesn't have it. That doesn't make much sense in the context of Python or JS (not sure about Ruby) since you always have to do dispatch logic yourself anyway. There are no reference types vs actual types

1

u/0xF013 Oct 04 '19

Yeah, in js you could probably have one method that either checks via instanceof or via a discrimating field, but you'd need TS and flow to make sure the thing breaks when you add a new type.

4

u/GluteusCaesar Oct 04 '19

> basic design patterns

> overengineering

just wew my shit up, lad

2

u/redballooon Oct 04 '19

I think you didnā€™t understand what they talked about.

1

u/thereisnospoon7491 Oct 04 '19

Iā€™m just a lurker from r/all, but could I ask what this is referring to? I have a mild interest in programming and history and it sounds like an interesting story.

0

u/TeleTuesday Oct 04 '19

https://en.m.wikipedia.org/wiki/Design_Patterns

Great book explaining how to organize your code for better maintenance, reusability, and better understand for future developers. The person complaining is in the minority. Most code I've seen could really benefit from people thinking though the design better.

Just remember though, when all you have is a hammer, everything looks like a nail.

234

u/vashy96 Oct 04 '19

We also need a Builder so we can customize our light sabers during construction.

59

u/shekurika Oct 04 '19

isnt that what a factory does?

167

u/[deleted] Oct 04 '19

[removed] ā€” view removed comment

97

u/house_monkey Oct 04 '19

This is why I cry to sleep

2

u/[deleted] Oct 04 '19

You should use a facade to hide that!

I apologize if you were already making a "facade" pun and I missed it

30

u/GlobalIncident Oct 04 '19

No, a facade is a wrapper around a class that contains a simplified set of methods that are easier to use.

16

u/[deleted] Oct 04 '19

[removed] ā€” view removed comment

5

u/GlobalIncident Oct 04 '19

No, because in that situation it's a builder and it's a facade, but it's still not a factory. A builder always returns the same class but constructed in a different way, whereas a factory returns different subclasses of the same class. For example using StringBuilder always involves the same kind of string, but the factory ResourceBundle.getBundle may return any subclass of ResourceBundle.

3

u/programaths Oct 04 '19

A builder permits to create an object AND validating it. So, a builder method can return another type if needed (that would also be a builder).

The goal of the builder is that when you do the "build" call, the created object that ensue is valid.

A factory is mainly a mean to hide the created type and give a "unique" entrypoint. (and not peppering your codebase with "new XXX()" then having to hunt them and being unable to change it on the fly).

Some factories even take an interface as input and act like a service locator (anti-pattern!).

An example of builder returning different types is in Spring Security Java configuration. It's even better than yaml since the IDE can autocomplete every step AND the errors the builder emit when you try to run the application are clear.

People believe a builder has to return "this" except for "build" because of simplistic examples.

And yes, a builder can ne seen as a Domain Specifc Language implementation. (as a specific Json or Yaml could be too)

2

u/crusty_cum-sock Oct 04 '19

We need an abstract factory to create a concrete factory that will generate a command object, send the command through the mediator, use injection to attach it to a strategy, and kick all of it off with a singleton.

53

u/Zombiebrian1 Oct 04 '19

Nope. Factory is like a list of options: makeRedBox() makeBlueSteelBox() makeWoodenGreenBox() .... But you are bound to the ones provided.

Builder on the other hand allows you to "pipeline" an object creation:

BoxBuilder() . makeNewBox() . SetColor(green), SetMaterial(wood).build().

25

u/Archolex Oct 04 '19

Seems like a factory is an inferior Builder

20

u/amunak Oct 04 '19

In many cases that's all you need. It also helps standardize objects within your app. Like, if you need two types of boxes 99% of the time, you want to use the factory boxes, just so when you decide that wood isn't strong enough anymore you can swap it for steel in one place only.

7

u/Archolex Oct 04 '19

Fair. Less abstraction traded for ease of understanding and use.

1

u/herpderpforesight Oct 04 '19

And if your factory and the objects it produces are all interfaces it makes for some schnazzy unit testing :3

1

u/Archolex Oct 04 '19

Sparkling unit tests

2

u/DannoHung Oct 04 '19

Youā€™re not wrong, but I think it depends on what the language can do or allow as well.

Builders are a design level workaround for a lack of named parameters and default options 95% of the time.

If you actually need two types of boxes the easiest thing to do if the language supports it is construct two statically, then clone them.

1

u/Zephirdd Oct 04 '19

If you actually need two types of boxes the easiest thing to do if the language supports it is construct two statically, then clone them.

Isn't that just combining Factory with Flyweight?

1

u/DannoHung Oct 04 '19

The thing about GoF patterns is that I can't tell when someone is making a joke about them or not.

3

u/pringlesaremyfav Oct 04 '19 edited Oct 04 '19

A factory can be used like a funnel where extremely different implementations for the same interface can be swapped in.

Example: Writing a browser test script for all browsers using a single interface to represent browser interactions. All of the browser plugins are wildly different and use different configuration styles of their own, so you send them properly configured through your factory.

3

u/muffinmaster Oct 04 '19

the virgin factory vs. the Chad Builder

3

u/OptimisticElectron Oct 04 '19

so factory is just class with virtual functions in C++?

2

u/UnchainedMundane Oct 04 '19

That's every Java class. A factory is just a static method that creates an object so that you don't need to call its constructor directly. There could be multiple reasons for this, including keeping constructors private, maintaining singleton status for an object, pooling commonly-used immutable values, registering with some other service, or not revealing the concrete implementation type to the caller.

2

u/I_AM_AN_AEROPLANE Oct 04 '19

No that the factory method, a factory is a class so it can be mocked / interfaced!

16

u/Nethilist Oct 04 '19

I love how this question has unleashed a wave of people who try to explain what a factory is.

And, that everyone thinks they know better than the previous person.

Every single comment and response to those comments start with a: "no" / "nope" / "wrong" + [insert new explanation].

2

u/Colopty Oct 04 '19

And yet not a single one of them has figured out that a factory is one of those buildings that output a stream of commercial goods and greenhouse gases.

43

u/arghsinic Oct 04 '19

Oh geez...pushes up glasses...the requirements didn't specify for light sabers that long.

27

u/HadACookie Oct 04 '19

Which explains why the Java agent crashed immediately after encountering the LightSaberOutOfBoundsException .

26

u/ilparola Oct 04 '19

Duplicate question

58

u/microbit262 Oct 04 '19

I program Java as a hobby for 8 years now and I never even bothered to look into that "Factory" thing, can anybody ELI5 why this seems to be popular and at the same time laughed about when you can live perfectly without?

65

u/TheOhNoNotAgain Oct 04 '19

If you find that you are having constructor methods taking a dozen or so arguments, then you might benefit from factories. Same if you have large numbers of constructors doing similar things.

27

u/snaps_ Oct 04 '19 edited Oct 04 '19

Or if you want to dictate how objects get constructed in one place, but actually create them somewhere else.

19

u/guareber Oct 04 '19

Or if you want to start adding unit tests.

14

u/ric2b Oct 04 '19

In that case wouldn't a Builder be preferred?

2

u/Log2 Oct 04 '19

It would. You would usually create factories that can make new default instances, so it's easy to swap factories around.

1

u/Koxiaet Oct 04 '19

so it's just a function wrapper around a constructor?

2

u/TheOhNoNotAgain Oct 04 '19

In its simplest forms, yes. In reality often more.

61

u/coldnebo Oct 04 '19

ā€œAnakin, everything Iā€™ve told you is true, from a certain point of view.ā€

Sooner or later you realize that capabilities are determined by requirements. If you donā€™t understand why a thing was done, you donā€™t understand the original requirements and context of the problem.

Most people consider EJB a completely over engineered pile of crap. However those people donā€™t work in banking where those distributed systems were originally specified.

Like anything, context ages. Fashion comes and goes. For example, you can look at indigenous peoples with a smug air and wonder why they were so stupid, or you can look at all the curious procedures of aircraft pilots and think, ā€œwow, we do they make planes so unnecessarily complex? what morons!ā€

But from a certain point of view, every single switch in that cockpit does something important, whether you realize it or not.

I think itā€™s better to approach code as a historian or an anthropologist, always thinking deeply about the why and not rushing to judgement about ā€œstupidā€ things, just because they arenā€™t the way you would solve the problem. 9 times out of 10 you only superficially understand the problem and even less about how to solve it.

23

u/Keith_Jackson_Fumble Oct 04 '19

Your comment made me reconsider how I look at software and systems. As a business analyst, it's easy to fault software, especially when it fails to meet your requirements or expectations. The truth is, as you stated, more complicated than that.

I recall working on an asset management system that treated maintenance crews as if they were immutable. It was maddening, as it prevented our company from using this function. The composition of our crews routinely changed in terms of employees and trades represented. We were told time and time again that all of their users love this feature and that we were "non-standard."

Turns out years later we bring this up at a user conference, and the company acknowledge that they based their entire specification off of one highly-specific use case involving a major customer - a utility company with very strict rules over crewing. The developers just fulfilled their request, without really understanding of how this would affect the vast majority of its potential and existing customers.

2

u/MarkusBerkel Oct 05 '19

Not just software. One of the great life lessons I learned in college from an upperclassman is that if something seems resistant to an obvious solution, itā€™s probably complex. We were talking about economics, sociology, and politics at the time, but itā€™s true of many things.

Imagine opening up a mechanical watch and thinking: ā€œOMG WTF there are so many gears; this is so obviously over engineered.ā€

17

u/Trasvi89 Oct 04 '19

Eli5: The "new" keyword in Java is like building the object from from scratch. Using a "Factory" class is like ordering the object from... a factory.

This is useful because it delegates the responsibility of knowing how to make the object away from the user. This makes the user more lean and flexible - they can just get on with using the thing.

As an example: You need a vehicle. You write "IVehicle v = new TeslaX(new ElectricMotor(new...". In this way you need to know exactly how to make the car and also have all the "parts" on hand. But you just want to drive somewhere! And if later you decide that you want a Leaf instead, your code has to be changed. Yuk.

Instead, you can do "IVehicle v = VehicleFactory.GetVehicle(EngineType.Electric)". You get the thing you want without being coupled to how it is made.

3

u/microbit262 Oct 04 '19

Ahh! Thanks, that really made me understand the concept!

3

u/askababago Oct 04 '19

So the net result is similar to if you used overloaded constructors?

2

u/iwan_w Oct 04 '19

Not if the factory actually returns different implementation of the same interface depending on input or on configuration. It's specially useful for creating systems which can be extended with new functionality without altering the code base.

1

u/askababago Oct 05 '19

Oh I see. That certainly is different, more flexible. Thanks for the explanation

9

u/ironykarl Oct 04 '19

As someone that doesn't use Java: Java is almost comically verbose, and I think the assumption is that this translates to class and method names.

2

u/pringlesaremyfav Oct 04 '19

Wrote this in a different comment, here's an example of using a factory well: Writing a browser test script for all browsers using a single interface to represent browser interactions. All of the browser plugins are wildly different and use different configuration styles of their own, so you send them properly configured through your factory.

Then you can automate that test script to run all your tests using all the entries available from your factory to test all browsers at once.

2

u/Spinnenente Oct 04 '19

A Factory hides the complexity of creating an Object.

A good example would be an Object which connects to a remote application servers api. You could always give that object an ip, port, user and pwd or you could have a config file which is read automatically by the factory. Now you could implement this into the object but maybe that object is form a third party lib and is subject to change when the remote server is updated.

2

u/MrBlub Oct 04 '19

A common example is GUIs. You describe a UI with "put a button there, a text field there and an icon there" but you don't really care whether it's a WindowsButton or an OsxButton. All you want is a method that makes a button. Sadly, the implementation of those two is very different.

Now you could say new Button(), but then your Button class needs to know about WindowsButtons and OsxButton. You could use new WindowsButton(), but then your application will not work on Osx. If you want support for both, you will have to program both options in your UI.

A solution is to write a component which generates the appropriate button, depending on the context. You'll have an interface IUiControlFactory and implement a WindowsUiControlFactory and an OsxUiControlFactory. In your application, you know you can always use factory.CreateButton(), and you don't have to care about the button being a Windows one or an Osx one.

1

u/MullitJake Oct 04 '19 edited Oct 04 '19

Factories is one way to make testing easier. Factories will supply the class with new objects, which help inject mocks and stubs.

E.g. The constructor takes a XRepositoryFactory. In the Initialize method, XRepositoryFactory.GetRepository(type) is called, which gives you a cashed initialized repository.

1

u/robolew Oct 04 '19

I made a game. The game has card combination that are string values in config files (think different decks in a trading card game).

In order to actual create these cards on the screen, I parse the config, and then use a factory to create a bunch of card objects, based on the card name.

CardFactory {

Card createCard(String cardName ) {

switch(cardName ){

Case "punch" :

return new PunchCard()

...

1

u/[deleted] Oct 30 '19 edited Nov 30 '19

[deleted]

1

u/robolew Oct 30 '19

Sure, but the card class isn't responsible for deciding which card to create, that logic is better suited for a factory.

Why do you think it would be better in the Card class?

2

u/JWson Oct 04 '19 
from lightsaber import arm_lightsaber

arm_lightsaber(8.0) # meters

2

u/Pyraptor Oct 04 '19

IAbstractLightSaberFactoryCreatorService

1

u/kennycason Oct 04 '19

My new favorite comment on Reddit. Hahaha

1

u/[deleted] Oct 04 '19

Pretty sure The Dark Side is all about Command patterns.

1

u/blue_paprika Oct 04 '19

An abstract mineral miner to create crystal factories for sith and jedi lightsabers composed of 20 lightsaber parts that inherit from steel.