• (nodebb)

    Not only he doesn't understand object oriented programming, he apparently doesn't understand functional programming, either.

    In fact, he looks like he doesn't understand programming at all.

  • Registered (unregistered)

    He's actually pioneering Dis-functional programming

  • GreatGobo (unregistered) in reply to Mr. TA

    I must admit, that I have serious problems even reading the code...

    There are two references to Url (uppercase U) and I have no idea where they are coming from or what it is supposed to mean. Help...

  • Jonathan (unregistered)

    This is a typed string concept where the idea is that it’s less likely to accidentally populate the incorrect string value between types.

    We tied this on a C# project about 10 years ago and although it helped avoid a certain class of mistake, overall it didn’t really feel worth it.

    It might be nice if C# had this as a more first class feature, but until then it’s too much of a pain.

  • Hanzito (unregistered)

    Does the extract function use a global? Or in seniorese: the singleton factory pattern?

  • OM222O (unregistered)

    Poor Remy ... "a private member with no accessors"? "It doesn't use the UrlHolder, because of course it couldn't"? TRWTF is Java reflections because you can easily get, set and modify private variables with reflections and stringly typed field names :) The even more RWTF is the Java standard library and things like sun.misc.unsafe which are by design meant to be used only with reflections :) Below code is not a joke, it is how you use most built in libraries in Java (such as sun.misc.unsafe, java.security.MessageDigest, etc.)

    Field f = Unsafe.class.getDeclaredField("theUnsafe"); f.setAccessible(true); unsafe = (Unsafe) f.get(null);

  • (nodebb) 
    // does reading a local file satisfy the definition of "download"?
// a book contains lots of pages, so we have our bases covered there!
String s = File.readAllText("c:\\Shakespeare_Hamlet.txt"); 

// if you think the below class instance holds a URL,
UrlDownloader ud = new UrlDownloader("http/::this can be a URL, or [email protected]");
// then you are wrong!
ud.downloadPage = s;

