Hacker News Reader

I get what he's trying to say. I think he expresses it very unclearly. I'll try to elucidate the main idea in an example:

If I give a programmer a task. His task is to create an api that can email someone a message with a subject and tell me whether the message is successfully sent. All I need is this:

    func email(address: str, subject: str, message: str) -> bool

I do not need this:

    Class Email(AddressObject, SubjectObject, MessageObject, ConfigObject, ClientObject).send_mail()

The definition of the Email object vs the email function is about 10x more complex with little benefit. The send_mail method is virtually IDENTICAL to the email function, the objects and patterns you are building are just extra cruft you are layering around the email method. Not to mention you literally have to define 5 extra objects as well. It's obvious to me that most of the code is 100% cruft yet why does everyone who is knee deep in design patterns gravitate towards that Email object? I look at Email object and I think: I get what you're doing, but WHY.. what is the point? Are people really unable to see why this abstraction is unneeded?

Some clown once told me dependency injection (The example object pattern above) helps with unit testing. I agree. Literally, the Email object has 5 extra objects that need to be unit tested so more unit tests!. More lines of code = more unit tests = a better program... In all seriousness, the core method is send_mail and that cannot be unit tested because it's IO. Everything you build around that method is extra BS that only needs to be tested because you made it exist.

Sometimes it baffles me how people just start using design patterns everywhere. I think what's going on is that people reach this cathartic state when they understand a new mind bending concept. Dependency Injection is a bit of mind bender, and this catharsis people feel when they reach a point of understanding blinds them from the downsides of patterns in general. Actually dependency injection is a stupidly simple concept, it's the word "dependency injection" that adds artificial complexity to the concept by making it sound cool and harder to understand.

View on HN

// returns group filters List<Filters> getFilters(); List<User> getMembers(); // returns all recipients after applying group and // individual recipient filters List<User> getRecipients(Email);

User : NamedTuple[user: str, email: str, group: str] func anExampleFilterFunction(any_Tuple_including_User: NamedTuple[str,...]) -> bool func filterByAFunction(iterable: List[NamedTuple[str,...]], filter_func: func) -> List[NamedTuple[str,...]] func getValuesFromTupleByName(name: str, List[NamedTuple[str,..]]) -> List[str] func sendEmails(email_list: List[str], msg: str, subject: str)

//a, b, c are different filter functions. filteredUsers: User = filterByAFunction(filterByAFunction(filterByAFunction(x, a), b), c) //or filterdUsers: User = filterByAFunction(x, func(y){ return a(y) && b(y) && c(y)})