UrlLinkExtractor ule = new UrlLinkExtractor (ud);
String[] extractedLinks = ule.extract();
// result: "Ophelia, by some critics, can be seen as honest and fair; 
// however, it is virtually impossible to link these two traits, since 'fairness' 
// is an outward trait, while 'honesty' is an inward trait."
  • (nodebb)

    If these are inner classes (which they appear to be), you can access private members without doing anything special like reflection, so UrlHolder isn't useless. This compiles and runs perfectly fine:

    public class Test {
	public static void main(String[] args) {
		new Test().foo();
	}

	void foo() {
		UrlHolder holder = new UrlHolder("www.example.com");
		System.out.println(holder.url);
	}
	
	class UrlHolder {
		private String url;
		
		public UrlHolder(String url) {
			this.url = url;
		}
	}
}

    It's still a WTF if they don't actually use the UrlHolder's value though.

  • Willy (unregistered) in reply to OM222O

    you must be more "senior" than me because in 20 years I have never had to call a built in library this way

  • Naomi (unregistered) in reply to OM222O

    Er... Unsafe is used internally by the runtime. "By design", it isn't "meant to be used" at all, unless you're the runtime. Certain library authors have found that it's useful in certain highly specific reflective tasks, but they're knowingly using a highly internal implementation detail in an unsanctioned way. Newer versions of Java have introduced proper APIs for the functionality formerly provided by Unsafe.

    You're correct that reflection can be used to bypass access constraints. This is generally regarded as a bad idea in most cases, but has one really useful, er, use: a reflective library can provide a mechanism for a class to register a member with the library without making it part of the class's API. (This typically happens with default constructors.) Like everything in software, it's a tradeoff: it can be used to do terribly unsafe things, but I don't see that as a reason to prevent it entirely. Hell, even C++ has a standards-compliant template hack to access private members (and no, I don't mean #define public private).

  • (nodebb) in reply to Jonathan

    @Johnathan: So a very verbose form of Apps Hungarian. But with partial compile-time enforcement of correct usage.

    You can get from partial to total as long as you wrap every property and method parameter of every object in every API you use. Sounds ... laborious.

    Addendum 2024-11-18 11:06: I imagine the same effort spent on unit tests instead would produce far better software.

  • MRAB (unregistered) in reply to Registered

    No, it's Objectionable Programming.

  • (nodebb)

    Um. Java does have a URL/URI class that wouldn't just verify that you're actually using a URL and not a poem. It also already is a class, so...

    This reminds me of when I as 12 and programmed Pascal... or wait, it didn't have objects until a few years later... well, it reminds me of a 12-year-old anyway. Not really having a plan or an idea...

  • Naomi (unregistered) in reply to Jonathan

    Java and C# can both use records for this purpose.

  • Naomi (unregistered) in reply to WTFGuy

    That's one way to look at it, but it can be so much more. Here's a practical example. My day job involves working with phone numbers a lot, and we integrate with a ton of different APIs, so we get phone numbers in a ton of different formats. If we pass them around as Strings, we can inadvertently use, say, an email address... and, also, different ways of formatting the same phone number aren't considered equal, which directly lead to a serious bug in our SMS opt-out logic that could have put us on the hook for massive fines if we hadn't caught it as quickly as we did. Now, we have a PhoneNumber class that internally normalizes the number, and there's no way for different formats to screw us over like that.

  • (nodebb) in reply to Jonathan

    To be fair, this works in C# in principle because it has value types. In Java this results in basically writing an app that uses up most of it's performance in GC :-)

    While I personally never were a fan of magic strings, you have to remember that C# is a way more advanced language. With real enums, nameof and extensions there was never really a need for even create stack objects to avoid boxing and allocations and often it is simply a fact that someone was sloppy and didn't make a proper service with strings floating around in the while. So I think by modern standards we can be pretty magic string free in C# land without any performance costs expect where they actually make sense.

  • LVSA (unregistered)

    As someone who mainly programs in Java and has a total of 0 years of professional experience - this is more horrifying than my terrible Java Swing calendar project for uni.

  • mdhughes (unregistered)

    You also just don't need this, it exists in the JDK:

    import java.io.; import java.net.;

    public class UrlGetter {

    public static void main(String[] args) throws Exception { InputStream in = (InputStream)new URL(args[0]).getContent(); byte[] data = in.readAllBytes(); System.out.println( new String(data) ); }

    }

  • LZ79LRU (unregistered) in reply to LVSA

    As someone very old indeed who has been programming since before Java was a thing I envy your youthful ignorance.

    Some may consider it a flaw. A weakness to be corrected or an obstacle to be overcome on your path to carrier success. And indeed, you can and should seek to learn. If for no other reason than because it is enjoyable to do so. But do not rush too fondly toward the fountain of knowledge and experience. For within lies both the ambrosia of excellence and the dark, horrific bile of realcode.

    And I speak not of bugs here, my lad. Not of errors made by developers past who were too dumb or inept to do things correctly. Nor do I speak of the evils wrought upon the working classes by ignorant managers who demand the impossible. Although thau shalt undoubtedly see a lot of both.

    What I speak of is code. Good working code. Code that does its duty solemnly and correctly in all ways in which it was intended. But code which nonetheless was constructed by means arcane and for purposes eldritch. Code which in both its excellence of function and madness of form exceeds that which mortal minds are meant to grasp. Code that will bend your mind over like a young boy at a church convention. Code that will break you, and exhaust you. Code which will rob your days of their luster and your nights of their dreams.

    So whilst I shall be the last to tell you learn not or experience not. For those are things of much good. I must also deliver a warning. Enjoy the bliss of youth and the fruits of ignorance. For knowledge, once claimed can not be given back. And all good things come with an equal price.

  • (nodebb)

    @Naomi. Agree completely that significant or high-touch business objects should have actual classes representing them, even if at bottom the guts of the object could be naturally expressed as a single string or even int. For reasons of normalization, validation, limiting or controlling range and manners of mutability, etc. All good stuff. Your phoneNumber class is an excellent example of that.

    Since v1.1 (practically speaking the very beginning) .NET has had a Uri class in one of its most foundational namespaces to wrap and parse and build URis, including those that are URLs. Because they aren't trivial format-free arbitrary strings of code points.

    OTOH, one can wrap most every string just because you can. Or because your boss has a fetish for it. Or because your devs don't know the OM/API they're working with and use strings or roll their own wrappers rather than using the built-in stuff already available to them.

  • Adam (unregistered)

    Nah, this code is absolutely SOLID.

  • Harre (unregistered)

    So you are saying that not all Java code looks like this?

Leave a comment on “Objectified”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article